開源軟件核心開發者流失的級聯效應仿真

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

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

0 引言

近年來，開源軟件蓬勃發展，廣泛運用于大數據、云計算、人工智能等諸多領域[1]。這引起了社會各界的廣泛關注，國務院也曾發文要將開源軟件社區的建設納入創新驅動戰略中去。與傳統商業軟件不同的是，基于web2.0/3.0的在線社區是推動開源軟件形成和發展的主要平臺。來自世界各地的開發者通過開源軟件社區協調合作，完成軟件項目的開發與迭代[2]。但開源軟件社區“集市型”的開發模式使得開發者能夠自由加入或退出項目的開發進程[3]。一旦出現核心開發者的流失將會使開發進程遭受重創，并引發一系列的級聯效應[4]。因此，從動態視角探究核心開發者流失對社區的影響并對其采取保護措施能夠有效提高社區的創新產出。

目前開源軟件社區已引起計算機、知識創新、管理等領域學者們的廣泛研究[5-8]。研究內容主要包括了開發者的協作模式機制、開發者類型劃分等。開發者協作模式機制方面：在Raymond提出的“集市模式”的基礎上[3]，一些學者認為開源軟件社區作為一種典型的開放式創新社區[9]，其開發過程是一種密集型的知識創造過程[10]，社區成員間的協作行為存在偏好連接、同質相吸的特征[1,5]；在子項目開發過程和開發者協作網絡的協同演化過程中，子項目與協作網絡中的社區結構存在顯著的相關性[6]。

開發者類型劃分方面：早期的研究中Mockus等人[11]基于簡單統計計數方法，通過代碼提交量區別開源軟件社區的核心開發者和邊緣開發者。繼而有相關研究關注到用戶行為：Nakakoji等[12]依據項目類型將開發者劃分為8種類型。Oliva等[13]基于問卷、訪談的結果來總結描述核心開發者行為特點，并以此作為識別標準。近年來，眾多學者基于復雜網絡的視角進行了眾多研究[6,14-18]，但多是基于度中心性大小、介數中心性大小或將兩者結合起來綜合考慮區分核心開發者和一般開發者，并在此基礎上通過探究網絡魯棒性(抗毀性)識別效果[6,14,17]。

上述研究使我們對開源軟件社區中的協作模式機制和開發者類型劃分方法有了更深入的認識，但還存在以下幾點有待進一步深化。在區分核心開發者的過程中，目前的已有研究多是從開發者節點在整體網絡中的拓撲結構特征(度、介數)出發。這些指標雖能反映開發者節點在網絡中的影響力，但是卻忽略了節點的局部特征社團結構(社區中開發者之間的協作關系形成的社團結構與項目開發存在顯著相關性)。在檢測識別效果方面，目前的研究中多是從靜態視角僅考慮節點流失后對網絡魯棒性的影響，尚未從動態視角探討節點流失對與其存在協作關系的開發者的影響。

由此，本文將以開源軟件項目AngularJS為例，通過收集開發者代碼提交記錄，抓取開發者協作關系來構建開發者協作網絡。在此基礎上將開發者社團結構考慮進來，識別核心開發者，并從動態視角探究核心開發者流失對社區內其他開發者造成的級聯效應。是對已有開發者類型區分方法的一種深化，也為網絡魯棒性檢測提供了新的視角，同時也是大型自組織系統研究的進一步擴充。

1 網絡構建及指標分析

1.1 開源軟件開發者協作網絡構建

本文選擇了GitHub社區中的AngularJS項目為研究對象，該項目誕生于2009年，現被Google收購，作為一款優秀的開源前端JS框架，已被用于多款Google產品中。GitHub是一個優秀的開源服務平臺，其Pull Request機制允許用戶任意參與到項目中去[19]，Git版本控制系統也記錄下了不同時段內所有開發者的代碼提交記錄。

源數據使用課題組實現的爬蟲工具，選取時間跨度為2010年8月(項目初始期)到2019年1月(本研究數據提取截止期)，抓取AngularJS代碼提交記錄共計38 764條，記錄內容包含開發者昵稱、注冊郵箱、代碼提交日期、修改文件數量、名稱和代碼增減行數等。

