[[142923]]

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

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

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

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

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

2.現(xiàn)在是2015年，開源項目沒有任何理由不提供公開源代碼控制機制。這有助于人們?yōu)槠渥鞒鲐暙I，并根據(jù)***提交內(nèi)容的日期來判斷項目的當前運作狀況。

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

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

5.使用build工具。

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

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

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

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

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

3.如果不具備適當?shù)耐ㄐ殴ぞ撸òㄠ]件列表、網(wǎng)站以及/或者bug追蹤工具）。

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

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

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

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

8.如果大部分通過郵件列表發(fā)出的消息都沒有回應(yīng)、遭遇調(diào)侃甚至是侮辱。

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

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

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

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