Read without ads and support Scribd by becoming a Scribd Premium Reader.
The Cathedral and the Bazaar
Eric Steven Raymond$Date: 2000/08/24 22:37:44 $
Copyright \u00a9 2000 by Eric S. Raymond
Copyright
Permission is granted to copy, distribute and/or modify this document under the terms of the Open
Publication License, version 2.0.
Revision History

Revision 1.5124 August 2000 Revised by: esr
First DocBook version. Minor updates to Fall 2000 on the time-sensitive material.
Revision 1.495 May 2000

Revised by: esr
Added the HBS note on deadlines and scheduling.
Revision 1.5131 August 1999 Revised by: esr
This the version that O\u2019Reilly printed in the \ufb01rst edition of the book.
Revision 1.458 August 1999

Revised by: esr
Added the endnotes on the Snafu Principle, (pre)historical examples of bazaar development, and originality in the bazaar.
Revision 1.4429 July 1999

Revised by: esr
Added the \u201cOn Management and the Maginot Line\u201d section, some insights about the usefulness of bazaars for exploring de
Revision 1.4020 Nov 1998

Revised by: esr
Added a correction of Brooks based on the Halloween Documents.
Revision 1.3928 July 1998

Revised by: esr
I removed Paul Eggert\u2019s \u2019graph on GPL vs. bazaar in response to cogent aguments from RMS on
Revision 1.31February 10 1998 Revised by: esr
Added \u201cEpilog: Netscape Embraces the Bazaar!\u201d
Revision 1.29February 9 1998 Revised by: esr
Changed \u201cfree software\u201d to \u201copen source\u201d.
Revision 1.2718 November 1997Revised by: esr
Added the Perl Conference anecdote.
Revision 1.207 July 1997

Revised by: esr
Added the bibliography.
Revision 1.1621 May 1997

Revised by: esr
First of\ufb01cial presentation at the Linux Kongress.
I anatomize a successful open-source project, fetchmail, that was run as a deliberate test of some
surprising theories about software engineering suggested by the history of Linux. I discuss these theories1

in terms of two fundamentally different development styles, the \u201ccathedral\u201d model of most of the
commercial world versus the \u201cbazaar\u201d model of the Linux world. I show that these models derive from
opposing assumptions about the nature of the software-debugging task. I then make a sustained argument
from the Linux experience for the proposition that \u201cGiven enough eyeballs, all bugs are shallow\u201d,
suggest productive analogies with other self-correcting systems of sel\ufb01sh agents, and conclude with
some exploration of the implications of this insight for the future of software.

1. The Cathedral and the Bazaar

Linux is subversive. Who would have thought even \ufb01ve 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 \ufb01rst 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\u2019s 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.

Linus Torvalds\u2019s 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 \u2013 rather, the
Linux community seemed to resemble a great babbling bazaar of differing agendas and approaches
(aptly symbolized by the Linux archive sites, who\u2019d take submissions fromanyone) out of which a
coherent and stable system could seemingly emerge only by a succession of miracles.

The fact that this bazaar style seemed to work, and work well, came as a distinct shock. As I learned my way around, I worked hard not just at individual projects, but also at trying to understand why the Linux world not only didn\u2019t \ufb02y apart in confusion but seemed to go from strength to strength at a speed barely imaginable to cathedral-builders.

2

By mid-1996 I thought I was beginning to understand. Chance handed me a perfect way to test my
theory, in the form of an open-source project that I could consciously try to run in the bazaar style. So I
did \u2013 and it was a signi\ufb01cant success.

This is the story of that project. I\u2019ll use it to propose some aphorisms about effective open-source
development. Not all of these are things I \ufb01rst learned in the Linux world, but we\u2019ll see how the Linux
world gives them particular point. If I\u2019m correct, they\u2019ll help you understand exactly what it is that
makes the Linux community such a fountain of good software \u2013 and, perhaps, they will help you become

more productive yourself.
2. The Mail Must Get Through

Since 1993 I\u2019d been running the technical side of a small free-access Internet service provider called
Chester County InterLink (CCIL) in West Chester, Pennsylvania. I co-founded CCIL and wrote our
unique multiuser bulletin-board software \u2013 you can check it out by telnetting to locke.ccil.org
(telnet://locke.ccil.org). Today it supports almost three thousand users on thirty lines. The job allowed me
24-hour-a-day access to the net through CCIL\u2019s 56K line \u2013 in fact, the job practically demanded it!

I had gotten quite used to instant Internet email. I found having to periodically telnet over to locke to
check my mail annoying. What I wanted was for my mail to be delivered on snark (my home system) so
that I would be noti\ufb01ed when it arrived and could handle it using all my local tools.

The Internet\u2019s native mail forwarding protocol, SMTP (Simple Mail Transfer Protocol), wouldn\u2019t suit,
because it works best when machines are connected full-time, while my personal machine isn\u2019t always
on the net, and doesn\u2019t have a static IP address. What I needed was a program that would reach out over
my intermittent dialup connection and pull across my mail to be delivered locally. I knew such things
existed, and that most of them used a simple application protocol called POP (Post Of\ufb01ce Protocol). POP
is now widely supported by most common mail clients, but at the time, it wasn\u2019t built-in to the mail
reader I was using.

I needed a POP3 client. So I went out on the net and found one. Actually, I found three or four. I used
one of them for a while, but it was missing what seemed an obvious feature, the ability to hack the
addresses on fetched mail so replies would work properly.

The problem was this: suppose someone named \u2018joe\u2019 on locke sent me mail. If I fetched the mail to snark
and then tried to reply to it, my mailer would cheerfully try to ship it to a nonexistent \u2018joe\u2019 on snark.
3
Search History:
Searching...
Result 00 of 00
00 results for result for
  • p.
  • Notes
    Load more