大教堂与市集(The Cathedral and the Bazaar)

http://www.catb.org/~esr/writings/cathedral-bazaar/

好软件都源自解决开发者的切身之痛。Every good work of software starts by scratching a developer’s personal itch.

优秀的程序员知道要写什么，而伟大的程序员知道要改写（和重用）什么。Good programmers know what to write. Great ones know what to rewrite (and reuse).

“为舍弃而计划，无论如何，你都要这样做。 “Plan to throw one away; you will, anyhow.” (Fred Brooks, The Mythical Man-Month, Chapter 11)

只要你态度正确，有趣的问题就会找上门来。If you have the right attitude, interesting problems will find you.

对一个项目失去兴趣的时候，你的最后责任就是找一个称职的接班人。When you lose interest in a program, your last duty to it is to hand it off to a competent successor.

把用户当作开发伙伴，是快速改进代码和有效调试的不二法门。Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.

早发布，常发布。并听取用户意见。Release early. Release often. And listen to your customers.

只要有足够多的人手参与公测和开发，任何问题都会显而易见并被很快化解。Givena large enough beta-tester and co-developer base, almost every problemwill be characterized quickly and the fix obvious to someone.

精巧的数据结构即使搭配笨拙的程序代码，也比精巧代码加笨拙结构的组合要强得多。Smart data structures and dumb code works a lot better than the other way around.

如果你把公测参与者作为最宝贵的资源来对待，那么他们就会成为你最宝贵的资源。If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource.

自主创意很好，能认可源自用户的点子也不错。有时借笔生花更具成效。The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.

通常，当你确信自己在解决一个错误问题的时候，会激发最具突破和创造力的方案。Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.

“完美（的设计）意味着没有东西可以再被加入，而是没有东西可以移除”“Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.”

任何工具都应该起到预期的作用，而一个真正杰出的工具会带来出乎意料的用途。Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.

在写任何网关软件的时候，都该花点功夫尽可能不去干扰数据流——除非用户强迫你，否则永远不要抛弃任何信息When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!写任何程序都是一样，维护好你的数据流

当你的语言还远不足以达到图灵完备的时候，不妨为语法蘸上一层“糖衣”When your language is nowhere near Turing-complete, syntactic sugar can be your friend.

安全系统的效用只取决于对秘密的保护，谨防伪安全。A security system is only as secure as its secret. Beware of pseudo-secrets.

要解决有趣的问题？那就先找到你感兴趣的吧！To solve an interesting problem, start by finding aproblem that is interesting to you

倘若开发的协调者拥有不逊于因特网的媒介，又懂得如何避免强权领导，那么群体智慧定要强于单打独斗。Provided the development coordinator has a communications medium at least as good as theInternet, and knows how to lead without coercion, many heads are inevitablybetter than one.

---

关于Linus的. 其实，李纳斯的睿智和最有影响的手笔并不在于他发明了Linux内核，而是创造了一种模式。有一次我当面向他表达这个见解的时候，他莞尔地说起那句口头禅：“基本上，我很懒，懒到用他人的工作换取口碑。”像狐狸一样懒惰，或许如同罗伯特·海因莱笔下那个著名的人物一样——太懒了，才不会失败。李纳斯也不像（至少目前没有）理查德·斯多曼和詹姆斯·戈士林（NeWS和JAVA之父）那样在在设计领域天赋异禀，在我看来，他的才智更多的表现在操控和执行中。凭借着规避错误和防止陷入僵局的第六感，他能够发现解决问题的捷径。事实上，整个Linux的设计都散发出这种气质，处处体现出他质朴简洁的设计风格。

Eric Raymond在做fetchmail时的建议

• 我早发布，常发布（从未低于十天一次，在高强度的开发周期则每天一次）。
• 我把每个曾和我讨论fetchmail的人都列入公测名单。
• 每当新版本发布，我都会不厌其烦的给公测名单里的每个人寄送一份，并鼓励其参与。
• 我听取公测人员的意见，在设计上征求他们的看法。并且当他们寄回补丁和反馈的时候，给予鼓励。

一个奇怪的现象. 实际上，在1997年5月下旬我改写本书的时候发现，发现出于一个有趣的原因，当人数逼近300峰值时就会开始流失成员。一些人要求我把他们从名单中去掉，因为fetchmail对他们而言已经近乎完美了，所以他们不再需要收到通讯了。或许对于一个成熟的市集型项目，这是其正常生命周期的一部分吧。 所以我坚信fetchmail项目的成功应部分归因为我克制了自己的自作聪明；这（至少能够）反驳“原创设计制约市集模式成败”的观点。回头看Linux，假设李纳斯在开发操作系统核心时力主原创的话，我们现在还能见到如此稳健成功的内核?吗所以说在满足要求下简朴的设计永远好过复杂的设计，一开始就从简朴的角度出发，克制自己的聪明并且承认自己能力限制才是正道

Bazaar模式下的软件开发的建议. 一旦你着手组建团队，就需要给出一个可行的承诺。你的程序并非必须运行良好，它可以是粗糙的、遍布瑕疵的、不完善的、也可以是缺少说明文件的。但是必须满足 a. 它能运行 b.能让潜在的协作开发者相信在不久的将来它能变得精良。在我看来一个项目的主持人是否能够做出足以彪炳的设计并不很关键。而至关重要的是，他是否可以从他人的创意中慧眼识英(操控性)。一个闭门造车的开发者将会输给一个懂得如何营造开放，演进环境的开发者。因为在这样的环境下，他可以从几百（甚至几千）人中汲取反馈从而探索设计空间、得到代码捐赠、错误检测、以及其他改进。

关于科学和贡献的东西. 所以说，（软件或其他领域）革新的根本问题是：首先，如何培养那么多能够创新的人才；以及如何避免排挤他们。假定大教堂风格可以促成创新，而门槛低、流程通畅的市集模式则无能为力，显然是很荒谬的。如果创造源自一个人加一个好主意，那么能吸引成百上千人共同协作的社会环境必然优于一个必须通过政治手腕向上级推销创意的环境（为了避免不被炒鱿鱼，你必须在得到批准之后才能继续研发）。确实，如果我们检视一下大教堂模式下的软件创新史，不难发现源自其自身的创造凤毛麟角。大企业需要通过大学中的研究获取新知（因此，万圣节文件的作者对Linux对研究成果的快速吸收深表不安）。或者收购一些由于某个创意而组建的小公司。这两种创新均非源自大教堂文化。恰恰相反，很多类似被买断的创见被（万圣节文件作者鼓吹的）“庞大的管理成本”扼杀了。

有趣的是，你会很快发现，即使你谦卑地坦陈别人为此做出多大的贡献，外界也不会这么看。大多数人认为是你创造了一切，而你只是为自己的天赋表示出适当的谦虚。李纳斯就是个生动的例子！话说回来，大多数科学、工程和软件的成果都不是来自原创天才，恰恰相反，是锐意进取铸就了神话。