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

　　所有的代碼必須以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等等。

　　這些可能和別的項目沒什么區別，但AS7的質控流程不只自動化到這種程度，它在所有的“連接環節”也是自動化的。這些環節包括：

　　Github中有Patch提交過來時，自動執行項目測試。

　　Jira中的Bug報告與Github中的Patch相關聯。

　　有了這兩點，則從代碼提交，到測試，到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

　　因此，社區的管理并不是想象中的那么“松散”。相反，社區的組織模式對管理提出了更高要求。而這些協作工具的發展，正是多年成功項目管理的經驗模型。希望通過這篇文章能幫助大家對開源社區的工作有更多的了解。

　　國內開源社區產品到現在也有七八個年頭了，過去的開源社區產品比較單一，我們叫作傳統論壇社區，其核心就是單一的論壇產品。站長們用論壇產品做社區也有很長時間了，開源論壇產品經歷這些年頭的風風雨雨，也服務了很多企業和個人站長。

　　當互聯網在中國的不斷發展，互聯網概念在中國網民心中不斷變化，很多模式也經歷了出現、繁榮、沒落的過程。從web1.0到web2.0時代的演化，甚至有人開始提web3.0的概念;從文本、bbs、blog、cms、podcast到近年熱門的電子商務、sns、miniblog等等，不同概念不同模式都承載了不同時代互聯網的特征和需求。

　　有很多模式在中國互聯網發展的潮流中倒下了，如單一的blog模式，因為找不到更好的盈利模式，國內有幾家當年極為流行blog托管站點都萎靡不振;有些模式在這個潮流中被融合和混搭了，如sns，08年紅紅火火，但因為用戶門檻高，燒錢厲害，這種模式逐漸被混搭到其他站點上來增加用戶黏度，成了站點的一個標準配置。傳統論壇社區在經歷這些年互聯網的變遷，單一的論壇社區產品再也不能更好的承載信息和價值。新社區成了很多站長共同的需求，產品的mash up(混搭)也成了開源社區的企業必須要做的事情，此時，開源社區產品多模式化的概念由此誕生。

　　如何滿足不同的站長在新時期互聯網的大環境大市場下能更好的運營，更好的去承載信息和價值，是開源社區需要思考的。

　　社區產品多模式化，真正實現mash up(混搭)!

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