开源社区中开发者的跨项目行为

赵佳斌，赵海燕，曹 健，陈庆奎

1(上海理工大学 光电信息与计算机工程学院,上海市现代光学系统重点实验室光学仪器与系统教育部工程研究中心，上海 200093)2(上海交通大学 计算机科学与技术系，上海 200030)

E-mail：cao-jian@sjtu.edu.cn

1 引 言

伴随社交网络与软件开发技术的逐步融合，形成了一种以开源社区为平台的社交化软件开发形态，原本集中封闭式的软件开发模式向开放、分布的软件开发模式转变.诸如GitHub这样的自组织、自愿参与的开源社区平台吸引了大量来自不同国家和地区、拥有不同开发经验的开发者参与到开源软件的开发中.

GitHub采用git来托管项目，支持基于pull-request[1]的开发方式，允许社区内的开发者分叉(fork)任意公开的软件项目，该操作会复制原始的项目进而允许开发者完成新功能编写或错误修复，从而为潜在的贡献者提供了低准入门槛.开发人员通过创建和分叉开源项目，推送修改的代码，审查合并他人推送的代码，收藏和关注感兴趣的开源项目和开发者等以便了解最新的开发动态.同时，开发者之间也通过评论、提问、@等机制相互交流、共享开发经验.这种开放化、社交化的协同开发方式支撑了群体性软件开发活动，使得开源社区不断壮大，也为软件开发提供了强大的生产力.截止到2018年，GitHub上托管的开源项目已经超过了9600万，开发者人数也突破了3100万.

GitHub鼓励软件开发活动的透明性[2]，它指的是开发者身份及其活动对其他用户是可见的.因而，开发者在开源社区的开发活动会留下大量的用户行为数据，这些行为数据能够反映开发者的意图、能力和经验等.GitHub平台上项目开发活动数据的公开和透明，为研究大规模软件协同开发平台的开发模式、协作方式和人员特点等提供了良好的条件.

开发人员通过参与某一项目可以提高其能力，了解技术的最新动态、乃至实现其自我价值.出于不同的目的与动机，多数开发者在一段时间内会同时参与到多个项目中，同时，在结束或者退出某一个项目后，又会选择另一个项目，这种同时或者依次在不同项目中的参与行为，本文称之为跨项目行为.在GitHub上，跨项目非常普遍，然而，对这一普遍性行为目前还缺乏研究.围绕这一行为有许多问题值得探讨，例如，开发者的跨项目行为有怎样的特点？开发者同时参加的项目或者依次参加的项目之间存在什么样的关联？回答这些问题对于设计和改善开源项目的推荐系统有着重要的意义.开源项目需要找到感兴趣的开发者，而开发者也需要找到感兴趣的项目，目前的推荐系统中忽略了开发者当前的项目参与状态，因此，对跨项目行为的理解能够有助于开发更好的推荐算法.

本文旨在通过分析开发者的行为数据，理解开发者跨项目行为特点.具体来说，我们尝试回答以下5个研究问题：

1)开发者在短期内是否会参加多个不同的项目；

2)开发者是否会在一个项目中长期贡献；

3)时间间隔对开发者再次回归项目有何影响；

4)一个开发者同时活跃参与的多个项目的相似性如何；

5)在某个项目中不活跃后新加入的项目与原来项目是否存在相似性.

本文组织如下：在第二节中介绍相关的研究工作，第三节中介绍研究所用的数据集，第四节介绍了本文的研究方法，第五节中对结果进行讨论，最后总结全文并对未来的研究进行了展望.

2 相关工作

近年来GitHub开源社区不断壮大，研究人员也对其展开了大量的研究，其中就包括对社区中开发者的分析.开源社区的开发团队成员多为自发组织的，具有较高的流动性和多样性[3].文献[4，5]对开源社区中新加入的开发者面临的问题做了总结并给出了解决方法的参考指南.文献[6，7]将开发者在开源社区中的角色分为项目负责人、核心成员、活跃开发人员、临时开发人员、错误修复者、错误报告者、读者和被动用户等，并将这种结构称之为“洋葱结构”.不同角色的开发者承担着不同的任务.值得注意的是流行项目的贡献者中48.9%都是临时贡献者[8].

