一、研發(fā)工具與研發(fā)模式

據(jù)說(shuō)，人之區(qū)別于禽獸，最大的特征在于利用，甚至發(fā)明工具。在沒(méi)有任何其他工具時(shí)，我們只能借助于自己的肢體，一旦有了工具之后，我們的能力將會(huì)大大的增加。

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

而在研發(fā)工具的領(lǐng)域，我們觀察到另外一些有趣的現(xiàn)象：因?yàn)檐浖邪l(fā)工具的開(kāi)發(fā)者，同時(shí)也是工具的使用者。因此，他們不僅僅會(huì)受制于工具，也往往會(huì)由此被激發(fā)，開(kāi)發(fā)出對(duì)自己而言更加趁手的工具。開(kāi)發(fā)者與使用者身份合二為一的現(xiàn)象，使得研發(fā)工具的發(fā)展，簡(jiǎn)直可以用「日新月異」、「層出不窮」甚至「爭(zhēng)奇斗艷」來(lái)形容。

隨著軟件復(fù)雜性的不斷增加，以及軟件開(kāi)發(fā)的參與者不斷增多，團(tuán)隊(duì)協(xié)作的輔助軟件，也開(kāi)始不斷增加，隨后我們發(fā)現(xiàn)：工具不僅僅限制了個(gè)人的行為模式，更進(jìn)一步限制了團(tuán)隊(duì)的協(xié)作模式。

軟件研發(fā)企業(yè)的管理者，往往會(huì)有某種錯(cuò)覺(jué)，他們會(huì)認(rèn)為：管理就是定下制度、流程與規(guī)范，然后「下面的人」就會(huì)照此執(zhí)行。因?yàn)橛腥恕嘎?tīng)話」，有人「不聽(tīng)話」，所以才需要獎(jiǎng)勵(lì)與懲罰的制度，來(lái)幫助管理者推行他的「規(guī)則」。所以，他們一般都很喜歡看《執(zhí)行力》這樣的書(shū)。

在開(kāi)源社區(qū)，事情變得有些不一樣。雖說(shuō)開(kāi)源社區(qū)也有「領(lǐng)導(dǎo)者」，甚至往往會(huì)有「精神領(lǐng)袖」，但他們并沒(méi)有暴力手段，也沒(méi)有經(jīng)濟(jì)手段，甚至行政手段。因此，要協(xié)調(diào)一幫自由散漫的黑客，共同開(kāi)發(fā)高質(zhì)量的開(kāi)源軟件，必須有更加高明的手段。

由于一切都是Open的，所以：不僅代碼人人可見(jiàn)，開(kāi)源社區(qū)的協(xié)作模式，也暴露在眾目睽睽之下。從某種意義上來(lái)說(shuō)：這促進(jìn)了開(kāi)源社區(qū)的協(xié)作工具的開(kāi)發(fā)、進(jìn)而使得開(kāi)源的研發(fā)協(xié)作模式，以遠(yuǎn)遠(yuǎn)超過(guò)企業(yè)內(nèi)部的演化速度飛速演化。

二、第一代開(kāi)源協(xié)作模式

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

作為協(xié)作核心的Maillist

一個(gè)開(kāi)源社區(qū)，往往就是一個(gè)郵件列表，隨著軟件的日益復(fù)雜，社區(qū)的不斷擴(kuò)大，郵件列表也會(huì)不斷分化，通常會(huì)劃分為：核心組、開(kāi)發(fā)組、用戶組。開(kāi)發(fā)組與用戶組的郵件列表，隨著軟件的架構(gòu)分化為多個(gè)模塊，還會(huì)進(jìn)一步分解。

在郵件列表里，所有的用戶都是平等的，在無(wú)法用工具保障流程的情況下，社區(qū)逐漸發(fā)展出了一套嚴(yán)格的郵件禮儀和格式規(guī)范。不規(guī)范的郵件，不會(huì)被理睬；不禮貌的家伙，甚至?xí)悔s走。

郵件越來(lái)越多，即使分成多個(gè)郵件列表，依然太多。Archive這樣的郵件歸檔、查閱的工具，就必須得有了。一封郵件，大家都來(lái)回復(fù)，嚴(yán)格re:的標(biāo)題，組成了一個(gè)可供追溯的線索。

