《The Cathedral & the Bazaar》 By：Eric Steven Raymond, 1997

基础版本：https://github.com/crazyangelo/Cathedral-and-Bazaar 基础版译注：原始版本為 1999 年 5 月 5 日，由謝志昌所翻譯；英文最新版為 2002 年 8 月 2 日的 3.0 版，由於內容更動處不少，因此逐一更新；翻譯以語句通順達意為主要考量，難免與英文版的字詞有所不同，為求盡善盡美，以 CC 授權釋出，希望各方同好自由修改散佈。

本版译注：将繁体字改成简体，并修正了一些词汇表达

第一章 教堂与市集

Linux 打破了许多软件发展的传统，这个世界级的操作系统在五年前（1991 年）仅仅靠着如丝般的网际网路，神奇地联合了散布在全世界数以千计兼职的玩家们来发展它，谁曾料到会发生这样的事情呢？

我当然也没料到，Linux 出现在我电脑萤幕是在 1993 年初，当时我埋首于 UNIX 及开放性原始码的软件发展已有十年，1980 年代中期，我是 GNU 专案首批的贡献者之一，我写过许多开放性原始码的软件放到网路上供人使用，也曾独立或协同发展好几个程序（nethack，Emacs 的 VC 和 GUD 功能，xlife，…等等），这些程序到今天仍广泛地为人所用，我想我知道这是怎么办到的。

GNU 是自由软件基金会（Free Software Fundation）的一个专案，目标是发展出 UNIX 上所有程序的自由版本，Emacs 是自由软件基会发展出来的一支程序，可做文字编辑器，提供写程序的整合发展环境，用来读电子邮件，新闻群组，甚至浏览网页。更详细的资讯请参考 http://www.gnu.org。 ―― 译注。

Linux 扭转了许多我认为我已知道的观念。多年来我一直宣扬使用小工具集、快速原型发展及程序进化的 UNIX 福音。但我也相信对于有一定复杂度的程序必需使用集中和有经验的方法来开发，我相信最重要的软件（操作系统以及庞大的工具程序如 Emacs）必须如建造一座教堂般，由个别的高手或一小群专家在光辉的孤立中小心翼翼地精雕细琢，时机未到之前，不会释出测试版。

Linus Torvald[^2] 的软件发展风格（尽早并经常发表新版本，授权每一件作者可以委托的事，不拒绝几乎到混乱程度的程序）的出现如同一个惊奇，没有令人肃然起敬的教堂，甚至 Linux 的同好们似乎组成了一个有不同流程和不同方式的大市集（Linux 的档案服务站台就是它适切的象征，每个人都服从着自由的规则），以这个风格发展出来的 Linux 既一致又稳定，表面上看来真是一连串的奇迹。

Linus Torvald 是 Linux 核心程序（kernel）的原始作者。 ―― 译注。

市集模式似乎是可行的，并且运作得很好，这个事实带来了相当的震憾。当以我的方法去认知时，我除了努力做好个人的专案，并也试着去了解为什么在Linux的世界，不但没有因为浑沌不清而四分五裂，反而以教堂建造者几乎想像不到的速度在茁壮。

直到 1996 年年中，我想我才开始了解这一件事。我得到了一个绝佳的机会来试验我的理论，这个机会是一个开放性原始码型式的专案，正好可以试用市集模式来发展，所以我做了这个专案，而且更有意义的是它成功了。

接下来在这篇文章中我将陈述这个专案的故事，并且以它为例提出关于有效地利用开放性原始码模式来发展软件的格言，这些法则并非都是我在 Linux 中第一次学到，但我们可以看到 Linux 的世界是怎么赋予它们特别的意义。如果我是对的，那么这些格言将会帮你真确地了解是什么促成 Linux 社群成为好软件的原创者，并且帮助你变得更具生产力。

第二章 信一定要寄到

