如何管理好開源軟件社區:開源項目管理方法

開源社區到底是怎樣形成的?開源項目是怎么管理的?

　　在這篇文章中，我想分享一下我在參與AS7開發過程中用到的管理工具及協作流程，并談一些對開源社區的理解。

　　AS7的開發流程主要涉及這樣一些核心工具：

　　github – 從AS7開始，幾乎JBoss的所有組件的代碼庫都轉移到github上面。

　　Jenkins – Jenkins原名Hudson，是一個CI(Continuous Integration)工具。AS7使用它來進行代碼的自動化持續測試。

　　JIRA – Jira用于根蹤項目Bug，記錄開發任務等。

　　聽起來和普遍的項目管理流程沒什么太大區別：幾乎所有的項目都會有一個代碼倉庫，有一個Bug跟蹤系統。(當然，可能有的項目并沒有集成測試環境，也不寫單元測試，質控基本靠人工-這是屬于管理水平較低的項目中的情況。)

　　那么，當一個社區項目成規模，成熟化以后，卻可以用看起來和別人沒什么不一樣的管理工具將項目管理得很好，這里面有什么秘密呢?我覺得差距主要體現在流程細節，工具的使用水平，測試的自動化程度這三個部分。

　　就JBoss的社區來講，我想分享一些具體經驗。首先我們要知道JBoss社區的Bug管理系統位于：

　　https://issues.jboss.org/secure/Dashboard.jspa

　　如果你有社區賬號，可以登錄進去，就可以看到這里面管著多少項目。以下是部分項目的截圖：

　　可以看到整個JBoss社區的項目規模是非常龐大的，這里面的很多項目既做為組件形成JBoss核心產品JBoss AS7，又可以獨立使用并與其它社區項目相結合，比如Hibernate，就是JBoss社區的產品之一。

　　這些項目的社區里面的開發人員，大部分沒有交集，各自在自己的項目中進行開發。也有少數的成員同時給好幾個項目貢獻代碼，這樣的開發人員一般是 Red Hat員工(Red Hat也會看社區里面的代碼的貢獻量;貢獻比較大的非Red Hat員工，往往會被高薪挖來成為全職)。

　　可能對開源社區的運作不太了解的人，會認為社區是“平的”，大家人人可以自由提交代碼，有大量的人貢獻代碼，然后一個好的項目就誕生、成長起來了。這可能是對社區模式的最大誤讀了。

　　實際情況恰恰相反，社區的人員組成結構更像是金字塔。真正組成社區的核心開發人員，一般也就那么3、5個人，這些人往往擁有非常強的編碼能力，非常 豐富的經驗，他們基本上可以在項目中貢獻80%～90%的代碼，并且項目設計由這些人完成，他們可能同時是標準制定者和代碼編寫者。

　　以JBoss項目RESTEasy為例：

　　http://www.jboss.org/resteasy

　　這個項目的社區領導Bill Burke身兼多重身份：首先他是Red Hat員工;然后他是JCP標委會成員，參與包括EJB，JAX-RS等多個J2EE標準的制定;同時，JAX-RS標準的框架實現：RESTEasy的 核心部分幾乎全部由他一人撰寫，同時他參與多個社區的編碼工作。而Bill Burke本人也是JBoss社區的創始人之一，在商業上非常成功，做為一名技術人，他的富有程度并不會輸給Red Hat核心管理層。

　　再來看RESTEasy的團隊核心成員：

　　https://community.jboss.org/wiki/ResteasyContributors

　　幾乎都是Red Hat員工，享受公司很好的待遇，從事社區專門的工作。除了JBoss這種由Red Hat直接支持的“商業味”比較濃的社區之外，我們再看下一些由開源基金會支持的“純正血統”的開源社區。比如Apache社區的一些項目，拿HTTPD為例：

　　http://httpd.apache.org/

　　左邊有Get Involved鏈接，分三個部分：Mailing Lists, Bug Reports, Developer Info。

　　可以看到，代碼開發并不是參與社區開發的全部內容。首先我們可以訂閱它的郵件列表，對社區中日常工作有一個大概了解，然后可以發現問題后提交Bug給社區去解決，最后是Developer Info，這里面可以找到代碼庫：

　　http://svn.apache.org/viewvc/httpd/httpd/trunk/

　　仔細看下貢獻者，發現人數并不太多。除了Apache基金會自己的核心成員，還有不少來自Red Hat，IBM等各家參與開發的公司的員工貢獻。在Red Hat的Security Team中，我的不少同事同時也是為HTTPD貢獻代碼的開發人員。

　　因此，我們要明確這樣一個概念，社區的平等，并不意味著社區是"平"的， 我參與過的所有社區幾乎都是金字塔型：核心團隊規模保持小而精，貢獻絕大部分代碼，他們往往就職于商業公司，或者在研究機構或開源組織中從事專業工作-憑 著技術狂熱和大量業余時間來參與社區開發，并形成了很大貢獻的人也有，但絕對不是社區里面的主流情況。

　　而用戶群體對于社區來講意味著什么呢?當然，代碼寫得再好，也得有用戶群才成。因此，項目流行程度取決于用戶規模，絕大部分用戶群體不會貢獻代碼， 但會貢獻使用心得，BUG報告，會幫助項目有意無意的做宣傳，貢獻各種各樣的外圍項目(比如Linux Kernel社區會收到各廠家貢獻的驅動代碼，這樣做當然也是因為各廠家有自己的商業利益。)。因此，社區是一個生態系統，必須有陽光，有空氣，有水，有 鳥獸魚蟲，它才繁榮。

　　而不管社區在商業化上是否成功，每一個運營良好的社區其背后管理模式有趨同的傾向。這種模式應該說首先是在Linux Kernel中的應用起來的，我們不能不說Kernel首先使用這種以Git為核心的代碼開發流程非常符合實際情況，并且幫助Kernel在商業上取得了 巨大成功。

　　接下來我們再來看看github，為什么JBoss社區要幾乎把所有的項目都遷到github上面來呢?因為它的代碼管理流程非常貼合開源項目的金字塔結構。github要求使用Pull Request流程來提交代碼。這個流程有這樣幾個特點：

　　所有的開發人員不可以直接向項目庫提交代碼

　　所有的開發人員必須將項目fork到自己的空間，在自己fork的項目里面寫代碼

原文轉自：http://www.anti-gravitydesign.com