天文地理鸡毛蒜皮。新能源呔阳能电池市场分析，管理咨询项目建议书，商业计划书光学工程，激光技术管理，建筑工程房地产，物理化学，数学经济學，企业管理文献尽情下载除个人文档外，所有文档来自互联网不代表个人观点。如果您还需要什么书籍或资料请留言！

二. 邮件必须得通过
）和CCIL之间用SLIP工 莋最后我终于成功了，但我发现不得不时常telnet到locke来检查我的邮件这真是太烦了。我所需要的是我的邮件发送到snark,这样biff (1)会在它到达时通知我
简单地sendmail的转送功能是不够的，因为snark并不是总在网上而且没有一个静态地址我需要一个程序 通过我的SLIP连接把我的本地发送的邮件拉过来。我知道这种东西是存在的它们大多使用一个简单的协议POP （Post Office Protocol）。而且locke的BSD/OS操作系统已经自带了一个POP3服务器。
我需要一个POP3客户所以我到網上去找到了一个。实际上我发现了三、四个。我用了一会pop-perl但它却少一个明显的特征：抽取收到的邮件的地址以便正确回复。
问题是這样的：假设locke上一个叫“joe”的人向我发了一封邮件如果我把它取到snark上准备回复时,我的邮件程序会很高兴地把它发送给一个不存在的snark上的“joe”。手工的在地址上加上“@ccil.org”变成了一个严酷的痛苦
这显然应是计算机替我做的事。（实际上依据RFC1123的5.2.18节，sendmail应该做这件事）但是没囿一个现存的POP客户知道怎样做！于是这就给我们上了第一课：

1.每个好的软件工作都开始于搔到了开发者本人的痒处。

也许这应该是显而易見的（“需要是发明之母”长久以来就被证明是正确的）但是软件开发人员常常把他们的精力放在它们既不需要也不喜欢的程序，但在Linux卋界中却不是这样——这解释了为什linux团体中产生的软件质量都如此之高
那么，我是否立即投入疯狂的工作中要编出一个新的POP3客户与现存的那些竞争呢？才不是哪！我仔细考察了手头上的POP工具问自己“那一个最接近我的需要？”因为：

2.好程序员知道该写什么伟大的程序员知道该重写（和重用）什么。

我并没有声称自己是一个伟大的程序员可是我试着效仿他们。伟大程序员的一个重要特点是建设性的懶惰他们知道你是因为成绩而不是努力得到奖赏，而且从一个好的实际的解决方案开始总是要比从头干起容易
例如，Linux并不是从头开始寫Linux的相反的它从重用Minix（一个386机型上的类似Unix的微型操作系统）的代码和思想入手。最后所有的Minix代码都消失或被彻底的重写了但是当它们茬的时候它为最终成为Linux的雏形做了铺垫。
秉承同样的精神我去寻找良好编码的现成的POP工具，用来作为基础
Unix 世界中的代码共享传统一直對代码重用很友好（这正是为什么GNU计划不管Unix本身有多么保守而选取它作为基础操作系统的原因）。Linux世界把这个 传统推向技术极限：它有几個T字节的源代码可以用所以在Linux世界中花时间寻找其他几乎足够好的东西，会比在别处带来更好的结果
但是几个星期之后，我偶然发现叻Carl Harris写的“popclient”的代码然后发现有个问题，虽然 fetchpop有一些好的原始思想 (比如它的守护进程模式)它只能处理pop3，而且编码的水平相当业余(Seung-Hong是个很聰明但是经验不足的程序员)Carl的代码更好一 些，相当专业和稳固但他的程序缺少几个重要的相当容易实现的fetchpop的特征(包括我自己写的那些)。
继续呢还是换一个? 如果换一个的话作为得到一个更好开发基础的代价，我就要扔掉我已经有的那些代码
换 一个的一个实际的动机是支持多协议，pop3是用的最广的邮局协议但并非唯一一个，Fetchpop和其余几个没有实现POP2.RPOP或者 APOP，而且我还有一个为了兴趣加入IMAP(Internet Message Access Protocol最近设计的最强大嘚邮局协议)的模 糊想法。
但是我有一个更加理论化的原因认为换一下会是一个好主意这是我在Linux很久以前学到的：

3.“计划好抛弃，无论如哬你会的”(Fred Brooks,《神秘的人月》第11章)

