Thinking in <The Cathedral and the Bazaar>  《大教堂和集市》摘要
by lostfire

1. Every good work of software starts by scratching a developer's personal itch.好的软件都起源于开发者本身的切身之痛
    这一条或许可以解释为什么开源的程序往往质量比较高。
2. Good programmers know what to write. Great ones know what to rewrite (and reuse).优秀的程序员知道写什么程序，伟大的程序员知道改写或重用什么程序。
    一个很简单的逻辑是，在现有基础上工作总比什么都没有强。很多人以为这样很难创造出伟大的作品，其实不然，对于大多数软件开发来说，优秀的软件总是在不断改进中创造出来的，谁能一步就做成伟大的作品呢？我认为这里的关键思想是软件要以用为本，软件不是艺术品，虽然伟大的软件看起来如此的完美，以至于创作的人常常将其当成艺术品来看待。软件开发的目的就是要满足人的需求，只不过优秀的设计比拙劣的设计更容易达到这个目标而已。
3. ``Plan to throw one away; you will, anyhow.'' (Fred Brooks, The Mythical Man-Month, Chapter 11)计划抛弃一种途径吧，因为你将来一定会这么做的。（选自《人月神话》）
  针对一个问题, 在尚未作出第一个解法前, 你通常并不真正了解这个问题. 也许第二次的時候你才能充分了解怎麼做才对, 所以即使你想做对一件事, 但起码你要准备从第一次做起.
4. If you have the right attitude, interesting problems will find you.如果你有正确的观念，你就会发现很多有趣的问题。
5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.当你对一个问题失去兴趣的时候，你的最后一个责任就是把它移交给一个胜任的继承者。
6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.把使用者当成合伙的开放者是进行快速代码改进和有效debug的最有效途径。
    事实上, 开放源码世界的所有人, 几乎都严重低估了因使用者增多而产生用以对抗系统复杂度的力量, 直到 Linus Torvalds 明白地揭露了這一点.在开源界很多软件的使用者同时就是开发高手，他们有更好的直觉和开发能力，绝对是必须重视的力量。
    每一个成功的软件几乎都经过若干次重写或重构，而迫使重写或重构的原因几乎全部来源于使用者的需求，他们高瞻远瞩又精准的需求迫使开源的软件不得不做的越来越棒。
7. Release early. Release often. And listen to your customers.早早的发布，经常发布，并倾听使用者的意见。
    其实现在我们很多熟知的公司或软件都自觉不自觉的通过这种方式来提高声望，比如PPlive，比如gmail，使用户产生一种期待和参与感，十分有利用提高软件的知名度，培养忠实的用户群体。
    看看Eric对Linus的评价：虽然 Linus 是一位很厉害的高手 (在我们之间, 有多少人能够完整地写出一個具有商品品质的作业系统核心呢? ), 但 Linux 並不是一个空间先进的观念, Linus 也并非(或者说至少目前还不是) 如 Richard Stallman 或 James Cosling (NeWS 和 java 的创世者)这样的天才创新者, 而我个人认为他是一位天才工程师, 他有避免程序错误及避免程序发展掉入死胡同的第六感, 和找到两点间最省力路径的技巧. 事实上,整个 Linux 的设计中, 我们可以看到 Linus 表现出的品质和他保守而简单的设计取向.
8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.如果有足够的beta测试者和合作开发者基础，几乎每一个问题都可以很快的定位，并且对某些人来说修复他们是很显而易见的事情。
    足够多的人来看程序，所有的问题都变得很浅显。
    我想这就是教堂模式和市集模式最主要的不同, 以教堂建造者的观点来看程序发展, 程序错误和相关问题难以处理,并潜伏在深处， 需要数个月的工夫仔细查看來找到他们, 而这对程式开发者的自信少有加许. 发布的周期越长, 一旦经长期等待的新版本发布后便不如预期完美, 使用者的失望也越大.
    开发者和单纯使用者对于软件模型的认识是不同的，开发者从内向外看，而使用者从外向里看，因而造成沟通上的问题。但开源模式就避免这个问题，大家都在代码级别上有效的交流。在《人月神话》里边Brook谈到了增加人员带来的沟通的开销是十分巨大的，这个问题在开源模式大大减少了一个人同其他所有人这种沟通，避免了沟通开销的问题。
