劉 鵬，張鵬臣，王念新

(江蘇科技大學(xué)經(jīng)濟(jì)管理學(xué)院，江蘇 鎮(zhèn)江 212003)

0 引言

近十多年來，開源軟件得以蓬勃發(fā)展，廣泛應(yīng)用于人工智能、虛擬現(xiàn)實(shí)、大數(shù)據(jù)分析等諸多領(lǐng)域。伴隨著web2.0/3.0技術(shù)不斷成熟而涌現(xiàn)的在線社區(qū)是孕育開源軟件的主要場所。與傳統(tǒng)商業(yè)軟件相比，開源軟件在開發(fā)模式上表現(xiàn)出很強(qiáng)的自主性。具體而言，在缺少中央調(diào)控的情況下，眾多社區(qū)成員通過彼此間自發(fā)的協(xié)調(diào)與合作，完成了軟件開發(fā)過程中復(fù)雜問題的發(fā)現(xiàn)與求解。這種看似“烏合之眾”的軟件開發(fā)模式的成功引起了學(xué)界的廣泛關(guān)注，相應(yīng)地，開源軟件社區(qū)中開發(fā)者之間的協(xié)作模式逐漸成為了計算機(jī)科學(xué)、管理科學(xué)、創(chuàng)新管理等領(lǐng)域的重要的研究課題[1-4]。

關(guān)于開源軟件社區(qū)的開發(fā)者協(xié)作模式的研究，Raymond做出了先驅(qū)性工作，他指出大多數(shù)商業(yè)軟件的開發(fā)采用了大教堂模式，而以Linux為代表的開源軟件則使用了集市模式[5]，即在足夠多的注視下，軟件的缺陷將無所遁形。這一論斷使人們對于開源軟件的開發(fā)模式產(chǎn)生了全新的認(rèn)識。然而，有學(xué)者指出，開源軟件，尤其是大型開源軟件的開發(fā)是一項(xiàng)知識密集型的工程，社區(qū)成員間的交互具有內(nèi)在的自治性與復(fù)雜性，集市模式還不足以揭示社區(qū)成員的協(xié)作模式[6-8]。特別是，開源軟件社區(qū)本質(zhì)上可以理解為一個知識型復(fù)雜自適應(yīng)系統(tǒng)[2,9]，針對這一特點(diǎn)，學(xué)界從復(fù)雜網(wǎng)絡(luò)視角對開軟社區(qū)的協(xié)作模式展開了諸多有益的探討。

在宏觀方面，相關(guān)研究主要關(guān)注整體社區(qū)層面上社區(qū)成員間協(xié)作關(guān)系所表現(xiàn)出的規(guī)律與特性[10-15]。例如，Bird等利用Apache服務(wù)器項(xiàng)目社區(qū)郵件通訊數(shù)據(jù)構(gòu)建了社區(qū)開發(fā)者協(xié)作網(wǎng)絡(luò)，結(jié)果顯示網(wǎng)絡(luò)中度分布具有明顯的無標(biāo)度特性[13]。Singh通過收集Sourgeforge上15個開源軟件社區(qū)的日志文件和郵件通訊數(shù)據(jù)，構(gòu)建開發(fā)者協(xié)作網(wǎng)絡(luò)，研究結(jié)果表明這些協(xié)作網(wǎng)絡(luò)具有不同程度的小世界特性，并且這一性質(zhì)對軟件的成功具有相關(guān)性[14]。除此之外，一些學(xué)者發(fā)現(xiàn)開源軟件社區(qū)成員間的協(xié)作網(wǎng)絡(luò)具有“核心—邊緣”結(jié)構(gòu)[16-19]，即網(wǎng)絡(luò)中的節(jié)點(diǎn)可以分為兩類，核心節(jié)點(diǎn)間交互密切，邊緣節(jié)點(diǎn)間幾乎不存在密切的協(xié)作關(guān)系。

微觀層面的研究工作主要圍繞建立交互關(guān)系雙方的屬性特點(diǎn)、現(xiàn)有關(guān)系結(jié)構(gòu)等方面展開[20-24]。例如，Hu等針對社區(qū)中個體屬性特征(如相互熟識程度)與交互關(guān)系建立的相關(guān)性進(jìn)行了分析[20]。Joblin等通過分析18個開源軟件的開發(fā)者網(wǎng)絡(luò)，發(fā)現(xiàn)層級結(jié)構(gòu)會隨著時間推移而轉(zhuǎn)變?yōu)橐环N混合結(jié)構(gòu)(即層級結(jié)構(gòu)只出現(xiàn)于核心開發(fā)者的交互關(guān)系之中，而邊緣開發(fā)者之間并不具有這一特征)，說明開發(fā)者在網(wǎng)絡(luò)中的位置影響其新的交互關(guān)系的建立[21]。

已有相關(guān)工作使我們對開源軟件社區(qū)的協(xié)作模式有了更加深入的認(rèn)識，但是在以下兩個方面還有待進(jìn)一步深化。首先，已有工作主要利用郵件交流數(shù)據(jù)來構(gòu)建開發(fā)者協(xié)作網(wǎng)絡(luò)，而這些數(shù)據(jù)往往包含了開發(fā)者郵件和用戶郵件，難免影響研究結(jié)果的準(zhǔn)確性，同時也限制了更深層分析工作的開展。其次，現(xiàn)有研究工作主要關(guān)注社區(qū)開發(fā)者協(xié)作網(wǎng)絡(luò)的靜態(tài)結(jié)構(gòu)特征，其結(jié)構(gòu)隨時間推移而展現(xiàn)出演化特性也不容忽視，特別是推動網(wǎng)絡(luò)演化的協(xié)作關(guān)系的形成特點(diǎn)還有待更加深入的探討。

對此，本文以Cloud Foundry項(xiàng)目社區(qū)為例，通過收集社區(qū)開發(fā)者代碼提交數(shù)據(jù)，利用代碼協(xié)作關(guān)系建立開發(fā)者協(xié)作網(wǎng)絡(luò)(即代碼協(xié)作網(wǎng)絡(luò))，并對其結(jié)構(gòu)及演化特性展開分析。本文力圖從復(fù)雜網(wǎng)絡(luò)視角為開源軟件社區(qū)協(xié)作模式的分析工作提供一種新的思路。此外，開源軟件開發(fā)也屬于開放式創(chuàng)新的一種具體模式，現(xiàn)有相關(guān)工作主要聚焦于科研合作、專利聯(lián)合研發(fā)等領(lǐng)域，本研究亦是對該方面工作的豐富。