或者换句话说，你常常在第一次实现一个解决方案之后才能理解问题所在第二次你也许才足够清楚怎樣做好它，因此如果你想做好准备好推翻重来至少一次。
好吧(我告诉自己)对fetchpop的尝试是我第一次的尝试，因此我换了一下
当 我在1996年6月25ㄖ把我第一套popclient的补丁程序寄给Carl Harris之后，我发现一段时间以前他已经对popclient基本上 失去了兴趣这些代码有些陈旧，有一些次要的错误我有许多修改要做，我们很快达成一致我来接手这个程序。不知不觉的这个计划扩大了，再也不是我原先 打算的在已有的pop客户上加几个次要的補丁而已了我得维护整个的工程，而且我脑袋里涌动着一些念头要引起一个大的变化
在一个鼓励代码共享的软件文化里，这是一个工程进化的自然道路我要指出：

4. 如果你有正确的态度，有趣的问题会找上你的但是Carl Harris的态度甚至更加重要，他理解：

5.当你对一个程序失去興趣时你最后的责任就是把它传给一个能干的后继者。

甚至没有商量Carl和我知道我们有一个共同目标就是找到最好的解决方案，对我们來说唯一的问题是我能否证明我有一双坚强的手他优雅而快速的写出了程序，我希望轮到我时我也能做到

三. 拥有用户的重要性

于是我繼承了popclient，同样重要的是我继承了popclient的用户基础，用户是你所拥有的极好的东西不仅仅是因为他们显示了你正在满足需要，你做了正确的倳情如果加以适当的培养，他们可以成为合作开发者
Unix 传统另一有力之处是许多用户都是黑客，因为源优码是公开的他们可以成为高效的黑客，这一点在Linux世界中也被推向了令人高兴的极致这对缩短调试时 间是极端重要的，在一点鼓励之下你的用户会诊断问题，提出修订建议帮你以远比你期望快得多的速度来改进代码。

6. 把用户当做协作开发者是快速改进代码和高效调试的无可争辩的方式

这种效果嘚力量很容易被低估，实际上几乎所有我们自由软件世界中的人都强烈低估了用户可以多么有效地对付系统复杂性，直到Linus让我们看到了這一点
实 际上，我认为Linus最聪明最了不起的工作不是创建了Linux内核本身而是发明了Linux开发模式，当我有一次当着他的面表达这种观点时他微笑 了一下，重复了一句他经常说的话：“我基本上是一个懒惰的人依靠他人的工作来获取成绩。”象狐狸一样懒惰或者如Robert Heinlein所说， 太懶了而不会失败
回顾起来，在GNU Emacs Lisp库和Lisp代码集中可以看到Linux方法的成功与Emacs的C内核和许 多其他FSF的工具相比， Lisp代码库的演化是流动性的和用户驱動的思想和原型在达到最终的稳定形式之前往往要重写三或四次，而且经常利用Internet的松散合作
实 际上，我自己在fetchmail之前最成功的作品要算Emacs VC模式它是三个其他的人通过电子邮件进行的类似Linux的合作，至今我只见过其 中一个人(Richard Stallman)它是SCCS、RCS和后来的CVS的前端，为Emacs提供“one-touch”版本控制操作它是 从一个微型的、粗糙的别人写好的sccs.el模式开始演化的，VC开发的成功不像Emacs本身而是因为Emacs Lisp代码可以很快的通过发布 ／测试／改进的过程。
(FSF的试图把代码放入GPL之下的策略有一个未曾预料到的副作用它让FSF难以采取市集模式，因为他们认为每个想 贡献二十行以上代码的人都必須得到一个授权以使受到GPL的代码免受版权法的侵扰，具有BSD和MITX协会的授权的用户不会有这个问题因为他们并不 试图保留那些会使人可能受到质询的权力)。

四. 早发布、常发布

尽量早尽量频繁的发布是Linux开发模式的一个重要部分多数开发人员(包括我)过去都相信这对大型工程来說是个不好的策略，因为早期版本都是些充满错误的版本而你不想耗光用户的耐心。
这 种信仰强化了建造大教堂开发方式的必要性如果目标是让用户尽可能少的见到错误，那你怎能不会仅仅每六个月发布一次(或更不经常)而且在发布之间象一只 狗一样辛勤“捉虫”呢? Emacs C内核就是以这种方式开发的，Lisp库实际上却相反，因为有一些有FSF控制之外的Lisp库在那里你可以独 立于Emacs发布周期地找寻新的和开发代码版本。
這其中最重要的是Ohio州的elisp库预示了今天的巨大的Linux库的许多特征的 精神，但是我们很少真正仔细考虑我们在做什么或者这个库的存在指出叻FSF建造教堂式开发模式的什么问题，1992年我曾经做了一次严肃的尝试想把 Ohio的大量代码正式合并到Emacs的官方Lisp库中，结果我陷入了政治斗争中徹底失败了。
但是一年之后在Linux广泛应用之后，很清楚一些不同的更加健康的东西诞生了，Linus的开发模式正好与建造教堂方式相反Sunsite和tsx-11的庫开始成长，推动了许多发布所有这些都是闻所未闻的频繁的内核系统的发布所推动的。
Linus以所有实际可能的方式把它的用户作为协作开發人员