自 1993 年起，我一直担任一家提供免费上线的小型 ISP 的技术人员，这家 ISP 叫做 County InterLink（CCIL），位于宾夕凡尼亚州的 West Chester。（我本身参与捐款设立 CCIL，并写了我们独一无二的多人佈告栏软件，你可以用 telnet 连线至 locke.ccil.org 一探究竟。目前它共有三十条线，可提供近三千位的使用者上网。）这个工作让我可以一天二十四小时透过 CCIL 56K 的线路上网。事实上，我的确非常需要它！

因此我必须常常利用便捷的网际网路电子邮件，但由于一些复杂的原因，使得我家里的机器（snark.thyrsus.com）要以 SLIP 协定连上 CCIL 有所困难。最后我还是做到了，但我马上发觉我必须周期性地以 telnet 连上 locke 来检查我是否有新信件，这实在是一件烦人的事。我想要的是︰我的邮件可以被送到 snark，而且送达时会通知我，然后我可以用 snark 上的工具程序来处理这些邮件。

网路原生的 SMTP（Simple Mail Transfer Protocol）转信功能在这里帮不上忙，因为我个人的机器并不是时时都和网路连结着而且它也没有固定的 IP 位址。我所需要的程序是这样的︰它可以间歇地连线把我的电子邮件都抓回来并放在我的机器。我知道有这样的程序，它们大部份都使用一个简单的网路应用协定叫 POP（Post Office Protocol）。目前 POP 是最通用的邮件客户端协定，但当时我使用的邮件读取端却没有这个协定。

我需要一支 POP3 的客户端程序。所以我到网路上搜寻之后找到一个。其实我找到了三或四支这样的程序。我使用了其中一个一阵子，但是它少了一个重要的特性，就是精巧地处理抓回来信件档头附的来源处，以使收件人能回覆信件至正确的网址。

这个问题是这样的︰假设 locke 上有一个叫做 joe 的使用者寄信给我，当我把信抓到 snark 上并回信给 joe 时，我的送信程序会傻呼呼地试着把这封回信送给根本就不存在 snark 上的使用者 joe。所以我必须动手编辑回信的网址即加上 <@ccil.org>，很快地这变成了一件颇痛苦的事情。

很明显的这是电脑应该帮我做的，可是现有的 POP 客户端程序却没有任何一支知道要这么做。这使我们学会了第一课︰

格言1︰好软件都是起源于程序发展者要解决切身之痛。

也许这已是众所皆知（不是有句着名的谚语叫︰「需要为发明之母」吗？），但有多少软件发展者为了薪水，把时间都耗在写他们既不需要也不喜爱的程序上呢？然而这样的事不会发生在 Linux 的世界 ―― 这也许可以解释为什么由 Linux 社群们发展出来的软件的平均水准都这么高。

所以，我是否该立即如抓狂般地投入写作一支新的 POP3 客户端的程序来和既有的一较高下？并不如你所想的，我仔细地检视我手上已握有的 POP 工具程序，看看那一支最符合我的需要，因为︰

格言2︰优秀的程序师知道要写程序，伟大的程序师知道要改写（和重覆利用）程序。

我并非在宣称我是一个伟大的程序师，但我愿去效法。伟大的程序师还有一项重要的特色是老制造着偷懒的办法，他们认为人们争取最好的成绩并不是为了努力的过程，而是为了最后的结果。更何况由一个部份可行的解决方法开始总比什么都没有容易得多。

举例来说，Linus Torvalds 当初写 Linux 的核心程序时也不是从零开始，他是由借重 Minix 的程序和构想开始的（Minix 是一个像 UNIX 的小型操作系统，它在386机器上执行），然而到最后原来属于 Minix 的码不是被移出就是被改写 ―― 尽管如此，Minix 的码毕竟曾存在于 Linux 中，并且曾为尚未茁壮的 Linux 提供一个骨架，最后终于诞生了 Linux。

为仿效这样的精神，我开始找寻一个现有而且写得有条理的 POP 工具程序，来作为我发展新程序的基础。

