开源软件版本发布与开源社区贡献评估的关系实证研究

董 晨 尹 刚

1(天津理工大学计算机科学与工程学院天津市智能计算及软件新技术重点实验室 天津 300384)2(国防科技大学计算机学院复杂系统软件工程湖南省重点实验室 湖南 长沙 410073)

0 引 言

开源软件是一种源代码可以自由获取、修改、再分发的软件[1-2]，其所展现出的强大创新力和生命力给软件产业带来了巨大的变革，开源软件正在被越来越多的领域所应用。例如著名的开源软件Linux正在被大量的企业和机构用作服务器操作系统，成为支撑起如今互联网高效运转的重要基础设施。开源软件的成功来自于开源社区的开源开发者[3-4]，这些开源开发者分布在世界各地，他们通过网络进行沟通和合作，并在一定的协同机制下为开源软件贡献代码[5]。据Linux基金会2017年的官方数据统计，已经有来自1 300多个公司的14 000多个开发者为Linux内核提交了代码贡献。由此可见,开源开发者是开发软件得以生存和发展的重要推动力。

另一方面，开源软件在不断发展的过程中会经历一个个的里程碑，并在恰当时机发布新的软件版本[6]。每一个软件版本可能包含了对上一个版本所包含的bug(软件缺陷)的修复，也可能包含了新添加的功能。在每次发布新的软件版本时，软件项目的管理团队需要在综合考虑软件的稳定性以及任务的紧迫性的前提下，决定是否需要把某些特定改动加入到本次发布计划中[7]。

软件版本发布规划不仅仅会直接影响到软件用户群体的使用体验，还有可能会影响到开源开发者的参与体验。然而正如前所述，开源开发者是促进开源软件不断发展的核心力量。因此，为了更好地分析开源社区对开源开发者贡献的接受现状，本文从开源软件版本发布的角度出发，对开源开发者的贡献评估进行了实证研究，并试图回答以下两个研究问题：

研究问题1:开源软件版本发布对开源社区贡献第一次评估反馈延迟的影响。

研究问题2:开源软件版本发布对开源社区贡献接受概率的影响。

通过这些研究，我们深入分析了开源软件版本发布与开源社区开发者贡献评估的关联关系。与此同时，我们也对开源社区提出了相应的实践建议，以促进开源社区的健康持续发展。

1 研究方法

如图1所示，我们首先构建开源软件版本发布与社区贡献数据集，然后基于此数据集分别开展两方面的研究：1) 软件版本发布与第一次评估反馈延迟的关联分析；2) 软件版本发布与贡献接受概率的关联分析。

图1 研究方法概览

1.1 数据集构建

(1) 调研项目。GitHub是目前最火的开源社区，它为开源软件提供源代码托管、开发任务管理等一系列功能和服务，目前已经托管了超过一千多万的开源软件项目。鉴于GitHub平台是极具代表性的开源社区平台，我们选取它作为我们的调研平台，并在该平台上进一步选取了要具体分析的开源软件。我们设定的软件筛选标准为：

• 软件版本发布频繁。

• 软件比较流行，参与的开源开发者数量大。

最终，我们选取了GitHub平台上三个流行开源软件：bootstrap、scikit-learn以及elasticsearch，三个开源软件具有不同的编程语言和应用领域，其基本信息如表1所示。如表2所示，其社区关注数量和开发者群体以及其代码提交数量都是位于社区前列水平，表明其是具有一定流行度的软件。

表1 调研项目的基本信息

表2 调研项目的流行度指标

(2) 原始数据采集。如图2所示，我们通过Github网站提供的数据服务接口采集实验所需的原始数据。Github提供了丰富的接口以获取其网站的各种数据，其中社区贡献数据通过接口“/repos/:owner/:repo/pulls”采集，版本发布数据通过接口“/repos/:owner/:repo/releases”采集。采集到的数据存储于关系型数据库MySQL中。

图2 数据采集方案

(3) 数据清洗。为保证实验的准确性和有效性，消除其他干扰因素的影响，我们对采集到的原始数据进一步清洗，其中包括以下操作：

• 剔除起始阶段的数据：由于在软件发展的起始阶段，软件的开发和维护还未进入稳定状态，其版本发布还未处于正常状态，因此我们对这一部分数据不予考虑，而从软件管理团队开始有规律性地发布版本开始。

• 只保留正式版本：在发布正式版本前，项目管理管理团队还会发布一些测试版本，而测试版本的发布较为随意一些，同时也过于频繁。因此，我们在实验中只保留了正式发布的版本而去掉了测试版本。过滤方式是使用文本分析的技术，判断每一个版本发布的后缀名是否以数字结尾，并且不包含“beta”字样。

• 只保留有效版本间的贡献数据：在确定了有效的正式版本后，我们定位出最老版本和最新版本，并只保留这两个版本之间的贡献数据。

最终，我们共收集了174个软件版本发布数据以及103 892个贡献数据。

1.2 软件版本发布与第一次评估反馈延迟的关联分析

