The Cathedral And The Bazaar

By Eric S. Raymond (http://www.catb.org/~esr/)

Can be found on-line at http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/.

EricRaymond wrote a paper on the success of Linux as a software development effort, when most everyone would have said that common sense prevented such an large-scale effort from being successful. He compared Linux and similar OpenSource efforts to the way that a bazaar develops, and compared typical commercial source developments to the way that trained masons with secret skills built cathedrals.

This highly influential paper is credited with convincing Netscape to release the source code to MozillaBrowser. You can read it at http://www.catb.org/~esr/writings/cathedral-bazaar/ and you can read the sequel, Homesteading the NooSphere, at http://www.catb.org/~esr/writings/homesteading.

-- BruceAtherton

AlanCox has a follow-on piece called "The Cathedral, the Bazaar, and the Town Council," which deals with the problem of too many people jumping into the Bazaar too soon, disrupting early development.

You can read it at http://www.slashdot.org/features/98/10/13/1423253.shtml (URL may be unstable.)

-- DaveSmith

I am interested in these ideas and amazed at the richness which has developed since I was last seriously browsing here in early 1997. I had an experience over the last 9 months which I want to characterize as TheCathedralIgnoresTheCustomer. -- JohnFletcher

I bought the book and was expecting an really compelling piece and found myself wondering what all the fuss was about. I didn't find the arguments coherent or convincing or even rational for that matter.

-- Sam Gentile

The real story is one of MarcAndreesen cleverly instigating a new Silicon Valley hype (in league with Tim O'Reilly, Larry Augustine, and a few others) by taking the first halfway reasoned explanation of the open source process (as it applied to an email download utility and Linux at large) and selling it to Jim Clark as a defensive maneuver against Microsoft.

Much has been said about why FreeSoftware/OpenSource is good for its users, but little has been said about why it is good to write the stuff, i.e., why it is good to put forth the tremendous effort involved in writing a program, only to give the result of that effort away. Nobody has been able to answer that question, except through an appeal to a self-destructive altruism, and that's why so many programmers have been leery of FreeSoftware/OpenSource.

There are many reasons. I'm contributing to several OpenSource projects hosted on sf.net, and the reasons vary. For example, in FlameRobin, we're simply working on it together because it's just too big project to be done by a single programmer. I started it out in 2003 and people who needed the tool picked up my code and started adding the features they were missing. This is called ScratchingTheItch? in OSS terminology. Now we have a completely functional program that covers our needs. None of us would ever go into writing it themselves. Only joint effort could produce it, and the only way to find people to contribute was to make it available for free in the first place.

Here's another example, IBPP library (also on sf.net) was open sourced when the original code authors wanted to migrate some of their systems to a different platform, but didn't have the resources to port it. They open sourced the code of the library, and other people came and ported it to other systems, just because they needed Linux, MacOS X, etc. port themselves.

There is also another reason: showing how good you are. This is common among students at Universities, etc. who just want to show their skills to the world.

There are even more reasons. For example, one developer joined our team just to learn C++ and get a feeling how it is to work on a bigger project - without having any potential consequences (aside from us not accepting his patches). -- MilanBabuskov

The thesis of TheCathedralAndTheBazaar is that there is something wrong with the question - if development takes that much effort, you're doing something wrong. What you're supposed to be doing is, you're supposed to download a bunch of free components, use them to produce another component (without putting too much effort into it - you can either connect components, or edit them, or combine them), and then release the new component for free. Other programmers will then download your component and use it to develop still more impressive components. Because of the availability of FreeSoftware to use as components, you're not supposed to be ReinventingTheWheel. Eventually, whatever your goal is, you'll be able to hope to find components that are already almost there, and it will be simple to just connect them together.

This is how Linux was built. In fact, it's probably the only way to write FreeSoftware/OpenSource.

If you want something whose components do not exist, you have to either write them yourself, or wait for others to write them for you. Eric S. Raymond suggests that you can persuade people to contribute by releasing early - release your first end-to-end solution, ambitious and largely unimplemented, and see what interest you can attract.

Sometimes you can't attract the interest, or you cant afford the patience. That's why, even though OpenSource claims not to take a stand on whether IntellectualProperty is good or evil (an attempt to appease both the FreeSoftware people and the big corporations who, it is hoped, will fund the development of OpenSource), Eric S. Raymond has had to take a stand in favor of intellectual property. Even he recognizes that, sometimes, it's the cathedral or nothing. -- EdwardKiser

See FundingOpenSource.

On the other hand, A Second Look At The Cathedral And The Bazaar at http://www.firstmonday.dk/issues/issue4_12/bezroukov/index.html, a serious research paper from a peer-reviewed journal.

Bezroukov's paper is definitely worth reading, but I wouldn't use it to dismiss the importance of ESR's paper.

Bezroukov basically does a StrawMan argument on ESR's statement on BrooksLaw. ESR makes the statement "But if Brook's Laws were the whole picture, Linux would be impossible." (Read Bezroukov's piece for more context.) Bezroukov distorts this to imply that ESR is suggesting that Brook's Law does not apply to Internet development, in general. Bezroukov later concedes that Brook's Law really is limited for Linux, although he doesn't give credit to Open Source for this; he attributes it to Linux's Unix's heritage.

Bezroukov then goes to work on ESR's statement that "Given enough eyeballs, all bugs are shallow." His main critique of this statement is that some bugs are deeper than others. He suggests that in open source software, people tend to do a lot of superficial bug fixes, at the expense of more important rewrites for architectural flaws. Some one can explain to me how this is less of a problem in closed source; Bezroukov did not get that point across to me. Finally, he takes a shot at Linux, giving us anecdotal evidence that Linux might not be so reliable after all. Granted, the anecdotal evidence comes from Ken Thomson, who should know, but it's still anecdotal. The paper is two years old, so maybe he'd revise his statement now.

-- SteveHowell

Another paper by Bezroukov on free software is at http://www.firstmonday.dk/issues/issue4_10/bezroukov/index.html

This granularity comes from the Unix heritage and is compatible with "cathedral" development.

Compatible but very limiting. What the CATB pointed out is that something new was occurring with software - global scaling. Unlike physical artifacts where if-i'm-holding-it-you're-not:

Software is cumulative. It doesn't wear out. Once someone implements a package, say the MD5 algorithm, no one else needs to do this again (within some given platform/language sphere).
Software is easy to copy: freely, instantly, globally.

These same things can happen within the borders of a closed software shop but the effects are tiny compared to what happens in OSS. Also, and more importantly, the *culture* of closed shops is to not share code, even internally. I worked for a large telecom (60,000 employees). We all worked on similar types of software but there was no central library of code. Each division jealously guarded their "assets". So few of the beneficial effects noted in CATB occurred.

Software once written can prove to be continuously useful. However Software does get lost, forgotten and subject to neglect when the next BigIdea comes along. Software is lost when treated and viewed as a HoardedAsset?. OpenSoftware on the other hand can have a life of it's own, living beyond the authors and initial users, especially if it is not singularly deposited in a central repository, or locked up in a special vault, or subjected to limitations on access. Software should be viewed as a tool having importance and value in what it shapes and creates.

You may enjoy hearing from Eric S Raymond a 33 minute talk on the topic of this page. It will clarify misconceptions, and introduces many concepts - such ideas as: BrainAmplification? SolitaryBrillianceIsNotEnough? PlausiblePromise? SufficientConditionForSuccess? He says the BazaarStyle works only when there is a MinimumLevelOfCompletion?, InitialCodeNucleus?, SolidTechnicalSkill? and reasonably sufficient PeopleSkills on the part of the Coordinating Party with a PathDesignedToAvoid? ThePitsOfDisaster?. He points out the WhatIsImportantInOpenDevelopment? is ReputationAndEgo?, the existence of an EgoAndGiftCulture? which assumes that YouGainByGivingAway?. He illustrates by way of the PotLatch that EgoBoo? plays an important part with HackersAndTheInternet?. He closes with the importance of CommonUnderstanding? and TheSevereEffortOfManyConvergingWills?. He says the Bazaar Style is a pattern showing HowToOperateInAnarchy? as a ModelForOurFuture?. Download and listen: http://www.catb.org/~esr/writings/cathedral-bazaar/linux1.d50.ra

I like the theory, but cathedrals weren't built the way ESR imagines. Most medieval cathedrals were built in small chunks that delivered value immediately. The chancel was constructed first and served as a place of worship for years while the sides of the nave and trancepts were built. Finally a roof was added to connect all of the structures. Each one was free-standing (modular) and in use while the next components were built. -- EricHodges

There is a picture of a rather large cathedral on the cover of TestDrivenDevelopment.

Is a "Cathedral" the same as a "SoftwareCrystal" ?

CategoryOpenSource CategoryBook CategoryPaper