开发者在一个项目中的角色并不是一成不变的，文献[9]分析了开发者从新加入人员逐步成为长期贡献者甚至是核心人员的原因，包括参与动机和整体开发环境，与普通加入者相比，他们在项目中的状态表现更为积极因而也更受关注.文献[10]对活跃项目中的开发者进行了研究，发现其中的开发者类型往往是混合型的，即开发者在各自的开发活动中表现出不同特征.例如一些贡献者在代码，评论和问题解决上表现相对均衡，而有的贡献者侧重其中的一方面.文献[11]以访谈的方式分析了影响开发者参与状态转变的因素.文献[12]研究了如何改善团队管理，他们发现项目中不活跃但作为潜在贡献者的这批开发者占80%，对整个项目的开发活动有着较大的影响，主要表现在问题解决速度和对pull-request响应上.

参与动机和社交关系将影响社区中开发者的行为.动机理论被广泛用于解释人类行为，同样适用于开源社区.开源社区中的开发者参与动机主要包括：学习如何写代码、关注社区中的名人、为个人或团队的工作做宣传、寻找有趣的新项目等[13].社交关系是另一大影响因素，开发者加入存在好友的项目其贡献率将会有大幅提升[14].社交因素有利于维持一种长期的贡献状态.文献[15]重点研究了开发者的关注网络，发现了四种典型的社交行为模式.文献[16]研究了开发者的合作模式，开发者之间的合作次数越多，那么他们再次合作的可能性也就越大.同时，开发环境及管理者对于合作有着明显的影响.

Commit提交行为是开源社区项目版本控制的一个重要操作，同时也是衡量开发者的贡献的一个重要指标[17].文献[18]对项目中组织及个人的提交行为做分析，大多数连续提交之间的时间间隔很短且满足幂律分布.文献[19]提出四个指标研究开发提交行为与项目版本变换的关系，研究发现，大规模提交所需时间是普通提交的3倍.

从上述相关研究工作的进展看，研究人员从不同的角度探索了开发者的行为特征，然而，本文探讨了开发者的跨项目行为特点，对上述研究进行了补充，从而有利于我们更完整地理解开源社区的开发者行为.

3 数据集

3.1 数据采集

本文的研究所依赖的数据借助GitHub提供的丰富的API接口获得.开发者在进行软件项目协同开发的过程中会积累一定数量的粉丝，粉丝数量代表了他在开源社区中的地位和影响力，拥有大量粉丝的开发者被视作社区中的“名人”.本文据此选择了在GitHub社区中最具影响力的1000名开发人员，提取了这些开发者在2017年1月-2018年12月为期两年的活动行为数据.

GitHub平台对开发者提供了贡献统计，开发者的贡献是以月为时间单位记录的，贡献次数及内容越多，该月所在区域显示的颜色就越深.记录的行为主要包括以下7种：Create Repository，Created commits，Created a pull request，Opened pull requests，Created an issue，Reviewed pull requests，Opened issues.

3.2 数据预处理

我们获取的原始数据包含了1000名开发者、47042个项目、7种不同操作的209562条行为数据.这些数据需要进行预处理.考虑到GitHub开源社区中的数据相对稀疏，本文将“月”作为分析周期；鉴于本文分析的是开发者跨项目的行为，仅保留开发者对社区中他人公开项目的行为数据；为了尽可能减少“被降低”的情况，即开发者新加入的项目由于没有足够的观察时间就被认为在加入后没有在该项目中进行长期的贡献和活动，剔除了2018年中新加入项目的记录，保证了开发者在项目中的行为数据的观察周期至少为一年.

4 问题分析及研究方法

4.1 开发者在短期内是否会参加多个不同的项目

