三代開源社區的協作模式

一、研發工具與研發模式

據說，人之區別于禽獸，最大的特征在于利用，甚至發明工具。在沒有任何其他工具時，我們只能借助于自己的肢體，一旦有了工具之后，我們的能力將會大大的增加。

但是，從另一個角度來看，工具也同時在限制我們的能力，甚至限制了我們的行為模式與思維模式。有一句俗話說得好：「手里拿著錘子，看見什么都像釘子。」

而在研發工具的領域，我們觀察到另外一些有趣的現象：因為軟件研發工具的開發者，同時也是工具的使用者。因此，他們不僅僅會受制于工具，也往往會由 此被激發，開發出對自己而言更加趁手的工具。開發者與使用者身份合二為一的現象，使得研發工具的發展，簡直可以用「日新月異」、「層出不窮」甚至「爭奇斗 艷」來形容。

隨著軟件復雜性的不斷增加，以及軟件開發的參與者不斷增多，團隊協作的輔助軟件，也開始不斷增加，隨后我們發現：工具不僅僅限制了個人的行為模式，更進一步限制了團隊的協作模式。

軟件研發企業的管理者，往往會有某種錯覺，他們會認為：管理就是定下制度、流程與規范，然后「下面的人」就會照此執行。因為有人「聽話」，有人「不聽話」，所以才需要獎勵與懲罰的制度，來幫助管理者推行他的「規則」。所以，他們一般都很喜歡看《執行力》這樣的書。

在開源社區，事情變得有些不一樣。雖說開源社區也有「領導者」，甚至往往會有「精神領袖」，但他們并沒有暴力手段，也沒有經濟手段，甚至行政手段。因此，要協調一幫自由散漫的黑客，共同開發高質量的開源軟件，必須有更加高明的手段。

由于一切都是Open的，所以：不僅代碼人人可見，開源社區的協作模式，也暴露在眾目睽睽之下。從某種意義上來說：這促進了開源社區的協作工具的開發、進而使得開源的研發協作模式，以遠遠超過企業內部的演化速度飛速演化。

二、第一代開源協作模式

第一代開源協作模式，在早期幾乎沒有符合自身特殊需要的工具，有什么用什么，因此最為常用的email，被發展為Maillist，成為整個開發團 隊的協作核心工具，大多數操作系統內置的diff/patch工具，使得代碼的交流以email patch為主。這些老牌的開源項目，從使用RCS、CVS，到了后來也開始逐步引入svn/git，bugzilla這樣的工具，但是圍繞 mailing list開展協作的特征，則持久不變。

作為協作核心的Maillist

一個開源社區，往往就是一個郵件列表，隨著軟件的日益復雜，社區的不斷擴大，郵件列表也會不斷分化，通常會劃分為：核心組、開發組、用戶組。開發組與用戶組的郵件列表，隨著軟件的架構分化為多個模塊，還會進一步分解。

在郵件列表里，所有的用戶都是平等的，在無法用工具保障流程的情況下，社區逐漸發展出了一套嚴格的郵件禮儀和格式規范。不規范的郵件，不會被理睬；不禮貌的家伙，甚至會被趕走。

郵件越來越多，即使分成多個郵件列表，依然太多。Archive這樣的郵件歸檔、查閱的工具，就必須得有了。一封郵件，大家都來回復，嚴格re:的標題，組成了一個可供追溯的線索。

在郵件列表里，通常出現個人的名稱，加上Reported-By、Tested-By、Acked-By的標記，即是一種代表個人名義的認可，也是流程規范的一部分，更是計算各人貢獻的依據。

Bugzilla應運而生

在郵件中，有一類話題是最活躍的，那就是bug。但是，通過翻找郵件查閱bug的最新的解決狀況，是非常困難的。一個bug，從提出，到最終解決， 并被確認在哪一個版本中發布fix，是一種穩定的狀態轉化模式。一個專有的處理工具，勢必應運而生。Bugzilla、trac等一批工具，就由此被創造 出來了。

