一、研發工具與研發模式
據說，人之區別於禽獸，最大的特徵在於利用，甚至發明工具。在沒有任何其他工具時，我們只能藉助於自己的肢體，一旦有了工具之後，我們的能力將會大大的增加。
但是，從另一個角度來看，工具也同時在限制我們的能力，甚至限制了我們的行為模式與思維模式。有一句俗話說得好：「手裡拿著錘子，看見什麼都像釘子。」
而在研發工具的領域，我們觀察到另外一些有趣的現象：因為軟體研發工具的開發者，同時也是工具的使用者。因此，他們不僅僅會受制於工具，也往往會由此被激發，開發出對自己而言更加趁手的工具。開發者與使用者身份合二為一的現象，使得研發工具的發展，簡直可以用「日新月異」、「層出不窮」甚至「爭奇鬥豔」來形容。
隨著軟體複雜性的不斷增加，以及軟體開發的參與者不斷增多，團隊協作的輔助軟體，也開始不斷增加，隨後我們發現：工具不僅僅限制了個人的行為模式，更進一步限制了團隊的協作模式。
軟體研發企業的管理者，往往會有某種錯覺，他們會認為：管理就是定下制度、流程與規範，然後「下面的人」就會照此執行。因為有人「聽話」，有人「不聽話」，所以才需要獎勵與懲罰的制度，來幫助管理者推行他的「規則」。所以，他們一般都很喜歡看《執行力》這樣的書。
在開源社區，事情變得有些不一樣。雖說開源社區也有「領導者」，甚至往往會有「精神領袖」，但他們並沒有暴力手段，也沒有經濟手段，甚至行政手段。因此，要協調一幫自由散漫的黑客，共同開發高質量的開源軟體，必須有更加高明的手段。
由於一切都是Open的，所以：不僅代碼人人可見，開源社區的協作模式，也暴露在眾目睽睽之下。從某種意義上來說：這促進了開源社區的協作工具的開發、進而使得開源的研發協作模式，以遠遠超過企業內部的演化速度飛速演化。
第一代開源協作模式，在早期幾乎沒有符合自身特殊需要的工具，有什麼用什麼，因此最為常用的email，被發展為Maillist，成為整個開發團隊的協作核心工具，大多數作業系統內置的diff/patch工具，使得代碼的交流以email patch為主。這些老牌的開源項目，從使用RCS、CVS，到了後來也開始逐步引入svn/git，bugzilla這樣的工具，但是圍繞mailing list開展協作的特徵，則持久不變。
一個開源社區，往往就是一個郵件列表，隨著軟體的日益複雜，社區的不斷擴大，郵件列表也會不斷分化，通常會劃分為：核心組、開發組、用戶組。開發組與用戶組的郵件列表，隨著軟體的架構分化為多個模塊，還會進一步分解。
在郵件列表裡，所有的用戶都是平等的，在無法用工具保障流程的情況下，社區逐漸發展出了一套嚴格的郵件禮儀和格式規範。不規範的郵件，不會被理睬；不禮貌的傢伙，甚至會被趕走。
郵件越來越多，即使分成多個郵件列表，依然太多。Archive這樣的郵件歸檔、查閱的工具，就必須得有了。一封郵件，大家都來回復，嚴格re:的標題，組成了一個可供追溯的線索。
在郵件列表裡，通常出現個人的名稱，加上Reported-By、Tested-By、Acked-By的標記，即是一種代表個人名義的認可，也是流程規範的一部分，更是計算各人貢獻的依據。
在郵件中，有一類話題是最活躍的，那就是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為代表的開源託管平臺免除了開源項目搭建自己的官方網站，管理工具，代碼倉庫之類的繁瑣事務，大大促進了開源項目的發展。不過，由於平臺的功能總是受限的，因此自建門戶，自組工具的開源項目依然層出不窮。
在第二代開源協作模式日漸成熟的過程中，另一股潮流也正方興未艾：「敏捷軟體開發」。其中，最為深入人心的概念之一，就是每個迭代，完成一批User Story。
在開源社區，這個概念被進一步演繹：無論是bug和feature，都被統稱為issue。這些issue，被分到不同的milestone（版本），即使最後有可能延期，milestone也會定義一個預期完成時間。
這是好事？還是壞事？其實很難評價，因為從開源的原始教義而言：所有的貢獻，都是自願、隨機、不可預期的。為自然生長的軟體，規定裡程碑，本來就顯得荒謬。但是，從另一方面而言，我們可以引用另一個中國人過馬路的例子：「不管紅綠燈，湊夠一堆人就過馬路」，開源軟體，往往也是「不管裡程碑，穩定一堆特性和bugfix，就發布一個版本」。
如果在開源軟體很少，更別提形成開源生態圈的情況下，這種隨意的做法還是可行的。但是在大量軟體，相互依賴的情況下，一個開源項目要贏得其他協作項目的信賴與協作，必須給出穩定的規劃，以便相互配合。
這種規範，也是被逼出來的。
雖然黑客們喜歡寫程序，但是要寫的程序實在太多了，能夠不重複造輪子，有現成的好工具可以直接拿來用，也是件好事。如果可以打開一個網站，註冊一個用戶，創建一個新的項目，剩下的事情自有平臺幫忙打理，那麼大家都可以愉快、專心的寫自己的代碼了。
平臺在逐步進化，因而能夠幫助開源項目，打理越來越多的事務。通常主流的開源項目託管平臺，都能夠完成：
更進一步的，還有能夠完成：簡單的自定義工作流、文件夾與靜態資源管理、輸出各種統計報表、甚至提供論壇、搜索、郵件列表以及各種排行榜等等。
在此之前，一個開源項目，是一個社區。到了大平臺的時代，整個平臺，構成了一個更大的社區。
到了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被發揚光大，可以說是優秀的繼承與創新。
在github，一鍵就能夠fork自己的分支，然後可以跟原有的分支毫無關聯，也可以非常方便的提交pull request，這就帶來了更加頻繁的分裂，使得分裂常態化了。
原來的開源社區，開發者修改了代碼，希望能夠貢獻給社區，需要穿越種種障礙，如果社區不接受，最後開發者只能逼不得已，自己開一個新的分支，變成一個新的項目。
在分裂是異常的狀態下，分裂是罪惡的，是不應該的，是會帶來陣痛的。當分裂變得常態化，pull request也變得常態化，分分合合，以每天N次的速度發生，恰恰因為如此，他不再是一種罪惡，而是一種健康的、向上的、以更快速度進步的模式。大家不再是在一個版本下，各自貢獻，而是在各自的版本下，獨立發展，想分就分，想合就合。
Pull request，從一個代碼合併的方式，變成了開發者之間主要的交流方式，他們發現，最好的交流，正是通過原始碼來交流，一切的講道理，都不如用原始碼來講道理。這恰恰是程式設計師們最習慣，也最喜歡的一種交流方式。
較之上一代的平臺，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帳號登錄，並使用一些有趣的服務。
這些擴展服務，極大的豐富了開源生態圈的內涵。
目前看來，git作為分布式配置庫的王者地位，已經不可動搖了。能夠初步總結的原因，至少有三個：
git與github互相促進，作為全球最大也最流行的開源社區，他的標配是git。這也導致越來越多的開源項目，選擇git作為標配
眾人拾材火焰高，越是參與開發的人不斷湧入，越是幫助git發展得更快。這是一個贏家通吃的世界
開源生態圈的出現，使得圍繞git、github發展出一大批相關的開源項目、開源工具以及次級社區。這一現象，在docker橫空出世之後，再一次得到展現。
開源社區，一直有非常悠久的CodeReview的歷史，哪怕在最早的mail & patch的時代，Review也是開源協作的頭等大事。僅僅梳理Review的歷程，也可以看到其中工具與流程的發展。
最初是郵件review，然後是在集成平臺上內置review功能，或者提供更強大的review插件。到github創新的提出pull request，則是一種更加方便有效的review模式。
與此同時，獨立於集成平臺的專門的code review工具，也開始發展起來：Review Board、Google Gerrit、Facebook Phabricator是其中重要的幾個代表。
在git逐步流行之後，大家發現基於git可以選擇的「玩法」實在是太多了。從最初寫下一行代碼，到最終出現在項目發布的版本之中，期間可以有無數的「路徑」。
在git-scm.com官方教程《ProGit》裡，提及了三種：集中式工作流、集成管理員工作流以及司令官與副官工作流。
在蔣鑫的《Git權威指南》裡，又提及基於TopGit、基於submodule、基於subtree、基於repo、基於gerrit、以及git與svn配合使用的不同工作模型。
再後來：GitFlow、Github的Pull Request、以及基於Github的Github Flow等等工作模式，堪稱百花齊放。
為什麼會出來這麼多workflow？因為團隊與項目的差別，實在太大了。現在到我們簡直無法想像：那些在各種情況下都堅持使用SVN都開發者，是怎麼熬過來的？
當然，從另一方面來說：選擇太多，也會帶來另一種煩惱...
從Everything as Code到Everything Automation，是另一個越來越明顯的趨勢。前兩天，我從機場出來，正好看到兩個並列的廣告牌，一個廣告的大意是：「UPS助您打通全球供應鏈」、另一個則是「中國銀行助您打通全球供應鏈」。這真的很有意思，看來在各行各業，大家都開始在關注整個生命周期的各個環節之間的打通。
只是，在軟體領域，我們會感覺到這是一種回歸。畢竟，最初的軟體開發，都是很簡單的。在一臺計算機上，自己寫程序，自己編譯，自己調試、運行，最後發布。既不用依賴他人，更不用等待什麼流程。
隨著項目越來越複雜，參與的人越來越多，我們的軟體，不能僅僅運行在自己的機器上，或者需要部署到伺服器上，或者需要發布到某種平臺上。在協作者眾多的情況下，如何分工合作？
在開發者水平參差不齊的情況下，如何保證質量？在分工、協作、流程與質量保證的要求之下，如何提高效率？
這些都是DevOps致力於解決的問題，也是DevOps不斷得以發展的原動力。
過去是如何？未來又會怎樣？想要回答這類問題，其實需要更加深入的思考：「開源社區的協作模式，為何會變？變化背後的邏輯是什麼？」
開源社區，與普通的軟體開發最大的不同，就是參與者多多益善。在《大教堂與集市》中，Eric Steven Raymond總結到：「如果開發者協調者有至少一個像Internet這樣好的溝通媒介，並且知道如何不靠強制來領導，那麼多人合作必然強於單兵作戰」，這簡直就是絕妙的預言。雖然當年的ESR也許並未預測到，基於Internet會出現那麼多輔助開源的相關工具（他們當時還只有郵件列表）。
所以，開源社區一直在致力於兩個看上去相反的目標：「吸引儘可能多的人，以儘可能簡單、便捷的方式，參與到開源中來」、「在人多得超乎想像的情況下，依然能夠保持，甚至不斷提高效率」。
開源社區，不會給參與者發工資，因此激勵是一個大問題。公平、公開、公正大計算所有參與者的貢獻，以所有人都能夠接受都形式，計算並公布各種排行榜，可以說是開源社區特有都「剛性需求」，因此SNS與開源社區的結合，成為必然。以後，面向開源協作的大數據分析，也一定會出現。
計算參與者的貢獻，僅僅是公平激勵的基礎。讓激勵變得有趣，變得有價值，變得有意義，則是吸引與回報參與者的不二法門。因此：遊戲化的思路，會被越來越多的引入到開源社區中來。
開源項目保障項目質量都最大利器，是引入數量眾多都熱心測試者。但是，僅僅有人願意測試，主動、積極都幫助測試，已經越來越不夠了。隨著項目越來越複雜，開源項目必須逐步走出僅僅依賴肉眼、依賴人多＋運氣的質量保障模式。
自動化測試、以及更加規範的Review流程，則是必然出現，而且將越來越重要的環節之一。
自由與規範，計劃與變化，興趣與責任。經常會在社區裡，成為爭論的熱點話題。雖然在《大教堂與集市》中，ESR極力鼓吹「禮物文化遠遠勝過交換經濟」，但是：「在一個龐大的社區，各種各樣的事務都需要有人去完成，而且還不能漫無章法。」
因此：「某種調節手段、協調者與協調機制、甚至是看不見的手」之類的東西，會慢慢的回到社區。
目前來說，依然只能是線上討論+線下開會。雖然，很多開源社區，開始學習《羅伯特議事規則》這樣的開會聖經。但是，開會依然是最令程式設計師感到苦惱的事情。在這方面，將來會不會出現更好的輔助工具，這方面很值得期待。
唯有變化，是不變的。開源協作模式，同樣如此。惟願我們，能夠成為推起其前進的力量之一。
稿源：Linuxer