教堂與市集 (The Cathedral and the Bazaar)
by Eric S. Raymond
中譯: 謝志昌 (Chih-Chang Hsieh) < cch@market.tw>
$Date: 1998/11/22 04:01:20 $, 翻譯日期: 1999/5/25
本文將剖析一個成功的開放性原始碼 (open source) 專案 -- fetchmail, 該案已審慎地驗證了 Linux 發展歷史中令人驚奇的軟體工程理論. 並就兩種基礎不同的軟體發展風格來探討這些理論: 一是大部份商業化世界所採的 ``教堂'' 模式, 另一是 Linux 世界所用的 ``市集'' 模式, 由於對軟體除錯工作本質相左的假設而導致這兩種不同的模式. 接著繼續討論由 Linux 發展經驗而來的定理: ``足夠多的人來看程式, 所有的錯誤都變得淺顯'', 這與其他主動更正自我的系統有幾分相似. 最後根據以上探討對軟體發展的未來做一結論.
1.教堂與市集 (The Cathedral and the Bazaar)
2.信一定要寄到 (The Mail Must Get Through)
3.擁有使用者的重要 (The Importance of Having Urs)
生命手抄报
4.儘早發表, 經常發表新版本 (Relea Early, Relea Often)
5.今花非昨花? (When Is A Ro Not A Ro?)
6.Popclient 變成 Fetchmail (Popclient becomes Fetchmail)
7.Fetchmail 成長了 (Fetchmail Grows Up)
8.由 Fetchmail 學到的一些經驗 (A Few More Lessons From Fetchmail)
9.市集模式必要的條件 (Necessary Preconditions for the Bazaar Style)
10.開放性原始碼軟體的社會關聯性 (The Social Context of Open-Source Software)
11.致謝 (Acknowledgements)
12.進一步的參考資料 (For Further Reading)
13.結語: 網景公司擁抱市集! (Epilog: Netscape Embraces the Bazaar!)
14.本文版本與變動紀錄 (Version and Change History)
1. 教堂與市集 (The Cathedral and the Bazaar)
Linux 打破了許多軟體發展的傳統, 這個世界級的作業系統在五年前僅僅靠著如絲般的網際網路, 神奇地聯合了散布在全世界數以千計兼職的玩家們來發展它, 誰曾料到會發生這樣的事情呢?
我當然也沒料到. Linux 出現在我電腦螢幕是在 1993 年年初, 當時我埋首於 UNIX 及開放性原始碼的軟體發展已有十年, 1980 年代中期, 我是 GNU 專案首批的貢獻者之一, 我寫過許多開放性原始碼的軟體放到網路上供人使用, 也曾獨立或協同發展好幾個程式 (nethack, Emacs 的 VC 和 GUD 功能, xlife, ... 等等), 這些程式到今天仍廣泛地為人所用, 我想我知道這是怎麼辦到的.
[譯注] GNU 是自由軟體基金會 (Free Software Fundation) 的一個專案, 目標是發展出 UNIX 上所有程式的自由版本. Emacs 是自由軟體基會發展出來的一支程式, 可做文字編輯器, 提供寫程式的整合發展環境, 用來讀電子郵件, 新聞群組, 甚至瀏覽網頁. 更詳細的資訊請參考 u.口害
Linux 扭轉了許多我認為我已知道的觀念. 多年來我一直被傳以: 小工具集, 快速原型發展及
程式進化的 UNIX 福音. 但我也相信對於有一定複雜度的程式必需使用集中和有經驗的方法來開發, 我相信最重要的軟體 (作業系統以及龐大的工具程式如 Emacs) 必須如建造一座教堂般, 由個別的高手或一小群專家在光輝的孤立中小心翼翼地精雕細琢, 時機未到之前, 不會釋出測試版.
Linus Torvald 的軟體發展風格 (儘早並經常發表新版本, 授權每一件作者可以委託的事, 不拒絕幾乎到卜算子咏梅意思
混亂程度的程式) 的出現如同一個驚奇, 沒有令人肅, 然起敬的教堂, 甚至Linux 的同好們似乎組成了一個有不同流程和不同方式的大市集 (Linux 的檔案服務站台就是它適切的象徵, 每個人都服從著自由的規則), 以這個風格發展出來的 Linux 既一致又穩定, 表面上看來真是一連串的奇蹟.
[譯注] Linus Torvald 是 Linux 核心程式 (kernel) 的原始作者.
h壁纸市集模式似乎是可行的, 並且運作得很好, 這個事實帶來了相當的震憾. 當以我的方法去認知時, 我除了努力做好個人的專案, 並也試著去瞭解為什麼在 Linux 的世界, 不但沒有因為渾沌不清而四分五裂, 反而以教堂建造者幾乎想像不到的速度在茁壯.
直到 1996 年年中, 我想我才開始瞭解這一件事. 我得到了一個絕佳的機會來試驗我的理論, 這個機會是一個開放性原始碼型式的專案, 正好可以試用市集模式來發展, 所以我做了這個專案, 而且更有意義的是它成功了.
接下來在這篇文章中我將陳述這個專案的故事, 並且以它為例提出關於有效地利用開放性原始碼模式來發展軟體的格言, 這些法則並非都是我在 Linux 中第一次學到, 但我們可以看到 Linux 的世界是怎麼賦予它們特別的意義. 如果我是對的, 那麼這些格言將會幫你真確地瞭解是什麼促成 Linux 社群成為好軟體的原創者, 並且幫助你變得更具生產力.
2. 信一定要寄到 (The Mail Must Get Through)
自 1993 年起, 我一直擔任一家提供免費上線的小型ISP 的技術人員，這家 ISP 叫做 County InterLink (CCIL), 位於賓夕凡尼亞州的 West Chester. (我本身參與捐款設立 CCIL, 並寫了我們獨一無二的多人佈告欄軟體 -- 你可以用 telnet 連線至lockeil 一探究竟. 目前它共有三十條線, 可提供近三千位的使用者上網.) 這個工作讓我可以一天二十四小時透過 CCIL 56K 的線路上網. -- 事實上, 我的確非常需要它!
章鱼丸子做法
因此我必須常常利用便捷的網際網路電子郵件, 但由於一些複雜的原因, 使得我家裡的機器() 要以 SLIP 協定連上 CCIL 有所困難. 最後我還是做到了, 但我馬上發覺我必須週期性地以 telnet 連上 lokcke 來檢查我是否有新信件, 這實在是一件煩人的事. 我想要的是: 我的郵件可以被送到 snark, 而且送達時會通知我, 然後我可以用 snark 上的工具程式來處理這些郵件.
簡單的 ndmail 轉信功能在這裡幫不上忙, 因為我個人的機器並不是時時都和網路連結著而且它也沒有固定的網址. 我所需要的程式是這樣的: 它可以透過 SLIP 連線把我的電子郵件都抓回來並放在我的機器. 我知道有這樣的程式, 它們大部份都使用一個簡單的網路應用協定叫
POP (Post Office Protocol), 而 locke 的 BSD 作業系統上確定已包含有 POP3 的伺服程式.
我需要一支POP3 客戶端的程式. 所以我到網路上搜尋之後找到一個. 其實我找到了三或四支這樣的程式. 我使用了一陣子的 pop-perl, 但是它少了一個滿重要的特性 -- 就是精巧地處理抓回來信件檔頭附的
來源處, 以使收件人能回覆信件至正確的網址.
這個問題是這樣的: 假設 locke 上有一個叫做 joe 的使用者寄信給我, 而 pop-perl 把信抓回到我的 snark 上, 當我要回給信給joe 時, 我的送信程式會傻呼呼地試著把這封回信送給根本就不存在 snark 上的使用者 joe. 所以我必須動手編輯回信的網址即加上 ``@ccil'', 很快地這變成了一件頗痛苦的事情.
很明顯的這是電腦應該幫我做的, 可是現有的 POP 客戶端程式卻沒有任何一支知道要這麼做.這使我們學會了第一課:
[格言1] 好軟體都是起源於程式發展者要解決切身之痛.
1. Every good work of software starts by scratching a developer's personal itch.
也許這已是眾所皆知 (不是有句著名的諺語叫: ``需要為發明之母'' 嗎?), 但有多少軟體發展者為了薪水, 把時間都耗在寫他們既不需要也不喜愛的程式上呢? 然而這樣的事不會發生在 Linux 的世界 -- 這也許可以解釋為什麼由 Linux 社群們發展出來的軟體的平均水準都這麼高.
所以, 我是否該立即如抓狂般地投入寫作一支新的 POP 客戶端的程式來和既有的一較高下? 並不如你所想的, 我仔細地檢視我手上已握有的 POP 客戶端程式, 看看那一支最符合我的需要, 因為
服务效率[格言2] 優秀的程式師知道要寫程式, 偉大的程式師知道要改寫 (和重覆利用) 程式.
2. Good programmers know what to write. Great ones know what to rewrite (and reu).
我並非在宣稱我是一個偉大的程式師, 但我願去效法. 偉大的程式師還有一項重要的特色是老製造著偷懶的辦法, 他們認為人們爭取最好的成績並不是為了努力的過程, 而是為了最後的結果. 更何況由一個部份可行的解決方法開始總比什麼都沒有容易得多.
舉例來說, Linus Torvalds www.earthspace/~esr/faqs/linus當初寫 Linux 的核心程式時也不是從零開始, 他是由借重 Minix 的程式和構想開始的 (Minix 是一個像UNIX 的小型作業系統, 它在 386 機器上執行), 然而到最後原來屬於 Minix 的碼不是被移出就是被改寫 -- 儘管如此, Minix 的碼畢竟曾存在於 Linux 中, 並且曾為尚未茁壯的 Linux 提供一個骨架, 最後終於誕生了 Linux.
為仿效這樣的精神, 我開始找尋一個現有而且寫得有條理的 POP 工具程式, 來作為我發展新程式的基礎.
在 UNIX 的世界中, 原始程式碼共享的傳統讓我們可以很容易地重覆利用程式碼 , 這也是為什麼GNU 專案要選擇UNIX 作為它發展的平台, UNIX 作業系統本身幾乎沒做什麼保留, Linux 的世界也遵行著這個傳統, 到接近它技術極限的地步, 它供人運用旳開放性原始碼程式, 有天文數字般地多, 所以在 Linux 已有的資源中找到一個足夠好的程式要比其他的作業系統容易.
而我也的確找到了, 連我先前的搜尋再加上這一次總共有九個程式候選-- fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail 及 upop. 我首先選擇Seung-Hong Oh 寫的
``fetchpop'' 作為出發點, 我加入了我要的 ``重寫郵件檔頭'' 功能, 並且作了多處的改善. 原作者
同意將這些納入fetchpop 的 1.9 版.
幾個星期之後, 我緩緩地讀著 Carl Harris 寫的 ``popclient'' 的原始碼, 並且發現了一個問題: 雖然 fetchpop 有一些好的初始想法(如它的伺服程式模式), 但它只能處理 POP3 的協定, 而且它的原始程式只有業餘的水準(Seung-Hong 是個聰明的程式設計師, 但經驗不夠老道). 而 Carl 寫的程式碼就比較好, 具相當的職業水準和穩固性, 但他的程式缺乏了許多重要的特色, 如 fetchpop 中巧妙的實作 (包括我加入的部份).
要換還是不換呢? 假如我選擇換的話, 那麼換到一個較好的發展基礎所要付出的代價就是要丟掉我已經寫好的程式碼.
事實上我選擇換的動機是為了能支援多種 post-office 的協定, 雖然 POP3 最廣為人採用, 但它卻不是唯一可用的協定. Fetchpop 和其他同類的程式並不支援POP2, RPOP, 或 APOP, 而我早先有一個概略的想法(只是為了有趣): 加入IMAP www.imap (Internet Message Access Protocol 最新最強的 post-office 協定) 協定的支援.
一個更正式的理論讓我覺得換到新的發展基礎是個好主意, 這個理論是早在 Linux 出現前, 我就已經學會了:
[格言3] ``計畫好如何捨棄一條路吧, 你遲早會想盡辦法這麼做的.'' (引自 Fred Brooks << 人-月 的迷思>> 一書的第十一章)
3. ``Plan to throw one away; you will, anyhow.'' (Fred Brooks, ``The Mythical Man-Month'', Chapter 11)
否則, 計畫走另一條路吧. 針對一個問題, 在尚未實作出第一個解法前, 你通常並不真正瞭解這個問題. 也許第二次的時候你才能充分瞭解怎麼做才對, 所以即使你想做對一件事, 但起碼你要準備從第一次做起.
我告訴我自己: 修改fetchpop 是第一次. 所以我換到 Carl Harris 的 popclient 繼續發展 (是第二次).
當 1996 年 6 月25 日我送給Carl Harris 我第一次對 popclient 所做的修正後 , 我才曉得他已經對這支程式沒興趣了. 原來的程式碼乏人照料已有一段時間, 還包括一些次要的錯誤. 有許多修正要做, 很快的我們兩人都同意由我接手整個程式是合理的一件事.
高中生必读在我不經意間, 這個專案的規模擴大了, 我不再只注意現在的 popclient 要修補那些次要的部分, 而是要
居民委员会接下維護整個整程式, 在我腦海曾浮現許多主意, 我想這可以引導我改變 popclient 的主要部分.
在鼓勵分享程式碼的軟體文化下, 一個專案以這樣自然的方式演進. 我表現出:
[格言4] 抱持正確的態度, 就會發現有趣的問題.
4. If you have the right attitude, interesting problems will find you.
但Carl Harris 的態度更為重要, 他懂得:
[格言5] 當你對一個問題不再感興趣時, 你最後的責任就是找位能勝任的接棒人.
5. When you lo interest in a program, your last duty to it is to hand it off to a competent successor.
雖然 Carl 和我沒討論這些, 但我們卻有一個共同的目標就是對這個問題寫出最好的解法. 現在唯一的問題只剩: 證明我是個可信賴的人, 而我已經做到, 所以他便欣然地把這支程式交給了我. 我希望這個專案在我手中能變得更好.
3. 擁有使用者的重要 (The Importance of Having Urs)
我繼承了 popclient, 更重要的是我也繼承了它的使用者. 擁有使用者是很棒的一件事, 並不是因為這展
現出你在解決他們的問題, 或是你在做好事. 而是好好地培養使用者, 他們可以變成協同發展者.
UNIX 的傳統中有一種力量, 那就是許多使用者同時也是程式高手, Linux 促使這變成一件非常愉快的事. 這是因為原始碼是公開的, 所以使用者可以變成有影響力的高手, 這對縮短除錯的時間實在太有助益了. 只要你給一點掌聲, 使用者們會幫你診斷問題, 建議需修正的地方, 以及改進程式碼, 這比你自己一個人包下全部的事要快得許多.
[格言6] 把你的使用者視為協同發展人, 可以讓你傷最少的腦筋, 但做到原始碼的快速改善, 程式的除錯有績效.
6. Treating your urs as co-developers is your least-hassle route to rapid code improvement and effective debugging.
這種效應所造成的影響力很容易就被低估, 事實上, 開放性原始碼世界的所有人, 幾乎都嚴重低估了因使用者增多而產生用以對抗系統複雜度的力量, 直到 Linus Torvalds 明白地揭露了這一點.
其實我認為 Linus 在技術上最聰明和最重大的貢獻並不在於寫出 Linux 的核心程式, 而在於發明Linux 的發展模式. 在一次和他的會面中, 我提出了這點見解, 他微笑著, 並重複他常說的一句話: ``基本上我是一個非常懶的人, 因其他人在 Linux 上真正的努力, 而感到與有榮焉.''
懶惰就像狐狸一樣地精明, 或者就如同 Rober Heinlein 曾說: ``因為太懶所以成功了.''
回顧過去的例子, 在 GNU Emacs 的 Lisp 程式庫及其 Lisp 程式碼的資源庫中 , 我們可以看到 Linux 模式所用的方法和所得的成功. 相對於 Emacs 中用 C 語言寫的核心部分及自由軟體基金會其他的工具(這都是以建造教堂的模式發展), Emacs Lisp 程式碼的資源庫非常地使用者導向並且更新很快, 好的點子和原型在最後成熟穩定前常常都已重寫過三或四次, 藉由網際網路而來的非緊密合作進行得很頻繁, 就像Linux 一樣.
我在還沒寫作 fetchmail 前, 最成功的傑作大概要算是 Emacs 的 VC 功能了, 這項專案進行時，我用像Linux 一樣的合作模式, 用 email 和其他三位作者互相聯繫, 到今天為止, 我只見過其中一位(他就是 Richard Stallman, Emacs 的作者以及自由軟體基金會 www.fsf的創辦人). Emacs 的 VC 功能是作為 SCCS, RCS 及後來的 CVS 的前端處理, 提供版本控制功能 ``按一下'' 的操作法, 這是由某位仁兄撰寫的小而有力的 sccs.el 功能改良而來, VC 功能的發展相當成功, 這是因為 Emacs 用的 Lisp 程式可以快速地經歷 ``發表 -- 測試-- 改良'', 而不像Emacs 本身核心的發展那樣緩慢.
4. 儘早發表, 經常發表新版本 (Relea Early, Relea Often)
儘早, 經常發表新版本是 Linux 發展模式中非常重要的一環. 過去, 大部份的程式發展者 (包括我) 認為這個策略對較大型的專案是不好的, 因為早期的版本幾乎可以定義為多錯的版本, 我們並不想把使用者
的耐心消磨殆盡.
這個過去的信念加強了軟體的發展要用建造教堂的方式的想法. 假如我們極欲強調的目標是讓使用者在軟體中發現最少的錯誤, 那你何不每半年 (或更長) 才發表一個新版本, 並且在發展新版本的期間, 賣力地除錯而累得像條狗似的. Emacs 的核心部分 (用 C 語言寫的) 就是用這種方式發展的, 但它的 Lisp 程式庫就不是. 因為 Emacs 的 Lisp 資源庫不在自由軟體基金
會的管轄內, 你可以在其中找到新發展的 Lisp 程式使用, 而不受限於 Emacs 的發表週期.
在 Emacs 的 Lisp 程式庫中, 最重要的一個來源是俄亥俄州的 elisp 資源庫, 它先前的精神就已經具有今日大規模 Linux 資源庫的特色, 但當時我們之中卻很少有人思考過我們到底做了什麼, 甚至想過我們已對自由軟體基金會的 ``建造教堂'' 的發展模式提出質疑. 1992 年左右, 我很認真地要把俄亥俄州elisp 資源庫中許多程式加入Emacs 正式的 Lisp 程式庫中, 但卻遭遇到官方的阻礙而失敗了.
但一年之後, Linux 已受到四方的矚目, 也帶來不同而且更健康的觀點, Linus 的開放性發展策略和 ``建造教堂'' 非常不同. 當時 Linux 的兩大資源庫sunsite 和 tsx-11 正在萌芽, 有許多版本在交流著, Linux 核心系統發表新版本的頻繁程度前所未有.
Linus 以最有效的方法, 視使用者為協同發展者:
[格言7] 儘早, 經常發表新版本, 並且傾聽使用者的意見.
Relea early. Relea often. And listen to your customers.
Linus 的創新並不完全在此(這在 UNIX 世界是行之有年的傳統了), 而在於提高這個做法效力的層次, 使其能匹配他在發展的系統的複雜度. 早期在 1991 年左右, 許多人都知道他一天內發表一次以上 Linux 核心程式旳新版本. 因為他善用網際網路和協同發展者們合作更勝於其他人.
他能我也能嗎? 還是只有像他這樣的天才才辦得到?
我並不認為如此, 雖然 Linus 是一位很厲害的高手(在我們之間, 有多少人能夠完整地寫出一個具有商品品質的作業系統核心呢? ), 但Linux 並不是一個空前耀進的觀念, Linus 也並非 (或者說至少目前還不是) 如 Richard Stallman 或 James Cosling (NeWS 和 java 的創始者) 這樣的天才創新者, 而我個人認為他是一位天才工程師, 他有避免程式錯誤及避免程式發展掉入死胡同的第六感, 和找到兩點間最省力路徑的技巧. 事實上, 整個 Linux 的設計中, 我們可以看到 Linus 表現出的品質和他保守而簡單的設計取向.
承上所說, 如果快速地發表新版本和徹底地善用網際網路媒介不是突然冒出, 而是以 Linus 天才工程師洞見所得的最省力路徑, 那麼他把網際網路的什麼功用發揮到最大?
其實問題的本身已反應出答案, Linus 讓Linux 的高手和使用者們經常感覺刺激和有收穫-- 感覺刺激是因協助發展 Linux 得到自我滿足, 感覺有收獲是因經常 (甚至每天) 進步的 Linux 幫助他們把工作做得更好.
Linus 想直接將投入除錯和發展的 ``人-時'' (person-hours) 數加到最大, 即使要付出的代價是程式碼的不穩定, 或是因一些程式錯誤被證實無法追蹤而嚇走原有的使用者. Linus 會如此做是因為他相信:
[格言8] 以足夠多的 ``beta 版'' 測試者和協同發展者做基礎, 幾乎程式 中的每一個問題都可以很快地找出來, 並且對某些人而言, 針對發現的問題的解決方法是顯而易見的.
8. Given a large enough beta-tester and co-developer ba, almost every problem will be characterized quickly and the fix obvious to someone.
或者用比較不那麼正式的說法: ``足夠多的人來看程式, 所有的錯誤都變得淺顯'', 我將此命名為 ``Linus 定律''.
我原本先前的論述是: ``某些問題對某些人而言是容易解決的'', 但Linus 有不同的意見: ``瞭解並解決問題的人不一定是第一個發現問題的人'', 他說: ``有些人發現問題, 有些人解決問題,
