開源軟件社區知識協作網絡核心開發者識別*
——以AngularJS為例

盧冬冬，吳 潔，劉 鵬，盛永祥

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

1 引言

隨著信息技術的進步，基于Web 2.0/3.0的各類在線社區孵化了一大批優秀的開源軟件產品[1,2]，這引起了社會各界的廣泛關注：國務院曾發文要將開源軟件社區發展納入創新戰略中；企業層面，諸如騰訊、阿里巴巴等也都積極地建設各自的開源項目社區。眾多開發者通過開源軟件社區參與到自己喜歡的項目中去，自發貢獻知識、分享知識、創造知識[3,4]。與其他在線社區類似，開源軟件社區中也存在著主導社區知識創造的核心開發者，這些核心開發者承擔了項目中的大部分代碼工作[5]，維系著眾多開發者之間的相互協作關系，促進了社區的集體智慧涌現[6]。因此，有效識別出核心開發者并施加保護手段對開源軟件社區中的知識創新活動具有重大的意義。

目前已有的核心開發者識別方法主要包括早期的簡單統計計數方法，Mockus等[7]通過統計代碼工作量，簡單、快速地識別出開源軟件社區中的核心開發者和邊緣開發者。也有相關學者關注到開發者的個體屬性和行為，Oliva等[8]通過問卷調查和個人訪談的結果來總結和描述核心開發者行為特點，并以此作為識別標準。廖志芳等[9]通過構建用戶行為分析模型OUBA-Model(Open source community User Behavior Analysis Model)識別開源軟件社區的關鍵用戶行為。這些方法雖然具有一定的優勢，但是往往會忽略用戶之間的交互行為。

近年來隨著網絡科學的發展，基于現實數據構建的社會網絡能夠較好地反映成員間的交互行為。眾多學者通過復雜網絡的方法發現了開源軟件協作網絡的中央邊緣結構，并從不同的角度展開了大量研究[10 - 12]。夏昊翔等[13]在研究OpenStack協作網絡演化時通過節點度的大小將開發者分成了核心開發者和一般開發者。李慧等[14]根據網絡中的入度、出度和介數等指標，對社區中的成員進行劃分。Joblin等[15]分析社區成員度和聚類系數，總結出核心成員在網絡中具有高成員度值和低聚類系數。Zhou等[16]在研究網絡魯棒性時則通過度和介數的大小對社區成員進行重要性識別。徐冰村等[17]通過度中心性DC(Degree Centrality)、介數中心性BC(Betweenness Centrality)和結構洞指數識別出開源社區中的意見領袖。

從上述研究中可見，目前已有研究多是通過社會網絡分析的方法進行評價指標的選取，但所選取的指標多是網絡中節點的基本拓撲參數，如出度、入度和介數等。這些指標雖然能夠反映節點在網絡中對其他節點的影響能力，也能反映節點在整個網絡中所處的位置特點，但尚未考慮到節點的局部特征，如節點之間的相互協作關系形成的社團結構是開源軟件項目開發進程中必不可少的[13,18]。因此，本文擬通過對節點的基礎指標做進一步處理，將節點局部特征即社團結構考慮進來，提出新的評價指標體系，識別出開源軟件社區知識協作網絡的核心開發者，從而對已有的指標體系進一步擴充，幫助項目管理者能夠更有效地識別核心開發者，促進社區知識創新。

2 網絡構建與指標分析

2.1 知識協作網絡構建

本文選取開源軟件社區GitHub的AngularJS項目作為研究對象，AngularJS是一款優秀的開源前端JS框架，已廣泛運用于Google的多款產品中。該項目目前包括Angular、Angular CLI、Angular Material和Angular Fire等多個子項目。

數據來源于GitHub中AngularJS的子項目庫，通過Git指令提取2010年8月(項目初始期)～2019年1月的7個主要子項目的代碼提交記錄，共計38 764條。記錄內容包含開發者郵箱、代碼提交日期、開發者姓名、修改文件數量和名稱等。