为评估软件版本发布对开源社区贡献第一次评估反馈延迟的影响，我们首先定义了以下三个变量。

(1) 版本发布周期：

RC(i)=Time(Ri+1)-Time(Ri)

(1)

式中：Ri表示按照时间顺序排列的第i个版本，而Time函数用于返回所传递参数的创建时间点。因此，发布周期RC表示两个相邻版本的时间间隔差。

(2) 发布后提交相对间隔：

(2)

式中：P表示处于版本Ri和Ri+1这时间段时，开源社区开发者所提交的某次贡献。因此，发布后提交相对间隔RI(i,R)表示的是：以上一个版本为基准点，贡献P在本次周期内是哪个阶段提交的。当RI取值为0时，表明贡献P是在上一个版本发布时被提交的；而当RI取值为1时，表明贡献P是在本次发布周期的结尾，也就是下一个版本发布时被提交的。

(3) 评估延迟：

ED(P)=Time(CMTfirst(P))-Time(P)

(3)

式中:CMTfirst函数用于返回某次开源贡献所接受到的第一个反馈，因此评估延迟ED表示从贡献P被提交开始，到它接收到第一个评估的时间延迟。对于每一条开源贡献数据，我们计算它的发布后相对间隔和评估延迟，然后分析它们之间的关联关系。

1.3 软件版本发布与贡献接受概率的关联分析

为评估软件版本发布对开源贡献接受概率的影响，我们首先定义了如下变量(发布后评估相对间隔)：

(4)

式中：TimeD函数用于返回开源贡献P的评估结果时间点。因此RID(i,P)的含义类似于式(2)中RI(i,P)的含义，只是P的分析时间发生了变化。

接着，我们统计了以下两组数据。

(1) 被合并的贡献分布数据:

(2) 被关闭的贡献分布数据:

在上面两组数据中，RID表示发布后相对间隔的取值分布，而Countaccepted和Countrejected分别表示被接受的和被关闭的开源贡献在RID下的数量分布。进而，我们对这两组数据进行对比统计，分析软件版本发布是如何影响开源贡献的接受概率的。

2 研究结果

2.1 研究问题1

发布后提交相对间隔和评估延迟的关联关系如图3所示。可以看出，当发布后相对间隔取值在0.5左右或者1.0左右时，开源贡献的第一次评估反馈延迟较小；而当发布后提交相对间隔取其他值时，反馈延迟具有波动性，不过在0.0附近时反馈延迟相对稳定地维持在一个较高水平上。

图3 软件版本发布与第一次评估反馈的关系

由以上实验观察我们可以得到初步的结论：在一个软件版本发布周期内，在后半期提交的开源贡献更有可能得到及时的反馈，而在前半周期提交的开源贡献的反馈延迟则更长一些。对于这种现象，一种可能的解释是在软件版本发布前，项目管理团队需要对项目整体的动态进行全局把握，并且由于筹划版本发布的事务，管理团队可能会有更多的时间关注项目，从而有更多的机会注意到开源贡献者所提交的工作，从而给予及时的反馈。

2.2 研究问题2

发布后相对间隔与开源贡献的接受概率的对应关系如图4所示。可以看出，虽然开源开发者的贡献的接受率大体维持在40%～50%之间，但确实也存在着一定的变化。尤其是在发布后评估相对间隔取值在[0.9,1.0]区间时，开源贡献的接受率是最低的；而当发布后评估相对间隔在较小区间取值时，开源贡献的接受率相对是高一些的。

图4 软件版本发布与贡献合并概率的对应关系

由以上实验观察我们可以得到初步的结论：在软件版本发布前，项目管理团队对开源贡献持谨慎态度，更倾向于拒绝而不是接受；而在版本发布后，项目管理团队对开源贡献持相对乐观一些的态度，具有更高的概率去接受开源贡献。对于这种现象，一种可能的解释是在软件版本发布前，项目管理团队更希望发布一个稳定的版本，而不是额外接受一个开源贡献，从而承担更多的不可控的风险。而在版本发布后，项目管理的紧张氛围有所缓解，同时又有后续充裕的时间对开源贡献和合并效果进行监控，因此管理团队有更高一些的概率去接受一个开源贡献。

3 实践建议

根据实验结果，我们对开源社区的参与者提出了针对性的实践建议，以促进开源社区更高效的健康发展。

3.1 面向管理者

对于开源软件项目的管理者来说，管理项目的版本发布以及管理开发社区开发者的贡献均为及其重要的事务。项目的版本发布管理是软件能够阶段性有序演化的必要手段，开源社区的贡献管理是软件能够持续发展的重要条件。然而管理团队的时间和精力是有限的，因此如何平衡好软件版本发布和社区贡献评估对于开源软件的发展是至关重要的。