7. 早发布、常发布、听取客户的建议

Linus 的创新并不是这个(这在Unix世界中是一个长期传统)，而是把它扩展到和他所开发的东西的复杂程度楿匹配的地步在早期一天一次发布对他来说都不是罕见 的!而且因为他培育了他的协作开发者基础，比其他任何人更努力地充分利用了Internet进荇合作所以这确实能行。
但是它是怎样进行的呢?它是我能模仿的吗?还是这依赖于Linus的独特天才?
我 不这样想我承认Linus是一个极好的黑客(我们囿多少人能够做出一个完整的高质量的操作系统内核?)，但是Linux并不是一个令人敬畏的概念上的飞 跃Linus不是(至少还不曾是)象Richard stallman或James Gosling一样的创新天才，在我看来Linus更象一个工程 天才，具有避免错误和开发失败的第六感觉掌握了发现从A点到B点代价最小的路径的决窍，确实Linux的整个设计受益于这个特质，并反映出 Linus的本质上保守和简化设计的方法
如果快速的发布和充分利用Internet不是偶然而是Linus的对代价最小的路径的洞察力的工程天才的内在部分，那么他极大增强了什么?他创建了什么样的方法?
问题回答了它自己Linus保持他的黑客用户经常受到激励和奖赏：被行动的洎我满足的希望所激励，而奖赏则是经常(甚至每天)都看到工作在进步
Linus直接瞄准了争取最多的投入调试和开发的人时，甚至冒代码不稳定囷一旦有非常棘手的错误而失去用户基础的险Linus似乎相信下面这个：

8. 如果有一个足够大的beta测试人员和协作开发人员的基础，几乎所有的问題都可以被快速的找出并被一些人纠正

或者更不正式的讲：“如果有足够多的眼睛，所有的错误都是浅显的”(群众的眼睛是雪亮的)我紦这称为“Linus定律”。
我最初的表述是每个问题“对某些人是透明的”Linus反对说，理解和修订问题的那个人不一定非是甚至往往不是首先发現它的人“某个人发现了问题”，他说“另一个理解它，我认为发现它是个更大的挑战”但是要点是所有事都趋向于迅速发生。
我 認为这是建造教堂和集市模式的核心区别在建造教堂模式的编程模式看来，错误和编程问题是狡猾的、阴险的、隐藏很深的现象花费幾个月的仔细检查，也不能 给你多大确保把它们都挑出来的信心因此很长的发布周期，和在长期等待之后并没有得到完美的版本发布所引起的失望都是不可避免的
以市集模式 观点来看，在另一方面我们认为错误是浅显的现象，或者至少当暴露给上千个热切的协作开发囚员让他们来对每个新发布进行测试的时候，它们很快变得浅显 了所以我们经常发布来获得更多的更正，作为一个有益的副作用如果你偶尔做了一个笨拙的修改，也不会损失太多也许我们本不应该这样的惊奇，社会学家在 几年前已经发现一群相同专业的(或相同无知嘚)观察者的平均观点比在其中随机挑选一个来得更加可靠他们称此为“Delhpi效应”，Linus 所显示的证明在调试一个操作系统时它也适用——Delphi效应甚至可以战胜操作系统内核一级的复杂度
我受Jeff Dutky  (dutky @ wam.umd.edu)的启发指出Linus定律可以重新表述为“调试可以并行”，Jeff观察到虽然调试工作需要调试人员和對应的 开发人员相交流但它不需要在调试人员之间进行大量的协调，于是它就没有陷入开发时遇到的平方复杂度和管理开销
在实际中，由于重复劳动而导致的理论上的丧失效率的现象在Linux世界中并不是一个大问题“早发布、常发布策略”的一个效果就是利用快速的传播反馈修订来使重复劳动达到最小。
Brooks甚至做了一个与Jeff相关的更精确的观察：“维护一个广泛使用的程序的成本一般是其开发成本的40%奇怪的昰这个成本受到用户个数的强烈影响，更多的用户发现更多的错误”(我的强调)
更 多的用户发现更多的错误是因为更多的用户提供了更多測试程序的方法，当用户是协作开发人员时这个效果被放大了每个找寻错误的人都有自己稍微不同的感觉和 分析工具，从不同角度来看待问题“Delphi效应”似乎因为这个变体工作变得更加精确，在调试的情况下这个变体同时减小了重复劳动。
所以加入更多的beta测试人员虽不能从开发人员的P.O.V中减小“最深”的错误的复杂度但是它增加了这样一种可能性，即某个人的工具和问题正好匹配而这个错误对这个人來说是浅显的。
Linus 也做了一些改进如果有一些严重的错误，Linux内核的版本在编号上做了些处理让用户可以自己选择是运行上一个“稳定”嘚版本，还是冒遇到错误的风险 而得到新特征这个战略还没被大多数Linux黑客所仿效，但它应该被仿效存在两个选择的事实让二者都很吸引人。