基于源數據，構建開發者協作網絡G=(V,E,W)。社區開發者用節點集合V表示，考慮到開發者昵稱可能出現重復的問題，以開發者注冊郵箱作為網絡節點標識。開發者間的協作關系用節點間的關系集合E表示，通過Python編程抽取開發者協作關系。由于軟件開發往往是基于舊版本的功能提升或完善，因此，在兩個版本發布間隔時間內針對同一文件進行代碼提交的開發者視為相互存在協作行為。兩個開發者之間的協作次數視為連邊的權重，用邊權重集合W表示。使用Gephi軟件可視化開發者協作網絡，并計算網絡基本拓撲參數(見表1)。網絡構建過程如圖1所示。

表1為構建的開發者協作網絡整體拓撲特征，節點數為3 982，說明截至本研究時期共計3 982位來自世界各地的開發者為AngularJS項目貢獻過自己的智慧。平均聚類系數為0.66，平均路徑長度為4.135，說明該協作網絡擁有小世界特性，社區中開發者協作關系緊密；模塊度為0.593則說明社區中存在著明顯的社團結構。

表1 開發者協作網絡拓撲參數

1.2 評價指標分析

目前的大多數研究中均是以度或介數對節點的重要性進行排序，但社區內開發者之間相互協作關系形成的社團結構(小團體)與子項目的開發進程存在著顯著相關性[6]，開發者在團體內部和團體之間的交互行為也能夠影響著開發者的重要性。基于此，將開發者節點的局部屬性即網絡的社團結構考慮進來，參照Guimera等[20]于2005年在生物新陳代謝網絡的背景下提出的模塊內參與度和模塊間參與度進行綜合分析。本文提出如下指標：

1)節點的度。度(ki)是指網絡中與節點i相連的其他節點數量。度大小能夠代表開發者的協作廣度，即與之存在協作關系的開發者的個數。圖2繪制了雙對數坐標下度的累積分布和冪律擬合函數。擬合優度R2=0.949，擬合效果非常好，說明網絡中存在著較明顯的核心邊緣結構，探究網絡中的核心開發者具有重要意義。

圖1 開發者協作網絡構建過程

圖2 度分布

2)節點加權度。加權度(Ki)是指網絡中與節點i相連的所有連邊權重總和。開源軟件社區中邊權重大小能夠代表相連兩個開發者的協作深度，即相連開發者之間的協作次數。開發者加權度則能夠代表開發者的總協作次數，加權度越大能夠表示開發者參與項目的積極性越高。

(1)

(2)

5)模塊間參與度：模塊間參與度(pi)用于衡量網絡中節點i與其他社團之間的協作關系密切程度[21]。開源軟件社區中，開發者的模塊間參與度越高表示該開發者參與其他小團體的數量越多，所承擔的小團體之間的“橋梁”作用越重要。式(3)為節點i的模塊間參與度，NM表示整個網絡中模塊的個數，kis表示節點i在模塊s中的度，ki表示節點i在整個網絡中的度。

(3)

2 核心開發者識別

根據上述各公式計算網絡中各節點的評價指標，計算結果如表2所示。

表2 開發者評價指標參數

已有研究中多采用度大小或介數中心性大小衡量核心開發者，本文考慮到開發者的社團結構屬性，將采用模塊內參與度和模塊間參與度兩個指標進行衡量。為了與已有研究形成對比，首先分別選取度大小排序、加權度大小排序、介數中心性大小排序下的前5位作為最重要的核心開發者，名單如表3所示。

針對多個評價指標組合，如傳統方法中度和介數中心性的組合、本文提出的模塊內參與度和模塊間參與度的指標組合方式，本文擬采用基于熵權法定權的多屬性決策方法對社區中有限的開發者進行重要性排序[22]，具體方法如下所述。

社區中共有3 982個開發者，可視為存在3 982個決策方案，設為Q={Q1,Q2,…,Q3 982}；4個評價指標(度、介數中心性、模塊內參與度、模塊間參與度)構成評價指標集S={S1,S2,S3,S4}。可構成3 982×4階原始決策矩陣M=(xij)3 982×4。

對原始數據進行歸一化處理形成標準決策矩陣N=(rij)3 982×4，其中：成本型指標認為指標數值越小越重要，效益型指標認為越大越重要，固定型指標認為越靠近某固定值越重要。故本文選取指標集中的指標均為效益型指標。接下來采用熵權法確定指標權重[22]，最終得到決策方案的總評價得分：

(4)

由此，可先將指標集放在一起計算，按照度(k)、介數中心性(b)、模塊內參與度(z)、模塊間參與度(p)的順序，計算得出原始矩陣M和標準化矩陣N如下：

采用熵權法計算指標權重，當指標選取度和介數中心性時，權重分別為

wk=0.297,wb=0.703

