2008 年 github 問世, 現今超過 10 年。 因此很多程式人開始寫程式時 github 就存在並廣泛使用。 使用開源軟體好像是工程師與生俱來的本領。 我們覺得當然要站在巨人肩膀上開發, 我們覺得開源所以值得信賴。我們覺得那麼多工程師參一腳的程式是比較穩定跟安全的。 上述雖然有些不盡然，但卻是個大方向。 教堂與市集論文寫於 1996 年, Linux 誕生五年. Linux 開源社群採取的協作的方式, 獲得相當的成功. 這件事在當時, 對於做軟體專案的方式產生了革命性的影響。 作者 Eric S. Raymond 對於 Linux 除了驚訝外, 決定要自己做個 open source 專案, 以窺其中奧妙。 之後他寫了教堂與市集論文然後出成書. 這本書據說大受歡迎, 洛陽紙貴。 不過由於電腦工程師的訓練，實在缺乏我們對於自身歷史的了解, 開發軟體多年後, 我才在 WoFoss （Women in Free and Open Source Software in Taiwan）第一次知道這本書。 感到自己過去的不足，所以希望介紹這本書，讓想要了解 open source 的科技人參考。
教堂與市集是軟體開發方法的譬喻。 在作者所處的年代, 他相信重要的軟體 (如: Kernal 或是 Emac ) 必須如建造大教堂般, 由一群厲害如大法師或魔術師的開發者潛心的關起門來起來，精心設計與實現。不 release Beta 版, 一出版就穩定好用。 跟教堂不同, Linux 社群是如同市集一般的開發模式 — 經常修改經常 release, 授權每一件事, 不拒絕到幾乎混亂。 在這樣各有各方法與議題的開發模式下的 Linux 竟然穩定並且開發快速。這樣的成功在當時，作者描述是奇蹟。
書中，作者講述了他開啟了 fetchmail open source 專案以及他從中學到了 １９ 個課題。 今日看來，大部份課題已經深植開發者心中。 比如：”優秀的程式師知道要寫程式，偉大的程式師知道要改寫（和重覆利用）程式” 或是 “儘早，經常發表新版本，並且傾聽使用者的意見”。 或是解釋為何 Open Source 會比較穩定的- “把你的使用者視為協同發展人，可以讓你傷最少的腦筋，但做到原始碼的快速改善，程式的除錯有績效”。 這是說, 越多的使用者或開發者可以更快速的找出更多的解法或漏洞, 因此可用來對付軟體系統的複雜度。 “假如專案發展協調者擁有至少跟網際網路一樣好的媒體，而他也不靠強制力來領導，那麼一群人必定勝過一個人” — 解說了 Internet 是 Open Source 興起的重要原因，並且去權威領導的多人協作方式是比較好的。 作者說的這些東西, 現今看起來沒有特別醒目之處。 但看看今日流行的軟體開發模式原來２０年前觀念就已經形成且持續影響。比如，有的公司甚至一天一次 release, 這在過去大概不可想。 現今取代了Internet，Github 成為 open source 新媒介，更容易讓多人協作。 或許也是造成Open source community 發展的重要原因。 還有現今軟體開發注重扁平化的討論與集體式的決策，不能說不受到Open source community 的影響。
本書的後面幾個章節, 作者討論了關於一個 open source project 有那些比較重要的先決條件。 個人覺得最重要的一點，是要讓人覺得這個專案未來大有可為。 不過顯然的，作者應該是覺得 open source project 的成功很大一部分取決於專案領導者。 他提醒專案領導者在專案設計上不要太賣弄聰明, 對專案參與者在技術上也不要太吹毛求疵, 這一些皆無助於讓大家參與貢獻。 專案領導者最重要的是能夠發掘別人設計的長才, 這甚至比自己有設計長才更重要。 他認為 Linus 人超好的, 他自己則有喜劇演員天資質。 我蠻贊同這個觀點的 — 參與過幾個社群的組織, 我有時覺得我的專業是為了讓我更能發掘他人優點。 不過在搜尋作者的過程中, 我發現作者 Eric S. Raymond 在”今日”可能不是一個好的 Open Source Leader。 主要是因為他在以前發表過一些不尊重女性的言論以及鮮明的反同立場, 明顯的違反了現今很多社群的 Code of Conduct。 以 Nodejs 社群為鑑, 可能會導致社群的分裂。 或者說我想問: 圖靈在世, 是否能加入他的社群; Ada 在世, 不知他會不會跟她說話!?
本書最後一章節停在了 Netscape 擁抱了 Open Source。 我暗自思量 20 多年後，如果作者聽到 Microsoft 擁抱 Open Source 改用 Linux 核心是會有啥想法呢!?