1 數(shù)據(jù)及分析方法

1.1 數(shù)據(jù)的獲取

Cloud Foundry最初由VMware公司發(fā)起，現(xiàn)由Cloud Foundry基金會(非盈利性組織)管理的開源云平臺項(xiàng)目，也是云應(yīng)用和云服務(wù)領(lǐng)域最早的項(xiàng)目之一。截止至2019年1月，該項(xiàng)目共涵蓋了CLI(Official Command Line Client)、UAA(User Account & Authentication Server)、Routing等41個子項(xiàng)目。這些子項(xiàng)目均通過git(一個開源的分布式版本控制系統(tǒng))進(jìn)行代碼的提交和修改，相應(yīng)git記錄了不同時間段所有參與項(xiàng)目開發(fā)人員的提交記錄。

由此，本文利用git收集了Cloud Foundry從2010年8月(項(xiàng)目的初始期)到2019年1月所有子項(xiàng)目下的提交記錄，共獲取了586 727條提交數(shù)據(jù)。其中，每條提交數(shù)據(jù)包含了提交者的郵箱地址、提交時間、代碼修改情況及所涉及的文件等信息，如圖1示例所示。

圖1 開發(fā)人員提交記錄數(shù)據(jù)示例

1.2 分析方法

1.2.1 網(wǎng)絡(luò)構(gòu)建方法

本文主要通過社區(qū)開發(fā)者之間的代碼協(xié)作關(guān)系構(gòu)建開發(fā)者協(xié)作網(wǎng)絡(luò)，網(wǎng)絡(luò)構(gòu)建過程分為以下步驟。

首先，通過每個提交記錄中的電子郵件地址將開發(fā)人員彼此區(qū)別開來，即如果兩條記錄是通過相同的電子郵件地址進(jìn)行提交，那么認(rèn)為這兩條記錄的代碼是由同一個開發(fā)者編寫的，相應(yīng)不同的郵箱地址抽象為網(wǎng)絡(luò)中不同的節(jié)點(diǎn)。

圖2 開發(fā)者協(xié)作關(guān)系抽取過程示意圖

然后，將開發(fā)者之間的代碼協(xié)作關(guān)系抽象為網(wǎng)絡(luò)中的邊。關(guān)于代碼協(xié)作關(guān)系的抽取，由于每個子項(xiàng)目都是按照版本進(jìn)行發(fā)布的，新版本往往是對舊版本功能的完善和提升，并且由兩個版本發(fā)布時間間隔內(nèi)進(jìn)行過代碼提交的開發(fā)者共同完成，相應(yīng)子項(xiàng)目的每個新版本可以看作是上述開發(fā)者相互協(xié)作而形成的獨(dú)立的知識產(chǎn)品。由此，本文中開發(fā)之間協(xié)作關(guān)系的抽取標(biāo)準(zhǔn)是：在子項(xiàng)目兩個相鄰版本發(fā)布的時間間隔內(nèi)，兩個開發(fā)者是否針對同一個子項(xiàng)目文件進(jìn)行過代碼提交，具體抽取過程如圖2所示。

圖2中，假設(shè)某個子項(xiàng)目的v1版本發(fā)布時間為2017年6月30日，開發(fā)者A和B分別在這個時間之前對該子項(xiàng)目中的文件2進(jìn)行了代碼提交；隨后，在v1版本發(fā)布之后到v2版本發(fā)布之前，開發(fā)者A和C也針對文件2進(jìn)行了提交。相應(yīng)地，開發(fā)者A分別和B、C建立代碼協(xié)作關(guān)系，而開發(fā)者B和C之間無代碼協(xié)作關(guān)系，每組協(xié)作關(guān)系上的時間戳設(shè)定為B、C的提交時間。

最后，在對數(shù)據(jù)集中的所有代碼協(xié)作關(guān)系抽取的基礎(chǔ)上，根據(jù)協(xié)作關(guān)系建立的時間戳的不同，以6個月的時間間隔構(gòu)建不同時間窗(17個時間窗)下的累積協(xié)作網(wǎng)絡(luò)，如2010.8～2011.1的協(xié)作網(wǎng)絡(luò)、2010.8～2011.7的協(xié)作網(wǎng)絡(luò)等。

1.2.2 網(wǎng)絡(luò)分析方法

本文主要采用社會網(wǎng)絡(luò)分析方法對所構(gòu)建的協(xié)作網(wǎng)絡(luò)展開分析。網(wǎng)絡(luò)規(guī)模用節(jié)點(diǎn)數(shù)量表示，節(jié)點(diǎn)度表示與目標(biāo)節(jié)點(diǎn)直接相連的節(jié)點(diǎn)數(shù)量。連通子圖表示網(wǎng)絡(luò)中一部分直接或間接相連節(jié)點(diǎn)構(gòu)成的子圖，其中規(guī)模最大的連通子圖稱為最大連通子圖。

圖3 開發(fā)者協(xié)作網(wǎng)絡(luò)整體結(jié)構(gòu)演化特性

除了上述基本統(tǒng)計指標(biāo)，本文通過聚集系數(shù)、平均最短路徑長度、模塊度3個指標(biāo)來分析網(wǎng)絡(luò)的結(jié)構(gòu)特性。聚集系數(shù)表示網(wǎng)絡(luò)中三角形數(shù)量與三元組數(shù)量的比值；平均最短路徑長度為任意兩個節(jié)點(diǎn)實(shí)現(xiàn)連接所需最少邊數(shù)的均值；模塊度主要衡量網(wǎng)絡(luò)中是否存在多個邊密度較高的局部區(qū)域(即模塊化結(jié)構(gòu))。本文采用Louvain算法[25]計算網(wǎng)絡(luò)的模塊度。

2 分析結(jié)果