本节主要分析开发者短期内参与到多个不同项目的现象是否很普遍及这种同时参加多个项目的行为与开发者属性的关系.

按条件对数据筛选后，按月作分组统计，结果如图1所示，其中在一个月中仅参与一个项目的记录数最多，为2497条，占23.7%，参与多于一个项目的记录数则占76.3%.其中的最大记录是某一位开发者在一个月中参与了67个不同的项目.在数据集上的平均值是7.29个.

图1 开发者在一个月中参与项目个数Fig.1 Number of projects the developer participatesin in a month

我们进一步按人员计算开发者每月参与项目数的均值，其频率直方图如图2所示.我们发现在一个月中参与项目个数的均值大于5个时，人数出现大幅下降.具体来看，参与项目个数不超过1个的占14.1%；其中均值在1-5之间的占57.1%.参与项目个数均值大于20个的仅占5.3%.

图2 一个月中参与项目数的频率直方图Fig.2 Frequency histogram of the number of participatedprojects in a month

上述结果表明，绝大多数的活跃开发者会同时参加多个项目，但是，他们同时参加的项目也不可能太多.产生这样的结果的原因主要是开发者的精力通常是有限的，完成一项新功能或者漏洞的修复需要一段时间；同时开发者有一些自己的项目需要编写和维护，所以通常无法参与数量过多的项目.

开发者的自身属性包括加入社区时长、拥有项目数量、关注项目的数量、常用编程语言等.首先分析参与项目数量与加入社区时长、拥有项目数量及关注项目数量的相关性.此处我们使用Pearson相关系数来衡量相关性，它是一种衡量两个随机变量相关程度的常用方法，相关系数r值取值范围在[-1，1]之间，取值越大就表示两个变量之间的相关程度越高，反之，相关程度越低.显著水平p值则是用来评估相关程度计算结果的“显著程度”.我们分别计算一个月中参与的项目数与加入社区时长、拥有项目数量、关注项目数量的Pearson相关性，计算结果如表1所示.根据取值范围判断变量的相关强度关系表及p值远小于0.01可知，短期内参与的项目数与所涉及的三个因素都有着很强的显著水平.其中，短时间参与项目数量与加入社区时长和关注项目数量弱相关；与拥有项目个数为强相关.

表1 跨项目行为的因素相关性分析Table 1 Correlation analysis for factors of cross-project behaviors

我们也分析了开发者常用语言与参与项目数量的关系，结果如表2所示.其中R语言的开发者参与项目数最多，其次为PHP，最少的是C语言的开发者.

表2 开发语言与参与项目数Table 2 Relationship between language and number of participating projects

4.2 开发者是否会在一个项目中长期贡献

本节分析开发者在项目中参与时长以及开发者在项目中的角色对其长期贡献的影响.互联网中，用户通常存在一个生命周期，这里的生命周期是指用户从加入平台，熟悉平台，参与平台到最终流失的过程.用户的生命周期就自身而言，是一种参与度的变化，用户参与度也可以称之为用户在该平台的活跃度.

开发者参与到开源项目中也会存在一种活跃度的变化，开发者从发现一个自己感兴趣的项目、熟悉该项目、参与其中到逐步流失这样的一个过程通常会体现在行为的时间间隔中.

在对开发者首次加入项目的时间做筛选后，以开发者参与的开源项目作为对象按月统计，结果如图3、图4所示.在开源项目中仅仅参加了一个月就不再参加的记录条数为14401条，占58.7%；参与月数为2-5个月的记录数为6519条占26.6%，在所分析的时间内参与月数超过15个月的有1673条记录，占6.83%，有142条记录在项目中的参与月数为24个月，受制于数据采集时长，实际持续的时间可能更长.