在郵件列表里，通常出現(xiàn)個(gè)人的名稱，加上Reported-By、Tested-By、Acked-By的標(biāo)記，即是一種代表個(gè)人名義的認(rèn)可，也是流程規(guī)范的一部分，更是計(jì)算各人貢獻(xiàn)的依據(jù)。

Bugzilla應(yīng)運(yùn)而生

在郵件中，有一類話題是最活躍的，那就是bug。但是，通過(guò)翻找郵件查閱bug的最新的解決狀況，是非常困難的。一個(gè)bug，從提出，到最終解決，并被確認(rèn)在哪一個(gè)版本中發(fā)布fix，是一種穩(wěn)定的狀態(tài)轉(zhuǎn)化模式。一個(gè)專有的處理工具，勢(shì)必應(yīng)運(yùn)而生。Bugzilla、trac等一批工具，就由此被創(chuàng)造出來(lái)了。

代碼提交流程的規(guī)范化

開(kāi)源社區(qū)，表面上非常的崇尚民主自由，但實(shí)際上卻盛行精英主義、甚至是個(gè)人獨(dú)裁的。我們往往會(huì)給某個(gè)開(kāi)源項(xiàng)目的創(chuàng)始人，冠以「仁慈的獨(dú)裁者」的頭銜。雖然，是否仁慈，大家不得而知，但獨(dú)裁確實(shí)是顯然的了。

最大的獨(dú)裁，是代碼的管理權(quán)。因?yàn)樽鳛閯?chuàng)始人與核心開(kāi)發(fā)者，他們往往以一己之力，貢獻(xiàn)了絕大多數(shù)的代碼，確定了項(xiàng)目最初的架構(gòu)與發(fā)展方向。他們不會(huì)容忍任何人隨意地向代碼庫(kù)提交代碼。

在郵件列表中，一個(gè)新來(lái)的家伙，從沒(méi)人認(rèn)識(shí)，到能夠獨(dú)立的向代碼庫(kù)提交代碼，非得經(jīng)歷艱辛的歷程不可。這樣的歷程，簡(jiǎn)單的說(shuō)，就是一次一次的Code Review。被審核通過(guò)、合入代碼庫(kù)的patch越多，一個(gè)人對(duì)于社區(qū)的貢獻(xiàn)就越大，可信度也越高，身份地位也逐步提高，然后，他也就可以去Review其他人的代碼了。

總結(jié)：在簡(jiǎn)陋的工具條件下，發(fā)展出高效、嚴(yán)格的社區(qū)協(xié)作模式

三、第二代開(kāi)源協(xié)作模式

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

這類平臺(tái)又可以分為兩大類：基于開(kāi)源的項(xiàng)目管理工具或issue tracking工具，自建平臺(tái)，以JIRA、DotProject、Redmine為代表；基于免費(fèi)開(kāi)源托管平臺(tái)，以SourceForge、Google、LaunchPad為代表；

第二代的開(kāi)源項(xiàng)目管理工具，可以說(shuō)，主要是在向企業(yè)內(nèi)的開(kāi)發(fā)管理學(xué)習(xí)。文檔、流程、角色、權(quán)限、統(tǒng)計(jì)報(bào)表等等功能，都開(kāi)始出現(xiàn)了。有些開(kāi)源項(xiàng)目，也在用這些東西。

以SourceForge與Google Code為代表的開(kāi)源托管平臺(tái)免除了開(kāi)源項(xiàng)目搭建自己的官方網(wǎng)站，管理工具，代碼倉(cāng)庫(kù)之類的繁瑣事務(wù)，大大促進(jìn)了開(kāi)源項(xiàng)目的發(fā)展。不過(guò)，由于平臺(tái)的功能總是受限的，因此自建門(mén)戶，自組工具的開(kāi)源項(xiàng)目依然層出不窮。

issue & milestone

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

在開(kāi)源社區(qū)，這個(gè)概念被進(jìn)一步演繹：無(wú)論是bug和feature，都被統(tǒng)稱為issue。這些issue，被分到不同的milestone（版本），即使最后有可能延期，milestone也會(huì)定義一個(gè)預(yù)期完成時(shí)間。

