# Chapter?1.?介紹 大部分自由軟件項目是失敗的。 人們總不太喜歡聽太多失敗的故事，只有成功的項目才能吸引我們的注意力。林林總總的自由軟件的總數是驚人的[[2](#)]，盡管只有一小部分的項目成功了，但這仍然只是那些廣為人知的項目的一部分。有太多的項目由于不為人知，即使失敗了我們也不會聽到。我們無法用一個確定的時間點來宣判一個項目的死刑，人們只是停止工作無所事事。即使我們知道一個項目的最后一個變動是何時添加的，但是在當時那些做這些工作的人通常并不知道這會是最后的晚餐。我們甚至無法明確地定義何時一個項目才算是斷氣了。是停止活動6個月之后？是用戶數量停止增長并且人數還少于開發者的數量時？當一個項目的開發者發現他們只是在重復別人的工作，而決定放棄項目，然后他們決定加入另一個項目，并且在項目中使用之前的一些工作成果？原先的項目死亡了，或者只是搬了一次家？ 因為是如此復雜，得出一個精確的失敗率是不可能的。但是十多年以來流傳于SourceForge.net或是用Google搜索得到的開源運動傳聞，都指向同一個結論：這個比率是非常高的，也許能達到90–95%。如果把那些雖然存活但是內憂外患的項目算在內，這個比率還將更高，這些項目通常仍然*在*生產可執行的代碼，但已不再是開發者的樂園了，要么是無法盡其所能的快速和互相依賴的作出進展了。 這本書的目的旨在說明如何避免失敗。它不僅演示了如何才是正確的做事方法，而且告訴你錯誤出在何處，以便你及時發現和糾正錯誤。我希望在讀過此書之后，你不僅能對如何避免開發過程中的常見陷阱有豐富的技術儲備，而且對如何使一個成功的項目得到成長和維護有深入的了解。成功不是一場零和游戲，此書也不是教你如何在競爭中獲勝或是領先的。相反，運作一個開源項目的重要部分就是流暢地同關聯項目合作。在更高的層次上，每一個成功的項目都為在世界范圍內自由軟件的成長作出一份貢獻。 如果說導致自由軟件項目失敗的原因類型與私有軟件是相同的，那是令人誘惑的。實際上，在自由軟件內不會有諸如建立在不切實際的需求上的壟斷，含混不清的規范，可憐的代碼管理，設計階段不足等等籠罩在傳統軟件工業上的幽靈。有關這些主題的書已經是汗牛充棟，我不打算重復。我想做的是描述自由軟件獨有的問題。當一個自由軟件項目開始運轉，最常見的問題是開發者（或是經理）難以識別開源軟件開發過程中的獨特問題，盡管他們可能已經在那些閉源軟件的常見問題上摔打了多年。 一個最常見的錯誤就是急于從開源的形式本身獲得好處，但這是不切實際的。一紙開放許可證不會一下子讓成群的活躍開發者自愿地把他們的時間交給你的項目，將一個原本問題多多的項目開源也不能自動地修正這些問題。實際上很可能相反，與不開源相比，開放一個項目短期內會帶來一系列全新的復雜問題和代價。開放意味著要讓完全陌生的人讀懂代碼，建立一個開發網站和郵件列表，通常還會第一次需要寫文檔。這些事情的工作量是相當大的。當然如果有開發者*表示*出了興趣，在他們為你的項目帶來好處之前回答他們的問題也是一個額外的負擔。如同開發者Jamie Zawinski回憶Mozilla項目早期的混亂狀況所說地： > *開源的確行，但它絕不是萬能藥。我對你的忠告是：你不能指望在一個垂死項目上灑一點"開源的精靈魔粉"就能讓所有事情奇跡般地運轉起來。做軟件是困難的。問題不會那么簡單。* > （來自**[http://www.jwz.org/gruntle/nomo.html](http://www.jwz.org/gruntle/nomo.html)**） 一個相關的錯誤是對展示和打包的輕視，特別是當一個項目順利運轉時總認為這些以后再做不遲。展示和打包有很多的目的，所有的一切都是為了減低進入的門檻。使項目對那些后來者有吸引力意味著編寫用戶和開發者文檔，建立為新來者提供信息的網站，盡可能自動化軟件的編譯和安裝工作，以及其他。很不幸，很多程序員認為與編碼相比，這些工作都是次要的。導致這種情況的原因有很多。首先，他們感覺這些都是附加作業，因為對熟悉項目的這部分少數人來說，它的益處是顯而易見的，反之亦然。畢竟這些編寫代碼的人并不真需要打包。他們知道如何安裝，管理和使用這些軟件，因為代碼就是他們編寫的。其次，展示和打包所需要的技術通常和寫代碼完全不同。人們總是傾向于專注自己所擅長的，即使另外的工作能對整個項目起到事半功倍的作用。 [Chapter?2, *起步*](# "Chapter?2.?起步")將詳細討論展示和打包，并且解釋從項目的一開始就確定這些工作的優先地位的重要性。 接下來的一個謬誤是認為開源幾乎或完全不需要項目管理，或者照搬商業開發的那一套管理模式也能在開源中做得很好。在一個開源項目中，管理總是不起眼的，但在成功的項目中，它通常在幕后起到推動的作用。一個簡單的心理試驗就足夠顯示其原因。一個開源項目由來自四面八方的程序員組成—一群臭名昭著的自由獨立思想者—他們中的大部分人從來沒有互相見過面，為這個項目工作只是出于他們的個人目標。心理試驗能很簡單地預測如果*沒有*管理，在這樣一個團體中會發生什么。除非發生奇跡，否則他們很快就會四分五裂。事情不會如我們希望的那樣自己運轉。管理偶爾會相當活躍，但是大部分時候是非正式的，微妙的，低調的。只有一件事情能把開發者團結在一起，就是他們相信團隊合作比單干能做得更多。因此最重要的管理目標是確保他們繼續相信這一點，做到這點需要設定交流的標準，需要讓能干的開發者不會因為個性而受到排斥，總之要使項目成為開發者的留戀之地。我們將在后面討論這些工作需要的具體技術。 最后還有一種類型的問題也許我們可以稱之為“文化引導失敗”。十年之前，甚至五年之前，談論自由軟件運動的整體文化都還為時過早，但現在不是了。一種清晰的文化正在慢慢浮現，雖然它不是一個整體—如同很多地域約束的文化，易于產生內在的異議和派別—但它有一個基本的一致的核心。大部分成功的開源項目展示了這個核心中的部分或全部特質。他們獎勵符合這種文化的行為，懲罰相反的；他們創造了一種鼓勵計劃外的參與氛圍，甚至不惜中心協調時間的代價；他們對粗野和禮貌的概念與流行觀念有本質上的區別。最重要的是，長期的參與已經內化了這些標準，所以他們能夠對將要發生的舉動能大體上取得共識。失敗的項目通常顯著的背離了這個核心，盡管并非本意，但通常是因為沒有對建立合理默認行為方式達成共識。這意味著一旦問題出現，由于參與者缺乏通過彌補分歧而對問題做出反饋的現成文化儲備，形勢會迅速惡化。 此書是一本實用的指南，而不是一篇人類學論文或是史書。然而了解今天的自由軟件文化的起源對任何一個實際的建議都是必要的基礎。一個理解這種文化的人能在開源世界任意馳騁，即使遇到很多的各地風俗和方言，仍然可以自信和有效地參與。相反，一個沒能很好理解這種文化的人將會在組織或是參與一個項目的過程中處處遇到困難和意外。由于自由軟件的開發人員的數量仍然在飛速增長，其中有很多人屬于后一種情況—這多半是一種新近加入的文化，并且會持續一段時間。如果你自認為是其中的一員，下一節為你在以后將在本書或是互聯網上遇到的討論提供了背景材料。（另一方面，如果你已經在開源中工作了一段時間，你也許早已了解了這段歷史，你可以選擇跳過這一節。）