开源软件社区开发者合作网络稳定性研究——以AngularJS为例

卢冬冬，吴 洁，刘 鹏，盛永祥

(江苏科技大学经济管理学院，江苏 镇江 212003)

0 引言

随着信息技术的发展，开源软件逐渐兴起，如腾讯、阿里巴巴等公司也大力开展各自的开源软件项目。与传统的商业软件开发不同的是，开源软件项目往往是由众多开发者通过开源软件社区自发进行交流和分工合作[1]，促进集体智慧的涌现。其中，开源软件社区具有开放特性，这使得项目参与者能够自由进入或退出项目[2]。这种自组织模式下人员的流动性对社区中开发者之间交互合作关系具有重要影响[3]。一旦出现人员大规模流失则会导致项目开发进程存在巨大风险。因此，探究开发者合作网络在面临人员流失时的稳定性具有重要意义，有利于促进这种大规模、自组织的创新系统中集体智慧的涌现。

已有的开源软件社区相关研究中，学者们多从网络视角构建了开发者协作网络并分析了开发者之间的合作模式、协调机制以及开发者的角色划分等。何鹏等[4]研究发现开源软件中开发者的偏好连接模型。刘鹏等[5]研究发现开发者协作关系表现出倾向性连接、同质相吸、差异偏好相结合的特征。廖志芳等[6]研究发现开源软件社区中的关键用户行为。夏昊翔等[7]研究发现子项目与社区具有显著的相关性。Nakakoji等[8]研究发现角色可以根据项目类型划分为8类。汪文娟等[9]研究发现项目演化过程中存在5种开发者类型。

而开源软件社区中关于开发者合作网络稳定性的研究则相对较少，与之相关的合作网络稳定性研究有：Osterloh等[10]研究发现社区人员专业和关注点的多样化能够更好地维持网络稳定性。李晨光等[11]研究发现保护中度节点能很好地提高产学研创新网络的稳定性。Yu等[12]研究发现协同创新网络的稳定性的最优化模型。George Wood[13]研究发现犯罪合作网络面对攻击显得更加脆弱。张晓冬等[14,15]研究发现不同阶段开源产品社区知识协作网络的稳定性不同。

可见，目前关于网络稳定性的研究中多从网络的结构稳定性角度进行衡量，但开源软件社区实质是以软件产品为导向的开发者协同社区，如果把该系统的某些特性仅仅归结于网络的结构作用往往具有一定的局限性，因此也需要从社区成员的创新产出即网络的功能角度考虑网络稳定性。并且已有的研究中对于节点类型也是同等程度的对待，而社区中成员属性不同会导致不同的角色类型。

由此，本文以当前较为流行的一个开源前端JavaScript框架AngularJS项目为例，收集其在GitHub上托管的项目库中的提交数据。依据代码修订关系构建开发者合作网络，从结构与功能两个角度对开发者节点进行不同类型的划分，研究不同类型开发者流失对开发者合作网络结构和功能稳定性的影响。从而对已有研究进行补充，为项目管理者提供建议。

1 AngularJS开发者合作网络分析

1.1 数据来源与网络构建

AngularJS是由Misko Hevery等人创建，后被Google收购的一款优秀的开源前端JavaScript框架。该项目和大量开源软件一样通过GIT版本控制系统在GitHub托管其项目库[16]，GitHub是一个面向开源及私有软件项目的托管平台，开发者通过GIT命令进行代码的提交、审核和修改等工作。本文从GitHub克隆了AngularJS的7个主要子项目库，时间跨度为2010年8月(项目初始期)到2019年1月(本研究数据提取截止期)。提取代码提交记录共计38 764条，这些记录包含了开发者姓名、邮箱、提交日期、修改文件量、修改文件名称以及代码增减行数。在此基础上，通过Python编程抽取开发者代码修订关系，在同一版本时期内，针对同一文件进行代码提交的成员存在合作行为。考虑到开发者姓名可能会出现重复的问题，以邮箱作为识别开发者的唯一标识。将开发者视为节点，每个版本内的合作关系视为连边，构建开发者合作网络。运用Gephi软件对开发者合作网络可视化处理，构建方法及可视化如图1所示。

