群體軟件開發中核心-邊緣開發者的區分研究

常志遠 何鵬

摘 要：在社區化群體軟件開發中，開發者根據角色的差異常被分為核心和邊緣兩類。以往區分兩類開發者，是基于開發者的代碼提交量，但此方法的通用性還需考察。為改善現有方法，使用關聯視角來看待開發者角色，運用開發者網絡來模擬社區組織結構，并根據開發者在組織結構中的職位穩定性進行檢測。研究表明，文中所提方法具有較好的有效性，且通過關聯視角發現核心開發者的職位穩定性比邊緣開發者更高、開發合作性更強。

關鍵詞：群體軟件開發;開發者網絡;核心開發者;邊緣開發者;計算機;網絡社區

中圖分類號：TP274文獻標識碼：A文章編號：2095-1302（2019）04-00-05

0 引 言

著名的“洋蔥”模型為開源軟件項目的成員設有8種角色，分別面向用戶、測試者和開發者。通過該模型可知，不同角色之間成員規模差異明顯。大量實證研究證明模型中開發者的代碼貢獻度呈“長尾”分布，即一小部分的開發者承擔了絕大部分工作。由此，開發者角色也被分為核心開發者與邊緣開發者兩類。核心開發者在項目中扮演重要角色并且形成領導結構，大量、長期的參與項目開發[1]。相反，邊緣開發者通常只做Bug修復或小的改善工作，在項目開發中的參與度較低。

一般看來，項目中邊緣開發者無足輕重，因為他們的知識儲備不夠并且缺乏改變。但也有研究表明：邊緣開發者在項目開發中與核心開發者一樣重要[2]。

在“many eyes”假說中，邊緣開發者尤為重要。此假說設想當源代碼被越來越多的人仔細檢查后，Bug將無所遁形。這也常被用來解釋為什么開源項目質量更高。

盡管現有研究中對核心與邊緣開發者的特性和兩者之間的相互影響有所認識，但仍存在兩個問題。首先，一個區分開發者角色的合適方法，對驗證軟件開發中的協作理論十分重要，而現有一些方法只采用簡單的概念區分。例如，僅以開發者提交的代碼行數來區分，當遇到只做大量瑣碎修復任務的開發者時，這種方法就會存在偏差。其次，區分核心-邊緣開發者的技術過于簡單，在描述角色時缺乏豐富性，導致難以發現開發者之間的關系，造成關聯視角缺失。

本文首先對10個大型開源項目的版本控制日志和開發者郵件列表數據進行分析，發現大多數已有區分核心-邊緣開發者方法具有一致性。其次，構建開發者合作網絡模型，采用網絡分析方法探索軟件項目中，隨著成員組織結構的不斷發展，核心開發者與邊緣開發者的特征變化。值得注意的是，本文發現核心開發者與邊緣開發者相比，在組織結構中擁有更高的位置穩定性和全局中心性。此外，核心開發者之間更可能相互合作，邊緣開發者也更傾向于與核心開發者合作，說明對邊緣開發者的認識不能只被視為沒有核心開發者活躍，他們還與核心開發者有大量交互。

本文的主要貢獻歸納如下：

（1）研究了10個大型開源項目，評估了采用基于計數方式區分核心-邊緣開發者的正確性。

（2）識別開發者組織結構特征，采用網絡分析方法掌握了核心-邊緣開發者的抽象概念，并證明了所得結果與以計數方法所得結果大致相同。

1 基于計數度量的方法

基于已有文獻，已有三種度量核心-邊緣開發者的方

法[3-5]普遍采用相應的閾值來區分核心和邊緣開發者。根據二八定律，采取其中的80%作為閾值。

1.1 提交數

提交數是開發者已授權且合并到主分支的git提交次數。一次提交代表在源代碼上做了相關修改。核心開發者通常會對代碼庫做頻繁修改，理論上，核心開發者的提交數將遠高于邊緣開發者。

1.2 代碼行數

代碼行數是開發者授權后增加和刪除代碼行數的總數，與提交數相似。由于核心開發者承擔了大部分修改任務，他們修改的代碼行數多于邊緣開發者。然而，一種潛在的問題是，當開發者只做大量瑣碎的修改時，這種基于代碼行數的方法將影響區分結果。

1.3 郵件數

