大教堂與市集四早發布，常發布

簡體傳統

四早發布，常發布
盡早和盡量頻繁的發布是Linux開發模式的一個重要部分。包括我在內的大多數開發人員都曾一貫認為——對于一個大型工程來說這并不是個好辦法。因為早期版本幾乎就是問題版的同義詞，而你卻并不想過早地把用戶的耐心消耗殆盡。
這種信念促使人們普遍采用大教堂式的開發模式。如果首要目標是令用戶盡可能少的遭遇錯誤，那么何不半年（或者更久）發布一次呢？這樣我們就有充足的時間在各版本間努力進行調試。Emacs的C核心就是這樣開發的，而Lisp庫則恰恰相反——在自由軟件基金會所轄以外，有很多獨立的新版本或研發代碼可供選擇。【注1】
其中最重要的，俄亥俄州立大學的Emacs Lisp 存檔，在當時就已經具有了今天Linux大型數據管理的許多精神與氣質。但是我們之中少有人深思過究竟要做什么，以及這個存檔的存在暴露了自由軟件基金會大教堂模式的哪些問題。在1992年前后，我曾盡力想把大量的俄亥俄代碼融入官方數據庫，但是卻在政治糾葛下半途而廢了。
一年后，Linux的影響逐步擴大。顯然，這要歸結于一些另類不過更加有益的理念。李納斯的開放性方針與大教堂模式大不相同。Linux的網絡存檔枝繁葉茂，各色發行版在坊間流傳。而所有這一起都要歸功于這種前所未有的核心發布模式。
以最有效的方法，李納斯把用戶視作合作伙伴：

7.早發布，常發布。并聽取用戶意見。
Release early. Release often. And listen to your customers.

快速發布，汲取用戶反饋并不是李納斯的創新（Unix世界歷來如此），而他的創舉在于將這個方法推升到了能和開發中的復雜度相匹敵的高度。早先（1991年前后）我不是沒聽過他那個一天之內不止一次發布核心的故事！因為他比其他任何人都辛勤的培養合作群體，促成網絡協作。這是卓有成效的。
這是如何生效的？難道是源于李納斯的天賦？
我不這么認為。無可厚非，李納斯是個骨灰級的黑客（我們之中有幾個可以從無到有創造一個企業級的操作系統內核呢？），但是Linux并不代表任何理念上的飛躍。李納斯也不像（至少目前沒有）理查德·斯多曼和詹姆斯·戈士林（NeWS和JAVA之父）那樣在在設計領域天賦異稟，在我看來，他的才智更多的表現在操控和執行中。憑借著規避錯誤和防止陷入僵局的第六感，他能夠發現解決問題的捷徑。事實上，整個Linux的設計都散發出這種氣質，處處體現出他質樸簡潔的設計風格。
承上所述，如果快速發布和淋漓盡致的使用網絡協作并非天成，而是源自李納斯的操控天賦和對捷徑的洞見。那么他究竟要把什么揮灑至極，又打算從中釋放什么呢？
這樣一問，答案自明。李納斯讓他的用戶/黑客們不斷得到激勵和獎賞：激勵源自參與過程中的自我實現，而獎賞則是那些持續（甚至是每天）的改進。
李納斯直接鎖定了在開發和調試中“人力—時間”績效最大化的目標，甚至犧牲程序的穩定性以及因為難以修正的錯誤而流失用戶也在所不惜。似乎他堅信：

8.只要有足夠多的人手參與公測和開發，任何問題都會顯而易見并被很快化解。
Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.