當指標選取模塊內參與度和模塊間參與度時，權重分別為

wz=0.571,wp=0.429

基于上述兩種指標組合，計算最終評價得分，選取排序前5位作為最重要的核心開發者，名單如表4所示。

綜上所述，結合已有研究中的指標和本文新提出的指標，最終識別出的核心開發者存在一定的相似性，但在重要性排序上存在著較明顯的差別。因此，本文將上述方法識別的結果均視為核心開發者，節點編號分別是：97,632,1 907,2 628,2 756,451,148,2 929,1 905。

表3 度、加權度、介數中心性排名前5開發者

表4 傳統指標和考慮社團結構指標識別的核心開發者

3 核心開發者流失的級聯效應

3.1 級聯效應描述

借鑒負載容量模型，探討社區內核心開發者流失時造成的級聯效應。一方面可以從動態視角探究核心開發者的流失對開源軟件社區穩定性的影響，另一方面也能夠借此揭示出開源軟件社區這種大規模自組織模式下的社區成員間的協作關系形成機制，更好地為項目管理者提出社區管理對策建議、規劃項目開發進程，促進社區的創新產出。目前的研究中[23-26]，學者們大都假定網絡中的節點存在“正常”和“失效”兩種狀態，即網絡中各節點由于其自身屬性問題會存在著一定的負載容量，當節點受到的負載大于其自身負載容量時，節點便處于“失效”狀態，反之為“正常”狀態。

對于本文而言，開源軟件社區中的開發者流動性的特點下，核心開發者的流失不僅僅會對網絡造成靜態效果下的影響，其所承擔的項目內容也將優先疏散到社區中與其存在協作關系的開發者，即工作負載會在社區開發者協作網絡的連邊中流動，進而可能會波及更多的開發者、造成范圍較大的影響，阻礙、延緩項目的開發進行，甚至導致項目的失敗。為了清晰地闡述這種動態的級聯影響過程，本文將作相應分析。

圖3 開發者流失的級聯效應示意

圖3反映了開發者節點流失后造成的級聯效應：初始階段(圖3a)網絡中各節點均處于正常狀態，社區工作正常穩定進行；突然某個時刻(圖3b)節點2出于自身或外界原因，選擇離開社區，處于“失效”狀態。原本需要開發者2負責的工作內容需要分配給與之存在協作關系，參與相同子項目的開發者(1,3,5,6,11,12)。此時(如圖3c)，面對新分配來的工作內容，有些開發者新的工作負載會大于其負載容量極限，不堪重負進入“失效”狀態(1,4,12)。而這些新“失效”的開發者的工作內容又會繼續分配給相應的開發者，造成更多的“失效”開發者8和9，如圖3d所示。

3.2 負載容量模型構建

經典的負載容量模型的構建主要需要解決以下3個方面的問題：初始負載的定義、負載重分配過程和節點處理負載的能力[27]。基于此，本文將從節點開發者的初始工作負荷、節點開發者的最大工作負載容量和節點開發者流失后如何影響鄰居節點三個方面構建開源軟件社區中的負載容量級聯失效模型。

開發者協作網絡中，節點的度大小代表了開發者的協作廣度，即與之存在協作關系的開發者個數。網絡中的邊則代表了開發者間的協作關系，邊權重則代表了相連兩個節點間的協作深度，即相連兩個開發者之間協作的次數。節點的加權度大小能夠綜合考慮該開發者的協作廣度和深度，可以基于度模型[23,28]構建改進的加權度負載容量模型。

1)節點的初始工作負荷：加權度大小能夠代表節點開發者的總的協作次數，加權度越大節點的初始工作負荷也越大，兩者之間存在著一定的關聯性。因此，可假設網絡中每一節點的初始工作負荷為它的加權度的函數，定義為

(5)

其中，Lj為節點j的初始工作負荷大小，Kj為節點j的加權度大小，α為可調參數，控制著不同加權度節點上的負荷差異性。

2)最大負載容量：通常情況下，節點處理負荷的能力均和其初始工作負荷有關，目前的眾多研究中，節點的最大負載容量均和初始工作負荷存在正比的關系，定義為

Cj=βLj

(6)

其中，Cj為節點j的最大負載容量，β為容量系數，β≥1。

3)負載重分配原則：當節點開發者i流失或崩潰后，開發者i上的工作負荷則需要重新分配到他的合作伙伴(鄰居節點)上。通常認為負載重分配原則受到開發者間的合作深度影響，即兩個開發者間合作次數越多，合作關系越緊密，那么開發者i流失或崩潰后，開發者j收到的來自i的工作負荷越大，定義為

