The difference between evaluating open source and commercial software is that in open source it is all up to you. Nobody teaches you how the product works. No experts call to explain everything. No whitepapers provide summaries of features and functionality. Nobody buys you lunch. You have to spend time gathering information and understanding the software. In other words, evaluating open source thoroughly enough to reduce risk is real work.
This chapter is a guide to doing that work.
Measuring the maturity of any software, commercial or open source, is far more an art than a science. This chapter will focus on the specific elements of an open source project, and those elements will serve as a guide to determining its maturity. Maturity, for the purposes of this chapter, is an indicator not only of age, but also of various dimensions of quality. It is also a proxy for the question, How much work is really required to use this software?
If some of the key elements of maturity are lacking—if information is difficult to find, if code is poorly structured and difficult to read, if forums are inactive and documentation is scant, if the project in general is of low quality—it translates into more work for those who would use the software. Problems will be hard to address. Help will be hard to find. Customization and configuration will be difficult. If the elements of maturity are present, the software will be much easier to use.
As the last chapter illustrated, most software, commercial or otherwise, exists in the gray area between mature and ill-formed. Almost every potentially valuable program also comes with significant drawbacks. The key to the successful deployment of software of any kind is to understand how the software will provide value and how you will avoid or compensate for the drawbacks inherent in using the software. The larger picture of whether a particular open source project will work for a particular purpose goes beyond issues of maturity, of course. Determining how the software will be used, who will be using it, and what it will fully cost are important factors that must be taken into account.
The purpose of this chapter, and the two that follow, is to lay out a comprehensive program to help you avoid the most common mistakes IT departments make when they decide to use open source software.
This chapter begins with a look at the traps an IT department can fall into if it does not take a comprehensive approach to evaluating open source, followed by a discussion of the elements of an open source project that determine maturity. The chapter ends with the formulation of an Open Source Maturity model that will be used later in the book to evaluate the open source projects in the chapters on specific areas of interest to IT departments.
All of the open source traps we identify in this section can be avoided if careful research and sober thinking of the type described in this and the following two chapters precede commitment to the use of open source. Let’s face it: many IT departments gravitate toward open source without adequately considering the issues involved, simply because it is exciting. It represents an interesting opportunity for the technologist and a way to save money for the business. The pitfalls outlined in this section occur because of overconfidence on the part of technologists, lack of due diligence, and poor communication.
Getting burned while selecting open source is usually the result of mistakes made in one of these broad categories:
It requires more work than expected.
It does not work well with existing systems.
It is harder to extend than anticipated.
Getting answers from the open source development team is impossible.
The good news is that most of the time it is easy to determine in advance whether these problems are likely to occur. And even if they are unavoidable, there is no barrier to overcoming them. Figuring out what an open source program does, and fixing it, is always possible.
The danger lies in rushing into using an open source program just because it is easy to get something running. Avoiding traps requires discipline. Here are six common ways of getting burned:
Selecting a product that is ill-suited for the technical skill set of the people responsible for running it. Ill-suited in this case can mean it uses a technology stack that the company’s IT department has little or no experience with.
Selecting a product that has withering community support. This means you have no support, and almost every question will have to be answered the hard way—by experimenting with the product or reading the code.
Selecting a product based on the buzz it is getting. Sometimes the buzz is about factors that have nothing to do with the software’s quality. A hot product can have gaping holes in terms of functionality.
Selecting a product that is being pushed out of the market because of commercial conflicts (trademark, copyright, etc.). Sometimes open source projects run afoul of commercial products. When an open source product emulates or extends a commercial product, it makes a huge difference whether the commercial firm ignores the effort, supports it, or seeks to shut it down.
Selecting a product that does not have momentum. Products with slow momentum lie dormant for a long period of time between releases. A bug reported to be fixed in the next release might not become available for quite a while.
Taking a product out of its natural home. If a product is most often used with Apache, MySQL, and Linux, and you want to use it with IIS, Oracle, and Solaris, integration problems might soar.
Some of these traps, of course, are not unique to open source. But paying careful attention to the methods in this book will help you to avoid all the problems just listed.