更通俗一點，就是：“足夠多的眼睛，就可讓所有問題浮現”，我稱之為“李納斯定律”
我最初的表述是：“（任何問題）都會被某人化解”，李納斯卻對此存有異議，他認為問題的發現和解決并不一定要由同一個人來完成，甚至可以說解決問題的通常不是發現者本人，我想這個糾正是必要的。“有人發現問題”，他說道。“其他人解決問題，而我要特別強調——發現問題才是重頭戲。”在下面的章節，我們會深入探討在調試時會發生什么。而關鍵是，在Linux的世界里無論發現還是修補問題都很迅速。
這就是大教堂與市集模式的區別。在修建教堂時，你所面臨的錯誤和開發中的問題狡黠兇險、隱伏至深。哪怕幾個人在幾個月的時間里竭盡全力也不見得能把它們通通解決。一旦漫長的等待換來不盡如人意的產品，那么失望就在所難免了。
另一方面，站在市集的角度。你可以假設所有問題都是顯而易見的——至少在上千個熱情參與者的反復推敲下，它們都會變得顯而易見。頻繁的發布可以換取更多的修正，所以偶爾捅個大漏子也沒什么大不了的！
這足可以說明問題了。如果“李納斯定律”是錯的，那么一個像Linux內核這么雜糅的東西，早該毀于一旦了。罪魁禍首自然是那些根深蒂固的錯誤和持續的惡性循環。換個角度，如果它是對的，也足夠解釋為什么Linux歷來罕有錯誤，并且能經年累月的持續運營。
大可不必為“三個臭皮匠頂個諸葛亮”而感到詫異。多年以前，社會學家就證實：一群同樣內行（或白癡）的人做出的平均預測要比其中任意一個都準確。這被稱為“德爾菲效應”。[1]顯然，李納斯是把這用在操作系統調試上了。然而即使面對如同操作系統內核這樣的復雜之事，“德爾菲效應”也能應對自如。【注2】
在Linux世界里，每個貢獻者都是自愿參與的，這也是促成“德爾菲效應”的特別之處。早期有評論指出，這些貢獻者不是隨機產生的，而是要經過層層過濾。這包括：要有足夠的興趣使用軟件；意圖了解其運行機理；嘗試自己解決遇到的問題；并且能做出實質性改進。最終產生的貢獻者往往是有真材實料的家伙。
“李納斯定律”也可以描述成“平行調試”。有時調試者可能需要和開發人員取得聯系，但是他們彼此之間卻不需要多少協調。故而增加開發者并不會帶來成指數增長的復雜度和邊際成本。
理論上，重復勞動帶來的能效消耗在Linux世界一直算不上個大問題。“早發布，常發布”策略的一個結果，就是用準確及時的反饋來盡可能的減少了重復勞動。【注3】
甚至對此，布魯克斯（《人月神話》的作者）曾做過一個非正式的論述：“一款廣泛使用的軟件，其維護費用是開發成本的40%以上。令人驚訝的是，其受用戶影響很大，用戶越多發現的錯誤就越多”【這是我所要強調的】
增加用戶意味著增加檢測程序的角度，自然發現的問題就更多。當用戶參與協同開發的時候這個效應便擴大了。在糾錯的時候，大家可以用不同的觀察方法和分析工具，從不同視角逼近同一個問題。“德爾菲效應”便應運而生了。在這個特定的調試環境下，多樣性也有助于減少重復勞動。
從開發者的角度看，更多的公測參與也許不能讓最棘手的問題易于梳理。但是卻能增加為解決問題找到合適人選的機會，對于這些人來說，某些問題或許稱不上問題。
李納斯還留了一手。Linux可以在出現重大缺陷的時候，為用戶提供兩個選擇——選用上一個穩定版本或冒險體驗實驗版。這個策略還沒有被Linux黑客普遍采用，也許他們真應該這么做。因為無論選擇哪一個都能讓彼此更具魅力。【注4】

注釋：
1.采用市集模式的開源軟件成功先例，在因特網熱潮之前就出現了。所以這當然不會源自Unix和因特網傳統。比如在1990年到92年初首先出現在DOS機上的info-Zip壓縮工具就是一例，另外就是同樣始于DOS的RBBS電子公告板系統。從1983年發展起來的強大的RBBS社團，使其至今（1999年中）都充滿活力——無論其間網絡郵件和文件共享技術發生了多么翻天覆地的變化。如果說info-Zip社團還或多或少的使用了網絡郵件的話，那么RBBS開發則純粹的依托于一個以TCP/IP為基礎形成的在線社團。

2. 對于掃清操作系統開發的復雜障礙，公開平等的審視是大有助益的，其實，這算不上是個新觀點。在1956年考巴托和維薩斯基共同設計了一個名為Multics的早期分時操作系統。[2]他們希望當Multics運行良好并滿足下面兩個條件的時候能得以發布：首先，它要經受的起來自用戶無償地公開審視和批評。其次，當自身越來越復雜的時候，其有責任對未來的開發者做出貢獻，以便令他們可以盡己所能開發出內核明晰的操作系統。換言之，就是有責任公開自己的最基礎版本。

