7年5月校订它时，这张表开始因为一个有趣的原因而缩短了，有几个人请求我把他们从表中去掉，因为fetchmai1已经工作的如此之好，他们不需要看到这些邮件了!也许这是一个成熟的市集风格工程的生命周期的一部分。
我以前一直在解决错误的问题，把popnett当作mTa和具有许多本地递送模式的mda的结合物，Fetchmai1的设计需要从头考虑为一个纯的mTa，做为一个普通Internet邮件路径的一部分。
当你在开中碰了壁时(当你现自己很难想通下一步时)，那通常不是要问自己是否找到正确答案，而是要问是否问了正确问题，也许需要重新构造问题。
于是，我重新构造了我的问题，很清楚，要做的正确的事是(1)把**Tp转支持放在通用驱动程序中，(2)把它做为缺省模式，(3)最终分离所有其他的递送模式，尤其是递送到文件和标准输出的选项。
我在第三步上犹豫了一下，担心会让popdiant的长期用户对新的递送方法感到烦心，在理论上，他们可以立即转而转文件或者他们的非sendmai1等价物来得到同样的效果，在实际中这种转换可能会很麻烦。
但是当我这么做之后，证明好处是巨大的，驱动程序代码的冗余的部分消失了，配置完全变得简单了——不用屈从于系统mda和用户的邮箱，也不用为下层os是否支持文件锁定而担心了。
而且，丢失邮件的唯一漏洞也被堵死了，如果你选择了递送到一个文件而磁盘已满，你的邮件就会丢失，这在**Tp转中不会生，因为**Tp侦听器不会返回ok的，除非邮件可以递送成功或至少被缓冲留待以后递送。
还有，性能也改善了(虽然在单次执行中你不会注意到)，这个修改的另一个不可忽视的好处是手册变得大大简单了。
后来，为了允许处理一些罕见的情况，包括动态sLIp，我必须回到让用户定义本地mda递送上来，但是我现了一个更加简单的方法。
所有这些给了我们什么启呢?如果可以不损失效率，就要毫不犹豫抛弃陈旧的特性，antoninedesaintexupery(在他成为经典儿童书籍作家之前是一个飞行员和飞机设计师)曾说过：
13.“最好的设计不是再也没有什么东西可以添加了，而是再也没有什么东西可以去掉。”
当你的代码变得更好和更简单时，这就是你知道它是正确的时候了，而且在这个过程中，fetehmai1的设计具有了自己的特点，而区别于其前身popnetbsp;现在是改名的时候了，这个新的设计看起来比老popnetdmai1的复制品，它们都是mTa，但是senmai1是推然后递送，而新的popnett是拉然后递送。于是，在两个月之后，我把它重新命名为fetehmai1。
七.Fetnetbsp;现在我有了一个简洁和富有创意的设计，工作得很好的代码，因为我每天都用它，和一直在增长的beta表，它让我渐渐明白我已经不是在从事只能对少数其他人有用的工我写了一个所有有一个unix邮箱和sLIp／邮件连接的人都真正需要的程序。
通过**Tp转功能，它成为一个潜在的“目录杀手”，远远领先于它的竞争者，这个程序如此能干以至于其他的程序不但被放弃简直被忘记了。
我知道你不可以真得瞄准或计划出这样的结果，你只能努力去设计这些强大的思想，以后这些结果就好象是不可避免的、自然的、注定了的，得到这种思想的唯一办法是获取许多思想，或者用工程化的思考其他人的好主意而过原来想到它的人的设想。
andreTanenbanm原来设想建造一个适合386的简单的unix用做教学，LinusTorva1e1s把andre的可能想到的minix可以做什么的概念推进了一步，成长为一个极好的东西，同样的(虽然规模较小)，我接受了cardharris和harryeiser的想法，把它们变得更强大，我们都不是人们所浪漫幻想的天才的创始人，但是大多数科学和工程和软件开不是被天才的创始人完成的，这和流传的神话恰恰相反。
结果总是执着的原因——实际上，它是每个黑客为之生存的成功!而且它们意味着我必须把自己的标准定高一点，为了把fetchmai1变得和我所能设想的那样好，我必须不仅为我自己的需要写代码，而且也要包括对在我生活围主页外的人们的需求的支持，而且同时也要保证程序的简单和健壮。
在实现它之后我先写的最重要的特征是支持多投——从集中一组用户的邮件的邮箱中取出邮件，然后把它路由到每个人手中。
我之所以加上多投功能部分是因为有些用户一直在闹着要它，更是因为我想它可以从单投的代码中揭露出错误来，让我完全一般地处理寻址，而且这被证明了。正确解释RFc822花了我相当长的时间，不仅因为它的每个单独部分都很难，而且因为它有一大堆相互依赖的苛刻的细节。
但是多投寻址也成为一个极好的设计决策，由此我知道：
14.任何工具都应该能以预想的方式使用，但是一个伟大的工具提供你没料到的功能。
Fetnett多投功能的一个没有料到的用途是在sLIp／的客户端提供邮件列表、别名扩展。这意味着一个使用个人机器的人不必持续访问Isp的别名文件就能通过一个Isp帐户管理一个邮件列表。我的beta测试员提出的另一个重要的改变是支持8位mIme操作，这很容易做，因为我已经仔细的保证了8位代码的清晰，不仅因为我预见到了这个特性的需求，而且因为我忠实于另一准则：
15.当写任何种类的网关型程序时，多费点力，尽量少干扰数据流，永远不要抛弃信息，除非接收方强迫这么作!
如果我不遵从这个准则，那么8位mIme支持将会变得困难和笨拙，现在我所需要做的，是只读一下RFc1652，在产生信头的逻辑加上一点而已。
一些欧洲用户要求我加上一个选项来限制每次会话取得消息数(这样他们就可以从昂贵的电话网中控制花费了)，我很长一段时间拒绝这样做，而且我仍然对它不很高兴，但是如果你是为了世界而写代码，你必须听取顾客的意见——这并不随他们不付给你钱而改变。
八.从Fetchmai1得来的另一些教益
在他们回到一般的软件工程问题以前，还有几个从fetchmai1得到的教益需要思考。
rnetoise”关键字，它被扫描器完全忽略了，当你把它们全抽取出的时候，关键字／值对更具可读性。
当我注意到rc文件的声明在多大程度上开始象一个微型命令语言时，这是一个Latenight的体验(这也是我为什么把popnett原来的“server”关键字改成了“po11”)。
对我来说似乎把这个微型命令语言变得更象英语可能会使它更容易使用。现在，虽然我对经过em和hTmL及许多数据库引擎所证实的“把它做成一个语言”的设计方式确信不疑，但是我并不是一个通常的“类英语”语法的狂热拥护者。
传统程序员容易控制语法使它尽量精确和紧凑，完全没有冗余，这是计算机资源还很昂贵时遗留下的一种文化传统，所以扫描策略需要尽可能的廉价和简单，而具有50%冗余度的英语，看来好象是一个非常不合适的模型。
这并不是我不用类英语语法的原因，我提到这一点是为了推翻它，在更廉价的时钟周期与核心的时代，简洁并没有走到尽头，今天对一个语言来说，对人更方便比对机器更廉价来的更加重要。
然而，有几个原因提醒我们小心一点，一个是扫描策略的复杂度开销——你并不想把它变成一个巨大的错误来源和让用户困惑，另一个是试图使语言表面上的类似可以和传统语言一样令人困惑(你可以在许多4gL和商业数据库查询语言上看到这一点)。
Fetchmai1的控制语法避免了这些问题，因为语言的领域是极其有限的。它一点也不象一个一般性的语言，它很简单地描述的东西并不复杂，所以很少可能在英语的一个小子集与实际的控制语言之间生混淆，我想这有一个更广泛的教益：
16.如果你的语言一点也不象是图灵完备的，严格的语法会有好处。
另一个教益是关于安全的，一些fetchmai1用户要求我修改软件把口令加密存贮在rc文件里，这样觑探者就不能看到它们了。
我没有这样做，因为这实际上起不到任何保护作用，任何有权读取你的rc文件的人都可以以你的名义运行fetchmai1——如果他们要破你的口令，它们可以从fetchmai1的代码中找到制作解码器的方法。
所以fetchmai1口令的加密都会给那些不慎重思考的人一种安全的错觉，这里一般性的准则是：
17.一个安全系统只能和它的秘密一样安全，当心伪安全。
九.集市风格的必要的先决条件
本文的早期评审人员和测试人员坚持提出成功的市集模式开的先决条件，包括工程领导人的资格问题和在把项目公开和开始建造一个协作开人员的社团的时候代码的状态。
相当清楚，不能以一个市集模式从头开一个软件，我们可以以市集模式、测试、调试和改进，但是以市集模式从头开始一个项目将是非常困难的，Linus没有这样做，我也没有，初期的开人员的社团应该有一此可以运行和测试的东西来玩。
当你开始创建社团时，你需要演示的是一个诺言，你的程序不需要工作的很好，它可以很粗糙、很笨拙、不完整和缺少文档、它不能忽略的东西是要吸引哪些人卷入一个整洁的项目。
Linux和fetchmai1都是以一个吸引人的基本设计进入公共领域的，许多和我一样在思考市集模式的人已经正确的认为这是非常关键的，然后得出了一个结论，工程领导者的高度的设计直觉和聪颖是必不可少的。
但是Linus是从unix得到他的设计的，我最初是从先前的popmai1得到启的(虽然相对Linux而言，它最后改变巨大)，所以市集风格的领导人／协调人需要有出众的设计才能，或者他可以利用别人的设计才能?
我认为能够提出卓越的原始设计思想对协调人来说不是最关键的，但是对他／她来说绝对关键的是要能把从他人那里得到的好的设计重新组织起来。
Linux和fetnetus(如同前面所说)并不是惊人的原始设计者，但他显示了现好的设计并把它集成到Linux内核中的强大决窍。还有我也描述了怎样从别人那里得到了fetchmai1中最强大的设计思想(**Tp转)。
本文的早期读者称赞我，说因为我做了许多关于原始设计的事，所以倾向于低估原始设计在市集项目中的价值，也许有些是对的吧，但是设计(而不是编码或调试)本来就是我最强的能力。
变得聪明和软件设计的原始创作的问题是它会变成一个习惯，当需要保持事物健壮和简洁的时候，你却开始把事情变得漂亮但却复杂。我曾经犯过错误，使得一些项目因我而崩溃了，但我努力不让它生在fetnetbsp;所以我相信fetchmai1项目的成功部分是因为我抑制自己不要变得太聪明，这说明(至少)对市集模式而言原始设计并不是本质的，请考察一下Linux假设LinusTorva1ds在开时试图彻底革新操作系统设计，它还会象今天我们所拥有的内核那样稳定和成功吗?
当然基本的设计和编码技巧还是必需的，但我希望每个严肃考虑起一个市集计划的人都已至少具备这些能力，自由软件社团的内部市场对人们有某些微妙的压力，让他们不要起自由不能搞定的开，目前为止，这工作得仍然相当好。
对市集项目来说，我认为还有另一种通常与软件开无关的技能和设计能力同样重要——或者更加重要，市集项目的协调人或领导人必须有良好的人际和交流能力。
这是很显然的，为了建造一个开社团，你需要吸引人，你所做的东西要让他们感到有趣，而且要保持他们对他们正在做的工作感到有趣，而且要保持他们对他们正在做的工作感到高兴，技术方面对达成这些目标有一定帮助，但这远远不是全部，你的个人素质也有关系。
并不是说Linus是一个好小伙子，让人们喜爱并乐于帮助他，也并不是说我是个积极外向的，喜欢扎堆儿工作，有出众的幽默感的人，对市集模式的工作而言，至少有一点吸引人的技巧是非常有帮助的。
十.自由软件的社会学语境
下述如实：最好的开是从作者解决每天工作中的个人问题开始的，因为它对一大类用户来说是一个典型问题，所以它就推广开来了，这把我们带回到准则1，也许是用一个更有用的方式来描述：
18.要解决一个有趣的问题，请从现让你感兴趣的问题开始。
这是nett的情形，也是我和fetchmai1的情形，但这已在很长一段时间被大家知晓了，Linux和fetchmai1的历史要求我们注意的有趣之处是下一个阶段——软件在一个庞大的活跃的用户和协作开人员的社团中的进化。
在《神秘的人月》一Fredrooks观察到程序员的工作时间是不可替代的：在一个误了工期的软件项目中增加开人员只会让它拖得更久，他声称项目的复杂度和通讯开销以开人员的平方增长，而工作成绩只是以线性增长，这个说法被称为“rooks定律”，被普遍当作真理，但如果rooks定律就是全部，那Linux就不可能成功。
几年之后，gera1einbeng的经典之作“Thepsy1ogyofnetg”为我们更正了rooks的看法，在他的“忘我(ego1ess)的编程”einberg观察到在开人员不顽固保守自己的代码，鼓励其他人寻找错误和展潜力的地方，软件的改进的度会比其他地方有戏剧性的提高。
einberg的用词可阻止了他的分析得到应有的接受，人们对把Internet黑客称为“忘我”的想法微笑，但是我想今天他的想法比以往任何时候都要引人注目。
unix的历史已经为我们准备好了我们正在从Linux学到的(和我在更小规模上模仿Linus的方法所验证的)东西，这就是，虽然编码仍是一个人干的活，真正伟大的工作来自于利用整个社团的注意和脑力，在一个封闭的项目中只利用他自己的脑力的人会落在知道怎样创建一个开放的、进化的，成百上千的人在其中查找错误和进行修改的环境的开人员之后。
但是unix的传统中有几个因素阻止把这种方法推到极致。一个是各种授权的法律约束、商业机密和商业利益，另一个(事后来看)是Internet还不够好。
在Internet变得便宜之前，有一些在地理上紧密的社团，它们的文化鼓励eingberg的“忘我”编程，一个开人员很容易吸引许多熟练的人和协作开人员，贝尔实验室，mITa1实验室erke1ey，都成为传统的、今天仍然是革新的源泉。
Linux是第一个有意识的成功的利用整个世界做为它的头脑库的项目，我不认为Linux的孕育和万维网的诞生相一致是一个巧合，而且Linux在19931994的一段Isp工业大展和对Internet的兴趣爆炸式增长的时期中成长起来，Linus是第一个学会怎样利用Internet的新规的人。
廉价的Internet对Linux模式的演化来说是一个必要条件，但它并不充分，另一个关键因素是领导风格的开和一套协作的氛围使开人员可以吸引协作开人员和最大限度地利用媒体。
但是这种领导风格与氛围到底是什么呢?它不能建立在权力关系之上——甚至如果它们可以，高压的领导权力不能产生我们所看到的结果，einberg引用了19世纪俄国的无政府主义者kropotkin的“memorisofaRevo1utionist”来证明这个观点：
“我从小生活在一个农奴主的家庭中，我有一个活跃的生活，象我们时代的所有年轻人一样，我深信命令、强制、责骂、惩罚等等的必要性。但是当我(在早期)必须管理一个企业，和(自由)人打交道时，当每一个错误都会产生严重后果时，我开始接受以命令和纪律为准则来行动和以普通理解为准则来行动的区别。前者在军事阅兵中工作的很好，但是它在现实生活中一文不值，目标达成只是靠许多愿望的聚合的简单后果。”“许多聚合在一起的愿望的直接后果”精确地指出了象Linux的项目所需要的东西。“命令的准则”在Internet这种无政府主义的天堂中一群自愿者之中是没有市场的，为了更有效的操作和竞争，想领导协作项目的黑客们必须学会怎样以kropotkins含糊指出的“理解的准则”模式来恢复和激活社团的力量，他们必须学会使用Linus定律。
前面我引用“de1hpi效应”来作为Linus定律的一个可能的解释，但是来自生物学和经常学的自适应系统的更强大的分析也提出了自己的解释，Linus世界的行为更象一个自由市场或生态系统，由一大群自私的个体组成，它们试图取得(自己)最大的实效，在这个过程中产生了比任何一种中央计划都细致和高效的自的改进的结果，所以，这里就是寻找“理解的准则”的地方。
Linux黑客取得的最大化的“实际利益”不是经典的经济利益，而是无形的他们的自我满足和在其他黑客中的声望，(有人会说他们的动机是“利他的”，但这忽略了这样的事实：利他主义本身是利他主义者的一种自我满足的形式)，自愿的文化以这种方式工作的实际上并非不寻常，我已参与一个科幻迷团体很长时间了，它不象黑客团体一样，显式地识别出“egoboo”(一个人在其他爱好者之中的声望的增长)作为自愿者活动背后的基础驱动力)。
Linus成功地把自己置于项目的守门人的位置，在项目中开大部分是别人做的，他只是在项目中培养兴趣直到它可以自己展下去，这为我们展示了对kropokin的“共同理解原则”的敏锐把握，对Linux这种类似经济学的观点让我们看到这种理解是怎样应用的。
我们可以把Linus的方法视为创建一个高效的关于“egoboo”(而不是钱)的市场，来把自私的黑客个体尽可能紧密的联系起来，达成只能通过高度协作才能得到的困难的结果，在fetchmai1项目中我展示了(在较小规模上)这种模式可以复制，得到良好的结果，也许我比他更有意识一点、更加系统一点。
许多人(尤其是哪些由于政治原因不信任自由市场的人)会盼望自我导向的自我主义者的文化破碎、报废、秘密和敌对，但这种盼望很明显地被Linux的文档的多样性、质量和深度打破了，程序员讨厌写文档似乎已是圣训，但Linux的黑客们怎么产生了这么多?显然Linux的egoboo自由市场比有大量资金的商业软件产品的文档部在产生有品德的、他人导向的行为方面工作的更好。
Fetnetux内核项目都表明，通过恰当的表彰许多其他黑客，一个强大的开者／协调者可以用Internet得到许多协同开人员而不是让项目分崩离析为一片混乱，所以关于rooks定律我得到了下面的想法：
19.如果开协调人员有至少和Internet一样好的媒介，而且知道怎样不通过强迫来领导，许多头脑将不可避免地比一个好。
我认为自由软件的将来将属于那些知道怎样玩Linus的游戏的人，把大教堂抛之脑后拥抱市集的人，这并不是说个人的观点与才气不再重要，而是，我认为自由软件的前沿将属于从个人观点和才气出的人，然后通过共同兴趣自愿社团的高效建造来扩展。
可能不只是自由软件的将来，在解决问题方面，没有任何商业性开者可以与Linux社团的头脑库相匹敌，很少有人能负担起雇佣200多个为fetnetbsp;也许最终自由软件文化将胜利，不是因为协作在道德上是正确的或软件“囤积居奇”在道德上是错的(假设你相信后者，Linus和我都不)，而仅仅是因为商业世界在进化的军备竞赛中不能战胜自由软件社团，因为后者可以把更大更好的开资源放在解决问题上。
友写给作者的感想:
你好，erinetbsp;我刚读了你的大教堂／市集的因为你的主页指出你还要继续关于这个问题的思考，我提供一些个人的观察。
先介绍一些背景：当1990年出现sdnet／2的时候，radgrantham和我把它移植到了2平台上，它在几个月之后以sd布(当然是以市集风格)，后来成为netsd／
我作为一个市集协调人学到了一些东西：
1.人们很快地自愿提供帮助，但是常常很慢，我们收到上百封信说：“我很想帮助，请告诉我需要什么?”这些人没提供什么帮助，不管他们有多么积极，真正有帮助的人那些给我们的第一封信便说：“嘿，我修改了这个，这儿有一个补丁。”最后我们忽略了所有第一种类型的邮件(只是把他们引向工作列表)，培养与第二种人的关系，这种情况所有协调人都应知道，来克服看到这么多“志愿者”时的盲目高兴。
(注意：他们的动机是好的，他们只是没有认识到他们正在志愿做什么)。
2.你已经提到了这一点，但我认为它是极端重要的：甚至在你宣布产品以前你必须有一个可工作的系统：例如，我们一直等到有了一个可引导的内核和一个单用户根she11之后才把它贴到usenet，曾有过(据我所知)四个不同的Linux项目，每一个都在Linux新闻组中有一大批拥护者，都创建了邮件列表，每个人都很热情，写了FaQ，还有许多诸如os的图标应是什么样的讨论。所有这些项目没有布一行代码或者一个内核、我挑选了mkLinux(app1e开的)作为一个可工作的版Linux(在一个项目Linux假设运转在68k上，而邮件列表中所有的讨论都是关于怎样把它移植到er上。68k版本甚至不能远程工作!)，这些项目吸引了上述的第一种“帮助者”，热情高涨但是实际上却没做什么事，杀掉一个项目最快的方法是在你什么都还没有之前就宣布它，我已经见的太多了，尤其是在
Linux世界里。
我知道这两点看起来相当悲观，但我知道当我们想到“啊，我们做了这么多事了，肯定搞定了不少问题了吧！”的时候，我们太容易失去理智。而那实际上只不过是一些善良的动机罢了(谁说过：“不要把动机和行动混淆在一起?”本·弗兰克林？)协调人需要解散所有那些诸如图标应该是什么样的、FaQ用hTmL格式还是sgmL模式的热情讨论，而把注意力放在取得产品的一个可工作的版本，一旦得到了，人们就真正开始帮助了。
（从正面来sd极大地得益于从它的开风格，我们得到了代码、设备驱动程序、钱和一些捐赠和借到的测试和开的硬件设备)。
我期望看到对我上述观点的任何评论和你关于这个主题写的任何东西。
Larrance
=>>(本章未完,请点击下一页继续阅读)