劉 鵬，張鵬臣，王念新

(江蘇科技大學經濟管理學院，江蘇 鎮(zhèn)江 212003)

0 引言

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

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

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

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

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

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

1 數據及分析方法

1.1 數據的獲取

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

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

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

1.2 分析方法

1.2.1 網絡構建方法

本文主要通過社區(qū)開發(fā)者之間的代碼協作關系構建開發(fā)者協作網絡，網絡構建過程分為以下步驟。

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

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

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

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

最后，在對數據集中的所有代碼協作關系抽取的基礎上，根據協作關系建立的時間戳的不同，以6個月的時間間隔構建不同時間窗(17個時間窗)下的累積協作網絡，如2010.8～2011.1的協作網絡、2010.8～2011.7的協作網絡等。

1.2.2 網絡分析方法

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

圖3 開發(fā)者協作網絡整體結構演化特性

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

2 分析結果

2.1 網絡的整體結構演化特性

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

圖4 各個時間窗下網絡的拓撲結構

圖5 開發(fā)者協作網絡的度分布及邊密度(T16)

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

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

表1 開發(fā)者協作網絡提交情況(T16)

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

圖6 最大連通子圖與外圍節(jié)點中開發(fā)者——子項目二分網絡嵌套性(T16)

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

圖7 最大連通子圖C、L、Q數值變化情況及典型拓撲結構

2.2 最大連通子圖結構及演化特性

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

2.2.1 宏觀層面分析

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

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

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

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

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

2.2.2 介觀層面分析

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

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

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

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

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

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

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

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

2.2.3 微觀層面分析

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

1)協作關系的結構特性分析

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

(1)

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

(2)

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

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

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

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

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

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

2)協作關系的屬性特性分析

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

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

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

(3)

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

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

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

3 與已有相關工作的對比

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

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

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

4 結論

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

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

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

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