2.1 網(wǎng)絡(luò)的整體結(jié)構(gòu)演化特性

圖3給出了所構(gòu)建的協(xié)作網(wǎng)絡(luò)的規(guī)模變化，其中17個時間窗分別表示為T0～T16。隨著時間窗的推移，整個網(wǎng)絡(luò)的規(guī)模不斷增大，從T4時間窗開始，一個規(guī)模遠(yuǎn)大于第二連通子圖(藍(lán)色實(shí)線)的最大連通子圖(紅色實(shí)線)逐漸涌現(xiàn)出來。從圖4各個時間窗下網(wǎng)絡(luò)的拓?fù)浣Y(jié)構(gòu)也可以直觀的看出最大連通子圖(彩色子圖)規(guī)模增長的同時，其結(jié)構(gòu)也發(fā)生了顯著變化。這表明在Cloud Foundry項(xiàng)目實(shí)施的過程中，數(shù)量可觀的開發(fā)者通過協(xié)作關(guān)系自發(fā)形成了匯聚，為了分析其結(jié)構(gòu)特性，本文針對T16網(wǎng)絡(luò)(即所獲取數(shù)據(jù)集中的終態(tài)網(wǎng)絡(luò))展開進(jìn)一步探查。

圖4 各個時間窗下網(wǎng)絡(luò)的拓?fù)浣Y(jié)構(gòu)

圖5 開發(fā)者協(xié)作網(wǎng)絡(luò)的度分布及邊密度(T16)

在雙對數(shù)坐標(biāo)下，圖5a繪制了網(wǎng)絡(luò)中不同度(k)節(jié)點(diǎn)的數(shù)量占比(P(k))情況。從圖中可以看出，隨著節(jié)點(diǎn)度的升高，對應(yīng)的節(jié)點(diǎn)數(shù)量占比(黑色實(shí)心圓)呈現(xiàn)下降趨勢，并且在總體上符合冪指數(shù)為-2.38的冪律分布(紅色實(shí)線)。這一現(xiàn)象說明少數(shù)開發(fā)者擁有大多數(shù)的協(xié)作關(guān)系，而大多數(shù)開發(fā)者的合作伙伴的數(shù)量相對較少。由此網(wǎng)絡(luò)中可能存在一定的層次結(jié)構(gòu)，圖5b對這一現(xiàn)象進(jìn)行了分析。

圖5b中，分別針對最大連通子圖和外圍節(jié)點(diǎn)(即最大連通子圖之外的子圖)，按照度由高到低的順序，繪制了不同度(k)節(jié)點(diǎn)間的連邊密度。其中，黑色虛線對最大連通子圖和外圍節(jié)點(diǎn)進(jìn)行了標(biāo)識(即黑色虛線左下區(qū)域?yàn)樽畲筮B通子圖，右上區(qū)域?yàn)橥鈬?jié)點(diǎn))。最大連通子圖中，隨著節(jié)點(diǎn)度的下降，不同度節(jié)點(diǎn)間的連邊密度逐漸下降，基本可以劃分為兩個區(qū)域(由紅色虛線表示)，而從圖中可以看出，第一個區(qū)域(k≥6)的邊緣密度明顯高于第二個區(qū)域(k<6)，這說明最大連通子圖中存在“核心—邊緣”結(jié)構(gòu)。與此同時，與最大連通子圖中的節(jié)點(diǎn)相比，外圍節(jié)點(diǎn)的連邊十分稀疏，說明外圍節(jié)點(diǎn)的提交行為存在一定的偶發(fā)性。這一結(jié)果意味著協(xié)作網(wǎng)絡(luò)中的開發(fā)者可以根據(jù)交互關(guān)系的密集程度劃分為3個層次，分別是核心開發(fā)者(最大連通子圖k≥6節(jié)點(diǎn))、邊緣開發(fā)者(最大連通子圖k<6節(jié)點(diǎn))、和外圍開發(fā)者(非最大連通子圖節(jié)點(diǎn))。

表1 開發(fā)者協(xié)作網(wǎng)絡(luò)提交情況(T16)

基于圖5的結(jié)果，表1從提交量和代碼修改量兩個方面對整個協(xié)作網(wǎng)絡(luò)中3類節(jié)點(diǎn)(即最大連通子圖中的核心節(jié)點(diǎn)和邊緣節(jié)點(diǎn)，以及外圍節(jié)點(diǎn))的提交記錄進(jìn)行了統(tǒng)計。對比3類節(jié)點(diǎn)的提交情況可以發(fā)現(xiàn)，整個項(xiàng)目的代碼編寫工作主要由最大連通子圖中的節(jié)點(diǎn)完成(代碼修改量和提交量分別占總體數(shù)量的98%和95.2%)；雖然外圍節(jié)點(diǎn)對于整個項(xiàng)目的貢獻(xiàn)并不顯著，但是這些外圍節(jié)點(diǎn)在一定程度上分擔(dān)了最大連通子圖節(jié)點(diǎn)的工作量，對于項(xiàng)目的推進(jìn)具有積極作用。最大連通子圖中，占整個網(wǎng)絡(luò)規(guī)模約1/4的核心節(jié)點(diǎn)(即k≥6節(jié)點(diǎn))的代碼修改量和提交數(shù)量均超過60%，完成了項(xiàng)目開發(fā)的大部分工作，是Cloud Foundry項(xiàng)目實(shí)施的主力開發(fā)者；邊緣節(jié)點(diǎn)(1≤k<6節(jié)點(diǎn))在3類節(jié)點(diǎn)中數(shù)量最多，雖然代碼修改量(37.9%)和提交量(26.4%)低于核心節(jié)點(diǎn)，但遠(yuǎn)遠(yuǎn)超過外圍節(jié)點(diǎn)。結(jié)合圖5的結(jié)果(即邊緣節(jié)點(diǎn)不可避免地與核心節(jié)點(diǎn)發(fā)生聯(lián)系)，我們基本上可以斷定邊緣節(jié)點(diǎn)對于核心節(jié)點(diǎn)的工作起到了補(bǔ)充作用。因此，在Cloud Foundry項(xiàng)目實(shí)施過程中，最大連通子圖中的開發(fā)者是主力軍，其中以“核心”開發(fā)者作為骨架；而最大連通子圖之外的開發(fā)者作為后備力量參與開發(fā)工作。

