Linux有一套令人感到吃惊的软件工程理论，为了验证这些理论，我专门在fetchmail项目中加以应用，效果之好让我感到惊讶。本文将讨论这些理论，并对比两种完全不同的开发模式：绝大多数商业公司所采用的“大教堂”模式和Linux世界采用的“集市”模式。两种模式的根本不同在于他们对软件排错有着完全对立的认识。我从Linux的经验出发，证实了这样一个命题：“只要眼睛多，bug容易捉”，这和那些由利己个体组成的自纠错系统有着异曲同工之妙。文末，我探讨了在这种观念的影响下，软件可能拥有的未来。
1
大教堂与集市
Linux是颠覆性的，就在5年前（译者注：此文最初版成形于年，后几经作者修订，年版本为最新版本。历经20余年，此文经受住了时间考验，文中所揭示的理论至今没有过时），谁能想到，几千名散布在全球各地的程序员，利用业余时间，仅仅通过Internet，就鬼斧神工般地造就一个世界级的操作系统？
我绝对想不到。年初，Linux进入我视野的时候，我在Unix和开源领域已经有10年开发经验了，我是年代中期GNU最早的贡献者之一，当时我已经在网上发布了一些开源软件，而且还正在开发或者合作开发一些程序（nethack、Emacs的VC和GUD模式、xlife等等），这些程序直到现在仍然被广泛的使用着，我并不是菜鸟。
Linux推翻了很多我以为我懂的东西，多年以来，我一直在宣扬“小工具”、“快速原型法”以及“演化式编程”等Unix信条。但我也相信，如果超过了一定的复杂度，更集中式的管理和更严格的流程是很有必要的。我相信大多数重要软件（操作系统和真正大型工具如Emacs编辑器）需要像建造大教堂那样，在与世隔绝的环境下，由天才式专家或几个行家里手精心打造，不成熟时绝不发布beta测试版。
LinusTorvalds的开发风格是：早发布、常发布、委托所有能委托的事、开放到几乎混乱的程度，这些都令人感到惊讶不已。在Linux社区，没有建筑大教堂那样的安静和虔诚，倒更像是一个乱糟糟的大集市，充满了各种不同的计划和方法（Linux的文件服务器就是个很好的例子，这里可以接受任何人的代码和文档提交），
然而，就在这样的环境下，居然诞生了一个稳定的操作系统，这真是奇迹中的奇迹。
事实上，集市模式真的管用，而且非常管用，这让所有人震惊。我开始以自己的方式去了解这种模式，除了在我的个人项目中努力探索外，我也试着去理解为什么Linux世界没有在混乱中四分五裂，反而以难以想象的速度变得越来越强。
年年中，我慢慢开始理解了，而且幸运地拥有了一个可以测试我的理论的机会，这个机会使我可以有意识地在集市模式下尝试一个开源项目，我这么做了，而且大获成功。
我要讲述的就是这个项目的故事，通过这个故事，我将引出一些在开源开发中很有用的理论，虽然对我来说，这些不都是从Linux中学到的，但我们可以看看Linux是怎样淋漓尽致地运用这些理论，如果我是对的，这些理论会帮助你准确地理解是什么让Linux社区能够源源不断地产生这么多好软件，还能帮助你成为一个富有成效的人。
2
邮件必达
“切斯特互联”(ChesterCountyInterLink，CCIL)位于美国宾夕法尼亚州(Pennsylvania)的西切斯特郡(WestChester)，这是一家小型的免费互联网服务提供商。年以来，作为联合创始人，我曾一直负责CCIL的技术部分,并编写了我们独创的多用户论坛程序——你可以通过telnet连到locke.ccil.org来试试看(译者注：别试了，这么多年了，早不在了)。时至今日，这个程序通过三十多条线路支持近三千名用户访问。这份工作使我能够使用CCIL的56K线路保持每天24小时连在网络上——当然，这是工作需要！
我已经习惯了使用电子邮件，但每过一会儿就telnet到locke上查一下邮件，是一件比较烦人的事。我很希望邮件能够自动地递送到snark（我家里的机器）上，这样，邮件来的时候就会通知我，然后我就能用本地工具来处理它。
互联网原生的邮件转发协议SMTP（SimpleMailTransferProtocol，简单邮件传输协议）并不适用，它最适用于机器一直在线的情况，而我家里的机器并不总是在线，而且也没有一个静态IP地址。我需要这样一个程序，它可以在我时断时续的拨号上网期间，把我的邮件取到本地。我知道有这种软件，它们大多使用了应用层协议POP（PostOfficeProtocol，邮局协议）。现在绝大多数常见邮件客户端都支持POP，但在那个年代，我所用的邮件阅读器并不支持。
看来我需要一个POP3客户端。于是我便到网上找了一个（事实上我找到了三四个），使用了一段时间后，我发现它有个明显的缺陷：它不能正确地解析取回邮件的邮箱地址，导致我不能正确回复。
问题是这样的：比如locke上有个叫joe的人给我写信，我把信取到snark上并试图回复时，邮件程序会傻乎乎地想把它发给snark上并不存在的joe。所以我不得不每次把回复邮件地址修改为
ccil.org的样子，这着实有点烦人。很明显这种事应该由计算机搞定，但没有任何一个现成的POP客户端能做到这点！这给我们上了第一课：
1.好的软件作品，往往源自于开发者个人的痒处。
按说这是显而易见的（正如老话说“需要是发明之母”），但太多的软件开发人员并不需要也不热爱他们正在开发的软件，他们把编程当差事，为的只是拿薪水。Linux世界里可不是这样——也许这可以解释为什么Linux社区里原创软件的平均质量是如此之高。
那么，我是不是应该立即投入到疯狂的编程中，做出一个全新的POP3客户端和其他程序一较高下？那可不行！我把手头的POP程序看来看去，认真思索“哪个最接近我想要的？”，因为：
2.优秀的程序员知道写什么，卓越的程序员知道重用什么。
我不敢说自己是卓越的程序员，我只是模仿他们。卓越程序员们有个很重要的特征是“建设性懒惰”，他们知道人们要的是结果而不是勤奋，而从一个部分可行的方案开始，明显要比从零开始容易得多。
以LinusTorvalds为例，他并没有尝试从零开始写Linux，而是以重用Minix（一个用于PC机的迷你型UNIX类操作系统）的代码和理念作为开始，虽然Linux中所有Minix代码最终都被移除或重写，但它在Linux成长初期确实起到了脚手架的作用。
基于同样的理念，我试图找到一些代码写得还不错的POP程序，作为我开发的基础。
Unix世界共享源代码的传统使得代码重用变得很便利（这正是GNU为什么选择Unix作为基础OS的原因，且不论它对Unix本身的保留意见），Linux世界则把这个传统发挥到技术上的极限。相比其他地方，从Linux世界多达数T字节的开放源码中，找到一些他人写的“足够好”的代码要可行得多。
不出意外，连同上次找到的，我一共找到九个备选程序：fetchpop、PopTart、get-mail、gwpop、pimp、pop-perl、popc、popmail和upop。我首先选择了Seung-HongOh写的fetchpop。我给程序加上了“邮件头重写”功能，并做了一些其他改进，这些改进被作者接受并在1.9版本中发布。
几周以后，我偶然发现了CarlHarris写的popclient代码，同时带来一个难题：尽管fetchpop有一些很好的创意（比如使用后台进程模式），但只能处理POP3协议，代码也略显业余（Seung-HongOh在那时是个聪明但缺乏经验的程序员，这两点都看得出来）。CarlHarris的代码要好一些，专业而稳健，但缺乏fetchpop中一些重要而精巧的特性（包括我写的那部分）。
继续完善fecthpop还是转换到popclient？如果转换，我写的那些代码就可惜了，但同时能换来一个更好的开发基础。
一个更实际的转换动机是popclient对多协议的支持。POP3是最常用的邮件服务器协议，但并不是唯一的。fetchpop以及其他备选程序并不支持诸如POP2、RPOP或AROP这些协议，而我还有点想加上对IMAP（InternetMessageAccessProtocol，互联网消息访问协议，这是最新设计、功能最强大的邮局协议，
转载请注明：http://www.budanx.com/xwzyl/8094.html