9. Smart data structures and dumb code works a lot better than the other way around.轻巧的数据结构同笨拙的代码搭配比相反的组合要好。
10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.如果你把beta测试者当作你最宝贵的资源，那么他们也会用成为你最宝贵的资源来回报你。
     看看Eric使用的方法吧：
1) 我尽早并经常发布新版本 (几乎至少每十天就发表一次, 甚至在开发的高峰期, 一天一次)
2) 对于每一位与我讨论 fetchmail 的人, 我把他们列入 beta 测试者的名单 , 所以名单越來越长.
3) 每当我开发出新版本, 一定发出像聊天般的通知给 beta 测试者名单上的人, 鼓励他们一起來参与这个项目.
4) 而我也总是倾听 beta 测试者的心声, 询问他们对于这个程序的设计上有无意見, 并且回应他们送来对程序的修补和回馈.

11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.下一个获得好点子的最好的方法是识别那些从使用者中反馈的好主意，更后到来的往往更好。
    你将会发现一件很有趣的事: 如果你很诚实并很谦虚地知道你欠人多少, 那么全世界都会认为你发明了全部, 而且对你先提出的天才创作, 也会以为你非常谦虚, 这些我们可以在 Linus 身上得到印证.
12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.通常最显著的最有创新性的革命都来自于意识到你对于问题概念理解的错误。
    当你在开发程序的过程中撞到障碍物时 -- 也就是当你发现很难想出下一步要怎么修复时, 通常是反省的时候了, 但不是问是否已找到正确的答案, 而是我们提出正确的问题了么?也许问题需要再重新整理一番.
13. ``Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.''"完美不是已经没有东西可以加入而是没有东西可以移除"－－from Andrew S. Tanenbaum<Modern Operating system>
14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.用所期待的方式使用任何工具都应该有用，但是真正伟大的工具会让你以从来未曾预想的方式使用。
     这个是一个多么伟大的境界，或许可以好比说你在解析了一千种表达式以后创造了正则表达式的解析器而你却不知道将来谁会怎样使用它，如果说这个说法不太恰当，那么在Linux中如此多的简单的工具，完成了超出其本意的工作或许可以说明问题。或许可以假设你做一个东西出于你的一个本意但它太经典了以至于用户在它基础上开发了许多种的新用法，或许我现在用gmail写blog就是gmail这个team不曾预想过的吧。
15. 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! 在写任何网关软件时，尽可能不去弄乱数据流，永远都不要丢弃任何信息，除非接受者强迫你这么做。
当CPU和存储都变得便宜时, 设定的语法的简洁已不再是我们的目标, 现在的情況是: 一个电脑语言中符合人性易於使用的重要性已超过节约电脑的计算资源.
16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.当你的语言没有严谨到接近图灵完整性的时候，最好采用平易的语法。
17. A security system is only as secure as its secret. Beware of pseudo-secrets.一个安全系统是否安全取决于它保存的秘密，不要伪装秘密。

集市模式的条件：
不能用集市模式来建立软件，只能用来测试，除错和改进。
要让你的设计使人能够相信你的软件将来会大有可为。
事实上，协调者是否具有天才设计并不重要，重要的是他要能够识别别人给出的好主意。
开放源码社区对于名誉的重视给人一种微妙的压力，如果无法胜任项目以后的发展，那么就不要去启动。
领导人良好的沟通技巧。
18. To solve an interesting problem, start by finding a problem that is interesting to you.为了解决一个有趣的问题，开始寻找一个对你来说有趣的问题吧。
19: Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.给开发协调者一个至少像Internet一样好的沟通媒介，并且知道如何不用强制来领导，那么许多人一定比一个人要好。
注：
1，蓝色字体部分是在下的一些理解。
2，详细文本，From:http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/index.html