在此基礎上，通過Python語言編程實現開發者知識協作網絡的構建工作。為了排除數據噪聲干擾，以開發者郵箱作為識別開發者的唯一標識，將開發者抽象為網絡中的節點。同一版本時期內有針對同一文件進行代碼提交行為的開發者視為存在協作關系，將協作關系抽象成節點間的邊。網絡構建方法和過程如圖1所示。

表1為AngularJS項目知識協作網絡拓撲特征，網絡規模即網絡中節點數量，為3 982，說明累積到2019年1月共有3 982名開發者為AngularJS貢獻過自己的知識。平均聚集系數為0.656，平均路徑長度為4.135，說明該網絡符合小世界特性，開發者之間協作關系較為緊密。模塊度為0.593則說明該網絡中存在明顯的社團結構，說明有必要對成員進行子模塊劃分。本文采用FUOCILN算法[19]對網絡進行子模塊劃分。

Figure 1 Method and process of knowledge collaboration network construction

Table 1 Knowledge collaboration network topology parameters

2.2 評價指標分析

本文方法基于開源軟件社區知識協作網絡中開發者的結構特征，除了采用以往研究中提到的度中心性和介數中心性指標，還將考慮開發者節點的局部屬性，即網絡的社團結構。參照Guimera等[20]于2005年在生物新陳代謝網絡的背景下提出的模塊內參與度和模塊間參與度進行綜合分析，相關指標已被證實在探究網絡穩定性方法具有較好的效果[21]。具體評價指標如下所示：

(1)度中心性DC。節點度是與該節點相連的邊的數量，表示社區中與開發者形成協作關系的開發者人數，DC越大說明與該開發者形成知識協作行為的開發者人數越多，因此該開發者的影響力越大。目前已被廣泛直接用于探究網絡中節點的重要性排序問題。

在雙對數坐標系中繪制節點度k分布和冪律擬合圖(如圖2所示，其中p(k)為度分布圖中的概率分布)，擬合優度R2=0.94907。擬合優度較高，說明該網絡屬于無標度網絡，存在著較明顯的中央邊緣結構。網絡中高度節點較少，低度節點多，說明社區中存在著較為明顯的核心開發者，核心開發者間緊密協作關系能夠促進社區源源不斷地知識創新。因此，識別開源軟件知識協作網絡的核心開發者是具有重要意義的。

Figure 2 Degree distribution

(1)

表2所示為知識協作網絡開發者節點的度中心性和介數中心性。從表2中能夠明顯看出開發者節點之間的度中心性和介數中心性均存在較大的差異，并且開發者的度中心性和介數中心性也存在明顯的不對稱性，度中心性最大的開發者并不是介數中心性最大的開發者，說明網絡中協作關系最多的開發者并不一定是網絡中最重要的“橋梁”，有必要將二者綜合起來進行開發者的識別工作。

(3)模塊內參與度。模塊內參與度Zi用于度量節點i與其所處模塊內其他節點的“良好連接”程度，如式(2)所示：

(2)

Table 2 Developer network topology parameters

(4)模塊間參與度：模塊間參與度Pi用于度量節點i與其他模塊的連接程度，其計算方式如式(3)所示：

(3)

其中，NM表示整個網絡中的模塊數量，kis表示節點i在模塊s中的連邊數量，ki表示節點i在整個網絡中的度。如果一個節點的連邊在越多模塊中有所分布，那么它的模塊間參與度越大。如果它的所有連接都只在自己的模塊內部分布，那么它的模塊間參與度為0。

表3所示為開發者的模塊內參與度Z和模塊間參與度P的計算結果，可以明顯看出開發者節點的度中心性DC和模塊內參與度Z、模塊間參與度P3者之間均具有一定程度的不對稱性。度最大的開發者并不一定擁有最大的模塊內參與度，也不一定擁有最大的模塊間參與度。處在各自社團中心位置的開發者并不一定是網絡中最重要的開發者，也不一定是與外界社團聯系越廣泛的開發者。

Table 3 Z and P of developers

