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

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

一旦你着手组建团队，就需要给出一个可行的承诺。你的程序并非必须运行良好，它可以是粗糙的、遍布瑕疵的、不完善的、也可以是缺少说明文件的。但是必须满足（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

[阅读全文]

因为九月初要出门两次，所以翻译要稍微拖后了。第八章可能要九月5号之后才能翻译出来了哦～～～

望广大读者继续关注哦～～呵呵，我自己感觉良好呢。好像自己很多读者的样子。

今天是西元2007年8月27日，农历丁亥年七月十五，也就是鬼节。

无论如何更重要的是，今天是我Blog的满月。

2007年7月27日的凌晨，我写下了《Mozilla的历史》一文，作为开博的标志（之前的是用来测试Blog的）。随即申请大陆信息产业部备案（至今仍在办理中），当日下午用手机信息形式通知朋友来捧场。

一个月中，我用中文写出了全部早期浏览器的历史；北美首个网站的历史；表情符号、万维网译名、网上冲浪的由来；翻译了《Mozilla之书》和《Tux福音》。当然还有其他的以及我目前正在翻译的《大教堂与市集》。

一个月内结识了很多朋友，比如幽谷部落的格主，Mybrand的老板，帮我改错的windrose和roy_hu，淘宝网德隆的董老板，译言的同仁（当然少不了雷大），Mozine的朋友（特别是许久不见的震哥还有那个随便给我该名的紫MM），志同道合的大梵天，秦皇岛的妩伶……总之多的数不过来。（排名不分先后，呵呵）

[阅读全文]

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

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

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

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

几乎每个支持TCP/IP

[阅读全文]

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

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

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

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

[阅读全文]

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

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

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

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

[阅读全文]

早发布，常发布

尽早和尽量频繁的发布是Linux开发模式的一个重要部分。包括我在内的大多数开发人员都曾一贯认为——对于一个大型工程来说这并不是个好办法。因为早期版本几乎就是问题版的同义词，而你却并不想过早地把用户的耐心消耗殆尽。

这种信念促使人们普遍采用大教堂式的开发模式。如果首要目标是令用户尽可能少的遭遇错误，那么何不半年（或者更久）发布一次呢？这样我们就有足够的时间像只狗一样周旋其间。Emacs的C核心就是这样开发的，而Lisp库则恰恰相反——在自由软件基金会所辖以外，有很多独立的新版本或研发代码可供选择。【注1】

其中最重要的，俄亥俄州立大学的Emacs Lisp 存档，在当时就已经具有了今天Linux大型数据管理的许多精神与气质。但是我们之中少有人深思过究竟要做什么，以及这个存档的存在暴露了自由软件基金会大教堂模式的哪些问题。在1992

[阅读全文]