开源软件社区开发者角色的演化分析

汪文娟，李 兵，2，何 鹏

（1.武汉大学a.软件工程国家重点实验室；b.复杂网络研究中心，武汉430072；2.南京财经大学江苏省电子商务重点实验室，南京210046）

0 引言

近年来，物联网、云计算技术等互联网应用逐渐深入和推广，引发了软件技术的变革，为适应海量信息处理、用户需求的个性化和多元化、软件的服务化，新型软件工程——群体软件工程［1］应运而生，实现了软件开发过程从封闭到开放，人员从精英到大众，组织从工厂到社群，方法从机器工程到社会工程的转变。典型的群体软件开发实例，有苹果的App Store和谷歌的Android应用商店。随着软件工程的转型，软件系统的规模越来越大且开发过程越来越复杂，面对群体软件开发的这一复杂特征，将软件工程与“网络科学”相结合，应用网络智能方法，开展对项目开发过程中面向群体的行为分析，为群体软件开发特性研究和质量保证提供有力支撑。

复杂网络与软件工程的交叉研究已引起了众多学者的关注与认可，相关研究成果［2－3］已发表在软件工程领域的权威期刊上，具有广阔的发展前景。软件网络的研究结合了复杂网络和软件工程理论，它以软件系统的结构特征为切入点，将复杂网络的理论应用到软件工程领域，研究软件这一类型的人工设计实现的系统是否也像社会和自然界中的网络一样具有复杂网络的特性。目前，软件网络研究主要是对已有软件采用逆向工程方法得出其中的组织结构进行分析，发现其中的复杂网络特性，反映软件系统的一些整体度量性质。随着软件的网络化趋势越来越明显，软件与网络的关系更加密不可分，用网络的观点来分析软件，为软件工程实践提供了新的视角，也是现今软件工程主要研究的问题之一。但软件开发是一个社会性（“人”）和技术性（“软件”和“网络”）汇聚［4］的过程，很多研究只是从技术性出发，探索了软件系统技术维度的复杂性，而软件开发是一项人工参与的活动，还涉及各类行为者的贡献，即软件开发的社会性，只有结合社会网络分析，才能使得网络化环境下软件的各个组成部分构成一个完整的生态系统。

软件是由人开发的系统，是一个人与人交互的网络，系统的结构、功能和演化方向与人的交互有着密切的关联。软件的结构可视为开发者间关系的一种折射。开发者合作关系的变动与软件的演化之间存在决定与反作用的关系。通过分析开发者网络的演化过程，挖掘出开发者在软件开发过程中的协作行为、活跃程度、贡献价值，为管理者及其他开发人员的开发行为提供决策参考。

在对软件进行分析时已有研究遇到了很多难题，例如，软件系统的数据很难得到，很少有现存的相关理论可供参考，开发者的边缘学习以及团队人员间的迁移融合过程。幸运的是，开源软件的广泛流行与发展，相比与商业软件，它更能满足人们的需要，促使越来越多的人自愿参与到开源软件社区中。开源软件的繁荣使得我们能够便捷、快速地获取到大量相关的数据，从而进行相关的研究。通常一个成功的开源软件在其生命周期中都会有一系列版本，针对软件的每个版本，我们构造相应的开发者网络，本文把开发者视为节点，把从事于同一个组件或包、类、方法开发的开发者间视为有一条合作边，构建开发者网络。引入开发者活跃度指标，通过该指标探析社区开发者的角色演化趋势。本文对一个成功的开源软件Tomcat（http：／／tomcat.apache.org／）的10个版本的开发者网络进行实例分析。