代碼提交流程的規范化

開源社區，表面上非常的崇尚民主自由，但實際上卻盛行精英主義、甚至是個人獨裁的。我們往往會給某個開源項目的創始人，冠以「仁慈的獨裁者」的頭銜。雖然，是否仁慈，大家不得而知，但獨裁確實是顯然的了。

最大的獨裁，是代碼的管理權。因為作為創始人與核心開發者，他們往往以一己之力，貢獻了絕大多數的代碼，確定了項目最初的架構與發展方向。他們不會容忍任何人隨意地向代碼庫提交代碼。

在郵件列表中，一個新來的家伙，從沒人認識，到能夠獨立的向代碼庫提交代碼，非得經歷艱辛的歷程不可。這樣的歷程，簡單的說，就是一次一次的 Code Review。被審核通過、合入代碼庫的patch越多，一個人對于社區的貢獻就越大，可信度也越高，身份地位也逐步提高，然后，他也就可以去 Review其他人的代碼了。

總結：在簡陋的工具條件下，發展出高效、嚴格的社區協作模式

三、第二代開源協作模式

第二代開源協作模式，有兩大特征：Web化、集成化。隨著Web技術的不斷成熟，開源社區也開始創造一個又一個的Web開源項目，其中Web化的項 目管理工具，如雨后春筍般冒了出來。在wikipedia上，issue-tracking systems列出了55個，project management software列出了152個，其中開源的也有30+，open-source software hosting列出了22個，堪稱蔚為壯觀。

這類平臺又可以分為兩大類：基于開源的項目管理工具或issue tracking工具，自建平臺，以JIRA、DotProject、Redmine為代表；基于免費開源托管平臺，以SourceForge、Google、LaunchPad為代表；

第二代的開源項目管理工具，可以說，主要是在向企業內的開發管理學習。文檔、流程、角色、權限、統計報表等等功能，都開始出現了。有些開源項目，也在用這些東西。

以SourceForge與Google Code為代表的開源托管平臺免除了開源項目搭建自己的官方網站，管理工具，代碼倉庫之類的繁瑣事務，大大促進了開源項目的發展。不過，由于平臺的功能總是受限的，因此自建門戶，自組工具的開源項目依然層出不窮。

issue & milestone

在第二代開源協作模式日漸成熟的過程中，另一股潮流也正方興未艾：「敏捷軟件開發」。其中，最為深入人心的概念之一，就是每個迭代，完成一批User Story。

在開源社區，這個概念被進一步演繹：無論是bug和feature，都被統稱為issue。這些issue，被分到不同的milestone（版本），即使最后有可能延期，milestone也會定義一個預期完成時間。

這是好事？還是壞事？其實很難評價，因為從開源的原始教義而言：所有的貢獻，都是自愿、隨機、不可預期的。為自然生長的軟件，規定里程碑，本來就顯 得荒謬。但是，從另一方面而言，我們可以引用另一個中國人過馬路的例子：「不管紅綠燈，湊夠一堆人就過馬路」，開源軟件，往往也是「不管里程碑，穩定一堆 特性和bugfix，就發布一個版本」。

如果在開源軟件很少，更別提形成開源生態圈的情況下，這種隨意的做法還是可行的。但是在大量軟件，相互依賴的情況下，一個開源項目要贏得其他協作項目的信賴與協作，必須給出穩定的規劃，以便相互配合。

這種規范，也是被逼出來的。

服務平臺化

雖然黑客們喜歡寫程序，但是要寫的程序實在太多了，能夠不重復造輪子，有現成的好工具可以直接拿來用，也是件好事。如果可以打開一個網站，注冊一個用戶，創建一個新的項目，剩下的事情自有平臺幫忙打理，那么大家都可以愉快、專心的寫自己的代碼了。