图1 开发者合作网络构建方法及可视化Fig.1 The method and visualization of the developer collaboration network

1.2 开发者合作网络结构分析

表1给出了所构建的开发者合作网络的拓扑特征，可见该合作网络中节点数为3 982，说明从项目初始期累积到现在共计3 982名开发者对该项目贡献过自己的知识，能够充分体现开源软件社区中的集体智慧。平均聚类系数为0.66，平均最短路径长度为4.135，说明该网络符合小世界特性；模块度为0.593则说明该合作网络中存在明显的社区结构。图2为双对数坐标下的节点度分布，基本符合幂律分布，可以看出网络中存在大量的低度节点以及少量的高度节点，说明开源软件社区开发者合作网络存在核心边缘结构[17-18]，核心成员间的紧密协作能够促进社区创新产出的不断增长。

图2 度分布Fig.2 The degree distribution

表1 开发者合作网络拓扑参数Tab.1 Topology parameters of developer collaboration network

1.3 开发者合作网络功能分析

AngularJS包含多个子项目库，分别存放各自子项目的代码。开发者在进行代码提交时，其修改或提交内容都需要被项目维护者进行比较和挑选，最优的内容才会被加入到原有项目库中，因此被记录下来的开发者在各子项目上的提交行为都是具有价值的。若将各开发者的提交次数视为贡献度，那么该开发者在各子项目的提交次数总和则为该开发者的总贡献度。如图3所示，开发者pete@bacondarwin.com在angular子项目库中共进行了1 000次贡献(代码提交)，以此类推在其他子项目库的贡献，可以看出该开发者参与知识贡献的子项目数量为5，未参与的子项目数量为2个。

图3 开发者对子项目贡献度度量方法示意Fig.3 The measurement method of the developer′s contribution to the subproject

由此可以使用二维列联表表示各开发者对子项目的知识贡献度，并在此基础上计算出各开发者和各子项目总贡献度以及各开发者参与子项目的个数，如表2、表3所示。研究表明大部分开发者只会参与其中一个子项目，而少数开发者对多个子项目进行知识贡献活动，并且各开发者都会对自己相对比较关注的子项目贡献大量的知识。各子项目也因其自身特点和代码工作量的原因，所需的知识贡献量存在较大差异。并且各子项目都存在对应的核心开发者贡献了大量的知识维持其功能稳定性。

表2 开发者与子项目二维列联表Tab.2 Two-dimensional contingency table for developer and subproject

表3 参与子项目人数统计Tab.3 Participation number of subprojects

2 节点类型划分

2.1 节点类型结构划分

传统意义上的节点重要性排序仅仅考虑节点度的大小，但节点的重要性往往还和节点所处的网络位置有关。该开源软件社区开发者合作网络模块度较高，说明网络中存在明显的社区结构，因此要考虑到节点所在模块内部以及节点与其他模块之间的联系。参照Guimera[19]提出的节点类型划分算法，引入模块内参与度Z和参与系数P，用这两个指标考虑节点在网络结构中的重要性。

模块内参与度：

(1)

参与系数：

(2)

式(2)用于度量节点与其他模块的连接程度，其中NM表示整个网络中模块的个数，kis表示节点在模块s中的度，ki表示节点i在整个网络中的度。如果一个节点的连接在所有模块中均匀分布，那么它的参与系数接近于1，如果它的所有连接都在自己的模块中，那么它的参与系数为0。