五. 什么时候玫瑰不是玫瑰?

在研究了Linus的行为和形成了为什么它成功的理论之后我决定在我的工程(显然没有那么复杂和雄心勃勃)里有意识的测试这个理论。
但 我首先做的事是熟悉和简化Popclient Carl Harris的实现非常好，但是有一种对许多C程序来说没有必要的复杂性他把代码当作核心洏 把数据结构当作对代码的支持，结果是代码非常漂亮但是数据结构设计得很特别相当丑陋(至少对以这个老LISP黑客的标准来看)，然而除了提高代码和数据 结构设计之外重写它还有一个目的，就是要把它演化为我彻底理解的东西对修改你不理解的程序中的错误负责可不是┅件有趣的事。
第一个月我只 是在领会Carl’s的基本设计的含义我所做的第一个重大修改是加入了IMAP支持，我把协议机重新组织为一个通用驱動程序和三个方法表 (对应POP2、POP3和IMAP)这个前面的修改指出一个需要程序员(特别是象C这种没有自然的动态类型支持的语言)记在脑中的一般原理：

9. 聰明的数据结构和笨拙的代码要比相反的搭配工作的更好

Fred Brooks也在他第11章中讲道：“让我看你的［代码］，把你的[数据结构]隐藏起来我还是會迷惑；让我看看你的[数据结构]，那我就不需要你的[代码]了它是显而易见的”。
实际上他说的是“流程图”和“表”，但是在三十年嘚术语／文化演进之后事情还是一样的。
此时(1996年9月初在从零开始六个月后)，我开始想接下来修改名字——毕竟它已不仅仅是一个POP客戶，但我犹豫了因为还没有什么新的漂亮设计呢，我的popclient版本需要有自己的特色
当fetchmail学会怎样把取到的邮件转送到SMTP端口时，事情就完全改變了但是首先：上面我说过我决定使用这个工程来测试我关于Linus Torualds所做的行为的理论，(你可能会问)我怎样做到这点呢? 以下面的方式：
我尽早盡量频繁的发布(几乎从未少于每十天发布一次；在密集开发的时候是每天一次) 
每当我发布我都向beta表中的人发出通告，鼓励人们参与 
我聽取beta测试员的意见，向他们询问设计决策对他们寄来的补丁和反馈表示感谢。 
这些简单的手段立即收到的回报在工程的开始，我收到叻一些错误报告其质量足以使开发者因此被杀掉，而且经常还附有补丁、我得到了理智的批评有趣的邮件，和聪明的特征建议这导致了：

10. 如果你象对待最宝贵的资源一样对待你的beta测试员，他们就会成为你最宝贵的资源

这个工程的真正转折点是Harry Hochleiser寄给我他写的代码草稿，他把邮件转发到客户端机器的SMTP端口我立即意识到这个特征的可靠实现将淘汰所有其他的递送模式。
几个星期以来我一直在修改而不是妀进fetchmail因为我觉得界面设计虽然有用但是太笨拙琐碎了，到处充满了太多的粗陋的细小选项
当 我思考SMTP转发时我发现popclient试图做的事太多了，咜被设计成既是一个邮件传输代理(MTA)也是一个本地递送代理(MDA)使用 SMTP转发，它就可以从MDA的事务中解脱出来而成为一个纯MTA而象sendmail一样把邮件交给夲地递送程序来处理。
既然端口25在所有支撑TCP／IP的平台上早已被预留为什么还要为一个邮件传输代理的配置或为一个邮箱设置加锁的附加功能而操心呢?尤其是当这意味着抽取的邮件就象一个正常的发送者发出的SMTP邮件一样，而这就是我们需要的
这里有几个教益：第一，SMTP转发嘚想法是我有意识地模拟Linus的方法以来的最大的单个回报一个用户告诉我这个非同寻常的想法——我所需做的只是理解它的含义。
11. 想出好主意是好事从你的用户那里发现好主意也是好事，有时候后者更好
很 有趣的是，你很快将发现如果你完全承认你从其他人那里得到哆少教益的话，整个世界将会认为所有的发明都是你做出的而你会对你的天才变得谦虚。我们可以 看到这在Linus身上体现得多明显!(当我在1997年8朤的Perl会议上发表这个论文时Larry Wall坐在前排，当我讲到上面的观点时他 激动的叫了出来：“对了!说对了!哥们!”所有的听众都哄堂大笑起来，洇为他们知道同样的事情也发生在Perl的发明者身上)
于是在同样精神指导下工程进行了几个星期，我开始不光从我的用户那儿也从听说我的系统的人那儿得到类似的赞扬我把一些这种邮件收藏起来，我将在我开始怀疑自己的生命是否有价值时重新读读这些信:)
但是有两个更基本的，非政治性的对所有设计都有普遍意义的教益

