Previous    Table of Contents    Up    Next

Not Understanding Open Source

The first problems can arise when people making decisions about whether to use open source for a project do not understand how open source works. A typical failure is for decision makers to not believe the philosophical tenets of open source (see Philosophical Tenets of Open Source in Chapter 3) or to believe one or more of the myths about open source (see Common Open-Source Myths, Misconceptions, and Questions in Chapter 3). As a result, they decide not to use open source because they imagine there are insurmountable problems, or, even worse, they choose open source but have unrealistic expectations. The first case causes the company to miss a possible opportunity, whereas the second can doom the project to failure.

One common fear decision makers have is that by choosing to make a project open source the core developers will be swamped by having to answer thousands of email messages from outside user developers. (Fear of developers being swamped by questions and requests is one reason that managers isolate engineers working on proprietary projects from customers.) Indeed, the core team will need to spend some of its time engaging with the community and answering questions; however, the bulk of the questions that arise on project mailing lists should end up being answered by other community members--the community naturally provides the necessary resources.

Another common misconception is that open sourcing one product means that everything connected with it, including totally separate programs, must also be open sourced. In the past, Microsoft and others who were opposed to open source have tried to play on this fear in statements and articles where they have called open source both "un-American" and "a cancer."1

The reality is that even under a strong open-source license such as the GPL only the actual source code of the application is affected. Other open-source licenses, such as the LGPL, Mozilla, and BSD, make it easy to combine proprietary and open-source code. There are real issues about what IP an open-source project will share, but they are not as horrific or all-devouring as people uninformed on the details of open source might fear. Note that because open-source licenses have yet to be thoroughly tested in court, lawyers are prone to be overly cautious when they first read an open-source license.

Many people believe that the point of doing open source is to get hundreds of outside developers to work for them for free. When this doesn't happen--and it almost certainly won't--they declare the project a failure. Moreover, managers who believe that open source is just a way to cut costs may not allocate sufficient resources to the project--starving it to death.

A related misconception is that you will get hundreds of developers contributing lots of random low-quality code that you will somehow need to deal with. This just doesn't happen. If you are lucky, you might get a number of outside developers experimenting with your source code trying to fix bugs or make improvements, but you will never hear from most of them. Like most people, developers do not want to appear foolish in a public forum. If they think that their potential contributions are not so great, they will most likely never show them to anyone. In fact, your problem is more apt to be the opposite: trying to convince potential contributors to submit code that they feel is less than perfect.

A common mistake is believing that a company can open source a project to get good PR while playing the same old proprietary game. The outside world will quickly see this for the sham it is, and no one will join the project. Doing an open-source project for the wrong reasons will probably get you a lot of bad press coverage and alienate outside developers.

A different type of problem is starting to occur as more people learn about open source: People sometimes believe that any open-source project they create must work exactly the same way as an existing open-source project. Projects such as Apache, Mozilla, and Linux are being held up as exemplars of the only way to run an open-source project. Although it is important to learn from successful open-source projects, we are still just beginning to understand the landscape of open source. To succeed requires adopting an open-source attitude and innovating new ways to do things.

Another mistake is not understanding that starting an open-source project is like launching a new product. They have similar life-cycle issues, the most important being that neither can be ended abruptly without upsetting your customers, which includes the community in the case of an open-source project. Open-source projects, like products, require an end-of-life plan. For more details, please refer to the section on Ending an Open-Source Project in Chapter 6.