3. 對于在開源開發中，為何重復勞動算不上個大問題的原因，約翰·哈斯勒（John Hasler）做過一個有趣的解釋。他建議我命名為哈斯勒定律：重復勞動開銷的增長趨向低于由開發團隊擴大帶來的指數式成本增長。也就是說，開發團隊擴大所帶來計劃和管理成本增速要遠高于重復做功的開銷。
這與布魯克斯定律并不沖突，總體而言，撫平復雜度和糾正錯誤的成本是與開發團隊規模成平方正比增長的，然而重復做功帶來的開銷則是其中同比增速緩慢的一個獨特環節。我們不難為此找到一個看似可信的原因：以一個既定的目標開始工作比讓一群自主的開發者達成一致要簡單的多，而且可以預防重復做功。但是卻不能有效的阻止開發陷入無法預期的惡性循環，最終導致整個系統置身錯誤之中。
將李納斯定律和哈斯勒定律結合起來，我們不難找到三種軟件工程的對應模式：對于開發者不超過三人的小工程，無需領導和預設管理結構。對于中型工程，采用傳統的管理模式成本則相對較低。并且可以有效的防止重復勞動，錯誤追蹤，并且能很快的發現詳細資料是否有遺漏，從而確保萬無一失。
在此之上，李納斯定律和哈斯勒定律共同說明了：對于大型工程，傳統管理模式帶來的問題和成本增幅，遠超過預期的重復勞動的開銷。而這種調動大家參與所帶來的微小開銷并不是一個結構上的缺陷，相反（我們看到）這能比傳統方法更有力的保證錯誤和細節無一遺漏。在大型工程中，應用這兩則定律可以讓那些傳統模式下的本息（沉默成本和邊際成本——譯者按）趨近于零。

4. Linux拆分穩定版和實驗版的作法，除了分担風險之外還有一個作用——干掉發布期限。實際上，一旦程讓序員同時面對刻版的功能列表和該死發布時間，軟件的質量就會大打折扣。這是研發中的一個重要問題。感謝來自哈佛商學院的馬可·伊恩斯蒂（Marco Iansiti）和艾倫·麥科馬克（Alan MacCormack）讓我明白了一個道理——放松二者任意一個，都可以讓工作進程更加有效。
一個做法就是制定發布日期，但讓功能列表可以變通調整。也就是說，在發布時允許舍棄部分功能。這是穩定版內核開發的基本策略；艾倫·考克斯（Alan Cox，穩定版內核的維護者）定期發布穩定版，但是不承諾何時解決某個問題或者何時添加某個實驗版的新功能。
另一個做法則是，鎖定開發列表但不制定發布時間。這是實驗版內核開發的基本策略。我們稱之為：“做完再叫醒我（wake me up when it's done）策略”。達·馬可（De Marco）和利斯特（Lister）的研究表明這不僅可以提高軟件質量，而且平均而言，它比任何“激進”或“保守”的策略都節省研發時間。
2000年初，我開始懷疑自己在前作（指本書的前期版本——譯者按）中嚴重低估了這種反發布時間（做完再叫醒我）策略對于開源社區的生產力以及質量的重要性。1999年GNOME倉促1.0版的教訓表明：即使是開源項目，為了趕進度而草率發布，也會嚴重影響軟件質量。
有充分的理由可以表明：開發過程的透明化、“做完在叫醒我”的策略以及開發者自主選擇研發對象的方法。是影響開源項目質量的三個同等重要的作用力。

譯者按：
1. 德爾菲效應, Delphi effect。德爾菲（Delphi）是希臘古都，宏偉的阿波羅（Apollo，太陽神）神殿便座落于此。相傳阿波羅經常在此宣布神諭，而在決斷之前會廣泛爭取意見。故而這里成為古希臘先哲聚集論道的場所。20世紀中期，美國軍方和蘭德（RAND）公司合作開展國防項目——“德爾菲項目”。顧名思義，其著重采用廣泛收集觀點意見的方法，從而產生了“德爾非法”（Delphi method）。日后“德爾菲法”被廣泛應用于工程和管理領域，形成了“立論-駁論-綜述”的三段式方法。
本書中的“德爾菲效應”則是作者的創造。德爾菲法強調廣泛征集專家的建議。而作者則并不認為必須專家參與，而且參與者的廣泛度和涵蓋面都遠超過德爾菲法。德爾菲法是一種方法，眾多專家參與，是其前提條件。而德爾菲效應則是強調一種廣泛平等參與所帶來的結果。
簡而言之，我認為這就是我們中國人說的“兼聽則明，偏信則暗”。

2. 考巴托：費爾南多·考巴托（Fernando J. Corbató）杰出的計算機學家，1990年圖靈獎的得主。
維薩斯基：維克托·A·維薩斯基（Victor A. Vyssotsky）著名數學家、計算機學家。
二人曾共同設計了Multics的內核，在該計劃停止之后，由貝爾實驗室的工程師以C語言為基礎借此開發而成了Unix。