关于开源项目的生存分析

Posted 2021-04-23 数据挖掘与开源生态

摘要

我们将生存分析方法应用于一个公开可用的软件项目的数据集，以检查可能导致它们在一段时间内不活跃的属性。我们进行了Kaplan-Meier分析，并将Cox比例风险模型拟合到软件传统图数据集的一个子集上，该数据集由GitLab/GitHub、Debian和PyPI上托管的3052个流行Python项目组成，历时165个月。我们表明，拥有多个托管服务上的存储库、发布主要版本的时间表和良好的开发人员网络的项目，会随着时间的推移保持健康，值得开发人员和贡献者付出努力。

0 1

引言

开源软件（OSS）项目在当今的软件环境中无处不在，并提供了丰富的数据集，在此基础上使用从传统的统计学到深度学习来分析软件开发过程的各个方面。它们的独特之处在于允许开发人员自愿投入他们的时间和精力来创建面向所有人使用的软件。虽然开源开发工作通常有一个人或机构选择开发的代码子集进行构建发布，并将其提供给大家，但这些项目是由一个分散的开发者团队维护的，他们的组织成本很低，能够生产出有时被数百万人使用的应用程序。在一项调查中，72%的参与者表示，他们在评估新工具时总是寻找开源选项。

Lucassen等人将软件生态系统的健康定义为“寿命和增长的倾向”。每一个健康的开源项目都需要一个专注的开发团队和一个设定的目标和成就的时间表。这些项目还需要足够受欢迎，以获得潜在志愿者的兴趣。当开发人员对项目和最终目标感到兴奋时，很难预测开源项目的健康状况。但是可以看到一个项目在一段时间内的表现。项目的健康状况可以通过贡献的数量和频率、开发人员实现大目标的频率，或者团队对软件准备发布的关注程度来计算。由于开发人员作为志愿者参与这些项目，他们希望确保他们的贡献不会进入到可能以非活动状态结束的项目中。如果志愿者事先知道这些知识，他们就可以在投入到单个项目之前考虑其他途径。

在这里，我们主要从添加的角度来关注项目的健康状况，因为每个添加到项目存储库的新代码都意味着团队正在满足其目标。我们还想了解在项目中工作的志愿者的数量，他们工作的时间线，以及他们用来托管项目的版本控制系统(VCS)的数量。在多个VCSs或存储库(如PyPI或Debian)上运行一个项目，突出了项目的可访问性，并表明了开发人员和工作团队的认真态度。我们使用生存分析(通常用于医学研究来预测治疗效果)，使用Kaplan-Meier生存分析来寻找流行开源项目随时间的生存概率，并使用Cox比例风险模型来量化这些变量的影响。

0 2

数据集

这种性质的分析只能通过一个数据集来实现，该数据集完整地记录了公共VCSs上项目的存储库以及所有提交(称为修订)和主要发布(具有特定名称的值得注意的修订，如版本号或发布日期)的历史。该分析使用软件传统图数据集的流行的-3k-python子集。该数据集包括2005年至2018年间在GitLab、GitHub、Debian和PyPI上托管的近3000个热门项目的快照。这些项目被标记为使用Python作为主要编程语言。分析单个存储库，我们能够准确地辨别一个项目的修订次数，以及交叉引用托管在多个vcs上的项目存储库。总的来说，我们提取了项目中每个修订和发布的时间戳和作者标识符，以及用于托管项目存储库的VCS。

对于生存分析，我们首先需要建立一个时间表，在这个时间表中我们分析项目的健康状况。我们提议的时间跨度为14年或165个月(我们将一个月定义为4周)，从2005年开始至2018年1月结束。因为Software Heritage在几个月内为每个项目收集了多个快照，所以每个项目的最新快照的近似值有很大的可变性。为了确保所有项目的工期相同，我们使用了2018年1月的单一截止日期。图1显示了在时间持续时间内按最长至最短工期排序的所有项目的持续时间。截止日期也确保了在2018年期间开始的项目会被从研究中丢弃，因为它们没有足够的时间来建立它们的修订时间表。在去除这些项目和那些历史上只有一个实例的项目后，我们最终得到2059个项目，并提取它们在165个月内的所有历史数据。没有排除异常值。

0 3

研究方法