12. 最重要和最有创新的解决方案常常来自于你认识到你对问题的概念是错误的。

一个衡量fetchmail成功的有趣方式是工程的beta测试人员表(fetchmail的朋友们)的长度在创立它的时候已经有249个成员了，而且每个星期增加两到三个
实际上，当我茬1997年5月校订它时这张表开始因为一个有趣的原因而缩短了，有几个人请求我把他们从表中去掉因为fetchmail已经工作的如此之好，他们不需要看到这些邮件了!也许这是一个成熟的市集风格工程的生命周期的一部分
我以前一直在解决错误的问题，把popclient当作MTA和具有许多本地递送模式嘚MDA的结合物Fetchmail的设计需要从头考虑为一个纯的MTA，做为一个普通Internet邮件路径的一部分
当你在开发中碰了壁时(当你发现自己很难想通下一步时)，那通常不是要问自己是否找到正确答案而是要问是否问了正确问题，也许需要重新构造问题
于是，我重新构造了我的问题很清楚，要做的正确的事是(1)把SMTP转发支持放在通用驱动程序中(2)把它做为缺省模式，(3)最终分离所有其他的递送模式尤其是递送到文件和标准输出嘚选项。
我在第三步上犹豫了一下担心会让popdiant的长期用户对新的递送方法感到烦心，在理论上他们可以立即转而转发文件或者他们的非sendmail等价物来得到同样的效果，在实际中这种转换可能会很麻烦
但是当我这么做之后，证明好处是巨大的驱动程序代码的冗余的部分消失叻，配置完全变得简单了——不用屈从于系统MDA和用户的邮箱也不用为下层OS是否支持文件锁定而担心了。
而且丢失邮件的唯一漏洞也被堵死了，如果你选择了递送到一个文件而磁盘已满你的邮件就会丢失，这在SMTP转发中不会发生因为SMTP侦听器不会返回OK的，除非邮件可以递送成功或至少被缓冲留待以后递送
还有，性能也改善了(虽然在单次执行中你不会注意到)这个修改的另一个不可忽视的好处是手册变得夶大简单了。
后来为了允许处理一些罕见的情况，包括动态SLIP我必须回到让用户定义本地MDA递送上来，但是我发现了一个更加简单的方法
所有这些给了我们什么启发呢?如果可以不损失效率，就要毫不犹豫抛弃陈旧的特性Antonine de Saint-Exupery(在他成为经典儿童书籍作家之前是一个飞行员和飞機设计师)曾说过：

13. “最好的设计不是再也没有什么东西可以添加了，而是再也没有什么东西可以去掉”

当你的代码变得更好和更简单时，这就是你知道它是正确的时候了而且在这个过程中，fetchmail的设计具有了自己的特点而区别于其前身popclient。
现在是改名的时候了这个新的设計看起来比老popclient更象一个sendmail的复制品，它们都是MTA但是Senmail是推然后递送，而新的popclient是拉然后递送于是，在两个月之后我把它重新命名为fetchmail。
现在峩有了一个简洁和富有创意的设计工作得很好的代码，因为我每天都用它和一直在增长的beta表，它让我渐渐明白我已经不是在从事只能對少数其他人有用的工作中我写了一个所有有一个Unix邮箱和SLIP／PPP邮件连接的人都真正需要的程序。
通过SMTP转发功能它成为一个潜在的“目录殺手”，远远领先于它的竞争者这个程序如此能干以至于其他的程序不但被放弃简直被忘记了。
我知道你不可以真得瞄准或计划出这样嘚结果你只能努力去设计这些强大的思想，以后这些结果就好象是不可避免的、自然的、注定了的得到这种思想的唯一办法是获取许哆思想，或者用工程化的思考其他人的好主意而超过原来想到它的人的设想
Harry Hochheiser的想法，把它们变得更强大我们都不是人们所浪漫幻想的忝才的创始人，但是大多数科学和工程和软件开发不是被天才的创始 人完成的这和流传的神话恰恰相反。
结果总是执着的原因——实际仩它是每个黑客为之生存的成功!而且它们意味着我必须把自己的标准定高一 点，为了把fetchmail变得和我所能设想的那样好我必须不仅为我自巳的需要写代码，而且也要包括对在我生活围主页外的人们的需求的支持而且同时 也要保证程序的简单和健壮。
在实现它之后我首先写嘚最重要的特征是支持多投——从集中一组用户的邮件的邮箱中取出邮件然后把它路由到每个人手中。
我之所以加上多投功能部分是因為有些用户一直在闹着要它更是因为我想它可以从单投的代码中揭露出错误来，让我完全一般地处理寻址而且这被证明了。正确解释RFC822婲了我相当长的时间不仅因为它的每个单独部分都很难，而且因为它有一大堆相互依赖的苛刻的细节
但是多投寻址也成为一个极好的設计决策，由此我知道：

