The Cathedral and the Bazaar

Eric S. Raymond — 1997

Historical Context

First Presented: May 21, 1997 at Linux Kongress

Published: Version 3.0, September 2000

Impact: Helped birth the modern open source movement and influenced Netscape's decision to release Mozilla's source code in 1998

Significance: Analyzed why decentralized, transparent software development often produces better results than closed, hierarchical approaches. Introduced the famous principle: "Given enough eyeballs, all bugs are shallow."

Original Source: catb.org/~esr/writings/cathedral-bazaar/

Full Book: The Cathedral and the Bazaar (O'Reilly)

L

Linux is subversive. Who would have thought even five years ago (1991) that a world-class operating system could coalesce as if by magic out of part-time hacking by several thousand developers scattered all over the planet, connected only by the tenuous strands of the Internet?

Certainly not I. By the time Linux swam onto my radar screen in early 1993, I had already been involved in Unix and open-source development for ten years. I was one of the first GNU contributors in the mid-1980s. I had released a good deal of open-source software onto the net, developing or co-developing several programs (nethack, Emacs's VC and GUD modes, xlife, and others) that are still in wide use today. I thought I knew how it was done.

Linux overturned much of what I thought I knew. I had been preaching the Unix gospel of small tools, rapid prototyping and evolutionary programming for years. But I also believed there was a certain critical complexity above which a more centralized, a priori approach was required. I believed that the most important software (operating systems and really large tools like the Emacs programming editor) needed to be built like cathedrals, carefully crafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its time.

Two Development Models

🏛️ The Cathedral

  • Centralized planning and control
  • Small teams working in isolation
  • Careful crafting before release
  • Limited beta testers
  • Traditional commercial model
  • "Release when ready"

🌐 The Bazaar

  • Decentralized collaboration
  • Thousands of developers worldwide
  • Release early, release often
  • Users as co-developers
  • Linux/open source model
  • "Given enough eyeballs, all bugs are shallow"
"Linus Torvalds's style of development—release early and often, delegate everything you can, be open to the point of promiscuity—came as a surprise. No quiet, reverent cathedral-building here—rather, the Linux community seemed to resemble a great babbling bazaar of differing agendas and approaches out of which a coherent and stable system could seemingly emerge only by a succession of miracles."

Raymond's Laws of Software Development

  1. Every good work of software starts by scratching a developer's personal itch.
  2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
  3. "Plan to throw one away; you will, anyhow." (Fred Brooks)
  4. If you have the right attitude, interesting problems will find you.
  5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
  6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
  7. Release early. Release often. And listen to your customers.
  8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. (Linus's Law)
  9. Smart data structures and dumb code works a lot better than the other way around.
  10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
  11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
  12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
  13. "Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away."
  14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
  15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!
  16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
  17. A security system is only as secure as its secret. Beware of pseudo-secrets.
  18. To solve an interesting problem, start by finding a problem that is interesting to you.
  19. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

Impact on Software Development

This essay fundamentally changed how we think about software development:

  • Open Source Movement: Helped legitimize open development models in business contexts
  • Netscape Decision: Directly influenced Netscape's 1998 decision to open-source their browser
  • Corporate Adoption: Companies realized open source could be a viable development strategy
  • Transparency Wins: Demonstrated that openness often beats secrecy in software quality
  • Community Power: Showed how distributed communities can outperform centralized teams

Read the Full Essay

The complete text with all 19 lessons and detailed case studies:

Read Online

Also available as a book from O'Reilly: The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary

Related Reading