重要通知:域名变更为m.bxuu.net请收藏
比其他任何人更努力地充分利用了Internet进行合作，所以这确实能行。
但是它是怎样进行的呢?它是我能模仿的吗?还是这依赖于Linus的独特天才?
我不这样想，我承认Linus是一个极好的黑客(我们有多少人能够做出一个完整的高质量的操作系统内核?)，但是Linux并不是一个令人敬畏的概念上的飞跃，Linus不是(至少还不曾是)象Richardstallman或JamesGosling一样的创新天才，在我看来，Linus更象一个工程天才，具有避免错误和开发失败的第六感觉，掌握了发现从A点到B点代价最小的路径的决窍，确实，Linux的整个设计受益于这个特质，并反映出Linus的本质上保守和简化设计的方法。
如果快速的发布和充分利用Internet不是偶然而是Linus的对代价最小的路径的洞察力的工程天才的内在部分，那么他极大增强了什么?他创建了什么样的方法?
问题回答了它自己，Linus保持他的黑客用户经常受到激励和奖赏：被行动的自我满足的希望所激励，而奖赏则是经常(甚至每天)都看到工作在进步。
Linus直接瞄准了争取最多的投入调试和开发的人时，甚至冒代码不稳定和一旦有非常棘手的错误而失去用户基础的险，Linus似乎相信下面这个：
8.如果有一个足够大的beta测试人员和协作开发人员的基础，几乎所有的问题都可以被快速的找出并被一些人纠正。
或者更不正式的讲：“如果有足够多的眼睛，所有的错误都是浅显的”(群众的眼睛是雪亮的)，我把这称为“Linus定律”。
我最初的表述是每个问题“对某些人是透明的”，Linus反对说，理解和修订问题的那个人不一定非是甚至往往不是首先发现它的人，“某个人发现了问题”，他说，“另一个理解它，我认为发现它是个更大的挑战”，但是要点是所有事都趋向于迅速发生。
我认为这是建造教堂和集市模式的核心区别，在建造教堂模式的编程模式看来，错误和编程问题是狡猾的、阴险的、隐藏很深的现象，花费几个月的仔细检查，也不能给你多大确保把它们都挑出来的信心，因此很长的发布周期，和在长期等待之后并没有得到完美的版本发布所引起的失望都是不可避免的。
以市集模式观点来看，在另一方面，我们认为错误是浅显的现象，或者至少当暴露给上千个热切的协作开发人员，让他们来对每个新发布进行测试的时候，它们很快变得浅显了，所以我们经常发布来获得更多的更正，作为一个有益的副作用，如果你偶尔做了一个笨拙的修改，也不会损失太多。也许我们本不应该这样的惊奇，社会学家在几年前已经发现一群相同专业的(或相同无知的)观察者的平均观点比在其中随机挑选一个来得更加可靠，他们称此为“Delhpi效应”，Linus所显示的证明在调试一个操作系统时它也适用——Delphi效应甚至可以战胜操作系统内核一级的复杂度。
我受JeffDutky()的启发指出Linus定律可以重新表述为“调试可以并行”，Jeff观察到虽然调试工作需要调试人员和对应的开发人员相交流，但它不需要在调试人员之间进行大量的协调，于是它就没有陷入开发时遇到的平方复杂度和管理开销。
在实际中，由于重复劳动而导致的理论上的丧失效率的现象在Linux世界中并不是一个大问题，“早发布、常发布策略”的一个效果就是利用快速的传播反馈修订来使重复劳动达到最小。
Brooks甚至做了一个与Jeff相关的更精确的观察：“维护一个广泛使用的程序的成本一般是其开发成本的40%，奇怪的是这个成本受到用户个数的强烈影响，更多的用户发现更多的错误”(我的强调)。
更多的用户发现更多的错误是因为更多的用户提供了更多测试程序的方法，当用户是协作开发人员时这个效果被放大了，每个找寻错误的人都有自己稍微不同的感觉和分析工具，从不同角度来看待问题。“Delphi效应”似乎因为这个变体工作变得更加精确，在调试的情况下，这个变体同时减小了重复劳动。
所以加入更多的beta测试人员虽不能从开发人员的P.O.V中减小“最深”的错误的复杂度，但是它增加了这样一种可能性，即某个人的工具和问题正好匹配，而这个错误对这个人来说是浅显的。
Linus也做了一些改进，如果有一些严重的错误，Linux内核的版本在编号上做了些处理，让用户可以自己选择是运行上一个“稳定”的版本，还是冒遇到错误的险而得到新特征，这个战略还没被大多数Linux黑客所仿效，但它应该被仿效，存在两个选择的事实让二者都很吸引人。
五.什么时候玫瑰不是玫瑰?
在研究了Linus的行为和形成了为什么它成功的理论之后，我决定在我的工程(显然没有那么复杂和雄心勃勃)里有意识的测试这个理论。
但我首先做的事是熟悉和简化Popclient。CarlHarris的实现非常好，但是有一种对许多C程序来说没有必要的复杂性。他把代码当作核心而把数据结构当作对代码的支持，结果是代码非常漂亮但是数据结构设计得很特别，相当丑陋(至少对以这个老LISP黑客的标准来看)，然而除了提高代码和数据结构设计之外，重写它还有一个目的，就是要把它演化为我彻底理解的东西，对修改你不理解的程序中的错误负责可不是一件有趣的事。
第一个月我只是在领会Carl‘s的基本设计的含义，我所做的第一个重大修改是加入了IMAP支持，我把协议机重新组织为一个通用驱动程序和三个方法表(对应POP2、POP3和IMAP)，这个前面的修改指出一个需要程序员(特别是象C这种没有自然的动态类型支持的语言)记在脑中的一般原理：
9.聪明的数据结构和笨拙的代码要比相反的搭配工作的更好
FredBrooks也在他第11章中讲道：“让我看你的［代码］，把你的[数据结构]隐藏起来，我还是会迷惑；让我看看你的[数据结构]，那我就不需要你的[代码]了，它是显而易见的”。
实际上，他说的是“流程图”和“表”，但是在三十年的术语／文化演进之后，事情还是一样的。
此时(1996年9月初，在从零开始六个月后)，我开始想接下来修改名字——毕竟，它已不仅仅是一个POP客户，但我犹豫了，因为还没有什么新的漂亮设计呢，我的popclient版本需要有自己的特色。
当fetehmail学会怎样把取到的邮件转送到**TP端口时，事情就完全改变了，但是首先：上面我说过我决定使用这个工程来测试我关于LinusTorualds所做的行为的理论，(你可能会问)我怎样做到这点呢?以下面的方式：
1.我尽早尽量频繁的发布
本章未完，请点击【下一页】继续阅读》》