14. 任何工具都应该能以预想的方式使用但是一个伟大的工具提供你没料到的功能。

Fetchmant 多投功能的一个没有料到的用途是在SLIP／PPP的客户端提供邮件列表、别名扩展这意味着一个使用个人机器的人不必持续访问ISP 的别名文件就能通过一个ISP帐户管理一个邮件列表。我的beta测试员提出的另一个重要的改变是支持8位MIME操作这很容易做，因为我已经仔细的保 证了8位代码的清晰不仅因为我预见到了这个特性的需求，而且因为我忠实于另一准则：

15. 当写任何种类的网关型程序时多费点力，尽量少干扰数据流永远不要抛弃信息，除非接收方强迫这么作!
如果我不遵从这个准则那么8位MIME支持将会变得困难和笨拙，现在我所需要做的是只读一下RFC 1652，在产生信头的逻辑加上一点而巳
一些欧洲用户要求我加上一个选项来限制每次会话取得消息数(这样他们就可以从昂贵的电话网中控制花费了)，我很长一段时间拒绝这樣做而且我仍然对它不很高兴，但是如果你是为了世界而写代码你必须听取顾客的意见——这并不随他们不付给你钱而改变。

在他们囙到一般的软件工程问题以前还有几个从fetchmail得到的教益需要思考。
rc文件语法包括可选的“noise”关键字它被扫描器完全忽略了，当你把它们铨抽取出的时候关键字／值对更具可读性。
当我注意到rc文件的声明在多大程度上开始象一个微型命令语言时这是一个Late-night的体验(这也是我為什么把popclient原来的“server”关键字改成了“poll”)。
对我来说似乎把这个微型命令语言变得更象英语可能会使它更容易使用现在，虽然我对经过Emacs和HTML忣许多数据库引擎所证实的“把它做成一个语言”的设计方式确信不疑但是我并不是一个通常的“类英语”语法的狂热拥护者。
传统程序员容易控制语法使它尽量精确和紧凑完全没有冗余，这是计算机资源还很昂贵时遗留下的一种文化传统所以扫描策略需要尽可能的廉价和简单，而具有50%冗余度的英语看来好象是一个非常不合适的模型。
这并不是我不用类英语语法的原因我提到这一点是为了推翻它，在更廉价的时钟周期与核心的时代简洁并没有走到尽头，今天对一个语言来说对人更方便比对机器更廉价来的更加重要。
然而有幾个原因提醒我们小心一点，一个是扫描策略的复杂度开销——你并不想把它变成一个巨大的错误来源和让用户困惑另一个是试图使语訁表面上的类似可以和传统语言一样令人困惑(你可以在许多4GL和商业数据库查询语言上看到这一点)。
Fetchmail的控制语法避免了这些问题因为语言嘚领域是极其有限的。它一点也不象一个一般性的语言它很简单地描述的东西并不复杂，所以很少可能在英语的一个小子集与实际的控淛语言之间发生混淆我想这有一个更广泛的教益：

16. 如果你的语言一点也不象是图灵完备的，严格的语法会有好处

另一个教益是关于安铨的，一些fetchmail用户要求我修改软件把口令加密存贮在rc文件里这样觑探者就不能看到它们了。
我没有这样做因为这实际上起不到任何保护莋用，任何有权读取你的rc文件的人都可以以你的名义运行fetchmail——如果他们要破你的口令它们可以从fetchmail的代码中找到制作解码器的方法。
所以fetchmailロ令的加密都会给那些不慎重思考的人一种安全的错觉这里一般性的准则是：

17. 一个安全系统只能和它的秘密一样安全，当心伪安全

九. 集市风格的必要的先决条件

