Alan Cox：大教堂、市集與市議會
在網上搜到的Cox大叔于1998年在開源社區寫的一篇文章，當時很轟動，明眼人一看就知道是針對ESR那篇《大教堂與市集》，從中可見Alan在項目管理風格上乃至個人性格上都與ESR、Linus等人不同之處。順便說一句，Alan現在出于“家庭原因”已經離開了Linux項目，他曾經評價 Linus是a good developer but a terrible engineer，甚至在Google+上直接說Linus就是一a*sh**e。不管如何，兩位曾經十余年里并肩戰斗惺惺相惜的大牛就此分道揚鑣還是惹人唏噓。
言歸正傳，以下為slashdot收錄的英文原文：Cathedrals, Bazaars and the Town Council。
以下是一些我對市集模式的想法，我認為這值得分享，這種模式會教你如何完全毀掉一個自由軟件項目。我還舉了一個我稱之為“市議會”(Town Council)效應的實例（雖然那些市議員們可不這么認為，注：此處指Linux項目開發者）。
關于軟件開發人員，你必須去了解一些情況。首先要了解的是真正優秀的程序員相對來說并不普遍，不僅如此，在很多其它專業領域里“真正的程序員”和一些搗亂的家伙之間的區別要比“偉大”和“普通”之間的區別要大得多，研究表明生產效率上最好的同其余的比重是30:1。
其次，你需要了解的是一大堆妄想型碼農(wannabe programmer)總是善于發表意見。其中很多人患上了一種叫做“流行性熱詞”(buzzword)疾病，或者對他們“非黑即白”(one true path)的思考方式有著特殊的偏執，網上很多討論都是廉價的。
第三個關于軟件項目的事情就是我們所謂的“閑雜人員”(the masses)。他們不是編程人員，而在其它方面有著大量貢獻——文檔編輯、用戶支持，以及對那類經常爭論你應該獲得許可證才能上網的人的說服工作。
我想以Linux 8086（注，Intel設計的16位處理器架構）為例來說明如何將整個工程全部搞砸。將Linux的一個子集移植到8086上大體是這世上最無聊的活動之一。整件事的發起就像個笑話并走向失控。
只有極少數真正的程序員會將時間及其良好的精神狀態（或許那是假的）花費在那些唯一價值在于“黑客精神”(Hack Value)的項目上，故而在任何時候那種項目也就兩三個核心貢獻人員而已。
不幸的是大批人認為將Linux運行在8086上是干凈的，為此義不容辭地想要“入伙”。這類人大多屬于妄想型碼農之流，以至于連閑雜人員在一個安全距離之外都會沾染上這個項目的“愚蠢”因子。
問題的導火索在于一大批充滿（大多善意的）危險的一知半解的人們的意識觀念——不是代碼，而是意識觀念。他們似乎很懂得如何去編程，但很多人連 “Hello World”這樣的C程序都不會。他們花了幾星期時間去爭論并投票該使用什么編譯器，甚至在項目開展一年后還在爭論是否去寫個充分完美的編譯器。他們熱衷于辯論如何生成大量二進制文件，卻又對內核swapper（注，即idle task）設計一無所知。
Linux 8086項目仍然進行著，真正的開發人員將郵件列表里許多其他成員加入到清除文件(kill files)中，以便他們之間可以順暢地通過郵件列表溝通，只因半吊子打醬油的家伙實在太多了。這一切不再是市集模式，而是形成了一個核心小組，對圈子里許多人而言這是一種禮貌用語。在這種情形下人們不可避免地處于被動位置。
像Linux這種基于用戶/程序員的項目成長緩慢，雖然它是靠著一群貢獻代碼的人得以成長起來，但這些人的背景要么是從原始的Minix（注，一種微內核操作系統）黑客社區起家，要么通過艱難的方式不斷從頭學起。隨著項目增長，人們本應該形成一個“Linux內核結構規劃管理委員會”，而不是掉入將人們招來喚去，不將失敗視為問題的怪圈，用Linus的話來說就是“給我看源碼”。
如果有人陷入困境，他可以發帖詢問，在這之前包括現在很大程度上都基于人們正常地擁有時間并具備知識來回復他。在Linux 8086的案例中，開發人員很長一段時間身陷囹圄。假使主動活躍的程序員對只有潛在用處的妄想型碼農的比例更高一點的話，我們就可以將一些雜音轉化成生產力。項目也就獲得更多有用的程序員，他們可以輪流向他人傳授經驗，任何學習活動都會讓你變得更好，哪怕只有一些少量實習生。
一些人會認為你無法將那些“次要程序員”(lesser programmer)訓練成真正的程序員。就Linux項目的個人經驗而言，很多人員只要獲得一丁點兒的幫助和自信鼓勵都將成為世界上最好的開發人員之一。只要幫助和鼓勵足夠多，很多人就能成功。
Linux 8086總算大部分從“侵擾”中恢復過來，可至今仍是個不起眼的小項目。你可以從CVS目錄樹上下載這個由Alistair Riddich領導的項目，他做了很多優秀的工作。隨著市議員的撤出，人們可以詢問、參與并改善這個項目。
我們從這個項目，還有其它相同命運的早期Linux 16位處理器項目（有的已死）中很清楚地學到以下幾點教訓。
- 從項目一開始就發布源代碼。哪怕不是很有用也無關緊要，將市議會排序分類的最好方式就是發布源代碼并告知人們。Linux、KDE以及GNOME都遵循這種方式并獲益良多。你可以花一輩子時間去爭論怎樣寫代碼才是正確的。只要代碼公布，人們（不管水平怎樣）都會把玩它。
- 要欣賞那些給一點幫助就會對項目做出巨大貢獻的人。如果他們最初的補丁有錯誤，不要盛氣凌人，向其解釋問題出在哪里并給出解決方案的建議，或者可以查詢解決方法的地方。解答真正的問題，幫助別人，你所花費的一分一秒都會成十倍地回報在項目上，對社會也會帶來無法估量的好處。[注]
- 不要忘記那些非開發人員。我難過地發現許多人問起“前5名最重要的內核成員”時卻極少涉及在所有人中最重要的一些——他們負責維護網站，更新日志和郵件列表，還有編輯文檔，這些都是同等重要。
- Linus那句“給我看源代碼”對真正的項目來說是個狹隘的視角。當你聽到人們說“我很想幫忙，可我不會編程”，那么他可以從事文檔編寫。當人們說“但英語不是我的第一語言”，這時你需要的是一位文檔編輯或另一門語言翻譯者。
- 嘗試將有用的人從雜音中分離出來，將有意愿幫忙的人從一大堆無聊評論中分離出來是很難的。在Linux 8086項目中我的確錯誤地放棄了這一目標，如何將那些只會空談而又無所事事的人弄走是一門學問。
下次碰到人們在項目上投票，或者問題討論了一個月才實現這類情況，給予他們警告。這樣才能使人正確地解決問題。在你看來如果一些稀奇古怪的事務不顧一切地運行著，要求他們給你發個補丁，只要能夠生效的話。
小心地說“我們應該怎樣”之類的話，對“我該如何做”這樣的人伸出援手。
Alan
[注]這段話舉個例子說明一下。Linux IPv6源碼作者以前在葡萄牙上網聊天，只會簡單討論和問一些基本問題。我們助其弄明白一些內核原理之后，他寫了大約75%的IPv6協議棧代碼，他最近受聘于美國思科公司。
附錄一：一篇針對本文的吐槽貼
附錄二：2009年Cox回復Torvalds的郵件，事情起因是Cox的一個tty patch導致kdesu(KDE project’s su utility)程序無法工作，該問題爭論長達兩個星期，此后Alan離開了Linux項目投奔Intel。