郵件數是開發者提交到郵件列表的郵件數量。核心開發者通常掌握深入的技術知識，而郵件列表是分享這些知識的主要平臺。核心開發者通過對整改提建議，討論潛在的挑戰，以及對其他開發者提出的修改意見作評價，分享和體現他們的專業知識。通常在時間上，核心開發者參與項目更集中且更持久，比邊緣開發者更具有責任感，因此核心開發者對郵件列表的貢獻更多。該法也只是一種簡單的度量方法，因為開發者回答問題和問問題的次數是相等的，同樣此方法并沒有突出交流方。

上述三種度量方法都已被用于區分核心-邊緣開發者工作，但終究只是復雜概念的簡單抽象，忽略了開發者之間交互信息的刻畫，導致區分方法的結果缺少實際價值。為此，本文提出一種在開發者合作與交流中存在的關聯視角，以期得到更多軟件工程中的實際關聯信息。

2 基于開發者網絡的度量方法

開發者網絡是對開發者關系的抽象化，將開發者作為節點，開發者之間的社交或技術交流作為邊。依托開發者網絡有助于發現如下特性：

（1）結構的一致性（兩個節點有相同的鄰居節點），可揭示哪些核心開發者們有相似的技能，從而選擇合適的開發者來分擔或替換開發任務;

（2）核心開發者之間的結構洞（Structural Hole）可推測出彼此合作上存在的問題;

（3）只以一名核心開發者作為全局中心，可能會存在組織風險。

2.1 網絡模型

通過對版本控制系統中提交日志和郵件列表的數據進行分析，了解核心開發者與邊緣開發者之間的交互關系。先前的研究表明開發者的角色會隨時間而變化[6]。為回答這個問題，本文使用時間序列分析窗口，分析一個項目在一年中多個相鄰時間段的情況。分析時間跨度為三個月，相鄰間隔為兩周，超過三個月，開發社區不會有重大改變，但在開發活動中暫時的決定會被丟失[7]。

2.2 開發者網絡中的核心開發者和邊緣開發者

本文將介紹五種依賴開發者網絡的網絡分析方法。

2.2.1 度中心性

度中心性用來度量網絡局部重要性，它代表開發者與其他開發者直接連邊的條數[8]。作為領導結構中的重要成員，核心開發者之間會有交流，還會對邊緣開發者進行技術指導。邊緣開發者可能只做與其他任務關聯不大的小改動，因此在開發者社區中與其他人的交互關系很少。所以核心開發者的度中心性高于邊緣開發者。

2.2.2 特征向量中心性

特征向量中心性是一種全局中心性度量方法，代表著開發者所預期的重要程度，通過是否和許多開發者有關聯或是否和處于全局核心的開發者有關聯來判斷。因為核心開發者在組織結構中至關重要，所以他們在開發者網絡中位于全局中心的位置。

2.2.3 層級

層級是有分層節點結構的網絡，就好像凝聚的小團體嵌入在缺少凝聚的大團體中。在層級網絡中，高層級節點之間的邊通常會跨過聚集組來降低它們的集群系數。已有研究表明，開發者們易于形成緊密的社區[9]，本文預測核心開發者扮演著協調社區其他開發者工作的角色。如果假設為真，則核心開發者會擁有高節點度和低聚類系數，屬于層級網絡中的高層;同時邊緣開發者顯示出低節點度和高聚類系數，屬于層級網絡中的低層。

2.2.4 角色穩定性

角色穩定性是開發者在不同角色轉換中的時間屬性。通過觀察隨時間變化后開發者網絡的變化，研究開發者在不同角色中轉換的模式。核心開發者因長期參與項目并且在特定領域擁有廣博的知識，通常擁有很高的可靠性。因此，在開發者網絡中核心開發者的角色穩定性應高于邊緣開發者。

2.2.5 核心-邊緣塊模型

核心-邊緣塊模型是一種形式化，用基于鄰接矩陣的表達獲取核心-邊緣結構的概念。這個模型描述了一組和許多其他節點相連的核心節點，被一組沒有和其他節點相連的邊緣節點所圍繞?？捎脕頊y試由度中心性區分的核心-邊緣開發者是否和采用塊模型在開發者網絡中得到的核心-邊緣開發者的位置一致。從塊模型可知，每一區組邊存在的可能性不同但又有關聯，p核心-核心>p核心-邊緣>p邊緣-邊緣。塊模型方法表示核心開發者通常能融洽的與他人配合，表現為在開發者網絡中和其余節點有緊密聯系。邊緣開發者經常依賴核心開發者的知識和幫助去完成他們的項目，因此邊緣開發者和核心開發者聯系緊密[10]。