据了解，关于开源软件社区开发者的角色划分，Nakakoji等［5］把开源软件项目划分为3类并提出将角色划分为8类，即：被动用户、积极用户、bug报告员、bug修复员、边缘开发者、积极的开发者、核心人员、项目经理。作者只是简单地根据节点度对开发者进行角色划分，而衡量节点重要性的指标目前已有很多，仅通过节点度无法很好地刻画节点的重要性，因此，本文提出了一个活跃度指标用于衡量开发者的活跃性，便于角色演化分析。另外，Xu等［6－7］进一步对开发者的角色进行划分，数量由8类简化为5类，最后又进一步简化为4类角色：即积极用户，核心开发者，合作者，项目经理。Borgatti［8］最早提出网络的核心－边缘结构概念，并提出算法和测试验证该结构的正确性。Crowston等［9］根据bug修复信息构建网络，阐述了开源软件开发团队中的核心－边缘结构，提出一种确定开发团队核心成员的有效方法。Sureka等［10］挖掘缺陷追踪系统中的信息，发现开发者合作网络的洋葱结构，并把开发者分为核心、半边缘、边缘三类。除此之外，Pinzger等［11］研究了开发者贡献网络与软件发布后缺陷数的关系，使用网络中心性指标衡量贡献网络的重要程度，指出中心模块比非中心模块有更多的缺陷倾向。在文献［12］中，Crowston论证了中心性在跨项目和时间上的分布，实证了项目的核心成员变动情况相对比较少，而且参与跨项目社区的情况也不多见。Wiggins等［13］对Fire和Gain两个项目的中心势动态做了研究，发现两个项目均随时间变化趋向于分散化。Huang等［14］指出在开源软件网络中，节点的重要性遵循二八定律。以上工作主要是用中心性指标来衡量节点的重要性，并用于缺陷分析与网络整体趋势分析。他们并没有关注单个开发者的演化趋势，以及网络中典型演化模式的提取。

本文重点对一个项目不同版本阶段的开发者网络中开发者角色进行演化分析，主要贡献为：1）收集整理了Tomcat 6项目从2006—2010年10个版本的开发者修改日志和邮件列表信息，构建每个版下的开发者网络，便于后续研究者在提供的数据集上对本工作的重现与更深入的研究；2）提取了5类典型社区开发者演化模式和每类开发者擅长从事的工作类型，有利于开发者的角色预测与任务分配，为管理者提供决策参考。

1 研究方法

首先利用我们团队开发的聚焦爬虫工具从svn日志与邮件列表信息中爬取开发者行为数据；然后根据项目的版本信息，把数据划分为10个连续的版本，并依次根据开发者参与的任务构建10个相应的开发者网络；基于所得的开发者网络，对开发者的活跃度进行演化分析，并基于开发者活跃度的演化趋势把开发者划分为5种类型，通过分析开发者活跃度与提交日志数之间关系的分布进而衡量开发者贡献度；最后，通过对日志信息的分类，得到每类开发者在不同任务上的实践技能。

1.1 开发者网络模型

本文选取了Apache软件基金会（ASF）资助的一个典型的开源软件项目－Tomcat作为实验案例，采用课题组自行开发的聚焦爬虫工具爬取Tomcat 6从2006年到2010年的开发者日志和邮件列表信息，主要包括信息的链接URL，开发者的姓名，commit的主题及提交时间。根据提供的版本发布信息，将数据划分为10个版本，考虑到有些版本相距时间只有几天，我们只选取相隔至少1个月的版本作为实验版本，因此，表1中第一列只给出每个版本相应的序号。在数据处理过程中，类似于已有文献的处理方法，只选取了具有提交日志权限的开发者，于是部分边缘用户被排除在外，表1给出了每个版本的详细信息。

在构建开发者网络过程中，用DevNet＝（V，E），V为网络的节点集，E为连边集。网络中节点代表参与的开发者，如果开发者i，j参与同一工作线程的开发则被视为存在一条合作连边eij＝1，否则eij＝0，本文没有考虑两个开发者间的合作次数，且两个开发者之间的合作被视为是相互的。图1是版本1的开发者网络拓扑结构。

表1 版本信息Tab.1 Version information

图1 版本1的开发者网络Fig.1 The developer network of version 1

1.2 活跃度

活跃度是度量开发者的交际范围以及衡量开发者重要性的指标。活跃度具体来说，就是开发者与多少人进行过交互。在开发者网络中，如果一个节点拥有更多的合作对象，那么这个节点所代表的开发者的活跃度越高。反之，活跃度很低的开发者与其他人建立的合作也相对少。因此，活跃度与节点的度息息相关，但又不简单地等于节点度。本文用Activei表示开发者i的活跃度：