圖3所示為模塊內參與度Z和模塊間參與度P分布圖。由圖3可以看出，節點大多位于圖的左半部分，說明網絡中各節點的模塊內參與度Z相對較小，僅有少數的節點具有較高的模塊內參與度Z，而模塊間參與度P則分布得較為均勻，但也能發現高模塊間參與度P的區域較為稀疏。這種情況也能夠說明社區中具有高模塊內參與度Z和高模塊間參與度P的核心開發者較少，所選指標能夠擬合現實情況，具有一定的準確性。

Figure 3 Distribution of Z and P

3 基于TOPSIS的核心開發者識別

3.1 識別方法

對于擁有多個評價指標的決策方法，本文擬采用基于TOPSIS(Technique for Order Preference by Similarity to an Ideal Solution)的多屬性決策方法[23]進行開源軟件社區知識協作網絡的核心開發者識別工作。其中，“熵”作為描述系統混亂程度的量，引入信息論后得到了廣泛運用，熵權法[24]作為一種客觀賦權方法，能夠有效避免人為因素干擾，客觀地為指標賦值，更加具有可信度。具體步驟如下所示：

網絡中共n個節點，可以視為n個方案，每個方案都有m個評價指標，可構成n×m階矩陣M。

(4)

將指標矩陣M標準化，其中指標類型不同，所使用的方法也不一樣。

(5)

其中，I1為成本型指標集，I2為效益型指標，I3為固定型指標。成本型的指標認為指標數值越小越重要，效益型的指標則認為指標值越大越重要，固定型的指標認為越靠近某固定值r越重要。

用標準化后的指標構成新矩陣N。

(6)

假設第j項指標的熵記為Hj,j=1,2,…,m，其計算公式為：

(7)

根據式(7)進一步計算權重wj。

(8)

由此可得加權標準化的決策矩陣Y為：

(9)

將每個評價指標的最大值的集合作為正理想方案A+，最小值的集合作為負理想方案A-，計算各決策方案與正負理想方案的距離:

(10)

最后，按式(11)計算每個決策方案的貼近度Ti，可作為最終決策方案的評價指標，代表開源軟件社區知識協作網絡中的開發者節點重要性程度，即貼近度。

(11)

3.2 核心開發者識別

針對開源軟件社區知識協作網絡，本文采用考慮了開發者節點局部社團結構屬性的“模塊內參與度”和“模塊間參與度”2個指標進行核心開發者的識別工作。除此之外，本文亦考慮到已有研究中的度中心性和介數中心性，通過指標間的不同組合方案進行核心開發者的識別，并進行相關識別效果的對比。

首先將這4個指標按照DC,BC,Z,P的順序放在一起進行計算。上述4個指標均為效益型指標，其指標值越大，節點越重要，得到原始矩陣M和其標準化矩陣N如下所示：

(12)

(13)

由式(7)計算得信息熵為：

HDC=0.8669，HBC=0.6842，HZ=0.7406，HP=0.8051

接下來對指標方案進行分類討論：

方案A：傳統的識別方法,組合DC和BC2個指標。由式(8)計算可得各指標權重：wDC=0.297,wBC=0.703。根據式(9)～式(11)計算各節點的貼近度得分，取排序前10得到知識協作網絡的核心開發者，結果如表4所示。

Table 4 Core developers identified by scheme A

方案B：組合本文提出的模塊內參與度Z和模塊間參與度P。通過計算各指標權重可得：wZ=0.571,wP=0.429。根據式(9)～式(11)計算各節點的貼近度得分，取排序前10得到知識協作網絡的核心開發者，結果如表5所示。

Table 5 Core developers identified by scheme B

方案C：組合DC,BC,Z,P4個指標，通過計算能夠得到各指標權重：wDC=0.1474,wBC=0.3496,wZ=0.2872,wP=0.2158。根據式(9)～式(11)計算各節點的貼近度得分，取排序前10得到知識協作網絡的核心開發者，結果如表6所示。

Table 6 Core developers identified by scheme C