开发者在GitHub中的角色通常分为三种：成员、贡献者和临时参与者.当开发者提交的pull-request被合并至源项目后，他就成为了该项目的贡献者.一个重要的问题是不同的角色是否会影响开发者的贡献时长?为此本文做了相应分析.由于存在开发者既是成员又贡献者的情况，此时将这类开发者划分为成员，分别计算三种角色参与项目的平均时长.我们发现作为成员，平均参与时长为7.39个月，贡献者为5.02个月，临时参与者为3.51个月.这个结果符合我们的一般认识.

图3 开发者在不同项目中参与月数Fig.3 Length of time developers participate in different projects

图4 聚合统计结果Fig.4 Cumulative results

4.3 时间间隔对开发者再次回归项目的影响

开发者长期参与到一个项目的过程中，可能会出现一段时间没有行为的情形，我们称之为“空窗期”.出现空窗期后，有些开发者会再次参加项目(本文称之为“回归”)，而有些开发者就不再参加项目了(本文称之为“流失”).

图5 时间间隔与回归项目的关系Fig.5 Relationship between the situation and time of returning to the project

本节分析参与过程中所存在的空窗期长短对开发者再次回归的影响.计算间隔n个月后开发者回归的情况，首先对记录中间隔周期不满n个月的进行删除，尤其是处于采集周期尾部的记录；然后统计在间隔了n个月后开发者回归到项目的记录数并计算其占比，结果如图5所示.在间隔周期为零个月的情况下(在连续的两个月中都有参与行为)，开发者再次回归的占比为62.51%；当间隔周期为一个月那么这个占比会下降到13.98%；当间隔为两个月，开发者再次回归的情况占6.95%；当间隔时间为8个月，回归情况占比不到1%.

4.4 开发者同时活跃参与的多个项目的相似性如何

根据前文的讨论，本文界定开发者在一个项目中的参与状态是否活跃的标准如下：开发者从发现一个感兴趣的开源项目、参与贡献、结束贡献从该项目中流失是一个连续的过程.本文将其中的启动期设置为两个月即当开发者连续两个月在一个项目中有行为，视作在该项目中开始活跃；设置启动期的目的是为了区分出那些临时的参与者；在持续活跃的过程中出现的空窗期不得超过两个月(超过两个月将引发较大的流失率).当时间间隔大于两个月，视作开发者在该项目中结束了本阶段的活跃.基于上述对与开发者在项目中的活跃度评判标准，得到了符合条件的621名开发者以及他们参与的5791个开源项目.

首先分析开发者在项目中活跃的持续时间，结果如图6所示.持续时间为2个月的记录数量最多；当持续时间增长到3个月时出现大幅回落；活跃持续时间在3-22个月的记录数相对平稳；活跃持续时长超过22个月的记录数又出现了明显的上升，这表明，每个项目中都会有一部分核心贡献者.

图6 活跃状态的持续时间Fig.6 Duration of the active state

接着我们分别从开源项目的开发语言、描述、标签、流行度和项目规模这五个不同的维度对开发者同时活跃参与项目的相似性进行计算.

开发语言相似性：开发语言描述的是项目所使用的开发语言，通常情况下开发者掌握了两种及以上的开发语言，根据项目语言的种类选择自己擅长的一种.

描述相似性：描述是项目的一个简介，大致描述了该项目实现的功能及用途，方便其他开发者根据描述所表达的内容来选择自己中意的开源项目.描述通常是一段简练的文字.本文采用了TF余弦相似性计算两个项目描述的相似性.具体做法是：首先对描述文本做分词处理，然后去停用词，接着构建词典并将文本转化为向量，由于文本信息转为向量，故采用余弦相似度计算其相似性.标签相似性：标签是开源项目的另一个特征，它是描述项目的一组关键词，这些关键词组成了一个集合，而Jaccard系数可以用来衡量两个集合的相似性，其核心就是计算两个集合交集与并集大小的比值，比值越大表示相似度越高.

流行度的相似性：GitHub中的大量开源项目会受到开发者不同程度的关注，关注者的数量代表着项目的流行度，为了有明确的区分度，本文根据关注者数量对项目的流行度进行划分如表3所示.

