群体软件开发中核心-边缘开发者的区分研究

常志远 何鹏

摘 要：在社区化群体软件开发中，开发者根据角色的差异常被分为核心和边缘两类。以往区分两类开发者，是基于开发者的代码提交量，但此方法的通用性还需考察。为改善现有方法，使用关联视角来看待开发者角色，运用开发者网络来模拟社区组织结构，并根据开发者在组织结构中的职位稳定性进行检测。研究表明，文中所提方法具有较好的有效性，且通過关联视角发现核心开发者的职位稳定性比边缘开发者更高、开发合作性更强。

关键词：群体软件开发;开发者网络;核心开发者;边缘开发者;计算机;网络社区

中图分类号：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 核心-边缘块模型

核心-边缘块模型是一种形式化，用基于邻接矩阵的表达获取核心-边缘结构的概念。这个模型描述了一组和许多其他节点相连的核心节点，被一组没有和其他节点相连的边缘节点所围绕。可用来测试由度中心性区分的核心-边缘开发者是否和采用块模型在开发者网络中得到的核心-边缘开发者的位置一致。从块模型可知，每一区组边存在的可能性不同但又有关联，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.