Open Source
Mailing List

Open Source Software

It is useful to take some time to understand Open Source Software. You may already be familiar with it. Does the Linux operating system or GNU (pronounced gah-noo) Project sound familiar? These highly successful Open Source Software projects have been receiving a lot of press lately.

Here we will provide an overview of open-source software. For more detailed information, visit the Free Software Foundation (www.fsf.org) and the Open Source Initiative (www.opensource.org). They publish excellent information on the topic and you are encouraged to spend some time reading their web sites.

A Common Misconception

It is a common misconception that Open Source or "Free" Software is about getting software without having to pay for it ("free of charge").  This is simply not the case. The issue is not price but rather freedom. To understand the concept, you should think of "free speech", not "free beer".

Open source software can be distributed free of charge or for a fee.   It doesn't matter.  The thing that matters is, you have the freedom to run, copy, distribute, study, change, and improve the software.

When Theory Meets Reality

How does the development of Open Source Software really work? There are no enforceable rules to control open source developers. In fact, the Open Source Definition itself does not impose any rules of conduct nor does it demand any kind of cooperation. Under the guidelines of the Open Source Definition an Open Source license must protect the unconditional right of anyone to modify (and redistribute modified versions of) open-source software. Nothing prevents half a dozen different people from taking any given Open Source product, duplicating the sources, and running off with it in a different direction. Oddly enough, "forking" of software projects rarely happens in practice.

Open Source guru Eric Raymond has published two landmark papers on the open source phenomenon, "The Cathedral and the Bazaar" and "Homesteading the Noosphere". These papers provide a lot of insight into how open source software works in practice. Rather than duplicating his work, I will summarize some important concepts.

Development Models

Open source software and commercial software employ development models at the opposite ends of the spectrum. Commercial software development uses what Raymond calls the Cathedral-model. In this model, software is built in secrecy by very few people. The software is not released until it is complete. In contrast, open source software is developed using the Bazaar-model. Software built in the bazaar style is released early and released often. As much of the project is delegated to co-developers as possible. The project moderator is as open as possible about the project.

It is very difficult to begin a project using the bazaar model. Typically, open source projects start off in isolation until the originator has produced enough of a program that a development community can be built around it. The key to building a development community is offering a plausible promise. A program doesn’t have to work particularly well. It can be crude, buggy, incomplete, and poorly documented. But what it must not fail to do is convince potential co-developers that it can be evolved into something really neat in the foreseeable future.

Customs and Behaviors

As mentioned earlier, it is rare that an open source project will "fork". The open source culture has developed an elaborate set of ownership customs over the past twenty years. These customs regulate who can modify software, the circumstances under which it can be modified, and who has the right to redistributed modified versions back to the community. Some of the more significant ownership customs are listed here.

  • There is strong social pressure against forking projects. It does not happen except under plea of dire necessity, with much public self-justification, and with a renaming.
  • Distributing changes to a project without the cooperation of the moderators is frowned upon.
  • Removing a person’s name from the project history, credits, or maintainer list is absolutely not done without the person’s explicit consent.

Copyright 1999-2000, Washington State Department of Transportation