3種方案識別出的核心開發者具有較明顯的重疊性，如Id編號為：1907,97,2756,632,2628等成員。將結果與GitHub網站中AngularJS項目的子項目庫給出的貢獻者(contributors)進行對比可見，3種方案識別出的核心開發者的貢獻度(contribution)均超過了100。說明3種方案識別出的核心開發者均具有一定的準確性。但是，各方案內成員重要性排序具有一定的差異性，說明3種方案仍需進一步比較。

4 有效性檢測

4.1 有效性檢測指標

為了比較3種方案識別核心開發者的效果，將3種方案識別出的結果按照重要性排序依次從網絡中移除，仿真模擬核心開發者的流失，并對網絡進行抗詆毀性檢測。

通常被用來衡量網絡性能的指標有網絡聚類系數、平均最短路徑和最大連通圖等[25,26]。而網絡拓撲結構中最大連通子圖能夠衡量項目社區開發者之間協作關系的緊密性。當某些節點被移除后，會造成與其相連的一些節點與最大連通圖之間的協作關系中斷，從而脫離最大連通子圖。因此，本文采用最大連通子圖的相對大小S來衡量網絡的抗詆毀性。最大連通子圖相對大小S的計算如式(14)所示：

(14)

其中，n表示網絡中的節點總數，n′表示最大連通子圖中的節點數。最大連通子圖相對大小表示知識協作網絡的人員之間的緊密聯系程度，S越大代表各社區開發者之間協作程度越高，關系越緊密，該網絡的抗詆毀性也越強。若核心開發者的離開對網絡影響較小，則說明該核心開發者在網絡中并不一定是最重要的。

4.2 有效性檢測分析

為了明晰各指標方案識別核心開發者的效果，需要對網絡進行抗詆毀性檢測。通過仿真模擬方案A(DC+BC)、方案B(Z+P)和方案C(DC+BC+Z+P)所識別的核心開發者流失對網絡結構的影響，并將相關結果與DC排序、BC排序、隨機性移除(RA)進行對照，結果如圖4a所示。研究發現：相對于隨機開發者的流失，不管是何種方案下識別的核心開發者，其流失后都會導致大量的與之存在協作關系的開發者脫離網絡的最大連通子圖，對網絡結構的影響較大。說明核心開發者在網絡中占據著重要的位置，扮演著重要的角色，有必要對其加以保護。同時也說明本文提出的指標體系和以往研究中提出的度中心性、介數中心性都具有一定的準確性。

對比不同方案識別的核心開發者流失對網絡的影響能夠發現：在圖4a中，方案B始終都處于最下方，該方案識別的核心開發者流失將會導致網絡受到最嚴重的破壞，說明當僅僅使用了模塊內參與度和模塊間參與度這2個評價指標所識別出來的核心開發者重要性順序更優，效果最顯著。其他幾種方案識別的核心開發者流失對網絡結構的影響整體相差不大，但也能看出綜合考慮了4種指標的方案C略優于其他方案。因此，本文提出的考慮了開發者所處社團結構的指標體系(模塊內參與度和模塊間參與度)在識別核心開發者時具有一定的優勢。

另外，在有關模塊內參與度和模塊間參與度的計算過程中，本文使用的FUOCILN算法進行網絡模塊劃分，但Newman[27]也提出了相應的算法。由此，不同模塊劃分算法是否會對結果造成影響值得我們進一步探究。通過計算可以發現：2種算法下節點的模塊劃分結果和模塊內參與度、模塊間參與度初始值雖然具有一定的差異性，但經過歸一化處理與指標權重計算后，所得到的核心開發者名單具有極大的相似性。方案B(僅考慮模塊內參與度和模塊間參與度)中，Newman算法得到的核心開發者Id分別為：1907,1933,2756,451,97,632,2628,1905,730,148?？梢园l現，名單中僅有148#開發者和885#開發者存在差異，并且在重要性排序上和FUOCILN算法的結果差距不大。同樣地，綜合考慮了度中心性和介數中心性的方案C也有類似的情況。另外，對照項目在GitHub社區公布的開發者貢獻度可知，各開發者的貢獻度均高于100。從圖4b也能夠發現：模塊劃分算法雖然對網絡中節點的模塊內參與度和模塊間參與度的計算結果有影響，但是最終對于知識協作網絡核心開發者的識別結果影響不大，并且方案B始終優于方案C。

