三代開源社群的協作模式

　　一、研發工具與研發模式

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

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

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

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

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

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

　　由於一切都是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、Facebook與Twitter這樣的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、Facebook 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極力鼓吹「禮物文化遠遠勝過交換經濟」，但是：「在一個龐大的社群，各種各樣的事務都需要有人去完成，而且還不能漫無章法。」

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

　　如何在社群裡平等、高效的協商？

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

　　結束語

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