1.3 标准化

在进行数据分析之前，通常要进行数据标准化以减少实验偏差。已有的标准化方法很多，本文采用Min－Max标准化，Min－Max标准化是对原始数据进行线性变换。设Min和Max分别为网络中所有节点Active指标值的最小值和最大值，将Active的一个原始值x通过Min－Max标准化映射成在区间［0，1］中的值x′：

对活跃度标准化后，计算相应的rank值，即若Active′i∈［k，k＋0.1），0≤k≤0.9，则ranki＝k＊10＋1。最后，根据rank值找到对应的活跃度等级。活跃度等级划分的标准：7≤rank≤10，等级为高；4≤rank≤6，等级为中；1≤rank≤3，等级为低。

1.4 日志信息类型

在文献［15］中，作者对5个开源软件的bug库进行分析，发现很多bug报告实际上并不是修复bug，而是提出一个新功能或者提高系统性能等。他采用人工对bug报告进行分类的方法，探究误分类对缺陷预测的影响。类似于该文献，我们对开发者日志信息类型分为6大类：BUG类，日志记录了纠正性的维护任务：对源代码进行语义上的更改；RFE类，日志记录了适应性的维护任务：增加新功能；IMPR类，日志记录了完备性的维护任务：提高系统整体性能；DOC类，日志记录了外部网站或代码文档的更新；REFAC类，日志记录了重构源代码的问题，通常由开发者提交；OTHER类，日志记录了代码移植，代码清理，规范更改（非文档和代码），测试用例。

日志信息的分类规则为：如果出现空指针异常NullpointerException源代码，需要进行语义上的更改缺陷导致运行时间或内存出现问题，该日志归类为BUG；如果出现非最优算法和垃圾收集策略导致的资源问题（时间，内存）要求对代码，日志信息，文档信息，异常信息，属性字段进行非语义上的修改或修复要求增加或删除文档和日志信息要求更新文档或日志信息的内容要求改变抛出异常的类型或信息要求变更支持新的输入和输出格式介绍已有功能的并发版本建议升级或修补第三方库去解决问题要求按照规约／文档修正已经实现的功能，该日志归类为IMPR（改进请求）；如果要求实现一个新的接口或方法要求增加新功能要求支持新的对象类型，规范或标准，该日志归类为RFE（功能请求）；如果由于丢失文档或文档过时而提交报告请求更新文档或增删文档请求更新外部网站，该日志归类为DOC（文档请求）；如果请求将代码移动到其他包，类或方法中请求为变量，方法，类，包或配置文件重命名请求属性在不同环境中的通用，该日志归类为REFAC（重构请求）；如果报告了违反java合同但是没有导致异常的事件有关兼容性修补程序的建议任务不需要修改源代码或文档（如包装，配置，下载），该日志归类为OTHER。

按照以上规则对日志信息分类，便于后续部分对不同角色演化模式的开发者所从事的工作进行对比分析。

2 实证分析

实验对象的选取是影响实证分析结果的重要因素之一，本文定义了一些筛选标准用于实验的软件系统，比如版本的数量，参与的开发者人数，演化周期，最终选取Tomcat项目为实证对象展开分析。

2.1 开发者活跃度的演化

软件需求的改变，功能的增加或删除等，促使软件开发和维护成为一个不断演进的过程，而整个过程中开发者间由于合作形成一个合作网络。随着开发者合作网络的演化，开发者活跃度也在不停的改变。活跃度的改变意味着开发者在团队中角色地位可能也会发生改变，实时地掌控开发者的角色能有效执行任务分配，为软件开发与维护带来便利。