圖6 最大連通子圖與外圍節(jié)點(diǎn)中開發(fā)者——子項(xiàng)目二分網(wǎng)絡(luò)嵌套性(T16)

表1的提交量分析反映出最大連通子圖的開發(fā)者承擔(dān)了絕大部分的開發(fā)工作，然而就工作類別(即參與不同的子項(xiàng)目)而言，是否也具有類似現(xiàn)象還值得進(jìn)一步考察。進(jìn)而，本文利用生態(tài)學(xué)中嵌套性理論[26]，分別對最大連通子圖和外圍節(jié)點(diǎn)中，開發(fā)者與子項(xiàng)目對應(yīng)關(guān)系構(gòu)成的二分網(wǎng)絡(luò)的嵌套結(jié)構(gòu)進(jìn)行了分析，如圖6所示，其中嵌套度數(shù)值越高說明嵌套結(jié)構(gòu)越清晰。從圖中可以看出，最大連通子圖(圖6a)的開發(fā)者—子項(xiàng)目網(wǎng)絡(luò)左上角具有一個較清晰的三角形結(jié)構(gòu)，并且嵌套度數(shù)值約為20.133，而外圍節(jié)點(diǎn)(圖6b)的二分網(wǎng)絡(luò)中，開發(fā)者與子項(xiàng)目間的關(guān)系較為分散，相應(yīng)的嵌套度數(shù)值為5.397。這一結(jié)果說明，與外圍節(jié)點(diǎn)相比，最大連通子圖中開發(fā)者與子項(xiàng)目間存在明顯的嵌套結(jié)構(gòu)，即存在一部分開發(fā)者會對大多數(shù)子項(xiàng)目貢獻(xiàn)代碼，其余的開發(fā)者則圍繞少數(shù)子項(xiàng)目進(jìn)行開發(fā)。因而，這種嵌套性結(jié)構(gòu)的存在對于整個項(xiàng)目開發(fā)延續(xù)性的維持具有一定的積極作用。換言之，只要關(guān)注多個子項(xiàng)目的開發(fā)者持續(xù)提交代碼，關(guān)注少數(shù)子項(xiàng)目的開發(fā)者的隨機(jī)流失并不會對整個項(xiàng)目的開發(fā)工作造成嚴(yán)重影響。

圖7 最大連通子圖C、L、Q數(shù)值變化情況及典型拓?fù)浣Y(jié)構(gòu)

2.2 最大連通子圖結(jié)構(gòu)及演化特性

從2.1節(jié)的分析可以看出，最大連通子圖對于整個項(xiàng)目的實(shí)施發(fā)揮了至關(guān)重要的作用，其結(jié)構(gòu)在不同的時間窗下也表現(xiàn)出明顯的變化。因此，本部分針對最大連通子圖，從宏觀、介觀和微觀3個層面對其結(jié)構(gòu)演化展開進(jìn)一步的探查。

2.2.1 宏觀層面分析

圖7繪制了開發(fā)者協(xié)作網(wǎng)絡(luò)最大連通子圖的聚集系數(shù)(C)、平均最短路徑長度(L)和模塊度(Q)隨著時間窗推移的演化情況，其中，C和L分別為實(shí)際數(shù)值與同規(guī)模隨機(jī)網(wǎng)絡(luò)聚集系數(shù)和平均最短路徑長度的比值。整體上，3個衡量指標(biāo)的數(shù)值都出現(xiàn)了不同程度的升高，但是通過對比三者的變化，可以發(fā)現(xiàn)最大連通子圖在演化過程中存在3種不同的結(jié)構(gòu)狀態(tài)。

第一種狀態(tài)出現(xiàn)在T0～T2時間窗下，最大連通子圖的模塊度、聚集系數(shù)和平均最短路徑長度的數(shù)值很小(C≈0，L<1.0，Q<0.4)，說明此時的網(wǎng)絡(luò)中連邊稀疏，且很難劃分出顯著的模塊化結(jié)構(gòu)，最大連通子圖主要表現(xiàn)為“松散連接”的狀態(tài)(如圖7bT1網(wǎng)絡(luò))。

隨后，在時間窗由T3到T5的移動過程中，最大連通子的模塊度和聚集系數(shù)分別出現(xiàn)了不同程度的升高(Q→0.8，C→50)，平均最短路徑長度則保持在相對較高的水平(L≈1.5)。這一結(jié)果表明，此時最大連通子圖出現(xiàn)了高度模塊化的狀態(tài)，并且大多數(shù)模塊間并未形成相互連接，任意兩個模塊間的聯(lián)系往往要通過第三方模塊，相應(yīng)最大連通子圖在整體上出現(xiàn)了多個模塊依次相連的“鏈?zhǔn)浇Y(jié)構(gòu)”(如圖7bT3網(wǎng)絡(luò))。

從T6時間窗開始，最大連通子圖在結(jié)構(gòu)上展現(xiàn)出第三種狀態(tài)：模塊度和平均最短路徑長度在數(shù)值上未發(fā)生明顯改變(Q≈0.8，L≈1.3)，說明最大連通子圖維持高度模塊化結(jié)構(gòu)的同時，模塊間逐漸相互連接起來；聚集系數(shù)的持續(xù)增大意味著節(jié)點(diǎn)間的連邊變得更加緊密。由此，可以斷定最大連通子圖宏觀上涌現(xiàn)出“多模塊的小世界”狀態(tài)(如圖7bT16網(wǎng)絡(luò))。

網(wǎng)絡(luò)的典型拓?fù)浣Y(jié)構(gòu)也直觀地顯示了這種現(xiàn)象，雖然3個時間窗下的網(wǎng)絡(luò)均呈現(xiàn)分割狀態(tài)，但與T1和T3的網(wǎng)絡(luò)相比，T16的最大連通子圖(彩色的子圖)規(guī)模明顯增大，并且在結(jié)構(gòu)上也發(fā)生了顯著變化，其余的小規(guī)模聚簇和孤立點(diǎn)散布于其外圍。

2.2.2 介觀層面分析

