2.1. Open Source Traps 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 wayby 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. |