在 UNIX 的世界中，原始代码共享的传统让我们可以很容易地重覆利用代码，这也是为什么 GNU 专案要选择 UNIX 作为它发展的平台，UNIX 操作系统本身几乎没做什么保留，Linux 的世界也遵行着这个传统，到接近它技术极限的地步，它供人运用的开放性原始码程序，有天文数字般地多，所以在 Linux 已有的资源中找到一个足够好的程序要比其他的操作系统容易。

而我也的确找到了，连我先前的搜寻再加上这一次总共有九个程序候选 ―― fetchpop、PopTart、get-mail、gwpop、pimp、pop-perl、popc、popmail 及 upop。我首先选择 Seung-Hong Oh 写的 fetchpop 作为出发点，我加入了我要的「重写邮件档头」功能，并且作了多处的改善。原作者同意将这些纳入 fetchpop 的 1.9 版。

几个星期之后，我缓缓地读着 Carl Harris 写的 popclient 的原始码，并且发现了一个问题︰虽然 fetchpop 有一些好的初始想法（如它的伺服程序模式），但它只能处理 POP3 的协定，而且它的原始程序只有业馀的水准（Seung-Hong 是个聪明的程序设计师，但当时经验不够老道）。而 Carl 写的代码就比较好，具相当的职业水准和稳固性，但他的程序缺乏了许多重要的特色，如 fetchpop 中巧妙的实作（包括我加入的部份）。

要换还是不换呢？假如我选择换的话，那么换到一个较好的发展基础所要付出的代价就是要丢掉我已经写好的代码。

事实上我选择换的动机是为了能支援多种 post-office 的协定，虽然 POP3 最广为人采用，但它却不是唯一可用的协定。Fetchpop 和其他同类的程序并不支援 POP2、RPOP 或 APOP，而我早先有一个概略的想法（只是为了有趣）︰加入IMAP（Internet Message Access Protocol，最新最强的 post-office 协定）协定的支援。

一个更理论性的理由让我觉得换到新的发展基础是个好主意，这个理论是早在 Linux 出现前，我就已经学会了︰

格言3︰「计画好如何捨弃一条路吧，你迟早会想尽办法这么做的。」（Fred Brooks，《人月神话》，第十一章）

否则，计画走另一条路吧。针对一个问题，在尚未实作出第一个解法前，你通常并不真正了解这个问题。也许第二次的时候你才能充分了解怎么做才对，所以即使你想做对一件事，但起码你要准备从第一次做起。

在《Programing Pearls》，著名的资讯工程格言家 Jon Bentley 评论 Brooks 的观察说「如果你丢弃一次，你将丢弃第二次」。他几乎是对的。他们两人的重点不是你应该预期第一次的尝试是错的，而是以正确的想法开始会比挽救一场灾难来得更有效率。

我告诉我自己︰修改 fetchpop 是第一次。所以我换到 Carl Harris 的 popclient 继续发展。

当 1996 年 6 月 25 日我送给 Carl Harris 我第一次对 popclient 所做的修正后，我才晓得他已经对这支程序没兴趣了。原来的代码乏人照料已有一段时间，还包括一些次要的错误。有许多修正要做，很快的我们两人都同意由我接手整个程序是合理的一件事。

在我不经意间，这个专案的规模扩大了，我不再只注意现在的 popclient 要修补那些次要的部分，而是要接下维护整个整程序，在我脑海曾浮现许多主意，我想这可以引导我改变 popclient 的主要部分。

在鼓励分享代码的软件文化下，一个专案以这样自然的方式演进。我表现出︰

格言4︰抱持正确的态度，就会发现有趣的问题。

但 Carl Harris 的态度更为重要，他懂得︰

格言5︰当你对一个问题不再感兴趣时，你最后的责任就是找位能胜任的接棒人。