3 實證研究

3.1 選用項目

本文選取10個開源項目，見表1所列，為了使實證結果具有代表性，所選項目需滿足以下條件：

（1）規模：源代碼在5萬行到16萬行之間，開發者規模在15～1 000人之間;

（2）時間：均從開發者的第一次提交開始計算;

（3）技術：綜合考慮項目的編程語言和庫的使用情況;

（4）應用領域：涉及操作系統、開發等。

3.2 研究問題

問題1：基于版本控制系統和列表郵件的數據來區分核心-邊緣開發者的方法之間是否具有一致性？

問題2：基于網絡分析的方法是否比基于計數方法的效果更好？

3.3 Cohens kappa系數

現有的區分核心和邊緣開發者的方法比較有效，即使不同區分方法的抽象概念一致，結果也不可能完全一致。然而，區分方法如果一致，結果的一致性一定比隨意分配開發者的一致性高?？紤]到本文開發者核心與邊緣兩類角色成員的頻率次數不對稱，即大量開發者是邊緣開發者，只有小部分為核心開發者，因此為檢測核心-邊緣開發者區分方法的一致性，本文采用Cohens kappa系數：式中：po是兩種方法區分同一類開發者角色一致性的次數與開發者總數的比例;pe是隨機分配下開發者的比例。Cohens kappa系數的范圍和對應一致性的強度見表2所列。

4 實驗結果

4.1 基于計數度量方法的一致性驗證

為驗證現有各種基于計數度量方法在區分核心-邊緣開發者角色上結果的一致性，本文分別分析了基于開發者的提交數、代碼行數、郵件數方法之間的兩兩一致性。QEMU項目的時間序列呈現結果如圖1所示。從中可以看出，一致性系數均為一般以上（即高于0.2），高于隨機區分所得的一致性。說明不同的基于計數度量方法大體吻合。由圖1還不難發現，基于提交數的方法與基于代碼行數的方法之間表現為高度一致性（約0.75）。另外，無論哪種方法，一致性均隨時間變化保持相對穩定。

綜上，結果證明在區分開發者的核心-邊緣角色中，采用不同的基于計數度量方法產生的結果基本一致，尤其是基于提交數和代碼行數。

4.2 基于開發者網絡的度量方法

4.2.1 層級

在分層網絡中，頂層的節點有高節點度和低聚類系數;底層節點有低節點度和高聚類系數。QEMU項目的節點度與聚類系數呈現結果如圖2所示，可發現節點度和聚類系數有明顯的依賴關系[11]。高節點度的節點會有低聚類系數，在2.2節中表明有這種特征的節點為核心開發者;低節點度的節點會有高聚類系數，這類節點被認為是邊緣開發者。

4.2.2 穩定性

在項目中履行自己的職責，并在之后的開發中一直有參與的開發者被認為是穩定的開發者。時間分辨方法通過檢測開發者是否由一個狀態轉化為另一狀態來研究角色的穩定性。QEMU項目中開發者的狀態轉換如圖3所示。開發者狀態轉化的可能性由馬爾可夫鏈表示。發現處于核心狀態的開發者與處于邊緣狀態的開發者相比，更能保持他們的原有狀態，并很少轉化為離開狀態（離開項目）或隔離狀態（開發者網絡中無相鄰節點，只做單獨的任務）?；谶@一結論，核心開發者判定為是比邊緣開發者更穩定的群體。

4.2.3 核心-邊緣塊模型

核心-邊緣塊模型描述：核心和邊緣開發者群體作為特定的兩類節點被安置在網絡中。為測試實證數據是否由核心-邊緣塊模型所描述，必須計算核心-核心、核心-邊緣和邊緣-邊緣邊的存在可能性。如果邊的存在可能性按照：p核心-核心>p核心-邊緣>p邊緣-邊緣的順序排列，我們可以推斷出核心開發者在項目中協調能力最強，邊緣開發者主要和核心開發者協作，且很少會與其他邊緣開發者合作。

所有項目的3類邊存在的概率見表3所列。核心-核心邊存在可能性的平均值為4.02×10-1，核心-邊緣邊存在可能性的平均值為3.30×10-2，邊緣-邊緣邊存在可能性的平均值為1.28×10-1。由此可發現邊緣開發者和核心開發者合作的可能性是與邊緣開發者合作的兩倍。