本節(jié)主要圍繞最大連通子圖中模塊的形成和演化展開介觀層面的分析。通過比較相鄰兩個時間窗下最大連通子圖模塊成員的重疊情況，圖8對最大連通子圖中模塊的演化過程進(jìn)行了繪制。其中，黑色豎線表示最大連通子圖中的模塊，長度為對應(yīng)模塊的相對規(guī)模，文字表示模塊編號；彩色流標(biāo)識了模塊間的演化關(guān)系。例如，#1為T2最大連通子圖中規(guī)模最大的模塊，逐漸與#0模塊合并形成T3最大連通子圖的#1模塊。

圖8中，對比不同時間窗下模塊間的演化關(guān)系可以發(fā)現(xiàn)，一方面，最大連通子圖上不斷有新的模塊涌現(xiàn)出來(如T3最大連通子圖的#0和#2模塊)；另一方面，最大連通子圖上的模塊主要通過自身發(fā)展和合并其它模塊的方式實(shí)現(xiàn)規(guī)模的擴(kuò)張，例如，時間窗T6中規(guī)模最大的模塊#8由T5的#3模塊演化而來，第二大模塊#7則是通過T5的#4和#6模塊合并而形成。在這兩方面因素的共同作用下，最大連通子圖在規(guī)模擴(kuò)張的同時展現(xiàn)出了多模塊的結(jié)構(gòu)狀態(tài)。

為了進(jìn)一步檢測最大連通子圖中模塊的演化與軟件子項(xiàng)目開發(fā)之間的關(guān)系，在圖8的基礎(chǔ)上，本文通過統(tǒng)計各個模塊在不同子項(xiàng)目上的提交情況，分析了模塊與子項(xiàng)目之間的關(guān)聯(lián)性，如圖9所示。其中，每個矩形表示模塊，矩形上的文字標(biāo)明了模塊編號(與圖8模塊編號對應(yīng))、提交量降序排列后排名前4的子項(xiàng)目編號；每個時間窗后的數(shù)值為最大連通子圖提交記錄所涉及的子項(xiàng)目數(shù)量與相應(yīng)時間段軟件中子項(xiàng)目總量的比值。例如，T4時間窗下，#4模塊提交量前4的子項(xiàng)目分別是*16(cf-release)、*20(cloud-controller-ng)、*10(bosh)、*27(garden)，T4(1.0)表示最大連通子圖的提交記錄涉及此時間窗下所有子項(xiàng)目。

圖8 最大連通子圖中模塊的演化過程

圖9中，不同時間窗下，最大連通子圖提交記錄所涉及的子項(xiàng)目數(shù)量與相應(yīng)子項(xiàng)目總量的比值均為1.0，說明開發(fā)者協(xié)作網(wǎng)絡(luò)的最大連通子圖會對軟件項(xiàng)目包含的所有子項(xiàng)目進(jìn)行代碼提交。進(jìn)一步觀察模塊演化時高提交量子項(xiàng)目的變化情況可以發(fā)現(xiàn)，各個時間窗下最大連通子圖上的模塊均會圍繞特定的子項(xiàng)目進(jìn)行代碼集中提交。例如，在T15時間窗下，模塊#10主要關(guān)注子項(xiàng)目*16(cf-release)，而模塊#13對子項(xiàng)目*19(cli)做了大量的代碼貢獻(xiàn)。此外，模塊的演化和合并也與子項(xiàng)目有關(guān)。

在模塊自身發(fā)展的過程中，每個模塊代碼集中提交的子項(xiàng)目較好地保持了延續(xù)性，并且這些子項(xiàng)目往往具有一定的軟件功能相關(guān)性。例如，T11的#0模塊演化為T16的#1模塊的過程中，始終主要圍繞子項(xiàng)目*25(fissile)、*20(cloud-controller-ng)、*21(consul-release)和*16(cf-release)進(jìn)行代碼提交。其中，fissile的功能是Cloud Foundry應(yīng)用發(fā)布部署的容器調(diào)度；cloud-controller-ng用于Cloud Foundry應(yīng)用的服務(wù)、用戶角色等的管理，實(shí)現(xiàn)開發(fā)者工作流的改善；consul-release是一個分布式的鍵值存儲程序，為Cloud Foundry應(yīng)用基礎(chǔ)框架提供服務(wù)發(fā)現(xiàn)、密鑰值配置和分布式鎖；cf-release提供Cloud Foundry應(yīng)用中單個組件發(fā)布的部署規(guī)范。這4個子項(xiàng)目均面向Cloud Foundry應(yīng)用，涉及應(yīng)用的開發(fā)管理、權(quán)限配置、組件發(fā)布和服務(wù)管理。

在模塊合并的過程中，能夠形成合并的兩個模塊在代碼集中提交的子項(xiàng)目上往往存在交叉，如T11的#1和#10合并為T12的#11(圖8)，合并前兩個模塊提交量前四的子項(xiàng)目中均出現(xiàn)了子項(xiàng)目*10、*16、*7，合并后依然會對這3個子項(xiàng)目進(jìn)行代碼集中提交。

綜合圖8和9的分析可以得出，開發(fā)者協(xié)作網(wǎng)絡(luò)的模塊與子項(xiàng)目的開發(fā)存在著內(nèi)在聯(lián)系，并且不斷地為特定的子項(xiàng)目貢獻(xiàn)源代碼。與此同時，開發(fā)者協(xié)作網(wǎng)絡(luò)的最大連通子圖通過新模塊的涌現(xiàn)和現(xiàn)有模塊的發(fā)展與合并實(shí)現(xiàn)規(guī)模的擴(kuò)張，以及多模塊相互連接狀態(tài)的維持。

2.2.3 微觀層面分析

開發(fā)者之間的代碼修訂關(guān)系(即協(xié)作關(guān)系)是協(xié)作網(wǎng)絡(luò)結(jié)構(gòu)演化的基礎(chǔ)，從前文的分析可以看出開發(fā)者間的協(xié)作關(guān)系兼具結(jié)構(gòu)和屬性的特性。在結(jié)構(gòu)方面，協(xié)作關(guān)系分布并不均勻，呈現(xiàn)冪率特性(圖5a)，說明開發(fā)者現(xiàn)有的協(xié)作伙伴數(shù)量(結(jié)構(gòu)特性)會影響進(jìn)一步協(xié)作關(guān)系的形成。在屬性方面，每個模塊內(nèi)的開發(fā)者往往圍繞特定的功能相關(guān)的子項(xiàng)目進(jìn)行代碼集中提交，不同模塊所涉及的子項(xiàng)目之間也存在差異(圖9)。此外，由于子項(xiàng)目功能的實(shí)現(xiàn)往往需要開發(fā)者具備較強(qiáng)的相關(guān)技術(shù)背景，開發(fā)者所關(guān)注的子項(xiàng)目本質(zhì)上反映了開發(fā)者的技術(shù)背景(即屬性)，由此可見，屬性的差異可能存在于模塊內(nèi)與模塊間的關(guān)系中。因此，本節(jié)針對T16的最大連通子圖(此時的最大連通子圖是一個多模塊小世界網(wǎng)絡(luò))，從結(jié)構(gòu)和屬性兩個方面對模塊內(nèi)外協(xié)作關(guān)系的特點(diǎn)展開進(jìn)一步的檢測。

1)協(xié)作關(guān)系的結(jié)構(gòu)特性分析