图4显示了模块内参与度和参与系数分布，由图4可以看出节点大多位于图的左半部分。结合图5模块内参与度分布图也可以发现，高Z值节点数量少，低Z值节点数量多，Z<2节点分布密集，Z>2节点分布稀疏，说明网络中的大部分节点模块内参与度小于2。因此本文将Z>2视为模块中心节点，共计107，占比3.67%。Z<2视为模块边缘节点。

图4 模块内参与度和参与系数分布图Fig.4 Z and P distribution

图5 模块内参与度分布Fig.5 Z distribution

参与系数P描述了节点与其他模块的连接程度，因此可进一步根据节点参与系数P的大小划分节点类型。

2)协调中心节点：Zi≥2，节点拥有较大的度，并且节点和其他各模块连接较好，能协调各模块之间的工作，因此其参与系数Pi>0.3节点划分为协调中心节点。

3)局部边缘节点：Zi<2，该节点没有较大的度且该节点至少70%的边都在其模块内部，Pi<0.5，则称这种节点为一般节点。

4)协调边缘节点：Zi<2，Pi>0.5，该节点可能没有拥有较大的度，但它能和其他模块之间连接相对较好，则称这种节点为一般协调节点。

另外，网络中存在很多度为0的节点，这类节点不存在模块内参与度和参与系数，因此将这类节点称为孤立节点，共计1 057个节点。

2.2 节点类型功能划分

从功能角度出发，上文中表2表3可以发现大部分的开发者只会参与1个子项目，少数的开发者会积极参与多个子项目。已有研究中发现参与多个子项目，在子项目之间游走的可能是核心开发者为了协调子项目或为新项目提供支持也可能是其他开发者(特别是新加入的开发者)[7,20]，因此可将知识贡献度和参与子项目的个数两个指标考虑进来。

图6给出了双对数下整个项目社区中的所有开发者节点的贡献度图，可见开发者节点间的知识贡献分布不均，高贡献度的开发者节点较少。为了方便起见，将100作为区别核心开发者和一般开发者的临界点。贡献度高于100共计65人，占比1.6%，视为核心节点。贡献度低于100的成员视为一般节点。然后根据参与子项目个数进一步对节点类型划分，假设参与子项目不止一个的为多子项目节点，只参与一个子项目的为单子项目节点。至此，从功能角度将节点分为多子项目核心节点、多子项目一般节点、单子项目核心节点和单子项目一般节点。

图6 开发者的贡献度Fig.6 Developer′s contribution

综上，从结构和功能两个角度对节点进行类型划分，结果如表4所示。

表4 节点类型划分结果Tab.4 Division result for types of node

3 网络稳定性分析

3.1 稳定性指标

通常被用来衡量网络性能的指标有网络聚类系数、平均最短路径、最大连通图、网络效率等[21]。而网络拓扑结构中最大连通子图能够衡量项目开发者之间合作关系的紧密性，当最大连通子图瓦解甚至崩溃，则表明合作网络中各模块之间失去联系，网络受到了严重的破坏。因此本文拟采用最大连通子图相对大小S，来衡量网络的结构稳定性。

最大连通子图相对大小：

(3)

式(3)中N表示网络中的节点总数，N′表示最大连通子图中的节点数。最大连通子图相对大小表示开发者合作网络的人员之间的紧密联系，S越大代表各开发者之间合作程度越高，合作关系越紧密，开发者之间存在一定的相互替代作用，那么这种合作网络结构比较稳定，人员流失不会对系统内开发者之间的关系造成太大的影响。

另一方面，通常可用技术能力、知识贡献等来衡量系统的功能特性[22]，开发者通过代码提交贡献自己的知识，促成项目的成功。因此可将项目的贡献度视为开发者合作网络功能稳定性指标，倘若某个开发者离开后，项目的贡献度骤减，则表明该开发者的离开会阻碍项目的开发进程。

3.2 网络结构和功能稳定性分析