這是好事？還是壞事？其實(shí)很難評(píng)價(jià)，因?yàn)閺拈_(kāi)源的原始教義而言：所有的貢獻(xiàn)，都是自愿、隨機(jī)、不可預(yù)期的。為自然生長(zhǎng)的軟件，規(guī)定里程碑，本來(lái)就顯得荒謬。但是，從另一方面而言，我們可以引用另一個(gè)中國(guó)人過(guò)馬路的例子：「不管紅綠燈，湊夠一堆人就過(guò)馬路」，開(kāi)源軟件，往往也是「不管里程碑，穩(wěn)定一堆特性和bugfix，就發(fā)布一個(gè)版本」。

如果在開(kāi)源軟件很少，更別提形成開(kāi)源生態(tài)圈的情況下，這種隨意的做法還是可行的。但是在大量軟件，相互依賴的情況下，一個(gè)開(kāi)源項(xiàng)目要贏得其他協(xié)作項(xiàng)目的信賴與協(xié)作，必須給出穩(wěn)定的規(guī)劃，以便相互配合。

這種規(guī)范，也是被逼出來(lái)的。

服務(wù)平臺(tái)化

雖然黑客們喜歡寫(xiě)程序，但是要寫(xiě)的程序?qū)嵲谔嗔?，能夠不重?fù)造輪子，有現(xiàn)成的好工具可以直接拿來(lái)用，也是件好事。如果可以打開(kāi)一個(gè)網(wǎng)站，注冊(cè)一個(gè)用戶，創(chuàng)建一個(gè)新的項(xiàng)目，剩下的事情自有平臺(tái)幫忙打理，那么大家都可以愉快、專心的寫(xiě)自己的代碼了。

平臺(tái)在逐步進(jìn)化，因而能夠幫助開(kāi)源項(xiàng)目，打理越來(lái)越多的事務(wù)。通常主流的開(kāi)源項(xiàng)目托管平臺(tái)，都能夠完成：

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

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

在此之前，一個(gè)開(kāi)源項(xiàng)目，是一個(gè)社區(qū)。到了大平臺(tái)的時(shí)代，整個(gè)平臺(tái)，構(gòu)成了一個(gè)更大的社區(qū)。

總結(jié)：以Web形式提供的集成化開(kāi)源項(xiàng)目托管平臺(tái)，標(biāo)志著開(kāi)源項(xiàng)目的協(xié)作模式，進(jìn)入成熟期

四、第三代開(kāi)源協(xié)作模式

到了MySpace、Facebook與Twitter這樣的SNS網(wǎng)站的興起，開(kāi)源項(xiàng)目的協(xié)作模式，受到SNS的啟發(fā)，也隨之進(jìn)入了第三代，以Social Coding為核心的開(kāi)發(fā)協(xié)作模式，這樣的模式在以Github為代表的網(wǎng)站上，體現(xiàn)的最為充分，眾多的模仿者也層出不窮。過(guò)去的開(kāi)源項(xiàng)目與托管平臺(tái)，都是以項(xiàng)目為中心來(lái)打造，而Github則是圍繞著參與開(kāi)源的人來(lái)打造。首先滿足的不是項(xiàng)目的需求，而是個(gè)人的需求，由于對(duì)人的黏性大大增加，也使得Github成為近年來(lái)最具吸引力的開(kāi)發(fā)社區(qū)。

圍繞著Github，一大批周邊擴(kuò)展服務(wù)被建立起來(lái)，構(gòu)成了一個(gè)更加有活力的生態(tài)圈。而程序員們，不僅在Github上參與開(kāi)源項(xiàng)目，更在Github上結(jié)交朋友，分享經(jīng)驗(yàn)，增進(jìn)能力。甚至這樣的協(xié)作模式，還拓展到了編程領(lǐng)域之外，成為開(kāi)放式協(xié)作的流行模式。

激勵(lì)機(jī)制

第三代開(kāi)源協(xié)作模式，以Github為代表，以Social Coding為精髓，這一代模式想要解決的問(wèn)題，是激勵(lì)機(jī)制的問(wèn)題。

第一代開(kāi)源協(xié)作，雖然創(chuàng)造了一批大大有名的項(xiàng)目，但事實(shí)上卻是一個(gè)非常小圈子的事業(yè)。即使是最為成功的Linux內(nèi)核開(kāi)發(fā)，也不過(guò)1000~2000人。一旦人多事雜，就會(huì)出現(xiàn)管理混亂的現(xiàn)象。