借鑒Guimerà等的研究工作[27]，本文提出了模塊內(nèi)外節(jié)點(diǎn)連邊特征的考察方法，分別如式(1)和(2)所示。

(1)

式(2)的p值則主要衡量模塊m中k度節(jié)點(diǎn)在跨模塊連邊中發(fā)揮的作用，其中，lio,km表示模塊m的跨模塊連邊中k度節(jié)點(diǎn)i參與數(shù)量，n為模塊m內(nèi)k度節(jié)點(diǎn)的數(shù)量。

(2)

圖10對T16最大連通子圖中各個模塊內(nèi)不同度節(jié)點(diǎn)的p、z值進(jìn)行了繪制。其中，上橫坐標(biāo)注明了模塊編號及規(guī)模，下橫坐標(biāo)為各個模塊中按照度值由低到高排列的節(jié)點(diǎn)度(k)，節(jié)點(diǎn)度為6的位置用紅色虛線進(jìn)行了標(biāo)識。

從圖10可以看出，除模塊#0之外，各模塊的z值隨著節(jié)點(diǎn)度的升高主要呈現(xiàn)上升趨勢，并且每個模塊的k≥6節(jié)點(diǎn)的z值基本上都大于0，說明這些模塊中k≥6節(jié)點(diǎn)模塊內(nèi)連邊數(shù)量較多。進(jìn)而，結(jié)合表1統(tǒng)計結(jié)果可以基本斷定，最大連通子圖中的核心開發(fā)者(k≥6節(jié)點(diǎn)，在最大連通子圖規(guī)模占比約為38%)分散在不同的模塊中，與對應(yīng)模塊中的其他開發(fā)者連接更好。換言之，核心開發(fā)者在每個模塊中都扮演中心角色，并且模塊內(nèi)的關(guān)系通常圍繞其形成。對于模塊#0，由于其規(guī)模過小，不存在k≥6節(jié)點(diǎn)，故模塊內(nèi)的關(guān)系幾乎沒有表現(xiàn)出任何結(jié)構(gòu)性的特征。

圖10 最大連通子圖(T16)模塊中不同度節(jié)點(diǎn)的p、z值

圖11 最大連通子圖中節(jié)點(diǎn)度(k)與新增邊概率((k))的關(guān)系

隨著模塊中節(jié)點(diǎn)度的升高，p值的變化并不具有顯著的規(guī)律性。但是通過比較分析每個模塊高度和低度節(jié)點(diǎn)的p值可以發(fā)現(xiàn)，模塊間連接的形成往往涉及k≥6節(jié)點(diǎn)。例如，模塊#12中，k≥6節(jié)點(diǎn)的p值高于0.2，最大值可以達(dá)到0.7左右，而k<6節(jié)點(diǎn)p值的最大值接近于0.2。雖然在模塊#0中沒有k≥6節(jié)點(diǎn)，但是度最高的節(jié)點(diǎn)(即k=3)也有最大的p值。這些結(jié)果說明模塊間連邊的形成往往需要核心開發(fā)者的參與。

從p、z值的變化可以看出，模塊內(nèi)外連接的形成都與核心節(jié)點(diǎn)有關(guān)。結(jié)合網(wǎng)絡(luò)中度分布的冪率特性，可以推測出最大連通子圖上的連邊具有結(jié)構(gòu)上的傾向性。圖11進(jìn)一步繪制了最大連通子圖由T15到T16的演化過程中，不同度(k)節(jié)點(diǎn)新增連邊概率((k))的變化情況。從圖中看出，在雙對數(shù)坐標(biāo)下，節(jié)點(diǎn)新增連邊概率與其度值在總體上符合冪指數(shù)為1.56的冪律分布(紅色實(shí)線)，相應(yīng)二者呈現(xiàn)出較為明顯的正相關(guān)關(guān)系，即節(jié)點(diǎn)度越高，新增連邊數(shù)量越多。因此，網(wǎng)絡(luò)中新的協(xié)作關(guān)系的建立在結(jié)構(gòu)上具有傾向性連接的特點(diǎn)。

2)協(xié)作關(guān)系的屬性特性分析

為了描述開發(fā)人員的技術(shù)背景，本文將每位開發(fā)者對不同子項(xiàng)目的提交情況作為一個向量，然后利用式(3)計算具有模塊內(nèi)(或模塊間)連邊的節(jié)點(diǎn)的平均屬性相似度。

式(3)中，模塊內(nèi)外建立協(xié)作關(guān)系雙方的平均屬性相似度表示為S。Vi和Vj分別為開發(fā)者i和j(雙方擁有協(xié)作關(guān)系)的技術(shù)背景向量，r為子項(xiàng)目編號，因而相應(yīng)的，Vr,i則表示開發(fā)者i對子項(xiàng)目r的提交量，E表示模塊內(nèi)(或模塊間)協(xié)作關(guān)系的數(shù)量。

