The Cathedral and the Bazaar

Summary of: The Cathedral and the Bazaar

Author(s) / Editor(s)

Eric Raymond compares two styles of software development using his own experience as illustration -- the traditional top-down (Cathedral) approach and the bottom-up (Bazaar) approach -- and points out how Internet-enabled cooperation makes the Bazaar approach highly efficient for the right tasks.


Publication Reference

Published in/by
First Monday


  • People will work best on what they are interested in. People will volunteer and dedicate their time and energy because they want to see the project succeed.
  • Doing anything should be treated as an experimental process. Progress and refinement are by definition re-doing. “Laziness” as a motive drives refinement as a means of maximizing efficiencies in service to the project’s goal. The result is robust data structures and minimal code.
  • Many eyes and heads are better than one when a means of coordinating exists. This is true of problem-finding, idea generation, bug-finding, bug-fixing, application-testing, and code-refinement.

Eric Raymond compares two styles of software development using his own experience as illustration. The Cathedral refers to a top-down command-and-control approach, whereas the Bazaar refers to a decentralized cooperative approach. The success of the bazaar-made operating system Linux led Raymond to investigate why that approach succeeded when the accepted norm was that only a Cathedral approach could successfully create good software.

Raymond reaches a number of conclusions about the Bazaar approach to writing software.

Every good work of software starts by scratching a developer's personal itch. “Scratching an itch” is a way of harnessing self-interest to get high-quality volunteer labor. Developers will work hardest at solving their own problems first, and since those problems are often also other people’s problems, the community has shared incentives to cooperate.

Good programmers know what to write. Great ones know what to rewrite (and reuse). This refers to the value of “constructive laziness,” i.e. that good programmers seek to do as little work as possible and therefore are drawn towards the most efficient methods they can find.

"Plan to throw one away; you will, anyhow." (Fred Brooks, The Mythical Man-Month, Chapter 11) Raymond clarifies, “you often don't really understand the problem until after the first time you implement a solution. The second time, maybe you know enough to do it right. So if you want to get it right, be ready to start over at least once.”

If you have the right attitude, interesting problems will find you. Your reputation directs things to you as people learn what you are good at.

When you lose interest in a program, your last duty to it is to hand it off to a competent successor. If you don’t make arrangements for the capable continuation of a software project, then the entire community loses.

Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging. Your users are your testers.

Release early. Release often. And listen to your customers. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. Or, less formally, "Given enough eyeballs, all bugs are shallow." I dub this: "Linus' Law". I am indebted to Jeff Dutky for pointing out that Linus' Law can be rephrased as "Debugging is parallelizable."

Smart data structures and dumb code works a lot better than the other way around. Brooks, Chapter 9: "Show me your [code] and conceal your [data structures], and I shall continue to be mystified. Show me your [data structures], and I won't usually need your [code]; it'll be obvious."

If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.

The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.

Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong. The moral? Don't hesitate to throw away superannuated features when you can do it without loss of effectiveness. Antoine de Saint-Exupery (who was an aviator and aircraft designer when he wasn't being the author of classic children's books) said: "Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away." When your code is getting both better and simpler, that is when you know it's right.

Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.

To solve an interesting problem, start by finding a problem that is interesting to you. In The Mythical Man-Month, Fred Brooks writes: “while coding remains an essentially solitary activity, the really great hacks come from harnessing the attention and brainpower of entire communities. The developer who uses only his or her own brain in a closed project is going to fall behind the developer who knows how to create an open, evolutionary context in which bug-spotting and improvements get done by hundreds of people.“

Provided the development coordinator has a medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.