h2g2 The Hitchhiker's Guide to the Galaxy: Earth Edition

A famous essay written by Eric Steven Raymond, a controversial figure in the Open Source world ,in 1997. It this essay that put him on the map, and started the critisism of self-aggrandisement, as he comments on Open Source, but does not create much code. After The Cathedral and the Bazaar he started the Jargon File, or The New Hackers Dictionary.

The Cathedral and The Bazaar looked at two different Open Source projects - Fetchmail and Linux - and their two differeing systems of development. Fetchmail worked on a traditional software development model where only a few developers could see and access the developmental source code - The Cathedral. Linux worked in a more open method, where anyone could see and propose changes to the source code - The Bazaar.

Though examining two Open Source projects the common view is that the essay is comparing Open Souce against Closed Source. There is a valid reason for this in that private software companies all used the Cathedral style for building their products at that time.

It was The Cathedral and The Bazaar where Linus' Law was first proposed - Given anough eyeballs all bugs are shallow. This law hypothesises that with enough beta-testers and enough co-developers examining the code then any problems can be easily and quickly catagorised and the solution will be obvious to someone.

Since the essay was written Open Source has expanded into big business. It could be argued that this essay was one of the main prompts of this sea-change, though the continual evolution of several Open Source projects into enterprise viable form would be more of a factor. It was, however, influential in the bazaarification of many Open Source projects and the move of Netscape into Open Source - and so the development of Mozilla.

Well, this is how I see this essay, any inaccuracies or incorrect assumptions then please step in and correct me Until later....
BCNU - Crescent

Oh good, I like your summary. Now I don't need to read it, though I've been meaning to for ages.

But just in case I change my mind:
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/

right, to provide an alternate summary....

under the conventional development model which has a long history, you develope your code with the intent of making ALL of the money available from that type of program. other people develope their own code for the same reason.

none of you manage to get a monopoly position, so as you all use incompatable and proprietary file formats, your customers end up with their data locking them into using your application (on whoever got to them first). at the same time, only your programmers get to see the code, and bugs only get fixed when your programmers are not busy adding new features in the hope of extending market share.

then someone manages to grab most of the users from one of the companies, and it goes bust. at this point it keeps tightly hold of it's proprietary code, in the hopes of a resurection or a minor profit from it, and the code disappears, and the customers end up stuffed, hoving to migrate all their data to the prorietary format of one of the other incompatible systems, and hoping they don't go the same way.

Ths model is what is used by the old guard in the cathedral model.

then we get the bazaar, as exemplified in the gnu/linux and generally open source model.

you start of with something you developed for yourself. you make it available to others, and some of them contribute fixes which make it more stable, or run on more systems, or add extra features which they need.

as long as enough people contribute, the code continues to improve, as can be seen from the variety of best of breed applications in one of the other threads.

in the mean time, you can make money by selling "value added" services, like technical support, and so can anyone else.

as the code gets more capable, you start saving money by being able to move away from the mandatory upgrade path which characterises the cathedral model.

Eventually, there is a dispute about the direction the code should go, and the project forks into two. sometimes these converge later on and get the improvements from both forks, sometimes one fork dies as the users express their preference, and sometimes they diverge very rapidly, and start to compete.

whichever path is followed, the file formats tend to remain compatable, because of the common roots, and the availabiliy of the source code so that you can include their improvements to the format into your forked code. (and they can include your improvements).

if one of the projects dies, the code is still available (usually) and the good bits which can easily be absorbed often get copied into the survivor. in any case, the data files are usually either completely compatable, or you can get the code and use it to write a converter so that most of your data can migrate easily to the replacement system.

Because lots of people are looking at the code, bugs get spotted fairly easily, and because a lot of the people looking are programmers, they usually fix it and send in the changes to the project (as required by most open source licences).

As each layer of the system becomes more capable, it acts as an enabling technology which allows you to add even further features to the system as a whole.

for example:

the gnu tools and bsd spawned the linux kernel.

this was bundled with the gnu tools, and distributions were born.

then XFree86 was developed and the system got a unix gui.

then kde and gnome were developed, and the gui got much more capable.

because kde and gnome were used on multimedia pc's, there developed a need for better realtime handling in the kernel, and propper audio support.

now you are getting things like rosegarden which act as a (mostly) fully featured software based recording studio for musicians, and similar programs for video editing which are being used in hollywood.

and because of the improved realtime handling, your ordinary programs are running faster as well.

in each case, the preceding level became "good enough", and new applications became possible, but the underlying code continued to improve.

However you don't need to start from scratch to use the bazaar model. It is becoming fairly common now for a company on the verge of going bust with no realistic chance to sell the software to make it open source, where its users often take over maintainance and extending the program.

Isn't the Jargon File (aka Hackers dictionary) an older piece of work than the Cathedral & Bazzar essay.

Well, firstly the Jargon file predates ESR's involvement in it - he revived it after a long slumber in 1990 [http://www.catb.org/~esr/jargon/html/revision-history.html]. And secondly, yes, the C&B paper didn't arrive until 1997, according to the Jargon file [http://www.catb.org/~esr/jargon/html/B/bazaar.html]

Interestingly, the summary of the 'bazaar mode' in that entry reads:
"Its characteristics include releasing code early and often, and actively seeking the largest possible pool of peer reviewers."

If my memory is correct on this wasn't the C&B essay also a pop at Richard Stallman and the way he ran the GNU project.