圖12 最大連通子圖(T16)模塊內(nèi)部及模塊之間協(xié)作雙方的平均屬性相似度

(3)

圖12繪制了T16最大連通子圖的模塊內(nèi)部及模塊之間協(xié)作雙方的平均屬性相似度。圖中，處于副對角線上的色塊表示模塊內(nèi)協(xié)作雙方的平均屬性相似度，其它色塊表示模塊間協(xié)作雙方的平均屬性相似度，顏色深度與平均屬性相似度數(shù)值正相關(guān)；帶有斜線的色塊表示對應(yīng)的兩個模塊間不存在協(xié)作關(guān)系。

從圖12可以觀察到，副對角線上色塊的數(shù)值較高(S≥0.6)，并且明顯高于同行(列)其它色塊的數(shù)值。例如，#4和#9模塊間存在協(xié)作關(guān)系，兩個模塊內(nèi)S值接近于0.9，而模塊間S值不超過0.5。這一結(jié)果意味著同一模塊的開發(fā)者在技術(shù)背景上往往具有較高的相似性，而跨模塊協(xié)作雙方則存在一定的差異性。

綜上，最大連通子圖每個模塊均由一定數(shù)量的邊緣開發(fā)者(k<6節(jié)點(diǎn))圍繞少數(shù)的核心開發(fā)者(k≥6節(jié)點(diǎn))構(gòu)成，并且不同模塊的核心開發(fā)者在一定程度上相互協(xié)作。由此，核心開發(fā)者在Cloud Foundry項(xiàng)目的開發(fā)過程中主要承擔(dān)了兩個角色，分別是模塊內(nèi)的中心角色和模塊間的中介角色。與此同時，同模塊的開發(fā)者往往表現(xiàn)出技術(shù)背景屬性上的相似性，而不同模塊的開發(fā)者間存在技術(shù)背景的差異性。因此，開發(fā)者協(xié)作行為表現(xiàn)出傾向性連接、同質(zhì)相吸、差異偏好相結(jié)合的特征。

3 與已有相關(guān)工作的對比

在已有的相關(guān)研究中，Joblin等[21]、以及夏昊翔等[2]的工作與本研究具有一定的相似之處，二者均聚焦于開源軟件開發(fā)活動中由開發(fā)者自發(fā)協(xié)調(diào)而形成的協(xié)作網(wǎng)絡(luò)的結(jié)構(gòu)狀態(tài)。但是，本研究與這兩項(xiàng)工作具有實(shí)質(zhì)上的不同。

Joblin等收集了18個開源軟件項(xiàng)目的提交記錄，通過代碼中函數(shù)的語義關(guān)系來描述開發(fā)者之間的協(xié)作關(guān)系并構(gòu)建相應(yīng)的協(xié)作網(wǎng)絡(luò)。研究結(jié)果顯示，這18個協(xié)作網(wǎng)絡(luò)的規(guī)模介于50到1 000之間，其中最大規(guī)模項(xiàng)目涉及的代碼量為1.7107行。與此同時，這些網(wǎng)絡(luò)均展現(xiàn)出了由松散連接狀態(tài)逐漸發(fā)展為緊密連接狀態(tài)的演化過程[16]。本文考查的Cloud Foundry社區(qū)開發(fā)者協(xié)作網(wǎng)絡(luò)的規(guī)模(整個網(wǎng)絡(luò)規(guī)模超過2 500，最大連通子圖規(guī)模接近2 000)以及所涉及的代碼量(6.86107行)明顯高于上述網(wǎng)絡(luò)。在結(jié)構(gòu)演化方面，雖然Cloud Foundry社區(qū)的開發(fā)者協(xié)作網(wǎng)絡(luò)的最大連通子圖最初表現(xiàn)為松散連接狀態(tài)，但是在隨后的演化過程中并不是發(fā)展為單一的緊密連接狀態(tài)，而是依次呈現(xiàn)出兩種不同的結(jié)構(gòu)特征(即鏈?zhǔn)浇Y(jié)構(gòu)和多模塊的小世界狀態(tài))。由此可見，Cloud Foundry社區(qū)的開發(fā)者協(xié)作網(wǎng)絡(luò)與Joblin等所考察的網(wǎng)絡(luò)具有不同的演化模式，這一現(xiàn)象可以通過軟件規(guī)模的差異加以解釋：Cloud Foundry項(xiàng)目在規(guī)模上遠(yuǎn)高于與Joblin等工作中所考察的項(xiàng)目，相應(yīng)會具有更高的功能復(fù)雜性，這不僅需要更多的開發(fā)者來實(shí)現(xiàn)軟件功能，也需要開發(fā)者之間形成更加精細(xì)的分工合作。進(jìn)而，大多數(shù)開發(fā)者圍繞特定的少數(shù)子項(xiàng)目展開提交工作，少數(shù)開發(fā)者對不同功能之間的開發(fā)工作進(jìn)行協(xié)調(diào)(如圖5和圖8所示)，促使協(xié)作網(wǎng)絡(luò)呈現(xiàn)出相互連接的模塊化結(jié)構(gòu)。小規(guī)模的開源軟件功能復(fù)雜性相對較低，開發(fā)者可以有足夠的精力參與多個軟件功能的開發(fā)工作，造成關(guān)注不同子項(xiàng)目的開發(fā)者之間協(xié)作關(guān)系緊密交織，繼而協(xié)作網(wǎng)絡(luò)宏觀上表現(xiàn)為緊密連接的狀態(tài)。