(7)

其中，ΔLji為節點j收到來自節點i的額外工作負荷，wij為節點i和節點j之間的連邊權重。當節點i和節點j之間連邊權重占節點i加權度的比重越大，節點j收到來自節點i的額外工作負荷也就越大。

當開發者j的鄰居節點流失或失效后，開發者j的初始負荷加上來自失效節點的額外負荷大于開發者j的最大負載容量時，開發者j也會隨之崩潰，處于“失效”狀態，反之“正常”。因此，開發者j的工作狀態sj可以表示為

(8)

其中,ΔLj*為節點j收到的所有失效鄰居節點的額外負荷。

3.3 級聯效應仿真

本文探究識別的核心開發者流失后對網絡的動態影響，需要對網絡進行蓄意攻擊，模擬核心開發者流失，進行仿真分析。開源軟件社區中，開發者均是利用自己的空閑時間自發進行知識貢獻行為。因此，開發者的最大負載容量會存在限制。與此同時，開發者在進行代碼提交時，其修改或提交內容都需要被項目維護者進行比較和挑選。項目維護者會挑選出最優的內容加入到原有項目庫中。因此，被記錄下來的提交次數均是具備相應的工作量的。而開發者在每次代碼提交時涉及到的文件數有時并不只是1個，但由于開發者的空閑時間有限，每次提交所涉及到的知識貢獻量以及開發者所能承受的最大工作量都不會很大，可對初始工作負荷中的可調參數取值α=1.1。最大負載容量通常不會比初始負荷大很多，容量系數越大，級聯失效現象越不明顯，擬對容量系數取值β=1.3。

仿真結果：核心開發者的流失勢必會嚴重破壞網絡的靜態結構，同時還會造成眾多開發者隨之“失效”。根據圖4一次傳播的級聯效應仿真結果，能夠明顯看出：核心開發者的流失會導致與之存在協作關系的大量開發者崩潰失效；其中一次傳播失效影響最嚴重的是編號2756的開發者，其流失后會導致76位開發者隨之失效，占據了其所有合作者數量的58.9%。該名開發者是本文所提出的模塊內參與度和模塊間參與度指標下識別出重要性排序第1的核心開發者；度排序第1的開發者97流失后導致54人失效；介數中心性排序第1，同時也是度和介數中心性綜合考慮排序第1的開發者1907，其流失后導致59人失效；加權度排序第1的開發者148流失后導致失效的開發者人數相對較少，僅有41人，這也是所有核心開發者中除了451之外導致失效開發者最少的開發者，但失效節點占比卻高達40.6%。

上述結果可以看出：節點的加權度決定了節點的初始工作負荷，當開發者節點加權度越大時，所承擔的初始工作負荷也越大，若該開發者流失理應導致網絡中多數的開發者隨之“崩潰失效”。但是仿真結果卻可以看出，網絡中初始工作負荷最大的開發者148流失后卻沒有導致最多人數、最大占比的開發者隨之“崩潰失效”。究其原因：開發者148僅少部分存在與之協作關系十分緊密的開發者，這部分的開發者在148流失后的負載重分配原則中收到了更多的來自148的額外工作負荷。而其余與148存在協作關系的開發者可能因其關系不緊密，收到的額外工作負荷相對較少。當我們考慮了開發者的社團結構特征后，最重要的開發者2756流失后造成的最多人數、最大占比的開發者隨之崩潰失效。可以清楚地看出：盡管需要重新分配的工作負荷沒有最大，但因其與協作者之間均能夠保持著相對平均的協作密切程度，所以負載重分配過程中影響了更多的合作者隨之崩潰失效。

圖4 一次傳播下的級聯效應

圖5 二次傳播下的級聯效應

考慮二次傳播的級聯效應時(見圖5)，可以發現在第二次傳播過程中隨之“崩潰失效”的開發者人數較多的分別是編號148導致119人失效，編號2628導致89人失效，編號1905導致88人失效。雖然考慮社團結構的編號2756開發者在第二次傳播過程中僅導致79人隨之“崩潰失效”，但失效占比中卻是所有核心開發者中最高的。當考慮總失效人數時，最多的分別是編號148導致160人失效，編號2756導致155人失效，編號2929和2628均導致137人失效，編號1905導致134人失效，但失效人數總占比最高的仍然是開發者2756。