基于本文从结构和功能两个角度对开发者类型的划分，进而引入一个问题：从网络结构角度和功能角度考虑开发者的重要性对网络结构和功能稳定性的影响是否具有一致性？因此，重复移除重要性排序下前50个节点，模拟开发者的流失，以探究3个指标重要性排序下节点对网络结构稳定性和功能稳定性的影响。

由图7和图8可知：总体而言，在面临贡献度大小和Z大小排序下节点流失对网络结构和功能的影响都大于P大小排序下节点流失的影响。当流失1 000个成员，仅占总人数1/3时，网络中最大连通子图相对大小和总贡献度也都逐渐趋向于0。

图7 3种指标排序下节点移除对网络结构稳定性的影响Fig.7 The effect of node removal on the stability of network structure under the ordering of three indicators

图8 3种指标排序下节点移除对网络功能稳定性的影响Fig.8 The effect of node removal on the stability of network functions under the ordering of three indicators

在结构稳定性方面：当移除前250个节点，按Z大小排序和按贡献度排序策略下，最大连通子图相对大小下降幅度基本保持一致。超过250个节点后，按Z大小排序移除节点时最大连通子图相对大小下降速度明显比按贡献度大小排序移除节点时速度快。而按P大小排序移除时，最大连通子图相对大小虽一开始没有其他两种策略下降速度快，但也比按贡献度大小排序策略先降为0。

在功能稳定性方面：3种策略下移除节点时，项目总贡献度下降速度最快的始终是按贡献度大小排序移除节点策略。按Z大小排序移除节点时，项目总贡献度下降速度先快后慢。而按P大小排序移除节点时，项目总贡献度下降速度虽忽快忽慢，但也整体呈现出先快后慢的趋势。

由此可见，相较于连接多个社区模块，社区成员与其内部模块成员间的联系更紧密时更能维持最大连通子图的大小，能够占据网络结构中心位置。而从网络功能的角度即知识贡献的角度出发，占据网络结构中心位置的成员并不一定是知识贡献最多的成员。说明开源软件社区中成员结构属性与功能属性具有不对称性。这导致知识协作网络的结构稳定性与功能稳定性也具有一定程度的不一致性。

3.3 不同类型节点对网络稳定性影响

本文对AngularJS开发者合作网络节点进行角色类型划分，不同类型开发者的流失对网络稳定性的影响值得我们进一步探索。因此，重复移除每种类型重要性排序下前10的节点，模拟不同类型开发者的流失。并将结果与传统的按度大小排序进行对比。

图9和图10可见：按度大小排序的开发者的流失策略下对网络结构稳定性的影响始终都不是最大的，说明本文对于节点类型划分进行稳定性分析是有必要的，具有一定的意义。

图9 不同类型开发者对网络结构稳定性影响Fig.9 Impact of different types of developers turnover on network structure stability

图10 不同类型开发者对网络功能稳定性影响Fig.10 Impact of different types of developers turnover on network function stability

从结构角度划分的节点类型来看，协调中心节点流失策略对网络结构和功能稳定性影响最大。局部中心节点流失策略下对网络结构稳定性的影响较大，但对于网络功能稳定性的影响相对较小。而协调边缘节点流失策略下，只有排序前十的节点流失后对网络结构稳定性的影响较大，对功能稳定性的影响始终相对较小。说明：网络中协调中心节点最为重要，这类节点同时具有较大的Z值和P值，既能够成为其模块的中心又能够和其他模块间保持较好的联系，同时这类开发者还为项目贡献了大量的知识；当节点具有较大的Z值和较小的P值时，这类节点虽在网络中占据着重要的位置，但其知识贡献量相对较少；当节点拥有较大P值和较小Z值，这类节点中存在少部分的节点占据网络中的重要位置，但其知识贡献量均相对较少；当节点拥有较小Z值和P值的节点，这类节点则对于网络稳定性的影响不大。