平臺在逐步進化，因而能夠幫助開源項目，打理越來越多的事務。通常主流的開源項目托管平臺，都能夠完成：

• 在線代碼瀏覽，并能夠支持不同的配置庫
• 需求管理、Bug管理，通常合并為Issue tracking
• 版本與里程碑管理
• 文檔編寫與管理，以Wiki的形式為主

更進一步的，還有能夠完成：簡單的自定義工作流、文件夾與靜態資源管理、輸出各種統計報表、甚至提供論壇、搜索、郵件列表以及各種排行榜等等。

在此之前，一個開源項目，是一個社區。到了大平臺的時代，整個平臺，構成了一個更大的社區。

總結：以Web形式提供的集成化開源項目托管平臺，標志著開源項目的協作模式，進入成熟期

四、第三代開源協作模式

到了MySpace、非死book與推ter這樣的SNS網站的興起，開源項目的協作模式，受到SNS的啟發，也隨之進入了第三代，以 Social Coding為核心的開發協作模式，這樣的模式在以Github為代表的網站上，體現的最為充分，眾多的模仿者也層出不窮。過去的開源項目與托管平臺，都 是以項目為中心來打造，而Github則是圍繞著參與開源的人來打造。首先滿足的不是項目的需求，而是個人的需求，由于對人的黏性大大增加，也使得 Github成為近年來最具吸引力的開發社區。

圍繞著Github，一大批周邊擴展服務被建立起來，構成了一個更加有活力的生態圈。而程序員們，不僅在Github上參與開源項目，更在Github上結交朋友，分享經驗，增進能力。甚至這樣的協作模式，還拓展到了編程領域之外，成為開放式協作的流行模式。

激勵機制

第三代開源協作模式，以Github為代表，以Social Coding為精髓，這一代模式想要解決的問題，是激勵機制的問題。

第一代開源協作，雖然創造了一批大大有名的項目，但事實上卻是一個非常小圈子的事業。即使是最為成功的Linux內核開發，也不過1000~2000人。一旦人多事雜，就會出現管理混亂的現象。

第二代開源協作，雖然借鑒了很多企業界的規范管理經驗，但是在事實上，卻是不適應開源軟件的風格的，舉一個例子：在Redmine中存在的角色、權限、工作流之類的東西，實際開源項目使用的，卻非常少。

第三代開源協作，借鑒了社交網絡中的各種數值化模型，關注者數量，Star數量，Fork數量，Issue數量，Pull Request數量，都在顯要位置標示出來，對于開發者形成正向激勵，還有很多的統計圖表，形象的展示了項目的活躍程度。

開源社區，原本就有非常深厚的，統計補丁數計算貢獻度的傳統，這一點在Github被發揚光大，可以說是優秀的繼承與創新。

基于fork/pull request的協作機制

在github，一鍵就能夠fork自己的分支，然后可以跟原有的分支毫無關聯，也可以非常方便的提交pull request，這就帶來了更加頻繁的分裂，使得分裂常態化了。

原來的開源社區，開發者修改了代碼，希望能夠貢獻給社區，需要穿越種種障礙，如果社區不接受，最后開發者只能逼不得已，自己開一個新的分支，變成一個新的項目。

在分裂是異常的狀態下，分裂是罪惡的，是不應該的，是會帶來陣痛的。當分裂變得常態化，pull request也變得常態化，分分合合，以每天N次的速度發生，恰恰因為如此，他不再是一種罪惡，而是一種健康的、向上的、以更快速度進步的模式。大家不 再是在一個版本下，各自貢獻，而是在各自的版本下，獨立發展，想分就分，想合就合。

Pull request，從一個代碼合并的方式，變成了開發者之間主要的交流方式，他們發現，最好的交流，正是通過源代碼來交流，一切的講道理，都不如用源代碼來講道理。這恰恰是程序員們最習慣，也最喜歡的一種交流方式。

圍繞Github出現的擴展服務

