我多次引用了弗雷德里克·P·布鲁克斯的经典著作《人月神话》（The Mythical Man-Month），在许多层面，他的观察至今还是颇具洞见的。我衷心的推荐其1986年刊发的包含《没有银弹》（No Silver Bullet）25周年纪念版。

Assison-Wesley社，ISBN 0-201-83595-9 （中文版：清华大学出版社，2002 ISBN 978-7-302-05932-5）

这个新版本还包含一份非常珍贵的回顾，一份布鲁克斯在20年后对文中少数几个没能经得住时间考验的论点的回顾。在本文第一版几近完工的时候，我首次读到了这篇回顾，并惊讶的发现布鲁克斯把市集模式归功于微软！（事实证明这显然是不正确的，1998年我们通过“万圣节文件”获知，微软内部开发团体朋党林立，不可能存在市集模式所必须的全面代码共享）

杰拉尔德·温伯格

[阅读全文]

与历史同行，是一种奇妙的感觉……

1998年1月22日，大约在我的《大教堂与市集》初版七个月后，网景通讯公司宣布了开放网景浏览器源代码的计划，事前我一无所知。

不久之后，网景的副执行总裁兼首席技术官埃里克·哈恩（Eric Hahn）给我发来了一封电邮：“首先，我要代表网景的全体同仁，感谢你指引我们走到了这一步。你的思想和著述给了这个决定至关重要的启迪。”

接下来的一周，我应网景之邀飞抵矽谷。和他们高管以及技术人员共同参与了一个为期一天（1998年2月4日）的战略会议。会上，我们决定了网景的源代码释放计划和许可证相关事宜。

几天后我写到：

网景正打算在商业世界里给我们提供一场大规模的、真正全球化的市集尝试。开源文化正在面临考验：如果网景此举失败，开源文化就会信誉扫地，商业世界在未来十年里都会对其不屑一顾。

另一方面，这也是个绝佳的机会。华尔街和其他地方对此举最初报以谨慎的肯定。我们也赢取了一个证明自己的机会。如果网景能借此重夺市场份额，或许会引发软件业一场等待许久的革命。

[阅读全文]

1997年最初的《大教堂与市集》以这样的预见收束——程序员/无政府主义者快乐的网络部族，战胜并压倒了等级森严的传统闭源世界。

然而，许多人对此持怀疑态度，他们提出的问题应该得到中正的回应。多数对市集模式的异议可以归结为以下观点：开源支持者们低估了传统管理对生产力的提升作用。

传统思维的软件开发经理经常会指责开源项目组的创建-变动-解散太随意了。这种随意性大大抵消了（对于单个闭源开发者来说）开源社区在人数上的优势。他们会指出软件开发取决于长时间的持续投入，和预期的消费者持续购买程度。而不只是取决于有多少人往锅里扔骨头，然后等着它炖熟。

无可否认，这些论调有一定道理。其实我早就在《魔法大锅炉》（The Magic Cauldron）一文中预计增值服务将会是未来软件业的经济命脉。

但是这个论调却回避了一个重要的问题，它暗自假设开源开发不能提供持续的投入。事实上，有些开源项目已经在相当长的周期里保持了一致的发展方向和有效的维护社区，而不需要传统管理中必不可少的激励模式和制度约束。

[阅读全文]

这句话一语中的：好的软件都是源自解决开发者的切身之痛，推而广之则是因为很多人也面临着相同的困扰。这将我们带回了“格言1”，或许换个角度重申能让其更具效用：

18.要解决有趣的问题？那就先找到你感兴趣的吧！

To solve an interesting problem, start by finding a problem that is interesting to you.

卡尔·哈里斯先前的popclinet如此，我的fetchmail也是如此。这个观点已经久为人知。而更有趣（Linux和fetchmail历史中更值得我们关注的）的话题则是出现在下一阶段——由用户和协作开发者组成的庞大的活跃社区，推动了软件的演进。

《人月神话》中，布鲁克斯指出程序员的编程时间不能简单叠加。为已经延期的项目增派人手会让它拖地更久。像我们之前提到的，他指出：项目的复杂度和沟通成本会以开发者人数为基础呈平方指数增长，而业绩仅能直线上升。

[阅读全文]

本文的早期审阅人和测试者不断地希望了解成功市集风格的先决条件，这包括项目负责人的资质和着手建立协作开发社区时代码的开放状况。

很明显，市集风格不能帮你从零开始编程。【注】你可以利用市集风格来测试、调试、改进代码，但是用这种风格来孕育一个项目会很困难的。李纳斯没有这样试过，我也没有。你初建的社区至少需要一个可以运行和测试的东西。

一旦你着手组建团队，就需要给出一个可行的承诺。你的程序并非必须运行良好，它可以是粗糙的、遍布瑕疵的、不完善的、也可以是缺少说明文件的。但是必须满足（1）它能运行；（2）能让潜在的协作开发者相信在不久的将来它能变得精良。

Linux和fetchmail都是在有了健硕，诱人的基础设计之后才推向公开的。我所提到的市集模式观察者们认为这是至关重要的。进而得出结论：一个睿智并且具备高超设计才能的领导是必不可少的。