就实际情况而言，软件版本发布管理是一个阶段性的集中工作，而社区贡献评估是一个持续性的工作，因此这两类工作的冲突不是一直存在的，只有在需要对软件版本发布进行规划和操作时才有可能发生。因此为了避免两类工作的冲突，开源软件的管理团队可以指派专人负责版本管理，而其他人则更加专注社区贡献的管理，这样既可以保证版本发布的质量，也可以保证社区贡献评估的及时反馈。此外，在版本发布期间，可以把不太确定的社区贡献接受到测试版本中而不是拒绝该贡献，这样既能保证发布版本的稳定性，又能吸收社区的贡献。

3.2 面向贡献者

对于贡献者来说，他们所关注的不应该仅仅在提交的贡献本身，还要对开源软件项目的整体发展和规划有更进一步的认识。在提交贡献时不干扰项目的版本发布规划，或者不被项目的版本规划所影响，尽量在版本发布空窗期提交贡献，提高自己被接纳的概率。此外，如果自己所提交的贡献没有得到及时的反馈，不要轻易迁怒于项目的管理团队，指责其响应时效低，并放弃对贡献的持续关注和必要更新，这会对项目的环境建设带来负面的影响，应该要考虑客观情况，积极应对。

4 相关工作

4.1 开源软件/社区

开源软件的快速发展吸引了大量研究人员的关注。杨波等[8]对托管在GitHub平台中开源软件开发过程中产生的数据进行分析并提取了多种类型的指标因素，例如问题解决速度和提交增加速度等，他们对这些因素之间的相关性展开了研究。孙晶等[9]提出了开源软件的可信性模型，定义了开源软件的可信属性及组件可信性，通过火狐浏览器验证了模型的有效性。刘雅新等[10]通过挖掘开源项目邮件列表信息与版本提交日志信息,构建了开发者的合作网络,基于此网络他们分别分析了开发者整体活跃度以及个体开发者活跃度的变化趋势。O’Mahony等[11]研究了开源社区的治理模式。杨彬[12]研究了开源世界的许可证机制的发展历史以及应用现状。Mocus等[13]选取两个著名的开源软件Apache和Mozilla为研究对象调研了开源软件的实际开发过程。

4.2 贡献评估

由于开源开发者群体数量巨大，其编程水平层次不齐，为了保证其所提交贡献的质量，开源社区需要对其贡献进行评估，这其中会涉及到一些任务指派和推荐等工作。卢松等[14]利用信息检索技术,综合考虑了开发者的影响力因子以及评估的时间衰减的因素,为每一个新提交的开源贡献自动推荐最合适的评估者。张文等[15]提出一种基于K最近邻算法的缺陷修复人推荐方法OSDR，该方法首先计算给定的缺陷报告与历史缺陷报告之间的文本相似度,然后利用K最近邻算法计算相似度最高的K个历史缺陷报告及其对应的修复人列表。Bosu等[16]研究了开发者的个人声誉是如何影响贡献评估结果的，发现核心开发者能够得到更及时的评估反馈，并且核心开发者的评估耗时较短，被接受的概率也更大。Beller等[17]对真实开源项目的贡献评估记录数据进行了实证研究，深入分析了贡献评估者的实际关注点。Hamasaki等[18]基于代码仓库和代码审查系统构建了四个开源软件代码评估的公开数据库。

4.3 软件开发管理

软件开发往往需要多个开发者一起协同完成某项任务，同时开发过程中会遇到需求变更、人员流动等问题，因此为了保证项目能够有效推进，需要对软件的开发过程和开发规划进行管理。杨崑等[19]调研了软件开发过程中开发团队常见的沟通与协调活动，并分析了能够影响开发团队沟通与协调活动的项目特征以及沟通协调活动与项目的输出之间的关系。邹筱菁等[20]深入分析了基于DevOps开发模式下的软件开发流程,并对相应步骤给出了规范示例。王晓凯[21]探讨了在项目管理过程里出现的常见问题并给出了针对性的解决策略。Münch等[22]从软件开发过程的基本概念入手，着重介绍了现在具有代表性的集中软件开发过程模型以及每一种模型所需的执行方法和必要工具。

5 结 语

本文选取了GitHub平台上三个流行开源软件bootstrap、scikit-learn以及elasticsearch作为实验对象，采集了这些项目的软件版本发布数据以及社区贡献数据。基于采集的数据，对开源软件版本发布与开源社区贡献的评估展开了实证研究。重点分析了开源软件版本发布对开源贡献第一次评估反馈、开源贡献接受概率的影响，我们发现：

1) 临近软件版本发布时间点前所提交的社区贡献的第一次评估延迟更低一些。而在软件版本发布刚结束后所提交的社区贡献的第一次评估延迟则要高一些。

2) 临近软件版本发布时间点前所提交的社区贡献被接受的概率更低一些。而在版本发布后所提交的社区贡献被接受的概率要高一些。

另外，根据实验结果我们还对开源软件管理者以及贡献者的行为模式以及协作理念提出了针对性的建议。

在将来的工作中，我们计划进一步研究开源软件版本发布对开源社区贡献类型的接受偏好，即修复软件缺陷的贡献以及实现新特征的贡献的接受率是如何受开源软件版本发布的影响的。