大教堂與市集十市集風格的先決條件

簡體傳統

十市集風格的先決條件
本文的早期審閱人和測試者不斷地希望了解成功市集風格的先決條件，這包括項目負責人的資質和著手建立協作開發社區時代碼的開放狀況。
很明顯，市集風格不能幫你從零開始編程。【注】你可以利用市集風格來測試、調試、改進代碼，但是用這種風格來孕育一個項目會很困難的。李納斯沒有這樣試過，我也沒有。你初建的社區至少需要一個可以運行和測試的東西。
一旦你著手組建團隊，就需要給出一個可行的承諾。你的程序并非必須運行良好，它可以是粗糙的、遍布瑕疵的、不完善的、也可以是缺少說明文件的。但是必須滿足（1）它能運行；（2）能讓潛在的協作開發者相信在不久的將來它能變得精良。
Linux和fetchmail都是在有了健碩，誘人的基礎設計之后才推向公開的。我所提到的市集模式觀察者們認為這是至關重要的。進而得出結論：一個睿智并且具備高超設計才能的領導是必不可少的。
但是李納斯是從Unix出獲得的設計，而我則是從早期的popclient（盡管日后改動很大，但是還無法和Linux相提并論）。那么，一個市集風格的領導者/主持人當真需要天賦異稟嗎？或者他們只是四兩撥千斤的動用了他人的創見？
在我看來一個項目的主持人是否能夠做出足以彪炳的設計并不很關鍵。而至關重要的是，他是否可以從他人的創意中慧眼識英。
Linux和fetchmail都印證了這個觀點。李納斯（如同前文描述的那樣），盡管不是一個驚世的原創設計者，但是卻展現了識別優秀設計并整合成為Linux內核的不凡才能。我也曾描述了fetchmail中最強大獨到的功能（SMTP轉發）是如何源自他人的。
本文的早期讀者捧我的場說我之所以容易低估市集項目中原創因素的價值，是因為我本身不缺乏創意靈感，所以就習以為常了。這番評論或許卻有見地，因為（與編碼和調試相比）設計確實是我的強項。
但是問題是，在軟件設計中展現聰明和原創力會養成一種習慣——當你需要保持設計穩健和簡潔的時候，會不自知把它們弄得有趣而復雜。我曾經因此搞砸過項目，所以在fetchmail的開發中我要避免重蹈覆轍。
所以我堅信fetchmail項目的成功應部分歸因為我克制了自己的自作聰明；這（至少能夠）反駁“原創設計制約市集模式成敗”的觀點。回頭看Linux，假設李納斯在開發操作系統核心時力主原創的話，我們現在還能見到如此穩健成功的內核嗎？
一定的設計和編碼技能是必須的。但是我想，任何一個深思熟慮準備試水市集項目的人都遠遠超出了這個底線。開源社區內部的聲望機制給人們一種微妙的壓力，從而大家不會去發起一些自己無力支撐的項目。目前看來，這行之有效。
我認為還有一種與軟件開發無關的技能，卻在市集項目中與優秀設計同等重要——甚至更勝一籌。那就是一個市集項目的主持人或領導者必須具備優秀的人際交流技能。
顯而易見，要創建一個開發社區，你需要招募人手，讓大家對你所做的感興趣，并讓大家對工作樂此不疲。為了達成這個目標，技術上的磨合必不可少，但卻遠不是故事的全部。與大家的人際融合也至關重要。
李納斯平易近人，招人喜歡并讓大家樂于幫助他——這并非偶然。我活波外向，喜歡群體工作，并且帶有一些插科打諢的言談和性情——這也絕非巧合。為了運營一個市集項目，哪怕是一點點人格魅力都對你大有助益！

