[[142923]]

在今年的OSCON大會上，紅帽公司的Tom Callaway作出了題為《你的失敗原因：本可避免的錯誤在開源項目中仍一再出現》的演講。2009年，Callaway開始加入Chromium項目的開發工作——而在此次演講中，Callaway以輕描淡寫的方式將其形容為一段并不愉快的經歷。

Callaway指出，他喜歡接受挑戰，但該項目卻讓他感到窒息，甚至最終使他選擇了退出相關工作。（Callaway表示，需要提到的是Chromium的代碼庫并不糟糕，只不過本身工作量很大、而且谷歌在項目開發過程中并沒有將其全部編寫完成。）這一切讓Callaway感到萬分沮喪，而人們也對他的遭遇感到好奇。Callaway希望能夠更為透徹地分析自己所遭遇的挫折，因此整理出了今天的這份清單——他將其稱為“失敗點”。

盡管Callaway并不打算通過博文博取什么關注，但人們仍然發現了他的經歷并就此展開討論。由于這份清單僅僅囊括了對他所聞所感的概括，因此多家媒體對他發出了演講邀請，其它網站上發布與之相關的解讀文章，甚至出現了開源類型下的職稱圖。不過在深入討論他的失敗點理論之前，Callaway希望首先定義真正的成功。人們樂于使用開發者的軟件成果是衡量成功的重要標準之一。其次（這也是我最喜愛的討論內容），我們需要健康的社區環境來保障成功。我們希望有更多人參與進來改進自己的產品方案、彼此幫助并定期發布更新內容。***，我們希望自己的工作能夠被“友好地分發”。一個被“友好分發”的開源項目意味著其需要經過預打包，Callaway解釋道。

大部分Linux用戶獲取大部分軟件的手段仍然是通過發行版當中的軟件包集合。這是人們尋找新型軟件時關注的***平臺。而在解釋了成功的定義之后，Callaway給出了以下失敗點的衡量標準：

1.如果你的代碼庫太過龐大，則會限制用戶下載這些代碼的意愿與能力。

2.現在是2015年，開源項目沒有任何理由不提供公開源代碼控制機制。這有助于人們為其作出貢獻，并根據***提交內容的日期來判斷項目的當前運作狀況。

3.如果你的源代碼控制機制不提供Web查看器以及/或者說明文檔，那么請馬上想辦法解決——這兩項因素至關重要。

4.糟糕的代碼比沒有相關代碼還差勁！大家需要提供說明文檔，解釋如何利用這些源代碼構建起整個項目。

5.使用build工具。

6.采用捆綁方式并不代表著項目會失去可維護性——捆綁只代表fork能力。

7.強迫人們在特定目錄之下安裝軟件項目。

Callaway表示一旦遇到以下情況，則意味著項目已經遭遇失敗：

1.如果你的代碼運行需要依賴于微軟Visual之類（***失敗了）。

2.如果你的項目被托管在某套系統內，但卻沒有配合冗余，或者是直接運行在了身邊的某臺普通計算機當中。

3.如果不具備適當的通信工具（包括郵件列表、網站以及/或者bug追蹤工具）。

4.如果你的代碼屬于其它項目的fork，而你的主要開發人員并沒有同時參與其母項目的編程工作當中。

5.如果你的代碼在進行開源之前屬于專有軟件（我們沒有辦法改變過去）。

6.如果你的代碼許可缺乏一致性。

7.如果你的代碼不具備任何說明文檔。

8.如果大部分通過郵件列表發出的消息都沒有回應、遭遇調侃甚至是侮辱。

9.如果有超過50%的項目貢獻者效力于同一家企業。

10.如果你的代碼不提供本地化支持。

11.如果你沒有對項目加以管理，或者單純依靠代碼發布廠商進行管理。

原文標題：This is why your open source project is failing