在管理自己的開源項目PencilBlue的過程中，我最喜愛的部分就是能夠與來自世界各地的參與者們 交流互動。在項目剛剛啟動初始階段，開發團隊只有兩位成員，但幾個月的時間過去之后、我們的貢獻者數量開始出現持續增長。這不禁讓我開始思考如何才能扮演 一位合格的項目維護人員，又該怎樣保證團隊順利引導項目在未來的幾年當中始終平穩運行。

[[133958]]

時至今日，全世界到底有多少技術人員在為開源軟件作出貢獻？如果GitHub的用戶數量可以作為參考的 話，那么開源社區的整體規模已經超過了850萬人。這是個巨大的數字，代表著那些有能力而且有意愿為開源事業提供助力的參與者。順帶一提，這些數字甚至還 沒有算上那些面向克隆版本或者匿名下載發行版的貢獻群體。如今，我們已經了解到開源社區的可觀受眾，那么如何才能讓他們對自己的項目感興趣呢？

要管理好一個開源項目，歸根結底需要做好以下三件事：

• 發展愿景
• 執行流程
• 項目印象

發展愿景

開源項目必須擁有一套明確的發展愿景。我曾經在北卡羅來納州召開的FOSS Fair大會上向幾位與會者征求過意見，詢問他們：“在開始或者參與到某個開源項目的貢獻之前，您會如何做出決 定？”他們給出的答案出奇地一致：“我覺得很煩，而且希望能夠解決目前面臨的問題。”大家正在試圖解決的問題通常也會給其他用戶帶來困擾。我們往往樂于加 入到那些有助于解決自身實際問題的開源軟件項目當中。理由很簡單，因為希望使用這款軟件或者考慮為其作出貢獻的技術人員希望能確保項目團隊的發展目標能夠 與他們的思路保持一致，而不僅僅是單純滿足他們當下的迫切需要。實現這項要求的最簡單方式，就是在自述文檔當中向大家解釋我們的發展愿景。“我目前只達到 了既定發展目標的20%，而且整個過程并不輕松，但這是我為項目定下的發展目標。”不用擔心，這樣的親民表述完全可行，畢竟每項工作都有很長的發展道路要 走，最重要的是幫助自己以及潛在參與者確定前進方向。

不過單單公布這樣的發展愿景顯然還太過粗放。我們接下來有必要與潛在參與者們定期進行對話，并探討接下來的幾個月項目將沖擊哪些階段性目標——不用太多，少點也可以。如果大家制定出了明確的路線圖，那么追蹤并展示項目進度將變得更為輕松。

構建一套路線圖

就在去年，我們構建起一套基礎性路線圖、用于指導在2014年第四季度內應該解決哪些問題。其實際效果 非常理想，因為這樣一來、我們幾乎用不著再為突如其來的特定功能而忙得不可開交了。不過，我們也確實在自己的路線圖當中建立了一些特殊的目標及實現日期。 當用戶們的反饋紛至沓來時，其要求往往與既定目標間存在偏差，這就迫使我們重新設定具體時間點。長期路線圖的存在使我們更傾向于選擇瀑布式流程而非敏捷開 發思路，而且雖然我個人并不想就此過多作出爭論，但我得說采取相對時間進程規劃在我們的項目當中取得了更理想的收效。舉例而言，在路線圖中規定某項媒體服 務應該在十二月完成效果更好，但將其具體規定在十二月的第二周則往往會與實際過程產生沖突。

獲取用戶反饋

決定項目的未來走向往往是件困難的工作。在起步階段，大家只需要遵循自己的思路推進工作即可。然而隨著 貢獻者以及/或者用戶群體的不斷擴大，我們往往會發現自己遵循的是群體意志、而非個人對于項目的喜好或者設定。畢竟我們的項目必須能夠滿足用戶的需求，而 不單單是為了取悅自己。這又是我在項目發展的幾個月后學到的另一項經驗。我們推出了一套自以為已經算是功能齊全的CMS，但用戶卻在反饋中提到“嘿，如果 其中還能……那肯定很酷”。這樣的反饋非常重要，因為這意味著人們在真正使用我們的開發成果，或者至少進行了嘗試。這可能會與我們自己的既定發展愿景產生 沖突，但如果這樣的要求多次出現，請各位千萬不要輕易忽視。客戶永遠是對的，而我們則必須將對方的要求納入考量范圍，從而確保項目的發展方向與他們的利益 保持一致。

#p#

執行流程