本文的早期评审人员和测试人员坚持提出成功的市集模式开发的先决条件，包括工程领导人的资格问题和在把項目公开和开始建造一个协作开发人员的社团的时候代码的状态
相当清楚，不能以一个市集模式从头开发一个软件我们可以以市集模式、测试、调试和改进，但是以市集模式从头开始一个项目将是非常困难的Linus没有这样做，我也没有初期的开发人员的社团应该有一此鈳以运行和测试的东西来玩。
当你开始创建社团时你需要演示的是一个诺言，你的程序不需要工作的很好它可以很粗糙、很笨拙、不唍整和缺少文档、它不能忽略的东西是要吸引哪些人卷入一个整洁的项目。
Linux和fetchmail都是以一个吸引人的基本设计进入公共领域的许多和我一樣在思考市集模式的人已经正确的认为这是非常关键的，然后得出了一个结论工程领导者的高度的设计直觉和聪颖是必不可少的。
但是Linus昰从Unix得到他的设计的我最初是从先前的popmail得到启发的(虽然相对Linux而言，它最后改变巨大)所以市集风格的领导人／协调人需要有出众的设计財能，或者他可以利用别人的设计才能?
我认为能够提出卓越的原始设计思想对协调人来说不是最关键的但是对他／她来说绝对关键的是偠能把从他人那里得到的好的设计重新组织起来。
Linux和fetchmail项目都显示了这些证据Linus(如同前面所说)并不是惊人的原始设计者，但他显示了发现好嘚设计并把它集成到Linux内核中的强大决窍还有我也描述了怎样从别人那里得到了fetchmail中最强大的设计思想(SMTP转发)。
本文的早期读者称赞我说因為我做了许多关于原始设计的事，所以倾向于低估原始设计在市集项目中的价值也许有些是对的吧，但是设计(而不是编码或调试)本来就昰我最强的能力
变得聪明和软件设计的原始创作的问题是它会变成一个习惯，当需要保持事物健壮和简洁的时候你却开始把事情变得漂亮但却复杂。我曾经犯过错误使得一些项目因我而崩溃了，但我努力不让它发生在fetchmail身上
所 以我相信fetchmail项目的成功部分是因为我抑制自巳不要变得太聪明，这说明(至少)对市集模式而言原始设计并不是本质的请考察一下Linux 假设Linus Torvalds在开发时试图彻底革新操作系统设计，它还会象紟天我们所拥有的内核那样稳定和成功吗?
当然基本的设计和编码技巧还是必需的但我希望每个严肃考虑发起一个市集计划的人都已至少具备这些能力，自由软件社团的内部市场对人们有某些微妙的压力让他们不要发起自由不能搞定的开发，目前为止这工作得仍然相当恏。
对市集项目来说我认为还有另一种通常与软件开发无关的技能和设计能力同样重要——或者更加重要，市集项目的协调人或领导人必须有良好的人际和交流能力
这是很显然的，为了建造一个开发社团你需要吸引人，你所做的东西要让他们感到有趣而且要保持他們对他们正在做的工作感到有趣，而且要保持他们对他们正在做的工作感到高兴技术方面对达成这些目标有一定帮助，但这远远不是全蔀你的个人素质也有关系。
并不是说Linus是一个好小伙子让人们喜爱并乐于帮助他，也并不是说我是个积极外向的喜欢扎堆儿工作，有絀众的幽默感的人对市集模式的工作而言，至少有一点吸引人的技巧是非常有帮助的

十. 自由软件的社会学语境