第二代開(kāi)源協(xié)作，雖然借鑒了很多企業(yè)界的規(guī)范管理經(jīng)驗(yàn)，但是在事實(shí)上，卻是不適應(yīng)開(kāi)源軟件的風(fēng)格的，舉一個(gè)例子：在Redmine中存在的角色、權(quán)限、工作流之類的東西，實(shí)際開(kāi)源項(xiàng)目使用的，卻非常少。

第三代開(kāi)源協(xié)作，借鑒了社交網(wǎng)絡(luò)中的各種數(shù)值化模型，關(guān)注者數(shù)量，Star數(shù)量，F(xiàn)ork數(shù)量，Issue數(shù)量，Pull Request數(shù)量，都在顯要位置標(biāo)示出來(lái)，對(duì)于開(kāi)發(fā)者形成正向激勵(lì)，還有很多的統(tǒng)計(jì)圖表，形象的展示了項(xiàng)目的活躍程度。

開(kāi)源社區(qū)，原本就有非常深厚的，統(tǒng)計(jì)補(bǔ)丁數(shù)計(jì)算貢獻(xiàn)度的傳統(tǒng)，這一點(diǎn)在Github被發(fā)揚(yáng)光大，可以說(shuō)是優(yōu)秀的繼承與創(chuàng)新。

基于fork/pull request的協(xié)作機(jī)制

在github，一鍵就能夠fork自己的分支，然后可以跟原有的分支毫無(wú)關(guān)聯(lián)，也可以非常方便的提交pull request，這就帶來(lái)了更加頻繁的分裂，使得分裂常態(tài)化了。

原來(lái)的開(kāi)源社區(qū)，開(kāi)發(fā)者修改了代碼，希望能夠貢獻(xiàn)給社區(qū)，需要穿越種種障礙，如果社區(qū)不接受，最后開(kāi)發(fā)者只能逼不得已，自己開(kāi)一個(gè)新的分支，變成一個(gè)新的項(xiàng)目。

在分裂是異常的狀態(tài)下，分裂是罪惡的，是不應(yīng)該的，是會(huì)帶來(lái)陣痛的。當(dāng)分裂變得常態(tài)化，pull request也變得常態(tài)化，分分合合，以每天N次的速度發(fā)生，恰恰因?yàn)槿绱?，他不再是一種罪惡，而是一種健康的、向上的、以更快速度進(jìn)步的模式。大家不再是在一個(gè)版本下，各自貢獻(xiàn)，而是在各自的版本下，獨(dú)立發(fā)展，想分就分，想合就合。

Pull request，從一個(gè)代碼合并的方式，變成了開(kāi)發(fā)者之間主要的交流方式，他們發(fā)現(xiàn)，最好的交流，正是通過(guò)源代碼來(lái)交流，一切的講道理，都不如用源代碼來(lái)講道理。這恰恰是程序員們最習(xí)慣，也最喜歡的一種交流方式。

圍繞Github出現(xiàn)的擴(kuò)展服務(wù)

較之上一代的平臺(tái)，Github提供了優(yōu)秀的開(kāi)放擴(kuò)展機(jī)制：OAuth、API、SDK、WebHooks、ServiceHooks等等，使得圍繞Github，擴(kuò)展各種滿足項(xiàng)目特定需要的服務(wù)，變得非常容易。

這就是從上一代平臺(tái)的開(kāi)源大社區(qū)，進(jìn)化為「圍繞Github的開(kāi)源生態(tài)圈」。

到目前為止，Github一共支持超過(guò)170個(gè)不同的擴(kuò)展服務(wù)，其中較為熱門(mén)的服務(wù)有：

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

Github 開(kāi)放平臺(tái)與API，基于Github OAuth API，其他網(wǎng)站可以支持開(kāi)發(fā)者用自己Github賬號(hào)登錄，并使用一些有趣的服務(wù)。

• Cloud IDE，用Github賬號(hào)登錄，直接在瀏覽器里打開(kāi)一個(gè)IDE，編輯自己在Github上的開(kāi)源代碼
• Resume Service，根據(jù)開(kāi)發(fā)者在Github上的各種社交行為與開(kāi)源項(xiàng)目貢獻(xiàn)度，自動(dòng)生成格式化的簡(jiǎn)歷

這些擴(kuò)展服務(wù)，極大的豐富了開(kāi)源生態(tài)圈的內(nèi)涵。

總結(jié)：社區(qū)天生就應(yīng)該是社交化的，Social Coding與開(kāi)源社區(qū)，簡(jiǎn)直就是天作之和。