虽然 Carl 和我没讨论这些，但我们却有一个共同的目标就是对这个问题写出最好的解法。现在唯一的问题只剩︰证明我是个可信赖的人，而我已经做到，所以他便欣然地把这支程序交给了我。我希望这个专案在我手中能变得更好。

第三章 拥有使用者的重要

我继承了 popclient，更重要的是我也继承了它的使用者。拥有使用者是很棒的一件事，并不是因为这展现出你在解决他们的问题，或是你在做好事。而是好好地培养使用者，他们可以变成协同发展者。

UNIX 的传统中有一种力量，那就是许多使用者同时也是程序高手，Linux 促使这变成一件非常愉快的事。这是因为原始码是公开的，所以使用者可以变成有影响力的高手，这对缩短除错的时间实在太有助益了。只要你给一点掌声，使用者们会帮你诊断问题，建议需修正的地方，以及改进代码，这比你自己一个人包下全部的事要快得许多。

格言6︰把你的使用者视为协同发展人，可以让你伤最少的脑筋，但做到原始码的快速改善，程序的除错有绩效。

这种效应所造成的影响力很容易就被低估，事实上，开放性原始码世界的所有人，几乎都严重低估了因使用者增多而产生用以对抗系统复杂度的力量，直到 Linus Torvalds 明白地揭露了这一点。

其实我认为 Linus 在技术上最聪明和最重大的贡献并不在于写出 Linux 的核心程序，而在于发明 Linux 的发展模式。在一次和他的会面中，我提出了这点见解，他微笑着，并重复他常说的一句话︰「基本上我是一个非常懒的人，因其他人在 Linux 上真正的努力，而感到与有荣焉。」懒惰就像狐狸一样地精明，或者就如同 Rober Heinlein 曾说︰「因为太懒所以成功了。」

回顾过去的例子，在 GNU Emacs 的 Lisp 程序库及其 Lisp 代码的资源库中，我们可以看到 Linux 模式所用的方法和所得的成功。相对于 Emacs 中用 C 语言写的核心部分及自由软件基金会其他的工具（这都是以建造教堂的模式发展），Emacs Lisp 代码的资源库非常地使用者导向并且更新很快，好的点子和原型在最后成熟稳定前常常都已重写过三或四次，藉由网际网路而来的非紧密合作进行得很频繁，就像 Linux 一样。

我在还没写作 fetchmail 前，最成功的杰作大概要算是 Emacs 的 VC（version control）功能了，这项专案进行时，我用像 Linux 一样的合作模式，用 email 和其他三位作者互相联系，到今天为止，我只见过其中一位（他就是 Richard Stallman，Emacs 的作者以及自由软件基金会的创办人）。Emacs 的 VC 功能是作为 SCCS，RCS 及后来的 CVS 的前端处理，提供版本控制功能「按一下」的操作法，这是由某位仁兄撰写的小而有力的 sccs.el 功能改良而来，VC 功能的发展相当成功，这是因为 Emacs 用的 Lisp 程序可以快速地经历「发表 ―― 测试 ―― 改良」，而不像 Emacs 本身核心的发展那样缓慢。

Emacs 的故事并非独一无二。有其他的软件结合了双层的架构与双层的使用者，前者采用教堂模式开发核心，后者采用市集模式开发工具箱。例如 MATLAB，一个商业的资料分析与视觉化工具程序。MATLAB 与其他类似结构的产品都指出，发酵与创新都在开放的部份发生，在那里各种社群都能够修补这些成果。

第四章 尽早发表，经常发表新版本

尽早，经常发表新版本是 Linux 发展模式中非常重要的一环。过去，大部份的程序发展者（包括我）认为这个策略对较大型的专案是不好的，因为早期的版本几乎可以定义为多错的版本，我们并不想把使用者的耐心消磨殆尽。