Figure 5 Demonstration diagram of complex network

4.3 結果討論

Figure 4 Anti-defamation detection of different schemes

從上述研究可以明顯看出：不管采用何種算法進行模塊劃分，考慮社團結構的指標體系識別出的核心開發者對網絡抗詆毀性的影響顯著高于傳統指標體系的，識別效果更優。究其原因：一方面，基于復雜網絡的相關知識，如圖5所示，圖5a中共計23個節點，可分為4個社團結構。通過計算網絡中各節點的評價指標可知節點3的度中心性、介數中心性和模塊間參與度均是最大的，分別為DC=7,BC=0.6124,P=0.6122；節點18的模塊內參與度Z=2.2678，在網絡各節點中模塊內參與度值是最大的。當按照傳統指標進行考慮時，節點3是網絡中最重要的，將其移除后節點4和節點5將會脫離最大連通子圖(如圖5c所示)；但如果考慮了社團結構，從模塊內參與度來看，節點18是網絡中最重要的，將其移除后節點19、節點21和節點22將會脫離最大連通子圖(如圖5b所示)。顯然，考慮社團結構識別出的節點18相較節點3能夠維系更多的節點保持在網絡的最大連通子圖之中。同樣模塊內參與度相對較大的節點6(Z=2.236)，雖然度中心性和介數中心性都不是最大的，但其流失后也會造成節點8、節點9和節點10脫離最大連通子圖(如圖5d所示)。由此可見，考慮社團結構識別出的重要節點對網絡結構影響更大。

另一方面，從現實角度來看，已有的大量研究也已經發現開發者協作網絡社團結構和子項目協同演化的現象，子項目與社團之間存在著顯著的關聯性[13,28]。開源軟件社區知識協作網絡中也存在著明顯的社團結構，當識別網絡中的核心開發者時，若僅僅考慮開發者節點在整個網絡中的結構屬性，往往容易忽略掉一些在整個網絡中并未占據重要位置但卻是某些子項目的核心開發者。故而加上考慮社團結構的模塊內參與度和模塊間參與度指標，能夠有效避免這類情況，識別效果更佳。

5 結束語

本文基于社會網絡分析的方法，以開源軟件社區AngularJS項目為實例，提出了一種開源軟件社區知識協作網絡核心開發者識別模型。在評價指標方面區別于以往只考慮度中心性和介數中心性，將開發者的局部特征即社團結構考慮進來，引入了模塊內參與度和模塊間參與度2個評價指標，基于TOPSIS多屬性決策方法識別出核心開發者。最后通過與真實數據對照以及網絡抗詆毀性的檢測探究方法的有效性，并將傳統的指標體系和本文提出的指標體系進行對比，驗證考慮了社團結構指標體系的優越性。研究發現：各方案識別出的核心開發者均具有一定的準確性，與網站給出的核心開發者重合度較高；引入社團結構的指標體系識別出的核心開發者有效性最顯著，識別效果最優。本文提出的指標一方面能夠進一步豐富開源軟件社區核心開發者識別模型的指標體系，具有一定的理論意義；另一方面也能夠為社區管理者提供一種更有效的核心開發者識別方法。同時，管理者在社區管理過程中不僅要考慮全局，也要重點關注一些子項目的核心開發者。

網絡科學飛速發展，在未來的研究中，我們將圍繞以下幾點進行探討：(1)是否可以借鑒Kojaku等[12]的研究通過構建開源軟件社區諸如知識網絡和協作網絡的多層復雜網絡，進行多層中央邊緣結構的相關研究；(2)借鑒Bertolero等[29]提出的復雜網絡中的“多元俱樂部”，探究開源軟件社區相關網絡中是否也存在著背景多元化的開發者社團結構現象；(3)在核心開發者識別的指標體系方面，雖然本文已經探討了社團結構的相關指標，但在此基礎上是否可以進一步借助Xu等[30]提出的“網關系數”探討開源軟件社區中的維系不同開發單元之間的協同的“網關”節點，值得深入研究。