五、開(kāi)源協(xié)作模式的新探索

Git：作為標(biāo)配

目前看來(lái)，git作為分布式配置庫(kù)的王者地位，已經(jīng)不可動(dòng)搖了。能夠初步總結(jié)的原因，至少有三個(gè)：

• git與github互相促進(jìn)，作為全球最大也最流行的開(kāi)源社區(qū)，他的標(biāo)配是git。這也導(dǎo)致越來(lái)越多的開(kāi)源項(xiàng)目，選擇git作為標(biāo)配
• 眾人拾材火焰高，越是參與開(kāi)發(fā)的人不斷涌入，越是幫助git發(fā)展得更快。這是一個(gè)贏家通吃的世界
• 開(kāi)源生態(tài)圈的出現(xiàn)，使得圍繞git、github發(fā)展出一大批相關(guān)的開(kāi)源項(xiàng)目、開(kāi)源工具以及次級(jí)社區(qū)。這一現(xiàn)象，在docker橫空出世之后，再一次得到展現(xiàn)。

Code Review：必不可少

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

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

與此同時(shí)，獨(dú)立于集成平臺(tái)的專門(mén)的code review工具，也開(kāi)始發(fā)展起來(lái)：Review Board、Google Gerrit、Facebook Phabricator是其中重要的幾個(gè)代表。

Workflow：百花齊放

在git逐步流行之后，大家發(fā)現(xiàn)基于git可以選擇的「玩法」實(shí)在是太多了。從最初寫(xiě)下一行代碼，到最終出現(xiàn)在項(xiàng)目發(fā)布的版本之中，期間可以有無(wú)數(shù)的「路徑」。

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

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

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

為什么會(huì)出來(lái)這么多workflow？因?yàn)閳F(tuán)隊(duì)與項(xiàng)目的差別，實(shí)在太大了?，F(xiàn)在到我們簡(jiǎn)直無(wú)法想象：那些在各種情況下都堅(jiān)持使用SVN都開(kāi)發(fā)者，是怎么熬過(guò)來(lái)的？

當(dāng)然，從另一方面來(lái)說(shuō)：選擇太多，也會(huì)帶來(lái)另一種煩惱...

CI、CD、DevOps

從Everything as Code到Everything Automation，是另一個(gè)越來(lái)越明顯的趨勢(shì)。前兩天，我從機(jī)場(chǎng)出來(lái)，正好看到兩個(gè)并列的廣告牌，一個(gè)廣告的大意是：「UPS助您打通全球供應(yīng)鏈」、另一個(gè)則是「中國(guó)銀行助您打通全球供應(yīng)鏈」。這真的很有意思，看來(lái)在各行各業(yè)，大家都開(kāi)始在關(guān)注整個(gè)生命周期的各個(gè)環(huán)節(jié)之間的打通。

只是，在軟件領(lǐng)域，我們會(huì)感覺(jué)到這是一種回歸。畢竟，最初的軟件開(kāi)發(fā)，都是很簡(jiǎn)單的。在一臺(tái)計(jì)算機(jī)上，自己寫(xiě)程序，自己編譯，自己調(diào)試、運(yùn)行，最后發(fā)布。既不用依賴他人，更不用等待什么流程。

隨著項(xiàng)目越來(lái)越復(fù)雜，參與的人越來(lái)越多，我們的軟件，不能僅僅運(yùn)行在自己的機(jī)器上，或者需要部署到服務(wù)器上，或者需要發(fā)布到某種平臺(tái)上。在協(xié)作者眾多的情況下，如何分工合作？
在開(kāi)發(fā)者水平參差不齊的情況下，如何保證質(zhì)量？在分工、協(xié)作、流程與質(zhì)量保證的要求之下，如何提高效率？

這些都是DevOps致力于解決的問(wèn)題，也是DevOps不斷得以發(fā)展的原動(dòng)力。

總結(jié)：開(kāi)源社區(qū)，始終在進(jìn)步，Github代表的也只是「一代」而已，新的一代協(xié)作模式，還會(huì)被創(chuàng)造出來(lái)的。

六、暗線：工具、習(xí)俗背后的邏輯

過(guò)去是如何？未來(lái)又會(huì)怎樣？想要回答這類問(wèn)題，其實(shí)需要更加深入的思考：「開(kāi)源社區(qū)的協(xié)作模式，為何會(huì)變？變化背后的邏輯是什么？」