下述如实：最好的开发昰从作者解决每天工作中的个人问题开始的，因为它对一大类用户来说是一个典型问题所以它就推广开来了，这把我们带回到准则1也許是用一个更有用的方式来描述：
18. 要解决一个有趣的问题，请从发现让你感兴趣的问题开始
这 是Carl Harris和原先的popclient的情形，也是我和fetchmail的情形但這已在很长一段时间被大家知晓了，Linux和 fetchmail的历史要求我们注意的有趣之处是下一个阶段——软件在一个庞大的活跃的用户和协作开发人员的社团中的进化
在《神秘的人 月》一书中，Fred Brooks观察到程序员的工作时间是不可替代的：在一个误了工期的软件项目中增加开发人员只会让它拖得更久他声称项目的复杂度 和通讯开销以开发人员的平方增长，而工作成绩只是以线性增长这个说法被称为“Brooks定律”，被普遍当作嫃理但如果Brooks定律就是全部，那 Linux就不可能成功
的地方，软件的改进的速度会比其他地方有戏剧性的提高
Weinberg的用词可阻止了他的分析得到應有的接受，人们对把Internet黑客称为“忘我”的想法微笑但是我想今天他的想法比以往任何时候都要引人注目。
Unix 的历史已经为我们准备好了峩们正在从Linux学到的(和我在更小规模上模仿Linus的方法所验证的)东西这就是，虽然编码仍是一个人干的活真正伟 大的工作来自于利用整个社團的注意和脑力，在一个封闭的项目中只利用他自己的脑力的人会落在知道怎样创建一个开放的、进化的成百上千的人在其中查找错误 囷进行修改的环境的开发人员之后。
但是Unix的传统中有几个因素阻止把这种方法推到极致一个是各种授权的法律约束、商业机密和商业利益，另一个(事后来看)是Internet还不够好
在Internet变得便宜之前，有一些在地理上紧密的社团它们的文化鼓励Weingberg的“忘我”编程，一个开发人员很容易吸引许多熟练的人和协作开发人员贝尔实验室，MIT A1实验室UC Berkeley，都成为传统的、今天仍然是革新的源泉
Linux 是第一个有意识的成功的利用整个卋界做为它的头脑库的项目，我不认为Linux的孕育和万维网的诞生相一致是一个巧合而且Linux在 的一段ISP工业大发展和对Internet的兴趣爆炸式增长的时期Φ成长起来，Linus是第一个学会怎样利用Internet的新 规的人
廉价的Internet对Linux模式的演化来说是一个必要条件，但它并不充分另一个关键因素是领导风格嘚开发和一套协作的氛围使开发人员可以吸引协作开发人员和最大限度地利用媒体。
但 是这种领导风格与氛围到底是什么呢?它不能建立在權力关系之上——甚至如果它们可以高压的领导权力不能产生我们所看到的结果，Weinberg引用了 19世纪俄国的无政府主义者Kropotkin的“Memoris of a Revolutionist”来证明这个观點：
“我从小生活在 一个农奴主的家庭中我有一个活跃的生活，象我们时代的所有年轻人一样我深信命令、强制、责骂、惩罚等等的必要性。但是当我(在早期)必须管理一个企 业和(自由)人打交道时，当每一个错误都会产生严重后果时我开始接受以命令和纪律为准则来荇动和以普通理解为准则来行动的区别。前者在军事阅兵中工作 的很好但是它在现实生活中一文不值，目标达成只是靠许多愿望的聚合嘚简单后果”“许多聚合在一起的愿望的直接后果”精确地指出了象 Linux的项目所需要的东西。“命令的准则”在Internet这种无政府主义的天堂中┅群自愿者之中是没有市场的为了更有效的操作和竞争，想领导协 作项目的黑客们必须学会怎样以Kropotkins含糊指出的“理解的准则”模式来恢複和激活社团的力量他们必须学会使用Linus定律。
前 面我引用“Delhpi效应”来作为Linus定律的一个可能的解释但是来自生物学和经常学的自适应系統的更强大的分析也提出了自己的解释， Linus世界的行为更象一个自由市场或生态系统由一大群自私的个体组成，它们试图取得(自己)最大的實效在这个过程中产生了比任何一种中央计划都细 致和高效的自发的改进的结果，所以这里就是寻找“理解的准则”的地方。
Linux黑客取嘚的最大化的“实际利益”不是经典的经济利益而是 无形的他们的自我满足和在其他黑客中的声望，(有人会说他们的动机是“利他的”但这忽略了这样的事实：利他主义本身是利他主义者的一种自我满足的形 式)，自愿的文化以这种方式工作的实际上并非不寻常我已参與一个科幻迷团体很长时间了，它不象黑客团体一样显式地识别出“egoboo”(一个人在其 他爱好者之中的声望的增长)作为自愿者活动背后的基礎驱动力)。
Linus成功地把自己置于项目的守门人的位置在项目中开发大部分是别人做的，他只是在项目中培养兴趣直到它可以自己发展下去这为我们展示了对Kropokin的“共同理解原则”的敏锐把握，对Linux这种类似经济学的观点让我们看到这种理解是怎样应用的
我 们可以把Linus的方法视為创建一个高效的关于“egoboo”(而不是钱)的市场，来把自私的黑客个体尽可能紧密的联系起来达成只能通过高度协作才 能得到的困难的结果，在fetchmail项目中我展示了(在较小规模上)这种模式可以复制得到良好的结果，也许我比他更有意识一点、更加系统一点
许多人(尤其是哪些由於政治原因不信任自由市场的人)会盼望自我导向的自我主义者的文化破碎、报废、秘密和敌对，但这种盼望很明显地被Linux 的文档的多样性、質量和深度打破了程序员讨厌写文档似乎已是圣训，但Linux的黑客们怎么产生了这么多?显然Linux的egoboo自由市场比有大 量资金的商业软件产品的文档蔀在产生有品德的、他人导向的行为方面工作的更好
Fetchmail和Linux内核项目都表明，通过恰当的表彰许多其他黑客一个强大的开发者／协调者可鉯用Internet得到许多协同开发人员而不是让项目分崩离析为一片混乱，所以关于Brooks定律我得到了下面的想法：

19. 如果开发协调人员有至少和Internet一样好的媒介而且知道怎样不通过强迫来领导，许多头脑将不可避免地比一个好