“The Cathedral and the Bazaar”

Sorry about this being a bit late, but I do blog regularly so I figured you would not mind. This essay by Eric Raymond discusses two different types of software engineering models, the Cathedral model and Bazaar model. It then goes on to explain why the Bazaar model is a superior model for an open source project and provides guidelines to follow.

In the Cathedral model, the source code of the project is limited to a small group of developers until a release, and then it is released to the public. The author argues, and I agree, that more time and energy are spent by the core developers of a project in the Cathedral model. This makes sense; the development of the project is limited to only a small group of people.

The Bazaar model lies at the other end of the spectrum.  The source code is stored on a server and accessible via the internet by the public at all times. This enables many people to look at the source code, play with it and contribute to the project.  In this model, there are many people contributing in many different areas of the project all at once. The work load is delegated out to many individuals all over the world, taking much of this burden off of the core developers.  At first it sounds like this may lead to chaos. I do not think that this would be an effective method of development in a production environment. But open source is a completely different breed of software development. And if managed correctly, this method which seems like chaos can be harnessed and made very useful.

Many of the necessary guidelines for a successful open source project can be found throughout this essay. I will just mention a couple that I found particularly important or interesting.

First, I think it is important to have a project that interests people or satisfies a need. If you want people to get involved and contribute to your project it must be interesting to them right? Contributors do not get paid for their time so they must be rewarded by personal gains, like contributing to a piece of software that solves an issue in their life. Most of the time, these people are willing to work harder than the people being rewarded financially. For example, I read an email in the project mailing list archive where this guy worked through the night on the project to resolve an issue and he was getting ready to go to work that morning. That is serious dedication and personal sacrifice!

It is also very necessary to have a tight core of developers manage the project. Everyone communicates with these individuals about decisions made on the project. I believe this is what prevents the wide- spread chaos. Many people communicating with just these few people, this keeps the number of communications lines at an acceptable level. If everyone tried to communicate with everyone on a large project nothing would get accomplished. So I would say this is a very important guideline. It seems that most projects follow this one.

There are many other great guidelines for an open source project, too many to mention. This essay by Raymond has convinced many in the open source world to adopt this type of model when undertaking a new project. That is impressive! Just want to thank Dr. B for pointing out this piece of work that has influenced so many in the open source community.