較之上一代的平臺，Github提供了優秀的開放擴展機制：OAuth、API、SDK、WebHooks、ServiceHooks等等，使得圍繞Github，擴展各種滿足項目特定需要的服務，變得非常容易。

這就是從上一代平臺的開源大社區，進化為「圍繞Github的開源生態圈」。

到目前為止，Github一共支持超過170個不同的擴展服務，其中較為熱門的服務有：

• 與其他項目管理工具集成（Bugzilla，Asana， Basecamp，Redmine，JIRA，ZohoProject）
• 與持續集成服務集成（Travis，Bamboo，CircleCI）
• 與消息通知服務集成（Amazon SNS，Email，IRC，Jabber）
• 與DevOps服務集成（AWS OpsWorks， DeployHQ）

Github 開放平臺與API，基于Github OAuth API，其他網站可以支持開發者用自己Github賬號登錄，并使用一些有趣的服務。

• Cloud IDE，用Github賬號登錄，直接在瀏覽器里打開一個IDE，編輯自己在Github上的開源代碼
• Resume Service，根據開發者在Github上的各種社交行為與開源項目貢獻度，自動生成格式化的簡歷

這些擴展服務，極大的豐富了開源生態圈的內涵。

總結：社區天生就應該是社交化的，Social Coding與開源社區，簡直就是天作之和。

五、開源協作模式的新探索

Git：作為標配

目前看來，git作為分布式配置庫的王者地位，已經不可動搖了。能夠初步總結的原因，至少有三個：

• git與github互相促進，作為全球最大也最流行的開源社區，他的標配是git。這也導致越來越多的開源項目，選擇git作為標配
• 眾人拾材火焰高，越是參與開發的人不斷涌入，越是幫助git發展得更快。這是一個贏家通吃的世界
• 開源生態圈的出現，使得圍繞git、github發展出一大批相關的開源項目、開源工具以及次級社區。這一現象，在docker橫空出世之后，再一次得到展現。

Code Review：必不可少

開源社區，一直有非常悠久的CodeReview的歷史，哪怕在最早的mail & patch的時代，Review也是開源協作的頭等大事。僅僅梳理Review的歷程，也可以看到其中工具與流程的發展。

最初是郵件review，然后是在集成平臺上內置review功能，或者提供更強大的review插件。到github創新的提出pull request，則是一種更加方便有效的review模式。

與此同時，獨立于集成平臺的專門的code review工具，也開始發展起來：Review Board、Google Gerrit、非死book Phabricator是其中重要的幾個代表。

Workflow：百花齊放

在git逐步流行之后，大家發現基于git可以選擇的「玩法」實在是太多了。從最初寫下一行代碼，到最終出現在項目發布的版本之中，期間可以有無數的「路徑」。

在git-scm.com官方教程《ProGit》里，提及了三種：集中式工作流、集成管理員工作流以及司令官與副官工作流。

在蔣鑫的《Git權威指南》里，又提及基于TopGit、基于submodule、基于subtree、基于repo、基于gerrit、以及git與svn配合使用的不同工作模型。

再后來：GitFlow、Github的Pull Request、以及基于Github的Github Flow等等工作模式，堪稱百花齊放。

為什么會出來這么多workflow？因為團隊與項目的差別，實在太大了。現在到我們簡直無法想象：那些在各種情況下都堅持使用SVN都開發者，是怎么熬過來的？

當然，從另一方面來說：選擇太多，也會帶來另一種煩惱...

CI、CD、DevOps

從Everything as Code到Everything Automation，是另一個越來越明顯的趨勢。前兩天，我從機場出來，正好看到兩個并列的廣告牌，一個廣告的大意是：「UPS助您打通全球供應鏈」、 另一個則是「中國銀行助您打通全球供應鏈」。這真的很有意思，看來在各行各業，大家都開始在關注整個生命周期的各個環節之間的打通。