项目大小代表整个项目的规模，这也是开发者选择项目的一个重要依据之一，同样将其划分为小规模、中等规模、较大规模和大规模四个等级如表4所示.

五个特征上的相似度结果如表5所示，相似度为1表示在这一特征上完全一致，相似度为0则表示在该特征上完全不相似.根据相似度大小划分了6个不同的范围，每个特征下划分了两种不同的情况分别是：同时活跃和下一项.

表4 项目规模划分表Table 4 Project size division table

表5 开发者活跃状态参与的项目的相似性表Table 5 Similarity table for projects in which the developer is actively involved

同时活跃状态下开发者对不同项目的参与情况存在差异，以不同的行为、以及角色做区分，结果如表6和表7所示.

表6 角色差异Table 6 Role difference

我们发现临时参与者的身份占比超过70%，虽然开发者会同时活跃在多个不同的项目中，但是重点参与的通常只有一个

表7 行为差异Table 7 Behavior difference

到两个，其中commit的次数远高于pull-request.例如编号为21号的开发者，在其同时活跃的6个项目中，仅在一个项目中为成员，在其余的项目中的角色都是临时参与者.

4.5 开发者在项目中结束活跃后新加入项目特点

一般情况下开发者在一个开源项目中结束活跃后，会选择加入一个新的项目，本节分析新加入项目的特点.

图7 加入新项目的平均时间间隔Fig.7 Average time interval for joining new projects

将开发者结束活跃的项目与随后加入的项目设置成一对，分别从间隔时间和标签、描述、开发语言、流行度和规模这些特征分析新加入的项目特点.实验结果如图7和表8所示.

表8 新加入项目与结束活跃项目的相似性表Table 8 Similarity table for new and ending active projects

结果显示开发者在一个项目中结束活跃后再次加入到新项目的平均时间间隔不超过一个月的开发者占75.6%.

5 讨 论

5.1 开发者在短期内是否会参加多个不同的项目

结果显示，绝大部分的情况下(76.3%)，开发者都愿意在一个月内(较短的时间段)参与两个及以上的不同项目，那么在向开发者进行开源项目推荐的时候就可以摒弃如下顾虑：开发者当前已经参加了一个项目，他将不再接受其他推荐，实际情况是开发者愿意在短时间内参与多个不同的开源项目.当然，这个数量通常是有限的，开发者当前参与的项目数量大于5个后，那么他接受新项目推荐的概率将大幅降低.据此，社区平台的推荐机制可以优先为那些参与项目数量小于5个项目的开发者提供个性化推荐服务.开发者参与项目的数量与自己所拥有的项目数量存在较强的相关性，开发者拥有的这些项目一部分是他自己创建的，另一部分是fork他人的开源项目，这些项目的数量越多也表示其在社区中越活跃，因而他在短期内参与较多项目的可能性也会相应高于其他开发者.

5.2 开发者是否会在一个项目中长期贡献

开发者在项目中的行为次数反映了他在该项目中的参与程度，次数越多就表明他在该项目中的参与度就越高，活跃度也越高.开发者在不同项目中参与的周期数和行为次数会存在较大的差异，对大部份的项目参与次数都较少且集中于某一个月中，对小部分的项目会有长周期(平均值为10个月)的参与和贡献，期间会存在若干的空窗期.这里提到的空窗期指的是对同一个项目两次参与行为之间的间隔时间.项目中的长期参与者大部分都是项目内部人员，当然临时参与者的提交被合并后，他就成为了该项目的贡献者，后续是以内部成员的角色参与其中.不同的角色参与项目的时长也存在明显的差异，项目成员的持续时间最长，而临时参与者最短.其中，这类开发者愿意长期参与维护或贡献的开源项目更能凸显该名开发者对某一特定领域的偏好.推荐系统在为该名开发者进行开发者建模时不妨可以考虑提高他长期参与贡献项目特点的权重，使得开发者模型更为精准.

5.3 时间间隔对开发者再次回归项目的影响

