本文的作者Eric Raymond是Open Source Software领域的领袖，这方面许多
新的思想正是从他那儿产生的，同时他也是UNIX上最流行的Email软件Fetchmail
的作者。
下面这篇文章有点儿长，然而它是值得你去耐心把它读完的。文章以Fetchmail
为例，讨论了Internet上集市风格的开发方式。
我们应该感谢HansB，是他把这篇长文章翻译成了中文。
Eric的主页地址在：http://www.tuxedo.org/~esr/
————————————————————————-
大教堂和市集
Linux的影响是非常巨大的。甚至在５年以前，有谁能够想象一个世界级的操
作系统能够仅仅用细细的Internet连接起来的散布在全球的几千个开发人员有以业
余时间来创造呢？
我当然不会这么想。在１９９３年早期我开始注意Linux时，我已经参与Unix
和自由软件开发达十年之久了。我是八十年代中期GNU最早的几个参与者之一。我
已经在网上发布了大量的自由软件，开发和协助开发了几个至今仍在广泛使用的
程序（Nethack,Emacs VC和GND模式，xlife等等）。我想我知道该怎样做。
Linux推翻了许多我认为自己明白的事情。我已经宣扬小工具、快速原型和演
进式开发的Unix福音多年了。但是我也相信某些重要的复杂的事情需要更集中化的，
严密的方法。我相信多数重要的软件（操作系统和象Emacs一样的真正大型的工具）
需要向建造大教堂一样来开发，需要一群于世隔绝的奇才的细心工作，在成功之前
没有beta版的发布。
Linus Torvalds的开发风格（尽早尽多的发布，委托所有可以委托的事，对所
有的改动和融合开放）令人惊奇的降临了。这里没有安静的、虔诚的大教堂的建造
工作――相反，Linux团体看起来像一个巨大的有各种不同议程和方法的乱哄哄的
集市（Linux归档站点接受任何人的建议和作品，并聪明的加以管理），一个一致
而稳定的系统就象奇迹一般从这个集市中产生了。
这种设计风格确实能工作，并且工作得很好，这个事实确实是一个冲击。在我
的研究过程中，我不仅在单个工程中努力工作，而且试图理解为什么Linux世界不
仅没有在一片混乱中分崩离析，反而以大教堂建造者们不可想象的速度变得越来越
强大。
到了１９９６年中，我想我开始理解了。我有一个极好的测试我的理论的机会，
以一个自由软件计划的形式，我有意识的是用了市集风格。我这样做了，并取得了
很大的成功。
在本文的余下部分，我将讲述这个计划的故事，我用它来明确一些自由软件高
效开发的格言。并不是所有这些都是从Linux世界中学到的，但我们将看到Linux世
界给予了它们一个什么样的位置。如果我是正确的，它们将使你理解是什么使Linux
团体成为好软件的源泉，帮助你变得更加高效。
二. 邮件必须得通过
１９９３年以前我在一个小的免费访问的名为Chester County InterLink的ISP
的做技术工作，它位于Pennsylvania的West Chester。（我协助建立了CCIL，并写了
我们独特的多用户BBS系统――你可以telnet到locke.ccil.org来检测一下。今天它
在十九条线上支持三千的用户）。这个工作使我可以一天二十四小时通过CCIL的56K
专线连在网上，实际上，它要求我这么做！
所以，我对Internet email很熟悉。因为复杂的原因，很难在我家里的机器
（snark.thyrsus.com）和CCIL之间用SLIP工作。最后我终于成功了，但我发现不
得不时常telnet到locke来检查我的邮件，这真是太烦了。我所需要的是我的邮件
发送到snark,这样biff(1)会在它到达时通知我。
简单地sendmail的转送功能是不够的，因为snark并不是总在网上而且没有一
个静态地址。我需要一个程序通过我的SLIP连接把我的本地发送的邮件拉过来。
我知道这种东西是存在的，它们大多使用一个简单的协议POP（Post Office
Protocol）。而且，locke的BSD/OS操作系统已经自带了一个POP3服务器。
我需要一个POP3客户。所以我到网上去找到了一个。实际上，我发现了三、
四个。我用了一会pop-perl，但它却少一个明显的特征：抽取收到的邮件的地址
以便正确回复。
问题是这样的：假设locke上一个叫“joe”的人向我发了一封邮件。如果我
把它取到snark上准备回复时,我的邮件程序会很高兴地把它发送给一个不存在的
snark上的“joe”。手工的在地址上加上“@ccil.org”变成了一个严酷的痛苦。
这显然应是计算机替我做的事。（实际上，依据RFC1123的5.2.18节，
sendmail应该做这件事）。但是没有一个现存的POP客户知道怎样做！于是这就给
我们上了第一课：
1.每个好的软件工作都开始于搔到了开发者本人的痒处。
也许这应该是显而易见的（“需要是发明之母”长久以来就被证明是正确的），
但是软件开发人员常常把他们的精力放在它们既不需要也不喜欢的程序，但在
Linux世界中却不是这样――这解释了为什么从Linux团体中产生的软件质量都如
此之高。
那么，我是否立即投入疯狂的工作中，要编出一个新的POP3客户与现存的那
些竞争呢？才不是哪！我仔细考察了手头上的POP工具，问自己“那一个最接近我
的需要？”因为：
2.好程序员知道该写什么，伟大的程序员知道该重写（和重用）什么。
我并没有声称自己是一个伟大的程序员，可是我试着效仿他们。伟大程序员
的一个重要特点是建设性的懒惰。他们知道你是因为成绩而不是努力得到奖赏，
而且从一个好的实际的解决方案开始总是要比从头干起容易。
例如，Linux并不是从头开始写Linux的。相反的它从重用Minix（一个386机
型上的类似Unix的微型操作系统）的代码和思想入手。最后所有的Minix代码都消
失或被彻底的重写了，但是当它们在的时候它为最终成为Linux的雏形做了铺垫。
秉承同样的精神，我去寻找良好编码的现成的POP工具，用来作为基础。
Unix世界中的代码共享传统一直对代码重用很友好（这正是为什么GNU计划不
管Unix本身有多么保守而选取它作为基础操作系统的原因）。Linux世界把这个传
统推向技术极限：它有几个T字节的源代码可以用。所以在Linux世界中花时间寻
找其他几乎足够好的东西，会比在别处带来更好的结果。
这也适合我。加上我先前发现的，第二次寻找找到了9个候选者――fetchPOP
，PopTart，get-mail，gwpop，pimp，pop-perl，popc，popmail 和 upop）。我
首先选定的是“fetchpop”。我加入了头标重写功能，并且做了一些被作者加入
他的1.9版中的改进。
但是几个星期之后，我偶然发现了Carl Harris写的“popclient”的代码，
然后发现有个问题，虽然fetchpop有一些好的原始思想(比如它的守护进程模式)，
它只能处理pop3，而且编码的水平