注：
有關市集風格是否可以幫你從零開始構建一個項目的另一個爭論是——其是否能夠促成真正意義上的創新。有人聲稱，由于缺少強有力的領導。市集風格只能在工程學前沿克隆和演進已有創新，卻無法孕育新知。這種垢弊極可能源自“萬圣節文件”——兩份微軟內部旨在發難的開源現象備忘錄。其作者認為，Linux不過是個拾人牙慧的類Unix系統，“（一旦這個計劃具有了同等的領先水平）管理開銷就必然變得異常龐大。”
這個觀點和事實大相徑庭，乃至文件作者后來自己也指出：“通常……創新首先出現在Linux上，其后才被推廣/整合到其他平臺。”
對我們而言，即使把上文中的“Linux”換成“開源軟件”也算不得什么新鮮事。回顧歷史，開源社區并沒有拾人牙慧的開發出Emacs、萬維網和因特網，同樣也未曾担負過龐大的管理成本。現在開源項目的不斷創新給我們提供了前所未有的施展空間。比如GNOME項目（信手拈來一例），已經達到了圖形用戶界面領域的頂尖水品。其復雜程度吸引了Linux社區外為數可觀的商業關注。類似的例子不勝枚舉，你可以抽空訪問一下Freshmeat.net，一看便知。
其論斷中還有一個本質的錯誤，即假定大教堂模式（或市集模式，亦或其他任何管理結構）可以順理成章的產生革新。這是一派胡言。群體沒有洞見創新的眼光——對此，市集模式中志愿組合的團隊也往往無濟于事。更不用說那些要為自己生計下注的社團委員會成員了。創新源自個體。其周圍社會機制的最有效激勵就是做出適當的回應——去培養、獎勵、鞭策他們，而不是排擠。
一改過去“孤單發明家”的套路，有人會把這種創新方式描述的頗具浪漫色彩，然而事實遠非如此；我并非斷言團隊無法再像過去那樣在開發中創造突破；事實上，我們在平行開發中學到，對于高質量的產品，團隊協作是必不可少的。但是我必須指出任何團隊的組建都是源于某人的創想（這也是必要的火花）。無論大教堂、市集、還是其他模式都可以抓住這稍縱即逝的火花，并將它引燃。不過，它們都不能在有需要的時候就立即擦然火花。
所以說，（軟件或其他領域）革新的根本問題是：首先，如何培養那么多能夠創新的人才；以及如何避免排擠他們。
假定大教堂風格可以促成創新，而門檻低、流程通暢的市集模式則無能為力，顯然是很荒謬的。如果創造源自一個人加一個好主意，那么能吸引成百上千人共同協作的社會環境必然優于一個必須通過政治手腕向上級推銷創意的環境（為了避免不被炒魷魚，你必須在得到批準之后才能繼續研發）。
確實，如果我們檢視一下大教堂模式下的軟件創新史，不難發現源自其自身的創造鳳毛麟角。大企業需要通過大學中的研究獲取新知（因此，萬圣節文件的作者對Linux對研究成果的快速吸收深表不安）。或者收購一些由于某個創意而組建的小公司。這兩種創新均非源自大教堂文化。恰恰相反，很多類似被買斷的創見被（萬圣節文件作者鼓吹的）“龐大的管理成本”扼殺了。
上面都是一些反證，這里應該把一個正面的例子奉獻給讀者。我建議大家試試下面的方法：
確立一個你能一以貫之的創新判別標準。比如“發現并加以區分（I know it when I see it）”就滿足這個判別條件。
選擇一款能和Linux競爭的閉源操作系統，和一個讓你可以了解其開發進展的最佳資訊渠道。
在一個月內每天關注Freshmeat和你選擇的消息渠道。分別記錄下二者中你認為是創新的點子數。
三十天后，匯總兩組數據。
在我寫下這些文字的日子里，Freshmeat出現了22條新消息。其中有三條看似可以在某方面推動技術革新。雖然這幾天Freshmeat不很景氣，但是假如有讀者在一個月內能通過任何閉源渠道發現這樣的三條創新，就真的值得大書特書了。