The Cathedral and the Bazaar

Eric Steven Raymond

Abstract

I anatomize a successful open-source project, fetchmail, that was run as a deliberate test of the surprising theories about software engineering suggested by the history of Linux. I discuss these theories in terms of two fundamentally different development styles, the ``cathedral'' model of most of the commercial world versus the ``bazaar'' 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 ``Given enough eyeballs, all bugs are shallow'', suggest productive analogies with other self-correcting systems of selfish agents, and conclude with some exploration of the implications of this insight for the future of software.

摘要
Linux的发展史促生了一些关于软件工程的惊人理论。我有意的在一个成功的开源项目fetchmail中测试了这些理论，并在此加以剖析。这里讨论了两种根本上不同的开发模式：大多数商业项目使用的“大教堂”模式和Linux世界的“市集”模式。我们将看到，这两种模式源于对软件调试工作的本质的两种彼此对立的假设。我接着从Linux的经验出发，对“只要眼球足够多，所有臭虫都好捉”的定理作了一个站得住的论证；建议它与其它由自主成员组成的自纠错系统之间富有意义的相似之处。最后，我探讨了这个发现对未来软件业的启示。

Table of Contents

The Cathedral and the Bazaar
The Mail Must Get Through
The Importance of Having Users
Release Early, Release Often
How Many Eyeballs Tame Complexity
When Is a Rose Not a Rose?
Popclient becomes Fetchmail
Fetchmail Grows Up
A Few More Lessons from Fetchmail
Necessary Preconditions for the Bazaar Style
The Social Context of Open-Source Software
On Management and the Maginot Line
Epilog: Netscape Embraces the Bazaar
Notes
Bibliography
Acknowledgements

The Cathedral and the Bazaar

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.

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 (aptly symbolized by the Linux archive sites, who'd take submissions from anyone) 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't fly apart in confusion but seemed to go from strength to strength at a speed barely imaginable to cathedral-builders.

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—and it was a significant success.

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

Linux 是颠覆性的。就是五年以前(1991)，谁能想得到散布在全球各地的几千名开发者的业余敲打，仅靠细细的互联网网线连接，能够魔术一般地铸成一个世界级的操作系统呢？
反正不是我。在1993年初Linux引起我的注意的时候，我已经在Unix和开放源代码开发领域做了十年了。我是80年代中期最早的GNU开发者之一。我已经在网上发布了相当一部分软件，正在开发或协助开发好几个直到今天都在广泛使用的软件（nethack，Emacs的VC和GUD模式，xlife和其它）。我觉得我很懂行了。
Linux颠覆了许多我以为我懂的东西。多年来我一直在宣扬小型工具、快速建模和进化式编程的Unix福音。但我也相信一个项目到了一定的复杂程度后就需要更集中地按事先计划管理。我相信最重要的软件（操作系统和Emacs之类的大型工具）需要像大教堂一样来搭建：遗世独立的圣人巨匠们牵尺引斤琢之磨之；时候不到beta版不出。

林纳斯·托瓦兹的开发风格令人惊讶：尽早尽多的发布，委托所有可以委托的事，开放到了泛滥的程度。这里没有建造大教堂的安静和虔诚；Linux社区更像一个充满不同议程和方法的嘈杂的大集市（Linux归档站点们就是一个绝好的例子，任何人的作品都接收）。一个统一稳定的系统若是从这儿产生看来只能依靠一系列的奇迹。
结果这种市集风格的确有效、非常有效——真是一个绝大的震撼。在我摸索的过程中，我不仅效力于个别的项目，而且努力去理解为什么Linux世界没有在混乱中分崩离析，而是以大教堂的建造者们难以想像的速度茁壮成长。
到１９９６年中，我想我开始理解了。我有了一个测试我的理论的完美机会，一个我可以有意识的用市集风格来运行的开源项目。我这样做了——结果非常成功。

这里讲述的就是这个项目的故事。我将借它来提出一些开源软件有效开发的精髓。它们并非全部源自Linux 世界，但我们会看到它们如何在Linux世界中得到印证。如果我是正确的话，它们会帮助您准确理解什么使得Linux社区成为优秀软件的源泉——或许，它们还会帮助您变得更加高效。

This is version 3.0
Copyright © 2000 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.
$Date: 2002/08/02 09:02:14 $
Source: http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
Retrieved Sept. 5, 2006