这个过去的信念加强了软件的发展要用建造教堂的方式的想法。假如我们极欲强调的目标是让使用者在软件中发现最少的错误，那你何不每半年（或更长）才发表一个新版本，并且在发展新版本的期间，卖力地除错而累得像条狗似的。Emacs 的核心部分（用 C 语言写的）就是用这种方式发展的，但它的 Lisp 程序库就不是。因为 Emacs 的 Lisp 资源库不在自由软件基金会的管辖内，你可以在其中找到新发展的 Lisp 程序使用，而不受限于 Emacs 的发表周期。

成功采用市集模式的开放原始码例子，早在网际网路时代之前，与 UNIX 无关，这网际网路的传统早就存在。info-Zip 这支压缩工具的发展在 1990-1992 年，主要是针对 DOS，就是一个例子。另一个子是 RBBS 电子佈告栏（也是针对 DOS），于 1983 年开始，发展了一个强壮的社群，直到目前（1999 年中）都还经常发布新版本，尽管网路邮件与档案分享有更巨大的优势。当 info-Zip 社群依赖网路邮件形成的规模，RBBS 的开发者文化实际上在 RBBS 支撑线上社群，使它完全独立于 TCP/IP 的基础设施。

在 Emacs 的 Lisp 程序库中，最重要的一个来源是俄亥俄州的 elisp 资源库，它先前的精神就已经具有今日大规模 Linux 资源库的特色，但当时我们之中却很少有人思考过我们到底做了什么，甚至想过我们已对自由软件基金会的「建造教堂」的发展模式提出质疑。1992 年左右，我很认真地要把俄亥俄州 elisp 资源库中许多程序加入 Emacs 正式的 Lisp 程序库中，但却遭遇到官方的阻碍而失败了。

但一年之后，Linux 已受到四方的瞩目，也带来不同而且更健康的观点，Linus 的开放性发展策略和「建造教堂」非常不同。当时 Linux 的两大资源库 sunsite 和 tsx-11 正在萌芽，有许多版本在交流着，Linux 核心系统发表新版本的频繁程度前所未有。

Linus 以最有效的方法，视使用者为协同发展者︰

格言7︰尽早，经常发表新版本，并且倾听使用者的意见。

Linus 的创新并不完全在此（这在 UNIX 世界是行之有年的传统了），而在于提高这个做法效力的层次，使其能匹配他在发展的系统的复杂度。早期在 1991 年左右，许多人都知道他一天内发表一次以上 Linux 核心程序的新版本。因为他善用网际网路和协同发展者们合作更胜于其他人。

他能我也能吗？还是只有像他这样的天才才办得到？

我并不认为如此，虽然 Linus 是一位很厉害的高手（在我们之间，有多少人能够完整地写出一个具有商品品质的操作系统核心呢？），但 Linux 并不是一个空前耀进的观念，Linus 也并非（或者说至少目前还不是）如 Richard Stallman 或 James Cosling（NeWS 和 Java 的创始者）这样的天才创新者，而我个人认为他是一位天才工程师，他有避免程序错误及避免程序发展掉入死胡同的第六感，和找到两点间最省力路径的技巧。事实上，整个 Linux 的设计中，我们可以看到 Linus 表现出的品质和他保守而简单的设计取向。

承上所说，如果快速地发表新版本和彻底地善用网际网路媒介不是突然冒出，而是以 Linus 天才工程师洞见所得的最省力路径，那么他把网际网路的什么功用发挥到最大？

其实问题的本身已反应出答案，Linus 让 Linux 的高手和使用者们经常感觉刺激和有收获 ―― 感觉刺激是因协助发展 Linux 得到自我满足，感觉有收获是因经常（甚至每天）进步的 Linux 帮助他们把工作做得更好。

Linus 想直接将投入除错和发展的「人-时」（person-hours）数加到最大，即使要付出的代价是代码的不稳定，或是因一些程序错误被证实无法追踪而吓走原有的使用者。Linus 会如此做是因为他相信︰

格言8︰以足够多的 beta 版测试者和协同发展者做基础，几乎程序中的每一个问题都可以很快地找出来，并且对某些人而言，针对发现的问题的解决方法是显而易见的。

