《大教堂与集市》—— Eric S.Raymond

[thzt]

我相信最重要的软件（操作系统和 Emacs 之类的大型工具）需要像大教堂一样来搭建
Linux 社区 更像一个充满不同议程和方法的嘈杂的大集市
为什么 Linux 世界没有在混乱中分崩离析， 而是以大教堂的建造者们难以想像的速度茁壮成长

• 1. 每一个好的软件的起因都是挠到了开发者本人的痒处
• 2. 好的程序员知道写什么。伟大的程序员知道改写 （和重复使用）什么。
• 3. 直到你第一次实现一个方案之前，你常常并 没有真正理解你的问题。第二次呢，或许你已经学到了如果 把它做对。所以你要是想把事情做对的话，准备好至少重来 一次
• 4. 如果你有正确的态度，有意思的问题会找到你
• 5. 当你对一个项目失去兴趣时，你的最后的职责是把 它交给一个称职的继承者
• 6. 把用户像合作者来对待是通往快速改进代码和有效 调试的最佳通道

---

早发布、常发布

• 7. 早发布。常发布。听取用户的意见
• 8. 如果 beta 测试者和合作开发者的群体足够大的 话，几乎每个问题都会快速显形，会有人轻而易举地把它解决。

只要眼球足够多，所有臭虫都好捉”。 我称之为“林纳斯法则”。我认为林纳斯法则中包含有大教堂模式和市集模式的关键区别。在大教堂式的编程观念中，臭虫和开发上的问题是 复杂、困难和深度的。要几个人全身全力几个月的钻研才有把它们清理干净的信心。所以需要长长的发布周期；一旦等 候已久的版本不够完美，失望是不可避免的。

另一方面，在市集式的观念中，你预设臭虫都是简单 的问题——至少在上千个共同开发者热心地琢磨每一个新版 本的情况下，它们会很快就变简单了。相应地，你频繁发布 来得到更多的纠错。作为一个附加效应，偶尔出个大勺子的 后果也没有那么严重了。

社会学家们多年前就发现 了一大群同样内行（或同样白痴）的观察者的平均预测要比 其中随机选择的一个人的预测可靠得多。他们称之 为“神庙 效应”。

林纳斯法则也可以表述为“调试是可并行的”。

“早发布、常发 布”策略的一个后果就是通过快速公布反馈修补来把重复做 功最小化。

布洛克（《人月神话》的作者）甚至作过一个相关的非 正式评论：“一个广泛使用的程序的维护费用一般是它的开 发成本的 40％以上。

---

臭虫大多集中在不同人写的代码的界面上

项目的通讯结构必须是 一个完整的图、每个人都与其他所有人交接。

• 11. 仅次于拥有好的主意的是认识到来自于用户的好 主意。

如果你完全坦诚和谦虚地承认你欠了别人 多少，你很快就会发现外面的世界会把你放在这样一个地位 上

• 12. 最有突破和创新的方案常常来自于意识到你把问 题的模型弄错了。
• 13. “设计达到完美的时候，不是增加得不能再增加 了、而是减少得不能再减少了”。
• 14. 任何一个工具都应该达到预期的用处，但是一个 真正棒的工具会带来你从来预期不到的用处。
• 16. 当你的语言离图灵穷尽还差得远的时候，，给语 法加点风味可以有帮助。
• 17. ）一个安全系统的安全性取决于它保守的秘密的安 全性。小心伪秘密。

当你开始社区建设的时候，你需要能够呈现一个可行的 前景。你的程序不一定要工作的非常好。它可以是粗糙的、 问题多多的、不完整的、缺少文档记录的。它一定不能失败 的是
（1）能运行，
（2）说服潜在的合作者它可以在可预 见的将来进化成真正漂亮的东西。

要建设一个开发社区，你需要吸 引人群，让他们对你做的事情感兴趣，并且让他们对自个儿 的工作量舒心。

• 18. 要解决一个有意思的问题，首先找到一个你觉得 有意思的问题。

项目的复杂程度和通讯成本按开发人员数目的平方增加，而 业绩仅以直线增加。

市集模式，通过借助“无私编程”效果的极致动力，强烈 抵制了布洛克法则的效果。