在保持原有發展愿景的同時維護好貢獻者群體并不是件容易的事。大家有時候不得不作出一些與參與者風格完 全不同的差異性決策。為了盡可能避免這類狀況的出現，最重要的是制定一套切實可行的pull request、問題交流以及設計模式強化流程。執行流程往往非常枯燥——其枯燥程度甚至超過了向每一位用戶解釋當前項目的既定目標。但這屬于“必要之 惡”，只有實現了這一點、我們的代碼才能具備應有的可維護性。

大家不妨回想一下，自己在一周當中有多少次是在為項目主干提交貢獻、而非功能分支？我自己得首先承認，我在這方面做得不好、每周至少會出現幾次有違這一思路的狀況。在通常情況下，這類問題一般出現在插件等層面而非平臺核心。

這是一大需要努力規避的問題，而且相信大家也一定聽說過那些所謂流氓程序員的家伙。他們拿出的開發成果 確實令人印象深刻，但要將其納入項目、卻往往意味著項目中的其他成員需要為此付出代價。解決的***辦法就是實行一套標準，為每位貢獻者及/或用戶設定對應 職責。以下列出的雖然看似小事，但卻能夠切實幫助我們緩和流程程序員帶來的負面影響：

• 為我們打造出的每項功能或者特性建立一套分支方案。
• 每套分支的名稱都應包含順序編號。
• 確保所有單元性測試都針對主版本以及分支版本分別運行。
• 盡量不要將自己的pull request加入其中。如果測試覆蓋率較為理想，那么小型團隊可以直接通過。
• 將我們自己的pull request視為一種學習經驗。思考自己為什么要以特定方式完成某項任務。不管其他人怎么看，為每個爭議點寫下三行注釋絕對能夠起到良好的效果。這意味著大家既能夠完成復雜的任務，同時也可以在未來規避“那時候我到底在想什么？”之類的窘境。

這些小事看似無關緊要，但卻能夠切實幫助貢獻者承擔起各自責任，從而保證項目中的每位成員都能與項目的發展愿景保持同步及一致。

#p#

項目印象

現在讓我們假設自己正在兩個非常相似的項目之間進行選擇，那么各位如何選出那個值得我們接下來為其付出 大量時間與精力的勝出者呢？我在評估包括PencilBlue在內的眾多項目時，這個問題始終困擾著我。我希望從不同項目之間找到顯著差異，但事實上很多 代碼庫都能實現同樣的效果，因此要想脫穎而出、大家往往需要拿出一點與眾不同的特性。老實講，這涉及到印象概念。我們的網站、文件以及自述文檔都要給人留 下很好的***印象，請各位千萬別忽略這一點。

作為一位開發者，我個人常常忽視視覺效果的重要性。我想當然地認為自己的代碼質量已經突出到能夠決定一 切，但在這全部30萬行代碼中，我們要如何向他人證明自己的結論呢？事實上，參與者們的不斷貢獻使項目以動態平衡的方式擁有穩定的發展節奏。而這種節奏越 是平穩，項目的生命周期就越是樂觀。

每一位項目管理者都需要認同一點：以透明化方式進行問責。

開源項目能夠從上游以及下游企業身上得到極大助益。其中大多數企業都能夠提供工具，從而在某種程度上幫助我們更好地進行項目開發。

• Travis CI:實現持續集成
• Coveralls:實現代碼覆蓋率
• Code Climate:實現代碼分析
• David:實現相關性分析

每一家企業都能在一定程度上為開源項目提供服務方案。它們同時也以提供考量指標的方式支持透明化需求。 利用這些指標，我們能夠更加明確不同角色對于項目質量的影響以及劃分。作為一項簡單的加法，只要我們的代碼能夠切實幫助他人解決問題、那么用戶對項目的信 心自然會獲得提升。人們會給出下面的反饋，并樂于加入進來以共同完成項目的共同發展目標。

我曾經讀到一篇博文，其中提到我們每個人都能夠單獨編寫出一套輕量級GTK MP3播放器，但如果大家能夠聚焦在一起、則可以搞出一些真正擁有傳世價值的出色成果。如果我們能夠向其他人展示自身項目的發展方向、告訴我們如何才能參 與進來并向他們證明自己的技術實力，那么這些群體智慧資源將為項目所用、并最終推動項目向著既定目標穩步前行。

原文鏈接：http://opensource.com/business/15/5/what-i-learned-managing-open-source-cms-project

原文標題：What I learned managing an open source CMS project