记得还是在读大学的时候读到的这篇文章，那个时候对文章的理解不是很深刻，工作多年以后再读这篇文章，对里面的很多思想有可比较深刻的认识，特别是关于软件管理方面的。 也许没有实践经验，有的东西就很难理解吧。
大师的思想不会随着时间的变化而失去光辉的，快20年过去了，依然闪烁着智慧。而且随着开源社区的壮大，git这样的工具出现，我们不的不佩服大师看待未来的眼光，对前沿的敏锐观察力。
英文版：The Cathedral and the Bazaar
中文版：大教堂和集市
摘抄
2.优秀的程序员知道要写什么，而伟大的程序员知道要改写（和重用）什么。 Good programmers know what to write. Great ones know what to rewrite (and reuse).
4.只要你态度正确，有趣的问题就会找上门来。 If you have the right attitude, interesting problems will find you.
7.早发布，常发布。并听取用户意见。 Release early. Release often. And listen to your customers.
我最初的表述是：“（任何问题）都会被某人化解”，李纳斯却对此存有异议，他认为问题的发现和解决并不一定要由同一个人来完成，甚至可以说解决问题的通常不是发现者本人，我想这个纠正是必要的。“有人发现问题”，他说道。“其他人解决问题，而我要特别强调――发现问题才是重头戏。”在下面的章节，我们会深入探讨在调试时会发生什么。而关键是，在Linux的世界里无论发现还是修补问题都很迅速。
这就是大教堂与市集模式的区别。在修建教堂时，你所面临的错误和开发中的问题狡黠凶险、隐伏至深。哪怕几个人在几个月的时间里竭尽全力也不见得能把它们通通解决。一旦漫长的等待换来不尽如人意的产品，那么失望就在所难免了。
另一方面，站在市集的角度。你可以假设所有问题都是显而易见的――至少在上千个热情参与者的反复推敲下，它们都会变得显而易见。频繁的发布可以换取更多的修正，所以偶尔捅个大漏子也没什么大不了的！
重复劳动开销的增长趋向低于由开发团队扩大带来的指数式成本增长。也就是说，开发团队扩大所带来计划和管理成本增速要远高于重复做功的开销。
将李纳斯定律和哈斯勒定律结合起来，我们不难找到三种软件工程的对应模式：对于开发者不超过三人的小工程，无需领导和预设管理结构。对于中型工程，采用传统的管理模式成本则相对较低。并且可以有效的防止重复劳动，错误追踪，并且能很快的发现详细资料是否有遗漏，从而确保万无一失。
在此之上，李纳斯定律和哈斯勒定律共同说明了：对于大型工程，传统管理模式带来的问题和成本增幅，远超过预期的重复劳动的开销。而这种调动大家参与所带来的微小开销并不是一个结构上的缺陷，相反（我们看到）这能比传统方法更有力的保证错误和细节无一遗漏。在大型工程中，应用这两则定律可以让那些传统模式下的本息（沉默成本和边际成本――译者按）趋近于零。
Linux拆分稳定版和实验版的作法，除了分担风险之外还有一个作用――干掉发布期限。实际上，一旦程让序员同时面对刻版的功能列表和该死发布时间，软件的质量就会大打折扣。这是研发中的一个重要问题。感谢来自哈佛商学院的马可?伊恩斯蒂（Marco Iansiti）和艾伦?麦科马克（Alan MacCormack）让我明白了一个道理――放松二者任意一个，都可以让工作进程更加有效。
一个做法就是制定发布日期，但让功能列表可以变通调整。也就是说，在发布时允许舍弃部分功能。这是稳定版内核开发的基本策略；艾伦?考克斯（Alan Cox，稳定版内核的维护者）定期发布稳定版，但是不承诺何时解决某个问题或者何时添加某个实验版的新功能。
另一个做法则是，锁定开发列表但不制定发布时间。这是实验版内核开发的基本策略。我们称之为：“做完再叫醒我（wake me up when it’s done）策略”。达?马可（De Marco）和利斯特（Lister）的研究表明这不仅可以提高软件质量，而且平均而言，它比任何“激进”或“保守”的策略都节省研发时间。
2000年初，我开始怀疑自己在前作（指本书的前期版本――译者按）中严重低估了这种反发布时间（做完再叫醒我）策略对于开源社区的生产力以及质量的重要性。1999年GNOME仓促1.0版的教训表明：即使是开源项目，为了赶进度而草率发布，也会严重影响软件质量。
有充分的理由可以表明：开发过程的透明化、“做完在叫醒我”的策略以及开发者自主选择研发对象的方法。是影响开源项目质量的三个同等重要的作用力。
正如布鲁克斯定律所言传统软件开发结构下的根本问题是：“为已经延期的项目增添人手会让它拖的更久。”通俗的讲，布鲁克斯定律昭示了：项目的复杂度和通讯成本会以开发人数为基础，呈现平方指数的增长态势，而绩效则仅能直线上升。
经验证实，错误大多集中在（不同人编写的）代码的接口处，而沟通/协调成本则会随着人员交流渠道的增加而增加，这就是布鲁克斯定律建立的基础。 然而问题也会随着开发者沟通渠道的增多而增加，后者恰好等于开发人数的平方。（更确切地说，是遵循N*(N-1)/2公式，其中N代表开发者人数）
布 鲁克斯定律（对于开发团队过大所导致的令人担忧的结果）的分析是基于一个潜在假设的：即项目必须采用全向连通的通讯结构，也就是说每个人都能与其他任何人取得联系。 然而在开源项目中，外延开发是可以分离的平行子环节，彼此关联甚少。代码变动和错误报告都流经项目的核心团队，只有在那里我们才需要担负“布鲁克斯式”的管理成本。
1.根据为我提供不同难易追踪途径的读者的推测，这种对多表象错误的追踪的复杂度呈“指数”分布（我理解为高斯或者泊松分布，而且这听上去很有道理）。 要是能通 过实证绘出类似分布曲线的话，绝对很有价值。假如其与等概率分布平行线大相径庭，那么即使独自开发也应该努力效仿市集模式。也就是限定追踪问题的成因的时 间，如果在限定时间内没有结果，那么就跳转到下一问题。坚持有时不见得是件好事……
9.精巧的数据结构即使搭配笨拙的程序代码，也比精巧代码加笨拙结构的组合要强得多。 Smart data structures and dumb code works a lot better than the other way around.
有趣的是，你会很快发现，即使你谦卑地坦陈别人为此做出多大的贡献，外界也不会这么看。大多数人认为是你创造了一切，而你只是为自己的天赋表示出适当的谦虚。李纳斯就是个生动的例子！
12.通常，当你确信自己在解决一个错误问题的时候，会激发最具突破和创造力的方案。 Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
这说明了什么？只要不损失效率，就不要对丢弃一些功能而举棋不定。圣-埃克苏佩里[3]（当他不写作经典儿童书籍的时候，是一个飞行员兼飞机设计师）曾说过：
13.“完美（的设计）意味着没有东西可以再被加入，而是没有东西可以移除”。 “Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.”
话说回来，大多数科学、工程和软件的成果都不是来自原创天才，恰恰相反，是锐意进取铸就了神话。