据1.3中提到的根据rank值把活跃度划分为3个等级：高、中、低。通过对数据的初步分析，发现在项目演化过程中，每个版本中都存在开发者的加入和离去，而且有一小部分开发者仅在某一个版本中参与合作或做出了贡献。为了进行版本间的开发者活跃度演化分析，本文提取出在这10个开发者合作网络中都出现过的11名开发者。如果将活跃度演化趋势相似的开发者归为一类，则这11名开发者可整体划分为5类，分别表示为A～E。图2分别给出了A，B，C，D，E 5类开发者在对应10个版本中的活跃度变化趋势，其中横轴表示版本序列号，纵轴表示rank值。

从图2可发现：A类开发者起初一段时间非常活跃，后来变得越来越不活跃。充分体现为他们在前5个版本都是处于非常活跃状态，随后逐渐由非常活跃变为活跃，最后变为不活跃。B类活跃度整体上先增后减。他们的活跃度在第五个版本的时候达到最大，之后下降到最小。他们的活跃度一直处于中等偏下的状态。C类活跃度整体下降且处于中等偏下的状态。曲线波动不大，活跃度偏小，整体上是下降的趋势。D类活跃度整体下降但处于中等偏上的状态。与C类开发者相似的是，活跃度整体都是下降的趋势，不同的是，曲线波动较大，活跃度偏大。E类活跃度递增而且一直处于非常活跃的状态。追踪Mark Thomas的rank值，起初为2，第6个版本已经达到10，且随后一直保持最大。

这5种演化趋势呈现的一种可能的解释是，在每个时间段可能分配给开发者的任务不一样，由于开发者在不同的工作上能力大小可能也不同，导致活跃度的变化。当分配给他们擅长的工作时，他们的活跃度大，当他们做自己不擅长的工作时活跃度就会变小。为了使所选取的11名开发者的演化模式尽可能代表社区开发者的存在的演化模式，我们还考虑了那些不是在每个开发者网络中都出现的开发者。如图2f，可以看到这3个人分别只在软件开发前期，中期和后期出现，但是他们都能归到所提取的5类模式中。即Jean－Francois Arcand属于第二种类型，活跃度先增后减。Johnny Kewl属于第三种类型，活跃度慢慢减弱且处于中等偏下的状态。Konstantin Kolinko则属于第五种类型，活跃度呈递增的趋势。这样进一步验证了我们对开发者角色类型的划分在很大程度上具有合理性，为开发者行为预测提供了一种新的视角。

图2 5种开发者类型Fig.2 Five types of developers

2.2 活跃度与贡献度的关系

研究活跃度与贡献度的关系，本文用开发者提交日志数作为衡量开发者贡献度的指标，开发者提交的日志数越大说明开发者贡献度越大，于是问题转化为研究活跃度与提交日志数的关系。我们分别统计了每个版本中rank值为1～10的开发者的平均提交日志数。根据10个版本开发者平均提交日志数随rank值的变化趋势，把拥有相同变化规模的版本画在同一个图中，如图3所示，横轴代表rank值，纵轴表示平均提交日志数。可以看出10个版本中开发者的平均提交日志数随rank值的变化都呈现指数增长趋势，说明当开发者的活跃度越大时，他提交的日志越多。一种可能的解释为，当一个开发者变为活跃时，很大程度上由于当前任务是该开发者所擅长或熟悉的工作，以至于该开发者贡献越大。反之，当开发者的活跃度小时所做的工作可能是他不太擅长的工作。因此，我们得出两个结论，活跃度与贡献度呈指数关系，开发者活跃度的改变意味着开发者角色地位的改变。

2.3 开发者的参与程度

基于2.1节实验结果，我们发现开发者的活跃度随时间是动态变化的。因此，为了分析社区中不同角色演化模式下开发者从事的工作类型，有必要研究所得的5类演化模式在不同的工作类型的分布情况。研究每个开发者对不同类型工作的贡献程度称之为开发者的专业技能，挖掘出每种工作类型中专业技能最好的开发者，有助于实现人到项目的推荐或者项目到人的推荐。在项目管理过程中，掌握开发团队中开发者专业技能的优劣势对项目管理者而言也至关重要，通过活跃度的变化定位开发者的角色演化趋势，预测开发者的行为便于任务分配。因此，本节重点对每个工作类型中5类开发者的参与程度进行分析。