在表3中，Linux項目邊存在可能性比其他項目都低，并且在同一項目中，核心-核心邊的存在可能性與另外兩條邊的存在可能性差兩個數量級。PostgreSQL項目核心-核心邊存在可能性為1，遠高出其他項目，核心-邊緣邊的存在可能性亦如此。在開發人數上這兩個項目很特殊：Linux項目的開發人數（1 467人）遠大于其他項目，PostgreSQL項目的開發人數（17人）遠小于其他項目。結果顯示項目的規模會影響開發者的合作關系，并且對邊緣開發者的影響極大。

綜上，網絡分析方法清楚地展示了早期實證工作中提出的核心-邊緣開發者的抽象特征。此外 ，結合核心-邊緣塊模型，發現開發者角色有特定的優先合作順序。

4.3 網絡分析方法和計數方法的一致性

上述實驗結果已證明了基于計數度量方法之間的一致性，以及開發者網絡中核心-邊緣開發者的獨特性。本節重點分析網絡分析方法和計數度量方法的一致性。網絡分析方法中的穩定性和核心-邊緣塊模型區分方法沒有列出，因為它們都源于度中心性。成對的計數方法和網絡分析方法之間的一致性如圖4所示。

總體來說，成對比較的一致性均為一般以上（即高于0.2），高于隨機區分時的一致性。此外，使用相同數據來源的區分方法間表現為高度一致性（約0.75）。因此，總體上網絡分析方法和計數方法的結果是一致的。然而其一致性是有缺陷的，其不一致性和計數方法中的不一致性相似。

5 結 語

軟件開發者在軟件項目中會扮演不同的角色。了解開發者角色的特征，可減少開發者合作中需要的溝通成本。本文以10個開源項目為分析對象，驗證了傳統核心-邊緣開發者角色度量方法的一致性。同時，本文也使用開發者網絡建立關聯視角，提出了一系列基于網絡的度量方法，如職位穩定性、層級和核心-邊緣塊模型，以此來探索核心開發者和邊緣開發者的不同之處，并驗證所提方法與已有方法的一致性。

參 考 文 獻

[1] CROWSTON K，WEI K，LI K，et al.Core and Periphery in Free/Libre and Open Source Software Team Communications[C]// In Proc.International Conference on System Sciences.IEEE Computer Society，2006.

[2] RAYMOND E.The cathedral and the bazaar knowledge[J].Technology & policy，12（3）：23-49.

[3] MOCKUS A，FIELDING R T，HERBSLEB J D.Two case studies of open source software development：Apache and Mozilla[J].ACM transactions software engineering methodology，2002，11（3）：309-346.

[4] TERCEIRO A，RIOS L R，CHAVEZ C.An empirical study on the structural complexity introduced by core and peripheral developers in free software projects[Z].In Proc.Brazilian symposium on software engineering，IEEE，2010.

[5] ROBLES G，GONZALEZ BARAHONA J M，HERRAIZ I.Evolution of the core team of developers in libre software projects[Z].In Proc.mining software repositories，IEEE，2009：167-170.

[6] JENSEN C，SCACCHI W.Role Migration and Advancement Processes in OSSD Projects： A comparative Case Study[C]// In Proc.International Conference on Software Engineering，IEEE Computer Society，2007：364-374.

[7] MENEELY A，WILLIAMS L.Socio-technical Developer Networks： Should We Trust Our Measurements？[C]// In Proc.International Conference on Software Engineering，ACM，2011：281-290.

[8] BRANDES U，ERLEBACH T.Network Analysis：Methodological Foundations （Lecture Notes in Computer Science）[Z].Springer-Verlag New York，Inc.，Secaucus，NJ，USA，2005.

[9] JOBLIN M，MAUERER W，APEL S，et al.From Developer Networks to Verified Communities：A Fine-Grained Approach[C]// In Proc.International Conference on Software Engineering，IEEE，2015：563-573.

[10] ZHANG X，MARTIN T，E J NEWMAN M.Identification of core-periphery structure in networks[Z].Phys.Rev.E，Mar，2015.

[11] RAVASZ E，BARABASI A L.Hierarchical organization in complex networks[J].Physical review E，2003，67（2）：26112.