只是，在軟件領域，我們會感覺到這是一種回歸。畢竟，最初的軟件開發，都是很簡單的。在一臺計算機上，自己寫程序，自己編譯，自己調試、運行，最后發布。既不用依賴他人，更不用等待什么流程。

隨著項目越來越復雜，參與的人越來越多，我們的軟件，不能僅僅運行在自己的機器上，或者需要部署到服務器上，或者需要發布到某種平臺上。在協作者眾多的情況下，如何分工合作？
在開發者水平參差不齊的情況下，如何保證質量？在分工、協作、流程與質量保證的要求之下，如何提高效率？

這些都是DevOps致力于解決的問題，也是DevOps不斷得以發展的原動力。

總結：開源社區，始終在進步，Github代表的也只是「一代」而已，新的一代協作模式，還會被創造出來的。

六、暗線：工具、習俗背后的邏輯

過去是如何？未來又會怎樣？想要回答這類問題，其實需要更加深入的思考：「開源社區的協作模式，為何會變？變化背后的邏輯是什么？」

開源社區研發工具的兩大目標：降低門檻，提高效率

開源社區，與普通的軟件開發最大的不同，就是參與者多多益善。在《大教堂與集市》中，Eric Steven Raymond總結到：「如果開發者協調者有至少一個像Internet這樣好的溝通媒介，并且知道如何不靠強制來領導，那么多人合作必然強于單兵作 戰」，這簡直就是絕妙的預言。雖然當年的ESR也許并未預測到，基于Internet會出現那么多輔助開源的相關工具（他們當時還只有郵件列表）。

所以，開源社區一直在致力于兩個看上去相反的目標：「吸引盡可能多的人，以盡可能簡單、便捷的方式，參與到開源中來」、「在人多得超乎想象的情況下，依然能夠保持，甚至不斷提高效率」。

如何計算參與者的貢獻？

開源社區，不會給參與者發工資，因此激勵是一個大問題。公平、公開、公正大計算所有參與者的貢獻，以所有人都能夠接受都形式，計算并公布各種排行 榜，可以說是開源社區特有都「剛性需求」，因此SNS與開源社區的結合，成為必然。以后，面向開源協作的大數據分析，也一定會出現。

如何激勵、吸引、回報參與者？

計算參與者的貢獻，僅僅是公平激勵的基礎。讓激勵變得有趣，變得有價值，變得有意義，則是吸引與回報參與者的不二法門。因此：游戲化的思路，會被越來越多的引入到開源社區中來。

如何保障項目質量？

開源項目保障項目質量都最大利器，是引入數量眾多都熱心測試者。但是，僅僅有人愿意測試，主動、積極都幫助測試，已經越來越不夠了。隨著項目越來越復雜，開源項目必須逐步走出僅僅依賴肉眼、依賴人多＋運氣的質量保障模式。

自動化測試、以及更加規范的Review流程，則是必然出現，而且將越來越重要的環節之一。

如何協調一致的工作？

自由與規范，計劃與變化，興趣與責任。經常會在社區里，成為爭論的熱點話題。雖然在《大教堂與集市》中，ESR極力鼓吹「禮物文化遠遠勝過交換經濟」，但是：「在一個龐大的社區，各種各樣的事務都需要有人去完成，而且還不能漫無章法。」

因此：「某種調節手段、協調者與協調機制、甚至是看不見的手」之類的東西，會慢慢的回到社區。

如何在社區里平等、高效的協商？

目前來說，依然只能是線上討論+線下開會。雖然，很多開源社區，開始學習《羅伯特議事規則》這樣的開會圣經。但是，開會依然是最令程序員感到苦惱的事情。在這方面，將來會不會出現更好的輔助工具，這方面很值得期待。

結束語

唯有變化，是不變的。開源協作模式，同樣如此。惟愿我們，能夠成為推起其前進的力量之一。

來自：http://www.jianshu.com/p/e6ecafe6c740