可以清晰地看出加權度大小排序下的核心開發者在二次傳播中也能夠影響較多的開發者隨之失效，但占比卻不是最高的。究其原因：一些度大的開發者之間會存在著相互協作關系，當發生二次傳播時波及到的開發者人數較多，影響范圍較廣，失效的開發者也會隨之增多，但是開發者間的協作關系并不緊密，導致失效人數占比不高。這也說明了社區知識創造過程中的“同質相吸”現象，度大的開發者之間存在緊密協作關系。當考慮社團結構所識別出的核心開發者，即那些既活躍在社團內部又游走于其他社團間的開發者，盡管他們的工作負荷并不是最大的，但由于與眾多開發者間均存在緊密協作關系，能夠造成極為嚴重的級聯失效現象。

綜上所述：擁有較大的工作負荷、占據網絡中重要位置的核心開發者，如度、介數較大的開發者流失后會造成社區中眾多開發者隨之“崩潰失效”。核心開發者間的緊密協作關系也導致初始工作負荷較大的開發者在二次傳播過程中造成了影響范圍更廣、更深遠的級聯失效現象。考慮社團結構識別出的核心開發者，既能占據其社團內部的核心位置，又是其他社團之間的“橋梁、要塞”，這類開發者盡管沒有承擔最強的工作負荷，卻因其相對平均的協作關系密切程度，造成了極為嚴重的級聯失效現象。

可見，開源軟件社區自組織演化過程中的“同質相吸”現象會導致核心開發者間存在緊密協作關系，倘若出現核心開發者的流失將會導致極為嚴重的級聯失效現象。在社區發展過程中，管理者有必要進行相應的人為干預。

4 結論與展望

為了探究核心開發者流失造成的級聯失效現象，本文基于已有指標提出了考慮開發者節點局部屬性的指標體系，基于多屬性決策的方法識別出來核心開發者，并在此基礎上構建了改進的負載容量模型，仿真模擬了一次傳播和二次傳播下核心開發者流失造成的級聯效應。得到幾點結論：1)開源軟件社區網絡中存在較明顯的核心邊緣結構，核心開發者之間也存在著緊密協作關系，這導致社區在面對核心開發者流失時會存在著較為明顯的級聯失效現象，會嚴重影響開源軟件社區的創新產出。2)基于社團結構提出的模塊內參與度和模塊間參與度所識別出的核心開發者不管是在一次傳播還是二次傳播的級聯效應下導致失效的開發者數量都相對較多。因此，在往后的研究中，有必要將開發者的局部屬性考慮進去識別核心開發者。3)開源軟件社區中，開發者的初始工作負荷和負載重分配原則對于級聯效應影響較大，特別是二次傳播情況下，初始工作負荷較大開發者會造成影響范圍更廣、更深遠的級聯失效現象。因此，有必要及時制止網絡中級聯失效現象的產生，杜絕二次傳播的風險。

由此，對社區在管理運營過程中提出以下幾點建議：在核心開發者識別上，不能再僅僅依靠傳統指標如度、介數等，有必要將社區中的社團結構考慮進來。在項目開發過程中，要重點關注核心開發者，特別是那些既能活躍在其社團內部又能活躍于其他社團間的開發者的動態。當出現核心開發者流失的情況時，應及時填補空缺，遏制風險的二次傳播。在工作內容發布時，應注重各子項目工作量的劃分，時刻關注社區內部開發者的工作負荷分配情況，不能使少數開發者承擔繁重的開發任務。管理者也應積極推廣項目，吸引更多的新開發者加入進來，積極鼓勵更多的開發者參與到核心技術的開發過程中去，使社區形成多核的局面，以此減少核心開發者之間的協作關系，降低級聯失效的風險。

基于上述結論不難看出：借鑒負載容量模型，探討社區內核心開發者流失時造成的級聯效應具有一定的理論意義；將考慮了開發者局部屬性的社團結構指標加入進來識別的核心開發者相對傳統指標也具有更優的識別效果。一方面創新性地從動態視角探討了核心開發者流失造成的影響，另一方面也是對開源軟件社區這種大規模自組織工作模式研究的推進，也有利于項目管理者更好地規劃項目開發進程，促進社區的集體智慧。

然而，本文目前仍然存在著一些不足。在構建負載容量模型時僅僅基于當前較為簡單的度模型進行了簡單的改進。仿真分析時，為了簡化討論過程網絡中所有節點的容量系數均取β=1.3，這些都是理想化的，真實系統中每個開發者節點的容量系數并不一定完全相同。因此，模型復雜化、開發者流失和容量系數多樣化這些均是本文后續研究的深化。