从功能角度划分的节点类型来看，除了多子项目核心节点流失策略对网络结构和功能稳定性的影响较大以外，其余各类型的节点流失策略对网络稳定性的影响都相对较小。将多子项目核心节点流失策略与结构角度划分的节点类型流失策略进行比较，可以发现：虽然其对网络功能稳定性的影响是所有策略中最大的，但其对网络结构稳定性的影响却没有协调中心节点、局部中心节点和部分协调边缘节点流失策略的影响大。这说明网络中参与多个子项目，并且贡献量也较大的开发者在项目开发进程中知识贡献量是无可替代的，也能够占据网络中较为核心的位置，但对网络结构影响却不是最大的。究其原因：该类开发者完成的大部分的工作往往由多个开发者共同完成或由其单独完成，若由多个开发者共同完成时，该类开发者离开后剩余开发者仍能形成相互协作关系，能保持该协作网络的连通性；而当由其单独完成时，这时就不存在相应的协作关系，也就不会对该合作网络结构造成影响。但是这类成员参与多个子项目通常是对各子项目提供技术支持或协调各子项目的工作，因此这种类型的开发者一旦离开，不仅会影响整个项目的协调性，甚至可能会造成某些子功能模块缺乏维护人员，进而造成软件开发进程的滞停，影响社区创新产出，需要重点关注。

综上所述，并非如以往研究中认为的度越大的节点对网络稳定性维持越好，因此有必要对开发者节点进行类型划分。不同类型开发者对网络稳定性影响不同。当关注网络结构稳定性时，应重点关注协调中心成员、局部中心成员和多子项目核心成员；当关注网络功能稳定性时，多子项目的核心成员和协调社区模块的中心成员会积极贡献大量知识；而在社区发展过程中则应综合关注网络结构和功能稳定性，重点关注协调中心成员和多子项目核心成员。

4 结论与展望

本文以开源软件项目AngularJS为例，通过收集到代码修订关系，抽取版本时间内的开发者合作关系，构建了开发者合作网络，并从网络结构和功能两个角度对节点类型进行划分，分析了不同类型开发者的流失对网络结构和功能稳定性的影响。得到以下几点结论：

1)开源软件社区开发者合作网络具有核心边缘结构，核心成员间的合作关系对项目的开发进程具有重要作用。其次，社区中的大部分开发者都仅仅是偶尔参与了项目，仅有少数开发者会持续性的参与项目的开发进程，并且大多数的开发者只会参与其中一个子项目，参与多子项目的成员相对较少。

2)开发者的结构属性与功能属性具有不对称性，这导致开发者合作网络结构稳定性与功能稳定性具有不一致性。占据网络结构中心位置，能很好地维持网络中节点间合作关系的开发者并不一定是知识贡献最多的开发者；度大的开发者也不一定是网络中最重要的开发者。

3)开源软件社区存在多种类型的开发者。不同类型开发者特点如下：从结构角度来看，高Z值高P值的节点知识贡献量相对较多，而高Z值低P值、低Z值高P值、低Z值低P值的节点知识贡献量则相对较少；从功能角度来看，多子项目的核心开发者能够占据网络的中心位置，知识贡献量也相对较大，其余类型的开发者则既没有占据网络中心位置，知识贡献量也相对较少。

4)不同类型的开发者对网络稳定性的影响不同。在社区的发展的过程中，项目管理者要在网络的结构稳定性和功能稳定性双重视角下重点关注高Z值和高P值的协调中心开发者以及多子项目核心开发者。

基于上述对于网络稳定性的影响研究，不难看出社区中最重要的开发者类型、各类型开发者的结构和功能属性特点。一方面是对于自组织模式下成员间协作行为研究和稳定性研究的丰富，另一方面也能够对企业参与开源活动提供管理建议。但本文存在以下几点局限：只是以AngularJS为例进行研究，这种结论是否满足其他大型开源软件项目值得进一步探究，另外本文对于稳定性的探究仅考虑静态影响，不同类型开发者的流失是否会导致一系列的级联失效问题也值得进一步探究。