生存分析是生物统计学中用来研究一个实体生命持续时间的一种统计方法。这种方法是基于对在研究过程中随时可能发生的事件的测量。用于生存分析的数据包括发生感兴趣事件之前的时间。例如，生存分析可以用来模拟肿瘤复发、治疗干预后死亡或患者出现症状之前的时间。对于生存分析在OSS开发中的应用，Lin等人和Ortega等人将感兴趣的事件定义为一段时间后停止贡献的开发者，并用它来研究开发者退出对项目健康的影响。Aman等人将新开发者的提交作为他们的事件，来分析将错误代码引入软件仓库的影响。在本研究中，我们将感兴趣的事件定义为软件库放弃或完全缺乏活动的事件。

生存分析的一个重要方面是审查。在观察所有项目的期间内，如果不活动(作为感兴趣的事件)没有发生，那么我们只知道事件没有发生的月总数。换句话说，事件发生的确切时间是被审查的。为了确定哪些项目应该被审查，Samoladas等人使用每月分析来检查每个项目的活动。如果一个项目连续两个月没有活动，则该项目被视为放弃。但这种方法导致的不活跃事件发生的项目子集非常小，而研究的不活跃项目中很大一部分来自于不同的方法。相反，我们使用Evangelopoulos等人使用的方法，即如果一个项目根本没有任何活动，则认为该项目被放弃。对于我们的研究，一个在2018年1月截止日期之后进行修订的项目肯定是积极的，并被视为审查，因为在165个月期间没有观察到不活动的时间。剩下的项目，在时间结束时突然没有显示活动(没有新的修订或发布)，就变成不活跃的。这种形式的截尾被称为第三类截尾(通常称为随机截尾)，允许不同的项目错开开始时间。Avelino等人将随机审查描述为软件项目研究中最常见的情况。研究的时间段是预先设定的，在研究的时间段内项目开始的时间不同，如图1所示。我们注意到数据集在时间段内包含的活动项目多于非活跃项目。

Kaplan-Meier (K-M)生存估计器是分析和比较生存概率的重要工具。它是一种非参数估计技术，是一种广泛使用的估计生存函数的方法，在删失值存在的情况下，生存函数是一个项目的持续时间超过时间t的概率。K-M估计产生了一条曲线，它接近数据的真实生存函数。这让我们可以比较不同属性的OSS项目的生存概率，即使一些数据被审查。虽然K-M曲线为我们提供了随着时间推移具有不同属性的项目的生存情况的可视化表示，但Cox比例风险模型允许我们使用回归模型来调查项目健康状况和关键项目属性之间的关联。有各种参数模型可用来对持续时间与其他属性的关系进行建模，但Cox比例风险模型允许在不考虑风险函数的情况下估计影响参数，后者描述了事件发生的风险如何随时间变化。我们对数据应用K-M估计和Cox比例风险模型来估计属性对开源项目整体健康状况的影响。

0 4

实验结果

我们使用项目的以下属性来估算随时间推移的存活率:

• majorReleases是否由项目开发人员发布

• hostType项目存储库使用的托管服务类型

• authorCount已向存储库提交修订的唯一开发人员的总数

• 多存储库项目是否托管在多个版本控制系统上

我们现在讨论运行K-M曲线和对数据拟合Cox比例-风险模型的结果。

4.1 Kaplan-Meier生存曲线

对于上面描述的所有四个因子属性，我们生成单独的K-M曲线，使用置信区间。图2显示了根据每个属性的分类值分组的项目的生存概率。我们还展示了来自log-rank检验的p值，结果表明，对于测试的每个属性，每组项目在生存方面是显著不同的。只有5.73%的项目至少发布了一个版本;一个合并了几个提交并给项目带来主要更新的修订，我们观察到至少有一个版本显著增加了165个月期间结束时项目存活的机会，如图2a所示。官方发布是一种方式，表明对项目进行了重大更改和添加，以至于可以将它们合并为软件的单个版本。这也意味着开发人员正在达到目标，该项目将继续保持活跃。有版本发布的项目的曲线右尾在80个月左右达到85%的存活概率，意味着长期存活者的存在，而零发布的项目在研究期限结束时的存活率低于30%。