但是李纳斯是从Unix出获得的设计，而我则是从早期的popclient（尽管日后改动很大，但是还无法和

[阅读全文]

在我们回到广义的软件工程问题之前，还有几条fetchmail开发中的独特细节需要深思。非技术性的读者可以安心跳过本章。

rc（fetchmail用户配置）文件语法中包含了一些完全不需解析的，可选的“噪音”关键词。与传统“关键词-对应值”匹配关系相比，它们所带来的趋近于英语语法的配置文件更具可读性。

这源自一个深夜的实验，当时我注意到rc文件的配置命令非常像一门微型指令语言。（这也是我把关键字“server”改成“poll”的原因）[1]

在我看来，努力使这个微型指令语言更像英语可以让其更便于使用。现在我虽然支持“让它成为一门语言（make it a language）”的设计流派（诸如Emacs、HTML和很多数据库引擎那样），但是并不热衷于“类英语”的语法。

[阅读全文]

现在有了一个简洁新颖的设计，我确信代码运行稳定，因为我每天都在用，公测名单也枝繁叶茂。我逐渐发现，我不再只是研发一个可能只有少数人才会用到的琐碎的个人软件了。而是在主持一个所有使用SLIP/PPP邮件接口的Unix用户都切实需要的软件。

凭借SMTP转发功能，fetchmail把竞争对手远远的甩在了后面，成了一个潜在的“领域杀手”。一个在同领域鹤立鸡群的杀手，它让对手们不但被抛弃而且被遗忘。

这种结果是可遇而不可求的。一个卓有建树的设计构想会把你顺理成章，甚至命中注定地推向成功。而找到这类构想的方法无非是拥有很多值得尝试的创意——或者能用工程的眼光把其他人的创意发挥到令原作者都难以想像的境地。

安迪·塔能鲍姆[1]首先为IBM PC机开发了一个简单的原生Unix系统，他的本意是把它作为一个教学工具（他称之为Minix）。李纳斯则把Minix

[阅读全文]

项目的真正转折点来自一份哈利·豪切斯的草拟程序，通过它我们可以将邮件转发至客户机的SMTP端。几乎在收到程序的同时，我就意识到，这个功能会让其他的邮件传送模式都成为历史。

我曾用几周的时间摆弄fetchmail，当时总觉得虽然界面还能用但是却不够漂亮，到处是用处不大的选项。“将收取到的邮件归档”或者“标准输出”选项尤其让人心烦，可我却说不出个所以然来。

（如果你对网络邮件的技术细节不感兴趣，那么就可以安心的略过下面两段。）

当我考虑加入SMTP转发的时候，才发现popclient包揽了太多的事情。它身兼两职——既是一个邮件传输工具（MTA）又是一个本地投寄工具（MDA）。但是如果有了SMTP转发功能，它就可以摆脱MDA的工作。像sendmail一样专注于MTA并把邮件的本地投寄工作交给其他软件。

几乎每个支持TCP/IP

[阅读全文]

在研究了李纳斯的作法，并得到他何以成功的理论之后。我决定在我的新项目中（当然没有Linux那么复杂和雄心勃勃）有意地尝试这些理论。

但是我首先要对popclient做大幅的重写和简化。卡尔·哈里斯的代码很扎实，但是却如同大多C程序设计师一样，有种不必要的繁琐。他把代码置于核心，而数据结构作为其支撑。结果代码很漂亮，而数据结构就很特别了，甚至可以说很缭乱了。（至少就LISP老手的标准而言是这样的）

除了改进代码和数据结构，我的重写还有另一层目的，就是要把它演进成一个我完全理解的东西。因为要是你不能对程序了如指掌，维护起来可就不好玩了。

在最初的一个月里，我只是遵循卡尔的设计理念。我所作的第一个重要改变是加入了对IMAP的支持。做法是：把原来的协议支持部分改写成一个通用驱动和三个可调用的方发表（分别针对POP2、POP3和IMAP）。这些变动都阐明了一个程序员需要铭记在心的通用原则（特别是对于像

[阅读全文]

从宏观上，可以说市集风格大大加速了调试和代码演进，但是如果想从微观（开发者和测试者日复一日的工作中）上，准确理解这是如何和怎样起到作用的，却又是另一回事了。在本章中（作于本书初版后三年，采纳了阅读本书，并身体力行的开发人员的意见），我们将关注其背后的机理，对于技术不感兴趣的读者可以安心的跳到下一章。

理解问题的一个关键在于认清如下的重要事实，那就是那些对源代码知之甚少的用户所提交的错误报告通常派不上大用场。因为他们一般只看到表面症状。在提交错误报告的时候，习惯从自身环境出发，这样（一）会忽视重要的背景数据，（二）通常会遗漏重现错误的关键步骤。

更深层的问题是，开发者和测试者的思维模式不同。测试者是由表及里的看问题，而开发者则是自内而外。在封闭源代码的开发环境里，他们被各自的角色羁绊，往往各说各话而且认为对方很难沟通。

开源开发打破了这种束缚。基于源代码，测试者和开发者可以很容易建立一个统一的模型，并借此有效沟通。仅仅描述表面症状的问题报告和深入源代码基础抽象模型的报告，对于开发者而言作用是截然不同的。

[阅读全文]