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

[[133958]]

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

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

• 發(fā)展愿景
• 執(zhí)行流程
• 項目印象

發(fā)展愿景

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

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

構(gòu)建一套路線圖

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

獲取用戶反饋

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

#p#

執(zhí)行流程

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

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

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

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

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

#p#

項目印象

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

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

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

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

• Travis CI:實現(xiàn)持續(xù)集成
• Coveralls:實現(xiàn)代碼覆蓋率
• Code Climate:實現(xiàn)代碼分析
• David:實現(xiàn)相關(guān)性分析

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

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

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

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