图2b显示了为开源项目使用不同托管服务的意义。GitHub是最大的社会化编码平台，所有的提交、问题、代码修改和请求都会被公开存档，这已经成为开放源码软件开发的标准。这吸引了很多开发者使用GitHub作为他们的仓库的主机，而Debian和PyPI则是开发者将他们的项目托管在GitHub上进行发布的软件包仓库。与其他两个托管服务相比，托管在GitHub上的项目在生存竞赛中脱颖而出。不过需要注意的是，基于 Debian 和 PyPI 的项目在前 55 个月的存活率较高，这也是三个服务中项目的平均存活时间 (50-57 个月)。当一个项目准备好发布时，特别是在Debian操作系统上或作为Python的库，它通常会被添加到Debian和PyPI的包库中。这意味着一个开源项目已经取得了显著的发展，并且非常活跃。但是我们看到，一旦超过了平均持续时间的阈值，Debian和PyPI上的两组项目的生存概率都明显下降。图2c就说明了这个事实。我们看到，为了发行目的，将软件库托管在多个服务上的项目，在分析持续时间结束时，有80%的健康存活率，而只使用一个软件库系统的项目则低于20%。

发布主要版本或在不同的存储库上发布项目是对开放源码项目健康开发周期的认可。如果一个项目有版本发布，那么它可以跨不同的系统发布。我们看到，随着时间的推移，一个项目的这种特征显著地增加了它生存的可能性。但是一个健康的开源项目的一个非常重要的组成部分是开发人员的网络，它实际上产生了这些发行版和分发版。Sentas等人分析，即使一个项目很受欢迎，如果主要开发人员离开这个项目，它也会处于被抛弃的危险中。因此，重要的是，主要的开发更改不能由选定的少数开发人员维护。在我们的数据集中，28.8%的项目只由一个开发人员进行修订。如果该开发人员离开了项目，就会给项目继续保持活跃带来严重的问题。图2d中的K-M曲线突出了这个问题，我们展示了至少有20个不同的提交者(对修订)的项目与那些没有提交者的项目的存活率。选择20作为临界值是因为这个数字将包括核心开发者群体以及少数次级开发者群体。它变得明显,良好的开发人员、网络提交和修改的任务是许多开发人员之间共享,最终拥有超过65%的存活率是不同项目维护领导的小组开发人员,与165个月后存活率约20%。

4.2 COX比例风险模型

我们将Kaplan-Meier分析中使用的分类属性拟合到Cox比例风险模型中，以估计这些属性对开源项目健康状况的影响。我们使用那些发布了主要版本的项目，在多个托管服务上有存储库，有超过20个发布了版本的独立开发者，并使用GitHub/GitLab作为他们的主要托管服务做为基准。这个基线作为危险比的对照或参考组。

表1给出了每个属性的危险系数。我们表明，所有比率在统计学上都是有意义的，没有发布的项目与有定期发布的项目相比，不活跃的可能性高3倍。同样，只有一个存储库的项目比有多个存储库的项目不活跃的可能性高3.3倍。如图2中的K-M曲线所示，当比较做出修订的独立开发者数量时，我们显示了项目之间的显著差异，低于20的项目被放弃的可能性是5.95倍。对于所使用的托管服务类型，我们发现与那些托管在GitHub/GitLab上的项目相比，托管在PyPI或Debian上的存储库的项目更不可能被放弃。这种观察与以下观点一致:当开发人员准备发布他们的软件时，他们只会在PyPI和Debian上托管存储库，从而在软件开发方面取得了重大进展。

应用于数据的两种生存分析技术强调了常规更新和开发人员良好网络对OSS项目的重要性。这些特征可能与看不见的变量有关，例如项目的私人资金或对软件工具的高需求。还有一种可能是开发者在项目中获得的报酬超过了我们用于分析的20名唯一作者，而项目因为资金突然减少而被放弃。然而，这个分析显示了一个项目的生存机会与开发人员和常规版本的多样性之间的明显联系。虽然生存分析通常用于医学研究，以估计生物的生存，但开源项目也像生物体一样，当所有组件都工作良好时，它们仍然保持健康，并随着时间的推移继续滋养和生长。但是忽视，以低修改率和过于依赖一小部分开发人员的形式出现，与长期的不活动有关。

05 总结

我们的研究目的是通过生存分析来探讨开源项目属性对其整体健康状况的影响。我们发现，虽然有重大发布的项目的百分比相对较低，但此类项目的存活率明显高于没有发布值得注意的修订的项目。我们还展示了使用多个托管存储库的影响，以及项目长期使用的服务类型。最后，使用Cox比例风险模型，我们估计拥有小型核心团队的项目比拥有多样化核心团队开发人员的项目更有可能处于不活跃状态。