图4中，横坐标代表任务信息的类型，纵坐标代表每类开发者参与某类任务占所有这类任务的百分比。图中A，B，C，D，E分别对应于图2中所划分的5种类型。从工作类型看，不难找出每类日志中提交比例最大的开发者。简单地说，就是可以找到每个工作类型中参与程度最好的开发者。在图3中，提交RFE日志比例最大的是B类开发者，说明B类开发者更多从事RFE类型工作。B，C，E 3类开发者在BUG修复过程中比重均相对比较大，并且非常接近，所以，在bug分配时可以考虑优先给这3类的开发者。尤为明显的是，在DOC和REFAC中，B类和E类开发者比重均超过60%，说明这两类开发者都集中从事某一类工作，且在图2中，不难发现，这两类开发者整体演化趋势相对比较稳定。

从开发者类型看，可以找出每类开发者提交得最多的日志类型即找出每类开发者的优势。例如图4中A类开发者提交的RFE和IMPR日志所占的百分比较其他日志类型大，所以A类开发者的优势是做RFE和IMPR工作。分析出开发者专业技能的优劣势，然后根据开发者活跃度的演化趋势来预测他的角色，以便更好地分配任务。

图3 10个版本中开发者平均提交日志数随rank值的变化趋势Fig.3 The change of the average number of logs commited by developers along with the change of rank in 10versions

3 结束语

根据社区开发者的活跃度演化趋势，文章把开发者的演化模式划分为5种类型，每种类型开发者的活跃度表现出不同的变化趋势。在分析开发者活跃度与贡献度的关系时，我们发现开发者的活跃度与开发者所提交的日志数呈指数关系，表明交互越活跃的开发者，提供的贡献也越大。因此，活跃度的改变意味着提交的日志数的改变，相反，可根据开发者提交日志的频率来预测其角色的改变。在2.1节中，我们得到A类开发者在前5个版本中非常活跃后来变得越来越不活跃，结合2.3节中的分析，A类开发者更擅长从事RFE和IMPR两类工作。在实际的软件开发过程中，在开发前期软件对提高功能和性能方面的需求更大，而此时A类开发者占主导，所以在图2a中表现为前5个版本A类开发者的活跃度非常大。在开发中后期，更多的时间会花费在对软件的测试，重构，修复上，因此他的活跃度会慢慢下降。图2e描述了E类开发者的活跃度逐渐变大，且随后保持最大。在统计5类开发者提交的日志数时，我们发现E类开发者提交的日志数非常大，是其他类型开发者提交的日志数的几倍甚至几十倍。从图4不难发现E类开发者对每类工作的贡献度都不小，这也说明了他是个全能型的人才。在软件开发的每个阶段，他都是核心人物。

实验结果表明，在不同的项目版本中，根据开发者活跃度的演化趋势，可将开发者大致划分为5种典型的演化模式。整体上，越活跃的开发者，提交的日志数也越多，两者呈指数增长关系。最后，对比不同演化类型的开发者在6类工作上的分布，发现开发者的演化趋势与软件开发周期有关，不同的开发者阶段由于关注事项的不同，擅长此类事项的开发者开始变得活跃，而已有活跃的开发者开始受到影响，一般的开发者仍然保持稳定的趋势。总之，我们的工作发现开源社区中开发者的角色随时间动态变化，表现明显的学习过程，越活跃的开发者往往贡献越大，且不同类型的开发者偏好的工作事项也不同。

关于时效网络，国内外都备受关注，如国内复旦大学的李翔教授团队，华中师范大学的池丽萍副教授团队，以及国外知名的巴拉巴西团队。时效网络模型可以保留事件的时序信息，能更好地描述动态系统的特征，其比例分布可以揭示不同事件之间隐藏的共性。在我们的演化分析过程中，演化本身就是一个时间序列分析，文章构建的开发者网络一定程度上就是一个在一段特定时间内交互网络，而时效网络是一个更细粒度的网络，关注开发者网络构建过程中的这种时间属性，对开发者角色度量与演化分析会提供一个新的研究视角。