夏昊翔等利用開發(fā)者提交記錄中的子父哈希碼關(guān)系構(gòu)建OpenStack云計算項(xiàng)目社區(qū)的開發(fā)者協(xié)作網(wǎng)絡(luò)，通過對其靜態(tài)結(jié)構(gòu)及網(wǎng)絡(luò)社區(qū)(模塊)的演化的分析，發(fā)現(xiàn)網(wǎng)絡(luò)的最大連通子圖會呈現(xiàn)出多模塊的“核心—邊緣”結(jié)構(gòu)，并且模塊的演化(涌現(xiàn)、發(fā)展、合并)與子項(xiàng)目內(nèi)在關(guān)聯(lián)[2]。本文所考察的Cloud Foundry社區(qū)開發(fā)者協(xié)作網(wǎng)絡(luò)在規(guī)模和項(xiàng)目所屬領(lǐng)域上與夏昊翔等的研究工作是非常接近的，同時在網(wǎng)絡(luò)靜態(tài)結(jié)構(gòu)上也得到了相似的結(jié)論，這也進(jìn)一步說明大型開源軟件社區(qū)可能具有共性的協(xié)作模式。除此之外，我們進(jìn)一步發(fā)現(xiàn)最大連通子圖中的開發(fā)者與其維護(hù)的子項(xiàng)目所構(gòu)成的二分網(wǎng)絡(luò)具有很強(qiáng)的嵌套性，這一結(jié)構(gòu)一定程度上解釋了在開發(fā)者自愿加入或退出開源社區(qū)的情形下，Cloud Foundry社區(qū)依然能很好地保持項(xiàng)目開發(fā)的延續(xù)性。在網(wǎng)絡(luò)社區(qū)演化方面，本研究與夏昊翔等的結(jié)論是基本一致的。但是，與OpenStack項(xiàng)目協(xié)作網(wǎng)絡(luò)中的社區(qū)相比，Cloud Foundry項(xiàng)目協(xié)作網(wǎng)絡(luò)中的社區(qū)所關(guān)注的子項(xiàng)目更多。與此同時，OpenStack項(xiàng)目協(xié)作網(wǎng)絡(luò)中，兩個關(guān)注完全不同子項(xiàng)目的社區(qū)往往會進(jìn)行合并，而在Cloud Foundry項(xiàng)目協(xié)作網(wǎng)絡(luò)中我們也并未發(fā)現(xiàn)這一現(xiàn)象。出現(xiàn)上述不同的原因可能是由于兩個項(xiàng)目在云計算服務(wù)中的定位不同：與OpenStack的基礎(chǔ)設(shè)施服務(wù)(IaaS，Infrastructure as a Service)相比，Cloud Foundry所提供的平臺服務(wù)(PaaS，Platform as a Service)往往需要不同方面服務(wù)的復(fù)雜交互(如用戶在部署應(yīng)用權(quán)限和運(yùn)行環(huán)境的交互)，相應(yīng)關(guān)注功能關(guān)聯(lián)的子項(xiàng)目的開發(fā)者之間會形成緊密協(xié)作，進(jìn)而通過這些協(xié)作關(guān)系構(gòu)成網(wǎng)絡(luò)社區(qū)會涉及相對較多的子項(xiàng)目。另一方面，OpenStack提供的服務(wù)更加側(cè)重于云計算的基礎(chǔ)架構(gòu)，相應(yīng)子項(xiàng)目的功能劃分上更加獨(dú)立，進(jìn)而基礎(chǔ)架構(gòu)的變化會導(dǎo)致關(guān)注不同項(xiàng)目網(wǎng)絡(luò)的社區(qū)的合并。Cloud Foundry平臺服務(wù)處于云計算架構(gòu)的上層，使用戶在部署自身應(yīng)用時無需考慮計算、存儲等資源的分配，因而網(wǎng)絡(luò)社區(qū)會在軟件功能上形成劃分，相應(yīng)只有所關(guān)注軟件服務(wù)功能相近(如用戶應(yīng)用的部署及配置服務(wù))的網(wǎng)絡(luò)社區(qū)會發(fā)生合并。

4 結(jié)論

本文以Cloud Foundry開源軟件社區(qū)為例，考察了開發(fā)者協(xié)作網(wǎng)絡(luò)的結(jié)構(gòu)與演化模式。研究結(jié)果顯示，一個規(guī)模遠(yuǎn)大于其他子圖的最大連通子圖逐漸在網(wǎng)絡(luò)中涌現(xiàn)，并且相應(yīng)的開發(fā)人員承擔(dān)了整個項(xiàng)目的絕大多數(shù)開發(fā)工作。通過進(jìn)一步分析最大連通子圖的結(jié)構(gòu)演化，我們發(fā)現(xiàn)其呈現(xiàn)出與子項(xiàng)目(即軟件功能)內(nèi)在關(guān)聯(lián)的階段性演化過程，主要結(jié)論可以總結(jié)為以下兩點(diǎn)。

首先，最大連通子圖由最初的“松散連接”狀態(tài)，逐漸形成“鏈?zhǔn)健苯Y(jié)構(gòu)，最終演化為具有“核心—邊緣”結(jié)構(gòu)的多模塊小世界狀態(tài)。在這一過程中，最大連通子圖上模塊的涌現(xiàn)、發(fā)展和合并均較好地保持了所維護(hù)的子項(xiàng)目的聚焦性和延續(xù)性。

其次，最大連通子圖呈現(xiàn)多模塊小世界特征時，模塊內(nèi)協(xié)作關(guān)系具有同質(zhì)相吸和傾向性連接相結(jié)合的特點(diǎn)；模塊間的協(xié)作關(guān)系具有差異偏好的特點(diǎn)，并且這種偏好的出現(xiàn)與開發(fā)者現(xiàn)有合作者的數(shù)量(即節(jié)點(diǎn)的度)密切相關(guān)。

通過上述結(jié)果不難看出，Cloud Foundry開源軟件社區(qū)并不是現(xiàn)有研究(如文獻(xiàn)[4])所提出的扁平化、自由流動的組織模式，而是自發(fā)形成了一種高度模塊化的網(wǎng)絡(luò)型組織模式，這為后續(xù)的相關(guān)研究工作提供了一定的借鑒。同時，開源軟件開發(fā)作為一種具體的開放式創(chuàng)新活動，上述研究結(jié)果亦是對開放式創(chuàng)新相關(guān)研究的豐富。在后續(xù)研究中，筆者會針對不同領(lǐng)域的開源項(xiàng)目(如Tensorflow、AngularJS等)展開分析，以檢驗(yàn)本文結(jié)論是否具有普遍性。此外，筆者將將結(jié)合協(xié)作關(guān)系的特點(diǎn)開展模型化研究，繼而從復(fù)雜網(wǎng)絡(luò)動力學(xué)視角進(jìn)一步探查上述演化模式背后的動力學(xué)機(jī)制。