最初，这里有一群真正的程序师。

他们从不以此自称，也不曾用“黑客”或其他特殊的字眼。据一位“真正的程序师”回忆，这个说法是1980年后才出现的。但是从1945年开始，计算机科技便不断吸引着这世界上无数最睿智和最具创造力的头脑。自从艾克特（Eckert）莫齐利（Mauchly）发明第一台ENIAC计算机之后，便不断有狂热的程序师投身其中，他们以编写程序、探索技巧为乐。一点一滴的积累起了一种具有自我意识的科技文化。

这批“真正的程序师”通常都有工程学和物理学背景，作为业余无线电玩家，他们称得上嗜痂成癖。厚厚的眼镜，白白的袜子，涤纶衬衫，再配上一条领带；用机器语言、汇编程序、FORTRAN和一堆“远古级”的语言编程。

从二战末到70年代早期，在这批处理和“铁块”大型机的黄金岁月里，“真正的程序师”是计算机科技文化的主宰。一些令人敬畏的黑客传说，就源自这一时期。这其中就包括诸多版本的“墨菲法则”

[阅读全文]

本文的改进得益于众多朋友与我交流并提出意见。特别要感谢Jeff Dutky <dutky@wam.umd.edu>， 他提出了“调试可平行展开”的观点，并帮我完成了其后的分析。同样要感谢Nancy Lebovitz <nancyl@universe.digex.net>，她建议我效法温伯格引述克鲁泡特金。来自General Technics邮件列表的Joan Eslinger <wombat@kilimanjaro.engr.sgi.com>和Marty Franz <marty@net-link.net>提供了关于可读性的批评。Glen Vandenburg <glv@vanderburg.org>指出了贡献人群自我选择的重要性，并对改进“冗余设计”做出了富有成效的探索。Daniel Upper <

[阅读全文]

我多次引用了弗雷德里克·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

[阅读全文]