在已取得研究成果的基础上，本文也存在一些不足之处：首先，所选取的10个版本的时间跨度并不相等，在数据上引入了一些量的偏差，导致版本更新时间跨度不等，但我们的实验结果表明，这些小的偏差并没有影响对开发者角色演化分析，所以，文章发现具有一定的代表性。其次，对合作者的定义比较狭隘，我们假设历史记录中参与至少同一个工作线程的开发者间存在合作，没有考虑其他形式的合作，比如论坛中的讨论合作，另外，所构建的开发者网络为无权网络，无法呈现他们之间的交互次数，但已有文献中，也有很多研究者采用了类似构建开发者网络的方法，并被证实这种网络的有效性。本文只分析了Tomcat软件，把开发者归为了5种角色类型，这样划分是否具有通用性，代表性，还需要对更多的开源软件进行实证，如Eclipse，Mozilla等流行的开源软件。

图4 每类日志中5类开发者提交日志所占的比例Fig.4 The proportion of logs commited by five types of developers in each type of logs

在接下来的工作中，我们将对比其他度量节点重要性指标对开发者角色演化趋势的刻画，比如节点度中心性，介数中心性，特征向量中心性等，验证文章提取的5类开发者角色演化模式的一般性。目前时效网络也备受关注，今后我们也将更细粒度地考虑合作网络的时间属性，进一步探究角色的演化分析。另外，本文只对Tomcat软件进行了研究，更多来自不同开发环境，不同语言的开源软件有待研究。

［1］ Whitehead J，Mistrík I，Grundy J，et al.Collaborative Software Engineering：Concepts and Techniques［M］.Berlin Heidelberg：Springer，2010：1－30.

［2］ Concas G，Marchesi M，Pinna S，et al.Power－Laws in a large object－oriented software system［J］.IEEE Trans On Software Engineering，2007，33（10）：687－708.

［3］ Louridas P，Spinellis D，Vlachos V.Power laws in software［J］.ACM Trans on Software Engineering and Methodology，2008，18（1）：2.

［4］ Kleinberg J.The convergence of social and technological networks［J］.Communications of the ACM，2008，51（11）：66－72.

［5］ Nakakoji K，Yamamoto Y，Kishida K，et al.Evolution patterns of open－source software systems and communities［C］／／Proceedings of the international workshop on Principles of software evolution.ACM，2002：76－85.

［6］ Xu N.An exploratory study of open source software based on public project archives［D］.Concordia University，2003.

［7］ Xu J，Gao Y，Christley S，et al.A topological analysis of the open source software development community［C］／／Proceedings of the 38th Annual Hawaii International Conference on System Sciences.IEEE，2005：4－7.

［8］ Borgatti S，Everett M.Models of Core／Periphery Structures［J］.Social Networks，2000，21（4）：375－395.

［9］ Crowston K，Howison J.Assessing the health of open source communities［J］.Computer，2006，39（5）：89－91.

［10］Sureka A，Goyal A，Rastogi A.Using social network analysis for mining collaboration data in a defect tracking system for risk and vulnerability analysis［C］／／Proceedings of the 4th India Software Engineering Conference.ACM，2011：195－204.

［11］Pinzger M，Nagappan N，Murphy B.Can developer－module networks predict failures［C］／／Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of Software Engineering.ACM，2008：2－12.

［12］Crowston K，Wei K，Li Q，et al.Core and periphery in free／libre and open source software team communications［C］／／Proceedings of the 39th Annual Hawaii International Conference on System Sciences.IEEE，2006，6：118.

［13］Wiggins A，Howison J，Crowston K.Social dynamics of floss team communication across channels［J］.Fourth International Conference on Open Source Software，2008，275（7）：131－142.

［14］Huang S K，Liu K M.Mining version histories to verify the learning process of legitimate peripheral participants［J］.International Conference on Software Engineering，2005，30（4）：1－5.

［15］Herzig K，Just S，Zeller A.It＇s not a bug，it＇s a feature：how misclassification impacts bug prediction［C］／／Proceedings of the 2013International Conference on Software Engineering.IEEE，2013：392－401.