或者用比较不那么正式的说法︰「足够多的人来看程序，所有的错误都变得浅显」，我将此命名为「Linus法则」。

我原本先前的论述是︰「某些问题对某些人而言是容易解决的」，但Linus有不同的意见︰「了解并解决问题的人不一定是第一个发现问题的人」，他说︰「有些人发现问题，有些人解决问题，我愿正式强调 ―― 发现问题是较大的挑战。」而在 Linux 的世界，发现问题和解决问题的速度都很快。

对「Linus法则」来说，我想这就是教堂模式和市集模式最主要的不同，以教堂建造者的观点来看程序发展，程序错误和相关问题难以处理，并隐伏在深处，需要数个月的工夫仔细察看来找到它们，而这对程序发展者的自信少有加许。发展的期间越长，一旦经冗长等待的新版本发表后不如预期完美，使用者的失望也越大。

另一方面就市集发展模式的观点来看，它假设程序错误都是显而易见的，或者说至少在上千位渴望新版的协同发展者面前，程序错误很快地都变得浅显，因此经常发表新版本是为了获得更多的指正，以及避免偶尔笨拙的修补。

以上已说明足够「Linus法则」。如果「Linus法则」是假的，那么任何像 Linux 核心程序这样复杂的系统，并且拥有像 Linux 核心程序这么多的高手在发展，早就因沟通不良及未被发现的程序错误而崩塌。反过来说如果「Linus法则」是真的，那正可解释为什么相对地 Linux 比较没有程序错误。

也许「Linus法则」并不是一个惊奇，社会学家多年前发现到在一群素质相同的观察家中，他们共同做出的预测要比其中任一位单独所做的要来得可信。这被称为「Delphi¹效应」。可见 Linus 只是把「Delphi效应」用在发展操作系统时对程序的除错上，所以「Delphi效应」能够克服发展系统的复杂度，即使复杂如操作系统核心²。

「Linus法则」也可称之为「程序除错可并行处理」。虽然多位程序除错者在除错时需要和一些程序发展者沟通协调，但是程序除错者彼此间却不需如此。所以增加程序除错者并不会像增加程序发展者那样，多出平方倍的复杂度和管理成本。

理论上造成程序除错效率减低的原因是多位除错者重复同一件工作，就实际的情形而言，在 Linux 的世界中几乎不会发生这样的状况。「尽早，经常发表新版本」这个策略使得程序错误的修补回馈得很快，藉此将除错者重复同一件工作的机会减至最低³。

Brooks 曾发表过一个即席的看法︰「维护一个广为人用的程序的总成本通常是发展这个程序成本的百分之四十或更多，令人讶异的是这维护成本深受使用者人数的影响，越多的使用者可以发现越多的程序错误。」（这正是我所要强调的）

因为增加越多的使用者，就会增加考验程序的方法，所以使用者越多，发现的程序错误也越多，当使用者也是协同发展者时这种效应会再被放大，每一位使用者以不同的直觉，不同的分析工具，和不同的角度来标明程序错误，因为这些不同，「Delphi效应」似乎真的有作用了，在个别情况下的除错工作，也因这些不同而减少重复出力的可能。

所以，以程序发展者的眼光看来，增加更多的 beta 版测试者也许不会减少目前藏在深处的程序错误的复杂度，但可以增加某位除错者以他的工具程序找到这个程序错误的机会，而这个程序错误对这位除错者来说是浅显的。

Linus 也在这种方式上下了赌注。因为程序都会有错误，Linux 核心程序以一种特别的方式来定出版本号码，让使用者可以选择要用上一个比较稳定的版本，还是选择错误风险比较高的新版来使用新功能。这个策略尚未正式为大部分的 Linux 高手所採行，但是它也显示出一个事实，就是使用者可做选择使得这两种版本都更有吸引力⁴。

【未完待续】