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