开发者参与贡献或维护一个开源项目通常是一个连续的过程，期间间隔周期的长短是反映他在该项目中活跃与否的重要指标[10]之一，时间间隔越长表示对于该项目的兴趣不断下降，那么他在项目中流失的可能性也就越大.本文认为，时间间隔为两个月是一个比较合适的分割点[10]，由于间隔超过两个月开发者回归的情况大幅降低，所以开发者在一个项目中连续两个月没有参与行为，那么可以判定他在该项目中流失即他将不再继续参与该项目.平台的开源项目推荐系统在进行项目推荐时，可以优先分析一下开发者在项目中的参与程度积极与否，从而得到一个合适的契机.

5.4 同时活跃状态下参与项目及新加入项目的相似性

我们发现描述相似性普遍很低，由此可知开源项目的描述相似性在实现推荐中并不是一个合适的特征.标签相似性略高于描述相似性，但绝大部分的情况小于0.3.开发语言的相似性要明显好于前两者，开发者在选择项目的时候都偏爱自己熟悉的语言.当然也存在开发语言完全不同的情况，主要原因是开发者通常会掌握两种以上的开发语言以满足不同的业务需求.在项目的流行度和规模上都表现出了较高的相似性，尤其是在项目的流行度上，这一点应该与选择分析的对象是有着较高影响力的开发者有关，后续的研究可以讨论开发者的影响力与项目流行度是否存在关联.

在一个项目结束活跃后，开发者往往会在较短的时间内加入一个新的项目，这个时间通常小于一个月.新加入项目和结束活跃项目两者相似性要明显高于同时活跃状态下的项目相似性，在开发语言上完全不同的情况大幅降低，这为项目推荐提供了重要的参考即开发者在选择下一个项目的时候会偏爱与上一个项目类似的开发语言.

6 总结与展望

本文对开发者在多个开源项目中的参与情况做了分析，意义在于尝试理解开发者的跨项目行为特点，为后续的开发者建模及开源项目的个性化推荐提供一定的参考依据.结果表明，开发者普遍都愿意同时参与多个开源项目，参与项目数与拥有项目数存在较强的相关性；角色为成员的开发者在项目中持续的时长要明显高于其他两种角色的开发者；当开发者在一个开源项目中的行为间隔超过两个月那么他再次回归该项目的可能性大幅降低；同时活跃状态下开发者参与的项目中，大部分都是以临时参与者的身份参与其中；开发者在一个项目中结束活跃后，普遍愿意在一个月内加入一个新的项目，且新加入项目的相似性要明显高于同时活跃状态下的相似性.对开发者进行开源项目推荐时，可通过分析他当前参与项目中的活跃状态变化，得到一个合适的推荐时机.这样的考虑开发者当前参与状态的推荐方式比起以往的推荐机制显得更合理、更人性化.

当然，本文所做的工作还相对有限，存在需要改进的地方.例如考虑到用户行为数据的稀疏性(20%的开发者在开源社区中做出了80%的贡献)，所以本文选取的研究对象是1000名有着较大影响力的开发者.还有就是对项目相似度的衡量，不应只局限于若干自带的属性.在下一步的研究工作中，要扩大实验数据的规模，覆盖更为广泛的开发者，同时增加对项目相似度的评价属性和方法，对开发者的行为进行更精准的评估.

开发者作为开源软件的核心，是整个开源社区的灵魂所在，开发者的状态将直接决定一个开源项目的成功与否甚至影响整个开源社区的健康可持续发展.本文分析了开源社区中开发者跨项目参与行为，主要包括参与项目情况、活跃度的变化和参与项目之间的相似度特点.开发者依然是未来研究工作的一个方向，可以重点关注哪些因素会影响开发者在开源项目中的活跃状态，哪些原因使得开发者从项目中流失及当前状态下开发者表现出的何种行为特点将预示着他将从该项目中流失.找到其中的影响因素并采取相应的措施将会使得整个开源社区受益.