開源社區到底是怎樣形成的？開源項目是怎麼管理的？
在這篇文章中，我想分享一下我在參與AS7開發過程中用到的管理工具及協作流程，並談一些對開源社區的理解。
AS7的開發流程主要涉及這樣一些核心工具：
聽起來和普遍的項目管理流程沒什麼太大區別：幾乎所有的項目都會有一個代碼倉庫，有一個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流程來提交代碼。這個流程有這樣幾個特點：
比如我要給RESTEasy項目交代碼：
https://github.com/resteasy/Resteasy
首先我要將項目fork到自己的空間：
https://github.com/liweinan/Resteasy
然後clone出來做修改，將修改提交進自己的代碼庫，並將修改內容生成Patch交由Bill Burke審核：
https://github.com/resteasy/Resteasy/pull/35
可以看到，把代碼庫遷到Github，不光是改變一個代碼庫管理工具這樣簡單，隨之而來的是整個流程管理的一種改變。圍繞著Git的這種代碼管理流 程，是Linux Kernel社區長久以來一直使用的模式，是社區管理成功經驗的直接沿用。有關github的Pull Request，可以參考：
http://help.github.com/pull-requests/
接下來我們談談質控：在JBoss AS7這個項目中，測試過程基本上是全自動化的，所有的測試最終必須形成單元測試代碼，用到的技術也非常豐富，包括：JUnit，Arquillian, Selenium等等。
這些可能和別的項目沒什麼區別，但AS7的質控流程不只自動化到這種程度，它在所有的“連接環節”也是自動化的。這些環節包括：
有了這兩點，則從代碼提交，到測試，到Bug跟蹤記錄的過程便全聯系在一起了，中間環節不需人工干預。
看下Github與項目測試之間的連接，具體看下AS7的這個Patch提交請求：
https://github.com/jbossas/jboss-as/pull/1676
注意到這兩條日志：
可以看到在github中有jboss-as-pull-request這個用戶將這個Patch與AS7的Jenkins測試服務器中的代碼進行了合並，並觸發執行了測試工作：
http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-param-pull/
jboss-as-pull-request這個用戶實際上是機器人，用於定時查找提交給AS7的Patch，執行合並測試工作並最終給出測試結 果。上面的地址是AS7的Jenkins測試服務器所在位置，僅能從github上面看到鏈接但無法從外網訪問。因此我將服務器的運行情況截圖如下：
有關Jenkins的使用方法，本文不准備展開講解，有興趣可看此篇文章： 《基於Jenkins的持續集成》
接下來我們看看github上面的代碼流程是如何和Jira結合在一起的。試著打開一個AS7的Bug Report看看：
https://issues.jboss.org/browse/AS7-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:changehistory-tabpanel#issue-tabs
看到有這樣一欄：
Github的Pull Reqest與Bug Report連系在了一起。這是通過JIRA與Github之間的插件完成的。下面是JIRA與Github之間相聯系的流程，在Jira中進行了定制實現：
通過Jira中的Link Pull Request，將代碼與Bug管理聯系在了一起。
除了與代碼相關的內容，社區必備的組成部分還應有文檔，論壇，及郵件列表。還是以JBoss社區為例，JBoss的文檔位於：
http://community.jboss.org/wiki
及：
http://docs.jboss.org/
都有專門的文檔團隊在維護，團隊規模並不小。接下來是論壇：
https://community.jboss.org/index.jspa
郵件列表也是社區常用的溝通工具：
https://lists.jboss.org/mailman/listinfo
因此，社區的管理並不是想象中的那麼“松散”。相反，社區的組織模式對管理提出了更高要求。而這些協作工具的發展，正是多年成功項目管理的經驗模型。希望通過這篇文章能幫助大家對開源社區的工作有更多的了解。