出品|開源中國

作者|莊表偉

【編者按】

2016 年，莊表偉撰寫了《三代開源社群的協作模式》一文，總結了開源協作模式經歷的三個階段：圍繞郵件列表階段、基於 All In One 平臺階段、基於社交化程式設計階段。今日重讀此文，仍然頗有收穫。莊表偉認為，六年時間過去，開源社群沒有出現明顯的革命性的變化，不過也有一些尚不明顯的趨勢，或者說重大挑戰出現。今將原文及近年來作者觀察皆呈現於此，以饗讀者。

作者：莊表偉，開源社理事、華為開源管理中心開源專家。常年混跡於技術社群與開源社群，著有《開源思索集》一書。

莊表偉

一、研發工具與研發模式

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

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

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

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

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

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

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

二、第一代開源協作模式

第一代開源協作模式，在早期幾乎沒有符合自身特殊需要的工具，有什麼用什麼，因此最為常用的 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 為代表；基於免費開源託管平臺，以 SourceF

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

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

（七）如何在社群裡平等、高效地協商？

目前來說，依然只能是“線上討論+線下開會”。雖然很多開源社群，開始學習《羅伯特議事規則》這樣的開會聖經。但是，開會依然是最令程式設計師感到苦惱。

的事情。在這方面，將來會不會出現更好的輔助工具，這方面很值得期待。

七、新趨勢隱隱出現（2022年增補）

（一）開源供應鏈安全，越來越被重視

隨著近年來頻頻出現的重大開源漏洞（Tomcat、FastJson、log4j…）、重大開源投毒事件、刪庫跑路事件等等，使得整個社群開始越來越重視

供應鏈安全

的問題。

如何將各個利益相關方團結起來？如何在技術層面、工具層面、責任與利益層面有所改進？思考並解決這些問題，可能會匯出一些革命性的協作模式。

（二）智慧輔助開發，帶來的挑戰

最近的一個新聞相當引人關注，GitHub Copilot 開始正式收費。

SFC 發起號召，要大家放棄 GitHub

。

但是，大趨勢是不可阻擋的。透過越來越多的開原始碼訓練，我們能夠得到更好的助手—— AI 幫助我們寫程式碼。在這個過程中，需要處理各種授權、版權、專利、收益分配，甚至道德評價等問題。思考並解決這些問題，可能會匯出一些革命性的協作模式。

（三）如何阻止開源世界的分裂？

開源從誕生之初，就是懷抱著天下一家，世界大同的理想。我們一直無法想象，或者說無法接受——開源世界可能會分裂為互不相通的幾個部分——這樣的未來。

假設世界真的分裂了，開源世界是否能夠不被分裂？從政治上、從社群協作機制上、從技術上是否能夠做些什麼？思考並解決這些問題，可能會匯出一些革命性的協作模式。

結語：作為身在此山中的開源圈內人士，我必須承認，我目前還沒有非常清晰、明白的方向與答案。只能期望有更多的朋友，一起來探索開源協作的未來！