開(kāi)源社區(qū)研發(fā)工具的兩大目標(biāo)：降低門(mén)檻，提高效率

開(kāi)源社區(qū)，與普通的軟件開(kāi)發(fā)最大的不同，就是參與者多多益善。在《大教堂與集市》中，Eric Steven Raymond總結(jié)到：「如果開(kāi)發(fā)者協(xié)調(diào)者有至少一個(gè)像Internet這樣好的溝通媒介，并且知道如何不靠強(qiáng)制來(lái)領(lǐng)導(dǎo)，那么多人合作必然強(qiáng)于單兵作戰(zhàn)」，這簡(jiǎn)直就是絕妙的預(yù)言。雖然當(dāng)年的ESR也許并未預(yù)測(cè)到，基于Internet會(huì)出現(xiàn)那么多輔助開(kāi)源的相關(guān)工具（他們當(dāng)時(shí)還只有郵件列表）。

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

如何計(jì)算參與者的貢獻(xiàn)？

開(kāi)源社區(qū)，不會(huì)給參與者發(fā)工資，因此激勵(lì)是一個(gè)大問(wèn)題。公平、公開(kāi)、公正大計(jì)算所有參與者的貢獻(xiàn)，以所有人都能夠接受都形式，計(jì)算并公布各種排行榜，可以說(shuō)是開(kāi)源社區(qū)特有都「剛性需求」，因此SNS與開(kāi)源社區(qū)的結(jié)合，成為必然。以后，面向開(kāi)源協(xié)作的大數(shù)據(jù)分析，也一定會(huì)出現(xiàn)。

如何激勵(lì)、吸引、回報(bào)參與者？

計(jì)算參與者的貢獻(xiàn)，僅僅是公平激勵(lì)的基礎(chǔ)。讓激勵(lì)變得有趣，變得有價(jià)值，變得有意義，則是吸引與回報(bào)參與者的不二法門(mén)。因此：游戲化的思路，會(huì)被越來(lái)越多的引入到開(kāi)源社區(qū)中來(lái)。

如何保障項(xiàng)目質(zhì)量？

開(kāi)源項(xiàng)目保障項(xiàng)目質(zhì)量都最大利器，是引入數(shù)量眾多都熱心測(cè)試者。但是，僅僅有人愿意測(cè)試，主動(dòng)、積極都幫助測(cè)試，已經(jīng)越來(lái)越不夠了。隨著項(xiàng)目越來(lái)越復(fù)雜，開(kāi)源項(xiàng)目必須逐步走出僅僅依賴肉眼、依賴人多＋運(yùn)氣的質(zhì)量保障模式。

自動(dòng)化測(cè)試、以及更加規(guī)范的Review流程，則是必然出現(xiàn)，而且將越來(lái)越重要的環(huán)節(jié)之一。

如何協(xié)調(diào)一致的工作？

自由與規(guī)范，計(jì)劃與變化，興趣與責(zé)任。經(jīng)常會(huì)在社區(qū)里，成為爭(zhēng)論的熱點(diǎn)話題。雖然在《大教堂與集市》中，ESR極力鼓吹「禮物文化遠(yuǎn)遠(yuǎn)勝過(guò)交換經(jīng)濟(jì)」，但是：「在一個(gè)龐大的社區(qū)，各種各樣的事務(wù)都需要有人去完成，而且還不能漫無(wú)章法?！?/p>

因此：「某種調(diào)節(jié)手段、協(xié)調(diào)者與協(xié)調(diào)機(jī)制、甚至是看不見(jiàn)的手」之類的東西，會(huì)慢慢的回到社區(qū)。

如何在社區(qū)里平等、高效的協(xié)商？

目前來(lái)說(shuō)，依然只能是線上討論+線下開(kāi)會(huì)。雖然，很多開(kāi)源社區(qū)，開(kāi)始學(xué)習(xí)《羅伯特議事規(guī)則》這樣的開(kāi)會(huì)圣經(jīng)。但是，開(kāi)會(huì)依然是最令程序員感到苦惱的事情。在這方面，將來(lái)會(huì)不會(huì)出現(xiàn)更好的輔助工具，這方面很值得期待。

結(jié)束語(yǔ)

唯有變化，是不變的。開(kāi)源協(xié)作模式，同樣如此。惟愿我們，能夠成為推起其前進(jìn)的力量之一。