在這篇文章中，我想分享一下我在參與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的項目里面寫代碼
所有的代碼必須以Patch的形式提交到大家共用的項目庫
所有提交的的Patch必須要由團隊核心成員審核后方可入庫(有的項目中，有這種權力的人只有一個。比如Linux Kernel，一些核心模塊，比如內存管理和進程調度，只有Linus本人有Patch合并權力)
比如我要給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等等。
