大教堂和市集
該文的作者Eric Raymond是Open Source Software領(lǐng)域的領(lǐng)袖，這方面許多新的思想正是從他那兒產(chǎn)生的，同時他也是UNIX上最流行的Email軟件Fetchmail 的作者。
HansB翻譯
本博文僅做簡單排版
一. 大教堂和市集
Linux的影響是非常巨大的。甚至在５年以前，有誰能夠想象一個世界級的操作系統(tǒng)能夠僅僅用細(xì)細(xì)的Internet連接起來的散布在全球的幾千個開發(fā)人員有以業(yè)余時間來創(chuàng)造呢？
我當(dāng)然不會這么想。在１９９３年早期我開始注意Linux時，我已經(jīng)參與Unix和自由軟件開發(fā)達(dá)十年之久了。我是八十年代中期GNU最早的幾個參與者之一。我已經(jīng)在網(wǎng)上發(fā)布了大量的自由軟件，開發(fā)和協(xié)助開發(fā)了幾個至今仍在廣泛使用的程序（Nethack,Emacs VC和GND模式，xlife等等）。我想我知道該怎樣做。
Linux推翻了許多我認(rèn)為自己明白的事情。我已經(jīng)宣揚(yáng)小工具、快速原型和演進(jìn)式開發(fā)的Unix福音多年了。但是我也相信某些重要的復(fù)雜的事情需要更集中化的，嚴(yán)密的方法。我相信多數(shù)重要的軟件（操作系統(tǒng)和象Emacs一樣的真正大型的工具）需要向建造大教堂一樣來開發(fā)，需要一群于世隔絕的奇才的細(xì)心工作，在成功之前沒有beta版的發(fā)布。
Linus Torvalds的開發(fā)風(fēng)格（盡早盡多的發(fā)布，委托所有可以委托的事，對所有的改動和融合開放）令人驚奇的降臨了。這里沒有安靜的、虔誠的大教堂的建造工作——相反，Linux團(tuán)體看起來像一個巨大的有各種不同議程和方法的亂哄哄的集市（Linux歸檔站點(diǎn)接受任何人的建議和作品，并聰明的加以管理），一個一致而穩(wěn)定的系統(tǒng)就象奇跡一般從這個集市中產(chǎn)生了。
這種設(shè)計風(fēng)格確實(shí)能工作，并且工作得很好，這個事實(shí)確實(shí)是一個沖擊。在我的研究過程中，我不僅在單個工程中努力工作，而且試圖理解為什么Linux世界不僅沒有在一片混亂中分崩離析，反而以大教堂建造者們不可想象的速度變得越來越強(qiáng)大。
到了１９９６年中，我想我開始理解了。我有一個極好的測試我的理論的機(jī)會，以一個自由軟件計劃的形式，我有意識的是用了市集風(fēng)格。我這樣做了，并取得了很大的成功。
在本文的余下部分，我將講述這個計劃的故事，我用它來明確一些自由軟件高效開發(fā)的格言。并不是所有這些都是從Linux世界中學(xué)到的，但我們將看到Linux世界給予了它們一個什么樣的位置。如果我是正確的，它們將使你理解是什么使Linux團(tuán)體成為好軟件的源泉，幫助你變得更加高效。
二. 郵件必須得通過
１９９３年以前我在一個小的免費(fèi)訪問的名為Chester County InterLink的ISP的做技術(shù)工作，它位于Pennsylvania的West Chester。（我協(xié)助建立了CCIL，并寫了我們獨(dú)特的多用戶BBS系統(tǒng)——你可以telnet到locke.ccil.org來檢測一下。今天它在十九條線上支持三千的用戶）。這個工作使我可以一天二十四小時通過CCIL的56K專線連在網(wǎng)上，實(shí)際上，它要求我怎么做！
所以，我對Internet email很熟悉。因?yàn)閺?fù)雜的原因，很難在我家里的機(jī)器（snark.thyrsus.com）和CCIL之間用SLIP工作。最后我終于成功了，但我發(fā)現(xiàn)不得不時常telnet到locke來檢查我的郵件，這真是太煩了。我所需要的是我的郵件發(fā)送到snark,這樣biff(1)會在它到達(dá)時通知我。
簡單地sendmail的轉(zhuǎn)送功能是不夠的，因?yàn)閟nark并不是總在網(wǎng)上而且沒有一個靜態(tài)地址。我需要一個程序通過我的SLIP連接把我的本地發(fā)送的郵件拉過來。我知道這種東西是存在的，它們大多使用一個簡單的協(xié)議POP（Post Office Protocol）。而且，locke的BSD/OS操作系統(tǒng)已經(jīng)自帶了一個POP3服務(wù)器。
我需要一個POP3客戶。所以我到網(wǎng)上去找到了一個。實(shí)際上，我發(fā)現(xiàn)了三、四個。我用了一會pop-perl，但它卻少一個明顯的特征：抽取收到的郵件的地址以便正確回復(fù)。
問題是這樣的：假設(shè)locke上一個叫“joe”的人向我發(fā)了一封郵件。如果我把它取到snark上準(zhǔn)備回復(fù)時,我的郵件程序會很高興地把它發(fā)送給一個不存在的snark上的“joe”。手工的在地址上加上“@ccil.org”變成了一個嚴(yán)酷的痛苦。
這顯然應(yīng)是計算機(jī)替我做的事。（實(shí)際上，依據(jù)RFC1123的5.2.18節(jié)，sendmail應(yīng)該做這件事）。但是沒有一個現(xiàn)存的POP客戶知道怎樣做！于是這就給我們上了第一課：
1.每個好的軟件工作都開始于搔到了開發(fā)者本人的癢處。
也許這應(yīng)該是顯而易見的（“需要是發(fā)明之母”長久以來就被證明是正確的），但是軟件開發(fā)人員常常把他們的精力放在它們既不需要也不喜歡的程序，但在Linux世界中卻不是這樣——這解釋了為什么從Linux團(tuán)體中產(chǎn)生的軟件質(zhì)量都如此之高。
2.好程序員知道該寫什么，偉大的程序員知道該重寫（和重用）什么。
我并沒有聲稱自己是一個偉大的程序員，可是我試著效仿他們。偉大程序員的一個重要特點(diǎn)是建設(shè)性的懶惰。他們知道你是因?yàn)槌煽兌皇桥Φ玫姜勝p，而且從一個好的實(shí)際的解決方案開始總是要比從頭干起容易。
例如，Linux并不是從頭開始寫Linux的。相反的它從重用Minix（一個386機(jī)型上的類似Unix的微型操作系統(tǒng)）的代碼和思想入手。最后所有的Minix代碼都消失或被徹底的重寫了，但是當(dāng)它們在的時候它為最終成為Linux的雛形做了鋪墊。
秉承同樣的精神，我去尋找良好編碼的現(xiàn)成的POP工具，用來作為基礎(chǔ)。
Unix世界中的代碼共享傳統(tǒng)一直對代碼重用很友好（這正是為什么GNU計劃不管Unix本身有多么保守而選取它作為基礎(chǔ)操作系統(tǒng)的原因）。Linux世界把這個傳統(tǒng)推向技術(shù)極限：它有幾個T字節(jié)的源代碼可以用。所以在Linux世界中花時間尋找其他幾乎足夠好的東西，會比在別處帶來更好的結(jié)果。
這也適合我。加上我先前發(fā)現(xiàn)的，第二次尋找找到了9個候選者——fetchPOP，PopTart，get-mail，gwpop，pimp，pop-perl，popc，popmail 和 upop）。我首先選定的是“fetchpop”。我加入了頭標(biāo)重寫功能，并且做了一些被作者加入他的1.9版中的改進(jìn)。
但是幾個星期之后，我偶然發(fā)現(xiàn)了Carl Harris寫的“popclient”的代碼，然后發(fā)現(xiàn)有個問題，雖然fetchpop有一些好的原始思想(比如它的守護(hù)進(jìn)程模式)，它只能處理pop3，而且編碼的水平相當(dāng)業(yè)余(Seung-Hong是個很聰明但是經(jīng)驗(yàn)不足的程序員)，Carl的代碼更好一些，相當(dāng)專業(yè)和穩(wěn)固，但他的程序缺少幾個重要的相當(dāng)容易實(shí)現(xiàn)的fetchpop的特征(包括我自己寫的那些)。
繼續(xù)呢還是換一個? 如果換一個的話，作為得到一個更好開發(fā)基礎(chǔ)的代價，我就要扔掉我已經(jīng)有的那些代碼。
換一個的一個實(shí)際的動機(jī)是支持多協(xié)議，pop3是用的最廣的郵局協(xié)議，但并非唯一一個，Fetchpop和其余幾個沒有實(shí)現(xiàn)POP2.RPOP，或者APOP，而且我還有一個為了興趣加入IMAP(Internet Message Access Protocol，最近設(shè)計的最強(qiáng)大的郵局協(xié)議)的模糊想法。
但是我有一個更加理論化的原因認(rèn)為換一下會是一個好主意，這是我在Linux很久以前學(xué)到的：
3.“計劃好拋棄，無論如何，你會的”(Fred Brooks,《神秘的人月》第11章)
或者換句話說，你常常在第一次實(shí)現(xiàn)一個解決方案之后才能理解問題所在，第二次你也許才足夠清楚怎樣做好它，因此如果你想做好，準(zhǔn)備好推翻重來至少一次。
好吧(我告訴自己)，對fetchpop的嘗試是我第一次的嘗試，因此我換了一下。
當(dāng)我在1996年6月25日把我第一套popclient的補(bǔ)丁程序寄給Carl Harris之后，我發(fā)現(xiàn)一段時間以前他已經(jīng)對popclient基本上失去了興趣，這些代碼有些陳舊，有一些次要的錯誤，我有許多修改要做，我們很快達(dá)成一致，我來接手這個程序。不知不覺的，這個計劃擴(kuò)大了，再也不是我原先打算的在已有的pop客戶上加幾個次要的補(bǔ)丁而已了，我得維護(hù)整個的工程，而且我腦袋里涌動著一些念頭要引起一個大的變化。
4. 如果你有正確的態(tài)度，有趣的問題會找上你的但是Carl Harris的態(tài)度甚至更加重要，他理解：
5.當(dāng)你對一個程序失去興趣時，你最后的責(zé)任就是把它傳給一個能干的后繼者。
甚至沒有商量，Carl和我知道我們有一個共同目標(biāo)就是找到最好的解決方案，對我們來說唯一的問題是我能否證明我有一雙堅(jiān)強(qiáng)的手，他優(yōu)雅而快速的寫出了程序，我希望輪到我時我也能做到。
三. 擁有用戶的重要性
于是我繼承了popclient，同樣重要的是，我繼承了popclient的用戶基礎(chǔ)，用戶是你所擁有的極好的東西，不僅僅是因?yàn)樗麄冿@示了你正在滿足需要，你做了正確的事情，如果加以適當(dāng)?shù)呐囵B(yǎng)，他們可以成為合作開發(fā)者。
Unix傳統(tǒng)另一有力之處是許多用戶都是黑客，因?yàn)樵磧?yōu)碼是公開的，他們可以成為高效的黑客，這一點(diǎn)在Linux世界中也被推向了令人高興的極致，這對縮短調(diào)試時間是極端重要的，在一點(diǎn)鼓勵之下，你的用戶會診斷問題，提出修訂建議，幫你以遠(yuǎn)比你期望快得多的速度的改進(jìn)代碼。
6. 把用戶當(dāng)做協(xié)作開發(fā)者是快速改進(jìn)代碼和高效調(diào)試的無可爭辯的方式。
這種效果的力量很容易被低估，實(shí)際上，幾乎所有我們自由軟件世界中的人都強(qiáng)烈低估了用戶可以多么有效地對付系統(tǒng)復(fù)雜性，直到Linus讓我們看到了這一點(diǎn)。
實(shí)際上，我認(rèn)為Linus最聰明最了不起的工作不是創(chuàng)建了Linux內(nèi)核本身，而是發(fā)明了Linux開發(fā)模式，當(dāng)我有一次當(dāng)著他的面表達(dá)這種觀點(diǎn)時，他微笑了一下，重復(fù)了一句他經(jīng)常說的話：“我基本上是一個懶惰的人，依靠他人的工作來獲取成績?！毕蠛傄粯討卸?#xff0c;或者如Robert Heinlein所說，太懶了而不會失敗。
回顧起來，在GNU Emacs Lisp庫和Lisp代碼集中可以看到Linux方法的成功，與Emacs的C內(nèi)核和許多其他FSF的工具相比，Lisp代碼庫的演化是流動性的和用戶驅(qū)動的，思想和原型在達(dá)到最終的穩(wěn)定形式之前往往要重寫三或四次，而且經(jīng)常利用Internet的松散合作。
實(shí)際上，我自己在fetchmail之前最成功的作品要算Emacs VC模式，它是三個其他的人通過電子郵件進(jìn)行的類似Linux的合作，至今我只見過其中一個人(Richard Stallman)，它是SCCS、RCS和后來的CVS的前端，為Emacs提供“one-touch”版本控制操作，它是從一個微型的、粗糙的別人寫好的sccs.el模式開始演化的，VC開發(fā)的成功不像Emacs本身，而是因?yàn)镋macs Lisp代碼可以很快的通過發(fā)布／測試／改進(jìn)的過程。
(FSF的試圖把代碼放入GPL之下的策略有一個未曾預(yù)料到的副作用，它讓FSF難以采取市集模式，因?yàn)樗麄冋J(rèn)為每個想貢獻(xiàn)二十行以上代碼的人都必須得到一個授權(quán)，以使受到GPL的代碼免受版權(quán)法的侵?jǐn)_，具有BSD和MITX協(xié)會的授權(quán)的用戶不會有這個問題，因?yàn)樗麄儾⒉辉噲D保留那些會使人可能受到質(zhì)詢的權(quán)力)。
四. 早發(fā)布、常發(fā)布
盡量早盡量頻繁的發(fā)布是Linux開發(fā)模式的一個重要部分，多數(shù)開發(fā)人員(包括我)過去都相信這對大型工程來說是個不好的策略，因?yàn)樵缙诎姹径际切┏錆M錯誤的版本，而你不想耗光用戶的耐心。
這種信仰強(qiáng)化了建造大教堂開發(fā)方式的必要性，如果目標(biāo)是讓用戶盡可能少的見到錯誤，那你怎能不會僅僅每六個月發(fā)布一次(或更不經(jīng)常)，而且在發(fā)布之間象一只狗一樣辛勤“捉蟲”呢? Emacs C內(nèi)核就是以這種方式開發(fā)的，Lisp庫，實(shí)際上卻相反，因?yàn)橛幸恍┯蠪SF控制之外的Lisp庫，在那里你可以獨(dú)立于Emacs發(fā)布周期地找尋新的和開發(fā)代碼版本。
這其中最重要的是Ohio州的elisp庫，預(yù)示了今天的巨大的Linux庫的許多特征的精神，但是我們很少真正仔細(xì)考慮我們在做什么，或者這個庫的存在指出了FSF建造教堂式開發(fā)模式的什么問題，1992年我曾經(jīng)做了一次嚴(yán)肅的嘗試，想把Ohio的大量代碼正式合并到Emacs的官方Lisp庫中，結(jié)果我陷入了政治斗爭中，徹底失敗了。
但是一年之后，在Linux廣泛應(yīng)用之后，很清楚，一些不同的更加健康的東西誕生了，Linus的開發(fā)模式正好與建造教堂方式相反，Sunsite和tsx-11的庫開始成長，推動了許多發(fā)布。所有這些都是聞所未聞的頻繁的內(nèi)核系統(tǒng)的發(fā)布所推動的。
Linus以所有實(shí)際可能的方式把它的用戶作為協(xié)作開發(fā)人員。
7. 早發(fā)布、常發(fā)布、聽取客戶的建議
Linus的創(chuàng)新并不是這個(這在Unix世界中是一個長期傳統(tǒng))，而是把它擴(kuò)展到和他所開發(fā)的東西的復(fù)雜程度相匹配的地步，在早期一天一次發(fā)布對他來說都不是罕見的!而且因?yàn)樗嘤怂膮f(xié)作開發(fā)者基礎(chǔ)，比其他任何人更努力地充分利用了Internet進(jìn)行合作，所以這確實(shí)能行。
但是它是怎樣進(jìn)行的呢?它是我能模仿的嗎?還是這依賴于Linus的獨(dú)特天才?
我不這樣想，我承認(rèn)Linus是一個極好的黑客(我們有多少人能夠做出一個完整的高質(zhì)量的操作系統(tǒng)內(nèi)核?)，但是Linux并不是一個令人敬畏的概念上的飛躍，Linus不是(至少還不曾是)象Richard stallman或James Gosling一樣的創(chuàng)新天才，在我看來，Linus更象一個工程天才，具有避免錯誤和開發(fā)失敗的第六感覺，掌握了發(fā)現(xiàn)從A點(diǎn)到B點(diǎn)代價最小的路徑的決竅，確實(shí)，Linux的整個設(shè)計受益于這個特質(zhì)，并反映出Linus的本質(zhì)上保守和簡化設(shè)計的方法。
如果快速的發(fā)布和充分利用Internet不是偶然而是Linus的對代價最小的路徑的洞察力的工程天才的內(nèi)在部分，那么他極大增強(qiáng)了什么?他創(chuàng)建了什么樣的方法?
問題回答了它自己，Linus保持他的黑客用戶經(jīng)常受到激勵和獎賞：被行動的自我滿足的希望所激勵，而獎賞則是經(jīng)常(甚至每天)都看到工作在進(jìn)步。
Linus直接瞄準(zhǔn)了爭取最多的投入調(diào)試和開發(fā)的人時，甚至冒代碼不穩(wěn)定和一旦有非常棘手的錯誤而失去用戶基礎(chǔ)的險，Linus似乎相信下面這個：
8. 如果有一個足夠大的beta測試人員和協(xié)作開發(fā)人員的基礎(chǔ)，幾乎所有的問題都可以被快速的找出并被一些人糾正。
或者更不正式的講：“如果有足夠多的眼睛，所有的錯誤都是淺顯的”(群眾的眼睛是雪亮的)，我把這稱為“Linus定律”。
我最初的表述是每個問題“對某些人是透明的”，Linus反對說，理解和修訂問題的那個人不一定非是甚至往往不是首先發(fā)現(xiàn)它的人，“某個人發(fā)現(xiàn)了問題”，他說，“另一個理解它，我認(rèn)為發(fā)現(xiàn)它是個更大的挑戰(zhàn)”，但是要點(diǎn)是所有事都趨向于迅速發(fā)生。
我認(rèn)為這是建造教堂和集市模式的核心區(qū)別，在建造教堂模式的編程模式看來，錯誤和編程問題是狡猾的、陰險的、隱藏很深的現(xiàn)象，花費(fèi)幾個月的仔細(xì)檢查，也不能給你多大確保把它們都挑出來的信心，因此很長的發(fā)布周期，和在長期等待之后并沒有得到完美的版本發(fā)布所引起的失望都是不可避免的。
以市集模式觀點(diǎn)來看，在另一方面，我們認(rèn)為錯誤是淺顯的現(xiàn)象，或者至少當(dāng)暴露給上千個熱切的協(xié)作開發(fā)人員，讓他們來對每個新發(fā)布進(jìn)行測試的時候，它們很快變得淺顯了，所以我們經(jīng)常發(fā)布來獲得更多的更正，作為一個有益的副作用，如果你偶爾做了一個笨拙的修改，也不會損失太多。也許我們本不應(yīng)該這樣的驚奇，社會學(xué)家在幾年前已經(jīng)發(fā)現(xiàn)一群相同專業(yè)的(或相同無知的)觀察者的平均觀點(diǎn)比在其中隨機(jī)挑選一個來得更加可靠，他們稱此為“Delhpi效應(yīng)”，Linus所顯示的證明在調(diào)試一個操作系統(tǒng)時它也適用——Delphi效應(yīng)甚至可以戰(zhàn)勝操作系統(tǒng)內(nèi)核一級的復(fù)雜度。
我受Jeff Dutky (dutky @ wam.umd.edu)的啟發(fā)指出Linus定律可以重新表述為“調(diào)試可以并行”，Jeff觀察到雖然調(diào)試工作需要調(diào)試人員和對應(yīng)的開發(fā)人員相交流，但它不需要在調(diào)試人員之間進(jìn)行大量的協(xié)調(diào)，于是它就沒有陷入開發(fā)時遇到的平方復(fù)雜度和管理開銷。
在實(shí)際中，由于重復(fù)勞動而導(dǎo)致的理論上的喪失效率的現(xiàn)象在Linux世界中并不是一個大問題，“早發(fā)布、常發(fā)布策略”的一個效果就是利用快速的傳播反饋修訂來使重復(fù)勞動達(dá)到最小。
Brooks甚至做了一個與Jeff相關(guān)的更精確的觀察：“維護(hù)一個廣泛使用的程序的成本一般是其開發(fā)成本的40%，奇怪的是這個成本受到用戶個數(shù)的強(qiáng)烈影響，更多的用戶發(fā)現(xiàn)更多的錯誤”(我的強(qiáng)調(diào))。
更多的用戶發(fā)現(xiàn)更多的錯誤是因?yàn)楦嗟挠脩籼峁┝烁鄿y試程序的方法，當(dāng)用戶是協(xié)作開發(fā)人員時這個效果被放大了，每個找尋錯誤的人都有自己稍微不同的感覺和分析工具，從不同角度來看待問題?！癉elphi效應(yīng)”似乎因?yàn)檫@個變體工作變得更加精確，在調(diào)試的情況下，這個變體同時減小了重復(fù)勞動。
所以加入更多的beta測試人員雖不能從開發(fā)人員的P.O.V中減小“最深”的錯誤的復(fù)雜度，但是它增加了這樣一種可能性，即某個人的工具和問題正好匹配，而這個錯誤對這個人來說是淺顯的。
Linus也做了一些改進(jìn)，如果有一些嚴(yán)重的錯誤，Linux內(nèi)核的版本在編號上做了些處理，讓用戶可以自己選擇是運(yùn)行上一個“穩(wěn)定”的版本，還是冒遇到錯誤的險而得到新特征，這個戰(zhàn)略還沒被大多數(shù)Linux黑客所仿效，但它應(yīng)該被仿效，存在兩個選擇的事實(shí)讓二者都很吸引人。
五. 什么時候玫瑰不是玫瑰?
在研究了Linus的行為和形成了為什么它成功的理論之后，我決定在我的工程(顯然沒有那么復(fù)雜和雄心勃勃)里有意識的測試這個理論。
但我首先做的事是熟悉和簡化Popclient。 Carl Harris的實(shí)現(xiàn)非常好，但是有一種對許多C程序來說沒有必要的復(fù)雜性。他把代碼當(dāng)作核心而把數(shù)據(jù)結(jié)構(gòu)當(dāng)作對代碼的支持，結(jié)果是代碼非常漂亮但是數(shù)據(jù)結(jié)構(gòu)設(shè)計得很特別，相當(dāng)丑陋(至少對以這個老LISP黑客的標(biāo)準(zhǔn)來看)，然而除了提高代碼和數(shù)據(jù)結(jié)構(gòu)設(shè)計之外，重寫它還有一個目的，就是要把它演化為我徹底理解的東西，對修改你不理解的程序中的錯誤負(fù)責(zé)可不是一件有趣的事。
第一個月我只是在領(lǐng)會Carl’s的基本設(shè)計的含義，我所做的第一個重大修改是加入了IMAP支持，我把協(xié)議機(jī)重新組織為一個通用驅(qū)動程序和三個方法表(對應(yīng)POP2、POP3和IMAP)，這個前面的修改指出一個需要程序員(特別是象C這種沒有自然的動態(tài)類型支持的語言)記在腦中的一般原理：
9. 聰明的數(shù)據(jù)結(jié)構(gòu)和笨拙的代碼要比相反的搭配工作的更好
Fred Brooks也在他第11章中講道：“讓我看你的［代碼］，把你的[數(shù)據(jù)結(jié)構(gòu)]隱藏起來，我還是會迷惑；讓我看看你的[數(shù)據(jù)結(jié)構(gòu)]，那我就不需要你的[代碼]了，它是顯而易見的”。
實(shí)際上，他說的是“流程圖”和“表”，但是在三十年的術(shù)語／文化演進(jìn)之后，事情還是一樣的。
此時(1996年9月初，在從零開始六個月后)，我開始想接下來修改名字——畢竟，它已不僅僅是一個POP客戶，但我猶豫了，因?yàn)檫€沒有什么新的漂亮設(shè)計呢，我的popclient版本需要有自己的特色。
當(dāng)fetehmail學(xué)會怎樣把取到的郵件轉(zhuǎn)送到SMTP端口時，事情就完全改變了，但是首先：上面我說過我決定使用這個工程來測試我關(guān)于Linus Torualds所做的行為的理論，(你可能會問)我怎樣做到這點(diǎn)呢? 以下面的方式：
1. 我盡早盡量頻繁的發(fā)布(幾乎從未少于每十天發(fā)布一次；在密集開發(fā)的時候是每天一次)。
2. 我把每一個和我討論fetchmail的人加入一個beta表中。
3. 每當(dāng)我發(fā)布我都向beta表中的人發(fā)出通告，鼓勵人們參與。
4. 我聽取beta測試員的意見，向他們詢問設(shè)計決策，對他們寄來的補(bǔ)丁和反饋表示感謝。
這些簡單的手段立即收到的回報，在工程的開始，我收到了一些錯誤報告，其質(zhì)量足以使開發(fā)者因此被殺掉，而且經(jīng)常還附有補(bǔ)丁、我得到了理智的批評，有趣的郵件，和聰明的特征建議，這導(dǎo)致了：
10. 如果你象對待最寶貴的資源一樣對待你的beta測試員，他們就會成為你最寶貴的資源。
六. popclient變成了Fetchmail
這個工程的真正轉(zhuǎn)折點(diǎn)是Harry Hochleiser寄給我他寫的代碼草稿，他把郵件轉(zhuǎn)發(fā)到客戶端機(jī)器的SMTP端口，我立即意識到這個特征的可靠實(shí)現(xiàn)將淘汰所有其他的遞送模式。
幾個星期以來我一直在修改而不是改進(jìn)fetchmail，因?yàn)槲矣X得界面設(shè)計雖然有用但是太笨拙瑣碎了，到處充滿了太多的粗陋的細(xì)小選項(xiàng)。
當(dāng)我思考SMTP轉(zhuǎn)發(fā)時我發(fā)現(xiàn)popclient試圖做的事太多了，它被設(shè)計成既是一個郵件傳輸代理(MTA)也是一個本地遞送代理(MDA)。使用SMTP轉(zhuǎn)發(fā)，它就可以從MDA的事務(wù)中解脫出來而成為一個純MTA，而象sendmail一樣把郵件交給本地遞送程序來處理。
既然端口25在所有支撐TCP／IP的平臺上早已被預(yù)留，為什么還要為一個郵件傳輸代理的配置或?yàn)橐粋€郵箱設(shè)置加鎖的附加功能而操心呢?尤其是當(dāng)這意味著抽取的郵件就象一個正常的發(fā)送者發(fā)出的SMTP郵件一樣，而這就是我們需要的。
這里有幾個教益：第一，SMTP轉(zhuǎn)發(fā)的想法是我有意識地模擬Linus的方法以來的最大的單個回報，一個用戶告訴我這個非同尋常的想法——我所需做的只是理解它的含義。
11. 想出好主意是好事，從你的用戶那里發(fā)現(xiàn)好主意也是好事，有時候后者更好。
很有趣的是，你很快將發(fā)現(xiàn)，如果你完全承認(rèn)你從其他人那里得到多少教益的話，整個世界將會認(rèn)為所有的發(fā)明都是你做出的，而你會對你的天才變得謙虛。我們可以看到這在Linus身上體現(xiàn)得多明顯!(當(dāng)我在1997年8月的Perl會議上發(fā)表這個論文時，Larry Wall坐在前排，當(dāng)我講到上面的觀點(diǎn)時，他激動的叫了出來：“對了!說對了!哥們!”所有的聽眾都哄堂大笑起來，因?yàn)樗麄冎劳瑯拥氖虑橐舶l(fā)生在Perl的發(fā)明者身上)。
于是在同樣精神指導(dǎo)下工程進(jìn)行了幾個星期，我開始不光從我的用戶那兒也從聽說我的系統(tǒng)的人那兒得到類似的贊揚(yáng)，我把一些這種郵件收藏起來，我將在我開始懷疑自己的生命是否有價值時重新讀讀這些信。:)
但是有兩個更基本的，非政治性的對所有設(shè)計都有普遍意義的教益。
12. 最重要和最有創(chuàng)新的解決方案常常來自于你認(rèn)識到你對問題的概念是錯誤的。
一個衡量fetchmail成功的有趣方式是工程的beta測試人員表(fegtchmail的朋友們)的長度，在創(chuàng)立它的時候已經(jīng)有249個成員了，而且每個星期增加兩到三個。
實(shí)際上，當(dāng)我在1997年5月校訂它時，這張表開始因?yàn)橐粋€有趣的原因而縮短了，有幾個人請求我把他們從表中去掉，因?yàn)閒etchmail已經(jīng)工作的如此之好，他們不需要看到這些郵件了!也許這是一個成熟的市集風(fēng)格工程的生命周期的一部分。
我以前一直在解決錯誤的問題，把popclient當(dāng)作MTA和具有許多本地遞送模式的MDA的結(jié)合物，Fetchmail的設(shè)計需要從頭考慮為一個純的MTA，做為一個普通Internet郵件路徑的一部分。
當(dāng)你在開發(fā)中碰了壁時(當(dāng)你發(fā)現(xiàn)自己很難想通下一步時)，那通常不是要問自己是否找到正確答案，而是要問是否問了正確問題，也許需要重新構(gòu)造問題。
于是，我重新構(gòu)造了我的問題，很清楚，要做的正確的事是(1)把SMTP轉(zhuǎn)發(fā)支持放在通用驅(qū)動程序中，(2)把它做為缺省模式，(3)最終分離所有其他的遞送模式，尤其是遞送到文件和標(biāo)準(zhǔn)輸出的選項(xiàng)。
我在第三步上猶豫了一下，擔(dān)心會讓popdiant的長期用戶對新的遞送方法感到煩心，在理論上，他們可以立即轉(zhuǎn)而轉(zhuǎn)發(fā)文件或者他們的非sendmail等價物來得到同樣的效果，在實(shí)際中這種轉(zhuǎn)換可能會很麻煩。
但是當(dāng)我這么做之后，證明好處是巨大的，驅(qū)動程序代碼的冗余的部分消失了，配置完全變得簡單了——不用屈從于系統(tǒng)MDA和用戶的郵箱，也不用為下層OS是否支持文件鎖定而擔(dān)心了。
而且，丟失郵件的唯一漏洞也被堵死了，如果你選擇了遞送到一個文件而磁盤已滿，你的郵件就會丟失，這在SMTP轉(zhuǎn)發(fā)中不會發(fā)生，因?yàn)镾MTP偵聽器不會返回OK的，除非郵件可以遞送成功或至少被緩沖留待以后遞送。
還有，性能也改善了(雖然在單次執(zhí)行中你不會注意到)，這個修改的另一個不可忽視的好處是手冊變得大大簡單了。
后來，為了允許處理一些罕見的情況，包括動態(tài)SLIP，我必須回到讓用戶定義本地MDA遞送上來，但是我發(fā)現(xiàn)了一個更加簡單的方法。
所有這些給了我們什么啟發(fā)呢?如果可以不損失效率，就要毫不猶豫拋棄陳舊的特性，Antonine de Saint-Exupery(在他成為經(jīng)典兒童書籍作家之前是一個飛行員和飛機(jī)設(shè)計師)曾說過：
13. “最好的設(shè)計不是再也沒有什么東西可以添加了，而是再也沒有什么東西可以去掉?！?/strong>
當(dāng)你的代碼變得更好和更簡單時，這就是你知道它是正確的時候了，而且在這個過程中，fetehmail的設(shè)計具有了自己的特點(diǎn)，而區(qū)別于其前身popclient。
現(xiàn)在是改名的時候了，這個新的設(shè)計看起來比老popclient更象一個sendmail的復(fù)制品，它們都是MTA，但是Senmail是推然后遞送，而新的popclient是拉然后遞送。于是，在兩個月之后，我把它重新命名為fetehmail。
七. Fetchmail成長起來
現(xiàn)在我有了一個簡潔和富有創(chuàng)意的設(shè)計，工作得很好的代碼，因?yàn)槲颐刻於加盟?#xff0c;和一直在增長的beta表，它讓我漸漸明白我已經(jīng)不是在從事只能對少數(shù)其他人有用的工作中，我寫了一個所有有一個Unix郵箱和SLIP／PPP郵件連接的人都真正需要的程序。
通過SMTP轉(zhuǎn)發(fā)功能，它成為一個潛在的“目錄殺手”，遠(yuǎn)遠(yuǎn)領(lǐng)先于它的競爭者，這個程序如此能干以至于其他的程序不但被放棄簡直被忘記了。
我知道你不可以真得瞄準(zhǔn)或計劃出這樣的結(jié)果，你只能努力去設(shè)計這些強(qiáng)大的思想，以后這些結(jié)果就好象是不可避免的、自然的、注定了的，得到這種思想的唯一辦法是獲取許多思想，或者用工程化的思考其他人的好主意而超過原來想到它的人的設(shè)想。
Andrew Tanenbanm原來設(shè)想建造一個適合386的簡單的Unix用做教學(xué)，Linus Torvalels把Andrew的可能想到的Minix可以做什么的概念推進(jìn)了一步，成長為一個極好的東西，同樣的(雖然規(guī)模較小)，我接受了Card Harris和Harry Hochheiser的想法，把它們變得更強(qiáng)大，我們都不是人們所浪漫幻想的天才的創(chuàng)始人，但是大多數(shù)科學(xué)和工程和軟件開發(fā)不是被天才的創(chuàng)始人完成的，這和流傳的神話恰恰相反。
結(jié)果總是執(zhí)著的原因——實(shí)際上，它是每個黑客為之生存的成功!而且它們意味著我必須把自己的標(biāo)準(zhǔn)定高一點(diǎn)，為了把fetchmail變得和我所能設(shè)想的那樣好，我必須不僅為我自己的需要寫代碼，而且也要包括對在我生活圍主頁外的人們的需求的支持，而且同時也要保證程序的簡單和健壯。
在實(shí)現(xiàn)它之后我首先寫的最重要的特征是支持多投——從集中一組用戶的郵件的郵箱中取出郵件，然后把它路由到每個人手中。
我之所以加上多投功能部分是因?yàn)橛行┯脩粢恢痹隰[著要它，更是因?yàn)槲蚁胨梢詮膯瓮兜拇a中揭露出錯誤來，讓我完全一般地處理尋址，而且這被證明了。正確解釋RFC822花了我相當(dāng)長的時間，不僅因?yàn)樗拿總€單獨(dú)部分都很難，而且因?yàn)樗幸淮蠖严嗷ヒ蕾嚨目量痰募?xì)節(jié)。
但是多投尋址也成為一個極好的設(shè)計決策，由此我知道：
14. 任何工具都應(yīng)該能以預(yù)想的方式使用，但是一個偉大的工具提供你沒料到的功能。
Fetchmant多投功能的一個沒有料到的用途是在SLIP／PPP的客戶端提供郵件列表、別名擴(kuò)展。這意味著一個使用個人機(jī)器的人不必持續(xù)訪問ISP的別名文件就能通過一個ISP帳戶管理一個郵件列表。我的beta測試員提出的另一個重要的改變是支持8位MIME操作，這很容易做，因?yàn)槲乙呀?jīng)仔細(xì)的保證了8位代碼的清晰，不僅因?yàn)槲翌A(yù)見到了這個特性的需求，而且因?yàn)槲抑覍?shí)于另一準(zhǔn)則：
15. 當(dāng)寫任何種類的網(wǎng)關(guān)型程序時，多費(fèi)點(diǎn)力，盡量少干擾數(shù)據(jù)流，永遠(yuǎn)不要拋棄信息，除非接收方強(qiáng)迫這么作!
如果我不遵從這個準(zhǔn)則，那么8位MIME支持將會變得困難和笨拙，現(xiàn)在我所需要做的，是只讀一下RFC 1652，在產(chǎn)生信頭的邏輯加上一點(diǎn)而已。
一些歐洲用戶要求我加上一個選項(xiàng)來限制每次會話取得消息數(shù)(這樣他們就可以從昂貴的電話網(wǎng)中控制花費(fèi)了)，我很長一段時間拒絕這樣做，而且我仍然對它不很高興，但是如果你是為了世界而寫代碼，你必須聽取顧客的意見——這并不隨他們不付給你錢而改變。
八. 從Fetchmail得來的另一些教益
在他們回到一般的軟件工程問題以前，還有幾個從fetchmail得到的教益需要思考。
rc文件語法包括可選的“noise”關(guān)鍵字，它被掃描器完全忽略了，當(dāng)你把它們?nèi)槿〕龅臅r候，關(guān)鍵字／值對更具可讀性。
當(dāng)我注意到rc文件的聲明在多大程度上開始象一個微型命令語言時，這是一個Late-night的體驗(yàn)(這也是我為什么把popclient原來的“server”關(guān)鍵字改成了“poll”)。
對我來說似乎把這個微型命令語言變得更象英語可能會使它更容易使用?，F(xiàn)在，雖然我對經(jīng)過Emacs和HTML及許多數(shù)據(jù)庫引擎所證實(shí)的“把它做成一個語言”的設(shè)計方式確信不疑，但是我并不是一個通常的“類英語”語法的狂熱擁護(hù)者。
傳統(tǒng)程序員容易控制語法使它盡量精確和緊湊，完全沒有冗余，這是計算機(jī)資源還很昂貴時遺留下的一種文化傳統(tǒng)，所以掃描策略需要盡可能的廉價和簡單，而具有50%冗余度的英語，看來好象是一個非常不合適的模型。
這并不是我不用類英語語法的原因，我提到這一點(diǎn)是為了推翻它，在更廉價的時鐘周期與核心的時代，簡潔并沒有走到盡頭，今天對一個語言來說，對人更方便比對機(jī)器更廉價來的更加重要。
然而，有幾個原因提醒我們小心一點(diǎn)，一個是掃描策略的復(fù)雜度開銷——你并不想把它變成一個巨大的錯誤來源和讓用戶困惑，另一個是試圖使語言表面上的類似可以和傳統(tǒng)語言一樣令人困惑(你可以在許多4GL和商業(yè)數(shù)據(jù)庫查詢語言上看到這一點(diǎn))。
Fetchmail的控制語法避免了這些問題，因?yàn)檎Z言的領(lǐng)域是極其有限的。它一點(diǎn)也不象一個一般性的語言，它很簡單地描述的東西并不復(fù)雜，所以很少可能在英語的一個小子集與實(shí)際的控制語言之間發(fā)生混淆，我想這有一個更廣泛的教益：
16. 如果你的語言一點(diǎn)也不象是圖靈完備的，嚴(yán)格的語法會有好處。
另一個教益是關(guān)于安全的，一些fetchmail用戶要求我修改軟件把口令加密存貯在rc文件里，這樣覷探者就不能看到它們了。
我沒有這樣做，因?yàn)檫@實(shí)際上起不到任何保護(hù)作用，任何有權(quán)讀取你的rc文件的人都可以以你的名義運(yùn)行fetchmail——如果他們要破你的口令，它們可以從fetchmail的代碼中找到制作解碼器的方法。
所以fetchmail口令的加密都會給那些不慎重思考的人一種安全的錯覺，這里一般性的準(zhǔn)則是：
17. 一個安全系統(tǒng)只能和它的秘密一樣安全，當(dāng)心偽安全。
九. 集市風(fēng)格的必要的先決條件
本文的早期評審人員和測試人員堅(jiān)持提出成功的市集模式開發(fā)的先決條件，包括工程領(lǐng)導(dǎo)人的資格問題和在把項(xiàng)目公開和開始建造一個協(xié)作開發(fā)人員的社團(tuán)的時候代碼的狀態(tài)。
相當(dāng)清楚，不能以一個市集模式從頭開發(fā)一個軟件，我們可以以市集模式、測試、調(diào)試和改進(jìn)，但是以市集模式從頭開始一個項(xiàng)目將是非常困難的，Linus沒有這樣做，我也沒有，初期的開發(fā)人員的社團(tuán)應(yīng)該有一此可以運(yùn)行和測試的東西來玩。
當(dāng)你開始創(chuàng)建社團(tuán)時，你需要演示的是一個諾言，你的程序不需要工作的很好，它可以很粗糙、很笨拙、不完整和缺少文檔、它不能忽略的東西是要吸引哪些人卷入一個整潔的項(xiàng)目。
Linux和fetchmail都是以一個吸引人的基本設(shè)計進(jìn)入公共領(lǐng)域的，許多和我一樣在思考市集模式的人已經(jīng)正確的認(rèn)為這是非常關(guān)鍵的，然后得出了一個結(jié)論，工程領(lǐng)導(dǎo)者的高度的設(shè)計直覺和聰穎是必不可少的。
但是Linus是從Unix得到他的設(shè)計的，我最初是從先前的popmail得到啟發(fā)的(雖然相對Linux而言，它最后改變巨大)，所以市集風(fēng)格的領(lǐng)導(dǎo)人／協(xié)調(diào)人需要有出眾的設(shè)計才能，或者他可以利用別人的設(shè)計才能?
我認(rèn)為能夠提出卓越的原始設(shè)計思想對協(xié)調(diào)人來說不是最關(guān)鍵的，但是對他／她來說絕對關(guān)鍵的是要能把從他人那里得到的好的設(shè)計重新組織起來。
Linux和fetchmail項(xiàng)目都顯示了這些證據(jù)，Linus(如同前面所說)并不是驚人的原始設(shè)計者，但他顯示了發(fā)現(xiàn)好的設(shè)計并把它集成到Linux內(nèi)核中的強(qiáng)大決竅。還有我也描述了怎樣從別人那里得到了fetchmail中最強(qiáng)大的設(shè)計思想(SMTP轉(zhuǎn)發(fā))。
本文的早期讀者稱贊我，說因?yàn)槲易隽嗽S多關(guān)于原始設(shè)計的事，所以傾向于低估原始設(shè)計在市集項(xiàng)目中的價值，也許有些是對的吧，但是設(shè)計(而不是編碼或調(diào)試)本來就是我最強(qiáng)的能力。
變得聰明和軟件設(shè)計的原始創(chuàng)作的問題是它會變成一個習(xí)慣，當(dāng)需要保持事物健壯和簡潔的時候，你卻開始把事情變得漂亮但卻復(fù)雜。我曾經(jīng)犯過錯誤，使得一些項(xiàng)目因我而崩潰了，但我努力不讓它發(fā)生在fetchmail身上。
所以我相信fetchmail項(xiàng)目的成功部分是因?yàn)槲乙种谱约翰灰兊锰斆?#xff0c;這說明(至少)對市集模式而言原始設(shè)計并不是本質(zhì)的，請考察一下Linux假設(shè)Linus Torvalds在開發(fā)時試圖徹底革新操作系統(tǒng)設(shè)計，它還會象今天我們所擁有的內(nèi)核那樣穩(wěn)定和成功嗎?
當(dāng)然基本的設(shè)計和編碼技巧還是必需的，但我希望每個嚴(yán)肅考慮發(fā)起一個市集計劃的人都已至少具備這些能力，自由軟件社團(tuán)的內(nèi)部市場對人們有某些微妙的壓力，讓他們不要發(fā)起自由不能搞定的開發(fā)，目前為止，這工作得仍然相當(dāng)好。
對市集項(xiàng)目來說，我認(rèn)為還有另一種通常與軟件開發(fā)無關(guān)的技能和設(shè)計能力同樣重要——或者更加重要，市集項(xiàng)目的協(xié)調(diào)人或領(lǐng)導(dǎo)人必須有良好的人際和交流能力。
這是很顯然的，為了建造一個開發(fā)社團(tuán)，你需要吸引人，你所做的東西要讓他們感到有趣，而且要保持他們對他們正在做的工作感到有趣，而且要保持他們對他們正在做的工作感到高興，技術(shù)方面對達(dá)成這些目標(biāo)有一定幫助，但這遠(yuǎn)遠(yuǎn)不是全部，你的個人素質(zhì)也有關(guān)系。
并不是說Linus是一個好小伙子，讓人們喜愛并樂于幫助他，也并不是說我是個積極外向的，喜歡扎堆兒工作，有出眾的幽默感的人，對市集模式的工作而言，至少有一點(diǎn)吸引人的技巧是非常有幫助的。
十. 自由軟件的社會學(xué)語境
下述如實(shí)：最好的開發(fā)是從作者解決每天工作中的個人問題開始的，因?yàn)樗鼘σ淮箢愑脩魜碚f是一個典型問題，所以它就推廣開來了，這把我們帶回到準(zhǔn)則1，也許是用一個更有用的方式來描述：
18. 要解決一個有趣的問題，請從發(fā)現(xiàn)讓你感興趣的問題開始。
這是Carl Harris和原先的popclient的情形，也是我和fetchmail的情形，但這已在很長一段時間被大家知曉了，Linux和fetchmail的歷史要求我們注意的有趣之處是下一個階段——軟件在一個龐大的活躍的用戶和協(xié)作開發(fā)人員的社團(tuán)中的進(jìn)化。
在《神秘的人月》一書中，Fred Brooks觀察到程序員的工作時間是不可替代的：在一個誤了工期的軟件項(xiàng)目中增加開發(fā)人員只會讓它拖得更久，他聲稱項(xiàng)目的復(fù)雜度和通訊開銷以開發(fā)人員的平方增長，而工作成績只是以線性增長，這個說法被稱為“Brooks定律”，被普遍當(dāng)作真理，但如果Brooks定律就是全部，那Linux就不可能成功。
幾年之后，Gerald Weinbeng的經(jīng)典之作“The Psychology Of Computer Progromming”為我們更正了Brooks的看法，在他的“忘我(egoless)的編程”中，Weinberg觀察到在開發(fā)人員不頑固保守自己的代碼，鼓勵其他人尋找錯誤和發(fā)展?jié)摿Φ牡胤?#xff0c;軟件的改進(jìn)的速度會比其他地方有戲劇性的提高。
Weinberg的用詞可阻止了他的分析得到應(yīng)有的接受，人們對把Internet黑客稱為“忘我”的想法微笑，但是我想今天他的想法比以往任何時候都要引人注目。
Unix的歷史已經(jīng)為我們準(zhǔn)備好了我們正在從Linux學(xué)到的(和我在更小規(guī)模上模仿Linus的方法所驗(yàn)證的)東西，這就是，雖然編碼仍是一個人干的活，真正偉大的工作來自于利用整個社團(tuán)的注意和腦力，在一個封閉的項(xiàng)目中只利用他自己的腦力的人會落在知道怎樣創(chuàng)建一個開放的、進(jìn)化的，成百上千的人在其中查找錯誤和進(jìn)行修改的環(huán)境的開發(fā)人員之后。
但是Unix的傳統(tǒng)中有幾個因素阻止把這種方法推到極致。一個是各種授權(quán)的法律約束、商業(yè)機(jī)密和商業(yè)利益，另一個(事后來看)是Internet還不夠好。
在Internet變得便宜之前，有一些在地理上緊密的社團(tuán)，它們的文化鼓勵Weingberg的“忘我”編程，一個開發(fā)人員很容易吸引許多熟練的人和協(xié)作開發(fā)人員，貝爾實(shí)驗(yàn)室，MIT A1實(shí)驗(yàn)室，UC Berkeley，都成為傳統(tǒng)的、今天仍然是革新的源泉。
Linux是第一個有意識的成功的利用整個世界做為它的頭腦庫的項(xiàng)目，我不認(rèn)為Linux的孕育和萬維網(wǎng)的誕生相一致是一個巧合，而且Linux在1993-1994的一段ISP工業(yè)大發(fā)展和對Internet的興趣爆炸式增長的時期中成長起來，Linus是第一個學(xué)會怎樣利用Internet的新規(guī)的人。
廉價的Internet對Linux模式的演化來說是一個必要條件，但它并不充分，另一個關(guān)鍵因素是領(lǐng)導(dǎo)風(fēng)格的開發(fā)和一套協(xié)作的氛圍使開發(fā)人員可以吸引協(xié)作開發(fā)人員和最大限度地利用媒體。
但是這種領(lǐng)導(dǎo)風(fēng)格與氛圍到底是什么呢?它不能建立在權(quán)力關(guān)系之上——甚至如果它們可以，高壓的領(lǐng)導(dǎo)權(quán)力不能產(chǎn)生我們所看到的結(jié)果，Weinberg引用了19世紀(jì)俄國的無政府主義者Kropotkin的“Memoris of a Revolutionist”來證明這個觀點(diǎn)：
“我從小生活在一個農(nóng)奴主的家庭中，我有一個活躍的生活，象我們時代的所有年輕人一樣，我深信命令、強(qiáng)制、責(zé)罵、懲罰等等的必要性。但是當(dāng)我(在早期)必須管理一個企業(yè)，和(自由)人打交道時，當(dāng)每一個錯誤都會產(chǎn)生嚴(yán)重后果時，我開始接受以命令和紀(jì)律為準(zhǔn)則來行動和以普通理解為準(zhǔn)則來行動的區(qū)別。前者在軍事閱兵中工作的很好，但是它在現(xiàn)實(shí)生活中一文不值，目標(biāo)達(dá)成只是靠許多愿望的聚合的簡單后果。“許多聚合在一起的愿望的直接后果”精確地指出了象Linux的項(xiàng)目所需要的東西?！懊畹臏?zhǔn)則”在Internet這種無政府主義的天堂中一群自愿者之中是沒有市場的，為了更有效的操作和競爭，想領(lǐng)導(dǎo)協(xié)作項(xiàng)目的黑客們必須學(xué)會怎樣以Kropotkins含糊指出的“理解的準(zhǔn)則”模式來恢復(fù)和激活社團(tuán)的力量，他們必須學(xué)會使用Linus定律。
前面我引用“Delhpi效應(yīng)”來作為Linus定律的一個可能的解釋，但是來自生物學(xué)和經(jīng)常學(xué)的自適應(yīng)系統(tǒng)的更強(qiáng)大的分析也提出了自己的解釋，Linus世界的行為更象一個自由市場或生態(tài)系統(tǒng)，由一大群自私的個體組成，它們試圖取得(自己)最大的實(shí)效，在這個過程中產(chǎn)生了比任何一種中央計劃都細(xì)致和高效的自發(fā)的改進(jìn)的結(jié)果，所以，這里就是尋找“理解的準(zhǔn)則”的地方。
Linux黑客取得的最大化的“實(shí)際利益”不是經(jīng)典的經(jīng)濟(jì)利益，而是無形的他們的自我滿足和在其他黑客中的聲望，(有人會說他們的動機(jī)是“利他的”，但這忽略了這樣的事實(shí)：利他主義本身是利他主義者的一種自我滿足的形式)，自愿的文化以這種方式工作的實(shí)際上并非不尋常，我已參與一個科幻迷團(tuán)體很長時間了，它不象黑客團(tuán)體一樣，顯式地識別出“egoboo”(一個人在其他愛好者之中的聲望的增長)作為自愿者活動背后的基礎(chǔ)驅(qū)動力)。
Linus成功地把自己置于項(xiàng)目的守門人的位置，在項(xiàng)目中開發(fā)大部分是別人做的，他只是在項(xiàng)目中培養(yǎng)興趣直到它可以自己發(fā)展下去，這為我們展示了對Kropokin的“共同理解原則”的敏銳把握，對Linux這種類似經(jīng)濟(jì)學(xué)的觀點(diǎn)讓我們看到這種理解是怎樣應(yīng)用的。
我們可以把Linus的方法視為創(chuàng)建一個高效的關(guān)于“egoboo”(而不是錢)的市場，來把自私的黑客個體盡可能緊密的聯(lián)系起來，達(dá)成只能通過高度協(xié)作才能得到的困難的結(jié)果，在fetchmail項(xiàng)目中我展示了(在較小規(guī)模上)這種模式可以復(fù)制，得到良好的結(jié)果，也許我比他更有意識一點(diǎn)、更加系統(tǒng)一點(diǎn)。
許多人(尤其是哪些由于政治原因不信任自由市場的人)會盼望自我導(dǎo)向的自我主義者的文化破碎、報廢、秘密和敵對，但這種盼望很明顯地被Linux的文檔的多樣性、質(zhì)量和深度打破了，程序員討厭寫文檔似乎已是圣訓(xùn)，但Linux的黑客們怎么產(chǎn)生了這么多?顯然Linux的egoboo自由市場比有大量資金的商業(yè)軟件產(chǎn)品的文檔部在產(chǎn)生有品德的、他人導(dǎo)向的行為方面工作的更好。
Fetchmail和Linux內(nèi)核項(xiàng)目都表明，通過恰當(dāng)?shù)谋碚迷S多其他黑客，一個強(qiáng)大的開發(fā)者／協(xié)調(diào)者可以用Internet得到許多協(xié)同開發(fā)人員而不是讓項(xiàng)目分崩離析為一片混亂，所以關(guān)于Brooks定律我得到了下面的想法：
19. 如果開發(fā)協(xié)調(diào)人員有至少和Internet一樣好的媒介，而且知道怎樣不通過強(qiáng)迫來領(lǐng)導(dǎo)，許多頭腦將不可避免地比一個好。
我認(rèn)為自由軟件的將來將屬于那些知道怎樣玩Linus的游戲的人，把大教堂拋之腦后擁抱市集的人，這并不是說個人的觀點(diǎn)與才氣不再重要，而是，我認(rèn)為自由軟件的前沿將屬于從個人觀點(diǎn)和才氣出發(fā)的人，然后通過共同興趣自愿社團(tuán)的高效建造來擴(kuò)展。
可能不只是自由軟件的將來，在解決問題方面，沒有任何商業(yè)性開發(fā)者可以與Linux社團(tuán)的頭腦庫相匹敵，很少有人能負(fù)擔(dān)起雇傭200多個為fetchmail出過力的人!
也許最終自由軟件文化將勝利，不是因?yàn)閰f(xié)作在道德上是正確的或軟件“囤積居奇”在道德上是錯的(假設(shè)你相信后者，Linus和我都不)，而僅僅是因?yàn)樯虡I(yè)世界在進(jìn)化的軍備競賽中不能戰(zhàn)勝自由軟件社團(tuán)，因?yàn)楹笳呖梢园迅蟾玫拈_發(fā)資源放在解決問題上。
轉(zhuǎn)載于:https://www.cnblogs.com/xihe/p/6138611.html
總結(jié)
- 上一篇： 人工智能几行代码实现换脸，python+
- 下一篇： g4600黑苹果efi_授人以鱼不如授人