基于RubyGems和npm软件生态系统中开发者保留率的研究

Posted 2021-06-18 数据挖掘与开源生态

摘要:软件生态系统可以看作是由技术组件（软件包）和维护技术组件的社会组件（开发人员社区）组成的社会技术网络。随着时间的推移，生态系统会随着社会技术的变化而演变，这些变化会极大地影响生态系统的可持续性。像开发者更替这样的社会变化可能会导致技术退化。这就需要识别导致开发人员放弃的因素，以便自动识别具有高放弃风险的开发人员。本文比较了RubyGems和npm两个软件包生态系统的这些因素，我们分析了他们在GitHub上托管的包的演变，考虑了提交方面的开发活动，以及与其他开发人员在评论方面的社交互动。我们的结果显示，具有以下行为的开发人员放弃生态系统的概率较高：不与其他开发人员进行讨论；社会活动不频繁；沟通少提交频率低；长时间没有提交或交流活动。这些行为可以用来自动识别放弃生态系统的可能性很高的开发人员，从而降低相关风险。

1. 简介

过去，软件开发主要是作为单个和孤立项目的一部分，而现在软件项目变得越来越相互依赖，形成了巨大的生态系统。Lungu将此类软件生态系统定义为“在同一环境中一起开发和演化的软件项目集合”。我们坚持这一定义，并将软件生态系统视为由技术组件（例如，软件包依赖关系网络及其源代码历史）和社会组件（例如，参与软件开发和维护的贡献者社区）组成的社会技术网络。众所周知的软件生态系统的例子是Linux操作系统的发行版和特定编程语言（如CRAN for R、RubyGems for Ruby和npm for javascript）的包管理器。作为软件生态系统一部分的项目不同于孤立的软件项目，因为它们共享源代码（例如，通过依赖共享库）和开发人员。

虽然研究界已经深入研究了单个项目的演化，但软件生态系统的演化仍然是一个新兴的研究课题。特别是，需要进一步研究社会方面即开发人员如何互动，以使他们的项目作为可持续软件生态系统的一部分保持最新；确定开发人员社区的社会特征的影响，以及这些特征随时间的变化等。在一个健康和可持续的生态系统中，开发者可以参与多个项目，并迁移到生态系统中的其他项目，而当开发者完全放弃生态系统时，问题就会出现。考虑到开发人员是成功的生态系统进化的支柱，确定影响开发人员保留的因素非常重要。可以通过预测可能的放弃风险并及早减轻这些风险来帮助生态系统的未来进化。这将增加重要开发商的保留率，并减少此类开发商离开社区的负面影响[5]。

本文的目的是找出影响开发者放弃生态系统的因素。特别地，我们研究了两个长期存在的软件生态系统npm和RubyGems的社会技术演化，它们分别对应于JavaScript和Ruby编程语言的包管理器。我们考虑在GitHub上开发的软件包的子集，因为我们调查了参与这些生态系统的软件开发人员的社会（通信）和技术（编码）活动。编码活动是从源代码提交中提取出来的，而社交活动（开发人员之间的通信）是基于GitHub注释机制（提交、发布和拉取请求注释），涉及多个开发人员。

论文的结构如下：第二部分讨论了相关工作，第三部分提出了研究假设。第4节描述了实验设置，包括数据收集方法和我们的研究假设的可操作性。第5节介绍了实验结果，第6节为核心和外围开发人员报告了我们的发现。第7节讨论了我们研究的局限性，第8节报告了对我们工作有效性的影响和威胁。最后，第9节总结并提出未来的研究方向。

2. 相关工作

研究团体已经对开发人员保留进行了调查，包括旨在理解开发人员放弃开源软件项目背后的因素的研究和测量开发人员周转率的研究，即测量由于社会变化（如开发人员离开或加入项目）而对开源软件项目产生的影响。

在最近的一项工作中，Lin等人研究了五个工业开源项目，以确定开发人员的流动性如何受到持续时间和贡献类型的影响。Yamashita等人分析了一系列GitHub项目的迁移趋势，以衡量它们的吸引力（吸引新来者的能力）和粘性（留住现有开发人员的能力）。Zhou和Mockus量化了贡献者的意愿和他们所处的环境，以模拟他们成为项目有价值贡献者的机会。

有几项研究侧重于如何提高软件项目新人的留任率。Steinmacher等人进行了系统的文献回顾，以确定和分类新来者面临的障碍。他们的研究提出了一个涉及五个因素的模型，即社会互动、先前的知识、寻找开始的方法、文档和技术障碍。他们发现，最明显的障碍是缺乏与项目成员的社会互动，没有（及时）得到答案和以前的技术经验。此外，他们还强调缺乏证据表明社会交往问题与新人成功之间存在因果关系。本文并不关注新来者，因为我们的目标是根据开发人员在生态系统中过去的活动来发现影响他们留下的因素。

3. 研究假设

为了确定影响开发人员保留的因素，我们将重点放在项目开发人员在所考虑的生态系统的技术（即提交）和社会（即通过GitHub评论进行交流）部分的活动上。如果某个人已经将更改提交给了项目的源代码存储库，那么我们认为他是一个开发人员，而不管更改的类型是什么。这意味着并非所有提交都必须包含对源代码文件的更改。

3.1与社会活动相关的研究假设

H_1.0 不交流的开发者更快地放弃生态系统的可能性更高。这个假设考虑了开发人员是否真的（通过GitHub评论）与生态系统中的其他开发人员进行讨论的特征。我们将开发人员分为三类：（1）社会活跃型；（2） 社交不活跃；（3）社会遗弃者。 

H_1.1 沟通不那么密集的开发者有更高的几率更快地放弃生态系统。这个假设根据每个开发人员提供的评论数量来探讨交流强度。我们从沟通强度的角度考虑了四类开发者：（1）非常弱 (2）较弱；(3) 较强；（4）非常强

H_1.2 通信频率较低的开发人员更快地放弃生态系统的可能性较高。这一假设探讨了社会活动的频率，即开发人员在整个生态系统中社会技术活动的时间跨度内，社会活动活跃的时间单位的百分比。我们根据开发人员在社交活跃期的百分比将他们分为四类：（1）很少(2） 很少(3）经常(4） 非常频繁。

3.2与技术活动相关的研究假设

关于技术活动的假设（以承诺来衡量）与社会活动的假设非常相似，只是H1.0没有对应的假设。为了被认为是一个开发人员，一个人需要在生态系统中做出超过一个月的承诺。考虑一类技术上不活跃的开发人员将毫无意义。

H_2.1 投入较少的开发人员更快地放弃生态系统的可能性更高。这个假设关注开发人员提交活动的强度。它们可以是：（1）非常弱；（2） 软弱的；（3）较强；（4）非常强。

H_2.2 不那么频繁地提交的开发人员更快地放弃生态系统的可能性更高。这个假设探讨了技术活动的频率，即开发人员在承诺方面活跃的时间单位的百分比，与他在生态系统中的社会技术活动的时间跨度有关。我们根据技术活跃期的百分比将开发人员分为四类：（1）非常罕见；(2)很少；(3)经常；(4)非常频繁。

4. 实验准备

为了验证我们的研究假设，我们为每个生态系统使用了两个数据源：从包管理系统中提取的信息，以及从GitHub中提取的开发和通信信息。最初，我们解析每个生态系统[1][2]中的所有包，以获取包名称、版本、依赖关系以及有关托管其开发的存储库的信息。接下来，我们使用GHTorrent数据集[13][3]获取托管在GitHub上的每个包的开发活动。为了将包与GitHub存储库匹配，我们分析了每个包在其信息中提供的所有可用链接（主页、bug tracker URI和源代码存储库链接），以恢复链接到GitHub存储库的链接。

     4.1  量化社会活动假设

H1.0 不交流的开发者更快地放弃生态系统的可能性更高。我们根据每个开发人员在与其他开发人员讨论时（通过GitHub注释）提供的消息的存在和时间戳来区分三个类别。我们用来描述社会活动的三个类别对应于：

社交活跃：至少讨论过一次并且仍在讨论的开发人员。

社交不活跃：从未讨论过的开发人员。

社会抛弃者：开发人员最初进行了讨论，但在发布最新消息后的一年多时间里，他们一直没有参与讨论。

H1.1 沟通不那么密集的开发者有更高的几率更快地放弃生态系统。我们依靠开发者在讨论中提供的评论数量来衡量他的沟通强度。评论的分布是高度偏斜的，即大多数开发者有少量的消息，而只有一小部分开发者非常活跃。因此，我们选择使用中位数作为中心趋势度量（而不是使用平均值），因为它对异常值和偏态分布更为稳健。类似地，我们使用四分位分组方法创建四个区间，根据社会活动强度对每个开发人员进行分类

非常弱：只有少量消息的开发人员（RubyGems:1-3，npm:1-4）

弱者：具有少量消息的开发人员（RubyGems:4-12，npm:5-15）

强：消息数量适中的开发人员（RubyGems:13-38，npm:16-50）

非常强大：拥有大量消息的开发人员（RubyGems:39-16321，npm:51-14202）

H1.2 通信频率较低的开发人员更快地放弃生态系统的可能性较高。沟通频率定义为不同的社会活动月数占开发人员社会技术活动总持续时间的百分比，即从第一次到最后一次贡献所用的月数。我们根据通信频率将每个开发人员分为以下几类：

很少：活跃的开发商参与社交活动的时间占其总入住时间的四分之一（0-25%）

较少：活跃的开发商参与社交活动的时间占其总入住时间的一半（25-50%）

经常：活跃的开发商参与社交活动的时间占其总入住时间的四分之三（5075%）

非常频繁：活跃的开发商在入住期间参与了社交活动（75-100%）

H1.3 长时间不交流的开发人员更快地放弃生态系统的可能性更高。社会不活跃的定义是，相对于开发人员社会技术活动的整个持续时间，开发人员不与其他开发人员交流的最大连续月数的百分比。与沟通频率类似，我们根据社交不活跃的百分比将开发人员分为四类：

非常短：0-25%

短：25-50%

长：50-75%长

很长：75-100%

     4.2  量化技术活动的假设

H2.1 投入较少的开发人员更快地放弃生态系统的可能性更高。提交强度是根据提交的数量来衡量的。与通信强度类似，提交也遵循高度倾斜的分布。

非常弱：提交次数很少的开发人员（RubyGems:1-7，npm:1-8）

较弱：具有少量提交的开发人员弱者（RubyGems:8-23，npm:9-25）

强：提交次数适中的开发人员（RubyGems:24-69，npm:26-81）

非常强：具有大量提交的开发人员（RubyGemts:69-8763，npm:82-20234）

H2.2 不那么频繁地提交的开发人员更快地放弃生态系统的可能性更高。提交频率定义为开发人员主动提交的不同月份占开发人员社会技术活动总持续时间的百分比

很少：活跃的开发人员承诺最多占其总入住时间的四分之一（0-25%）

少：活跃的开发人员承诺最多占其总入住时间的一半（25-50%）很少

经常：活跃的开发人员承诺最多占其总入住时间的四分之三（50-75%）经常

H2.3 如果开发人员不承诺更长的时间，那么他们很有可能更快地放弃生态系统。无提交活动定义为开发人员未提交的最大连续月份数占开发人员编码活动总持续时间的百分比（表2的第11-12行）。我们根据无提交活动的百分比对每个开发人员进行分类，其中不活动期可以是：

非常短：0-25%

短：25-50%

长：50-75%

很长：75-100%

5.生存分析结果

我们的研究假设需要根据提取的数据加以验证或否定。为了了解每种活动类型（包括其强度和频率）对软件生态系统中开发人员放弃的影响，我们采用了生存分析的统计技术。

   5.1社会活动生存分析

    H1.0 不交流的开发者更快地放弃生态系统的可能性更高。对于这两个生态系统，积极沟通的开发者的生存曲线明显高于其他两类。此外，社会不活跃的贡献者和社会抛弃者从参与生态系统的一开始就更有可能放弃生态系统，而在这两个生态系统中，只有不到10%的人在10年以上保持活跃。这些结果证实了我们的假设，即在某个时刻不与其他开发人员沟通或停止沟通的开发人员更有可能更快地放弃生态系统。

H1.1 沟通不那么密集的开发者有更高的几率更快地放弃生态系统。

每个通信强度类别的开发者的生存曲线如图2所示。强通信强度和非常强通信强度的开发者的生存曲线高于弱通信强度和非常弱通信强度的开发者的生存曲线。这些结果证实了我们对这两个生态系统的假设，即与生态系统中的其他开发人员进行更深入交流的开发人员更有可能在更长的时间内保持活跃。

H1.2 通信频率较低的开发人员更快地放弃生态系统的可能性较高。

我们也没有发现频繁和非常频繁类别之间的显著差异。然而，我们确实发现了这两个生态系统在统计学上的显著证据，即很少或非常很少交流的开发人员比经常或非常频繁地使用社区的开发人员更有可能放弃生态系统。

H1.3 长时间不交流的开发人员更快地放弃生态系统的可能性更高。

上图给出了不同类别通信开发人员的生存曲线。这些曲线表明，开发人员通信不活跃的时间越短，在生态系统中保持活跃的开发人员的概率就越高。验证了我们的假设。

5.2技术活动生存分析

H2.1 投入较少的开发人员更快地放弃生态系统的可能性更高。

上图显示了两个生态系统的活动强度类别的存活曲线。强和非常强的承诺活动强度下的存活曲线高于两种弱强度下的存活曲线。

H2.2 不那么频繁地提交的开发人员更快地放弃生态系统的可能性更高。

上图显示了提交频率类别的生存曲线。RubyGems和npm的存活趋势不同(RubyGems中经常活跃的开发人员在其活动的头几个月的生存曲线较低。更具体地说，只有40%的频繁活跃的RubyGems开发人员在活动的第五个月后仍然活跃，而50%的频繁活跃的开发人员在36个月后不会放弃生态系统。

H2.3 如果开发人员不承诺更长的时间，那么他们很有可能更快地放弃生态系统。上图表明，开发人员保持不活动状态的时间越长，放弃生态系统的概率就越高。更具体地说，RubyGems和npm开发者如果长时间处于不活跃状态，那么他们在加入生态系统100个月后保持活跃的概率分别不到10%和25%。对于RubyGems和npm，在很短时间内保持不活跃状态的开发人员在100个月后保持活跃状态的概率分别接近60%和80%。短时间不活动的存活概率降低，但仍大于长时间不活动的存活概率。这些数据支持我们的假设，即长时间不承诺的开发人员放弃生态系统的概率更高。

6．核心开发人员与外围开发人员

一些实证研究已经调查了开放源码项目的社会技术结构，并表明大部分开发工作通常可以归因于一小部分开发人员。这些开发人员被称为核心开发人员，并有大量和长期的参与[6]。另一方面，外围开发商的贡献更加不规则，或者他们的参与是短期的。我们定义了两个指标来量化给定生态系统中开发人员工作的强度和分布。

定义1技术强度（TI）：生态系统E中开发者d的技术强度（TI）是最大值n，使得d对E中至少n个开发者参与的项目至少有n个承诺。

定义2技术扩散（TS）：开发人员d在生态系统E中的技术扩散（TS）是最大值n，使得d对属于E的至少n个不同项目具有至少n个承诺。

在本节中，我们将所有开发人员分为两类，即每个生态系统中的核心开发人员和外围开发人员，以评估对于开发人员的不同贡献频率和参与程度，生存分析是否会产生不同的结果。

对于H1.1，当在npm生态系统中考虑基于TS的核心开发者时，在通信强度类别之间没有发现统计差异。这表明从事多个项目的npm核心开发人员在生态系统中保持活跃的概率相似，而不管他们的交流强度如何。同样的结果也出现在基于TI的外围开发人员身上，这表明npm外围开发人员对小项目的承诺数量较少，无论他们的通信强度如何，他们保持活跃的概率都是相似的。

关于H1.2，我们还观察到核心开发人员和外围开发人员之间的行为存在一些差异，但仅适用于npm。根据图3中整个npm群体的结果，外围TI开发人员的生存概率降低，这表明无论其通信活动的频率如何，对小项目的承诺数量较少的外围开发人员都不太可能在生态系统中保持活跃。

 

 

 

关于H1.3，我们发现了两个生态系统中核心TS开发者的差异，并给出了以下结果

最后，我们发现两种生态系统的H2.2存在一些差异。更具体地说，对于npm，我们发现无论是对大型项目有大量承诺的核心TI开发人员，还是对小型项目有少量承诺的外围TI开发人员，当他们承诺较少时，都更有可能放弃生态系统。所有的核心TI开发人员都有类似的放弃生态系统的概率，而不管他们的提交频率如何。此外，我们发现RubyGems中的核心和外围TS开发人员都有类似的放弃生态系统的概率，不管他们的提交频率如何。这些结果表明，在两个生态系统中，提交频率对开发人员放弃的影响是不同的：在npm中，频繁的提交活动表明核心和外围开发人员在生态系统中长期存在；在RubyGems中，它似乎不是区分核心贡献者和外围贡献者的有用因素，而核心贡献者和外围贡献者更有可能在RubyGems中保持较长时间的活跃。

9结论

在本文中，我们对两个大型、长寿命的软件生态系统：RubyGems和npm进行了广泛的实证研究。我们研究了社会技术活动的频率和强度与开发者保留之间的关系。社交活动通过GitHub评论以涉及多个开发人员的通信来衡量，而技术活动则通过提交来衡量。

我们的研究结果表明，当开发人员：(1) 不与其他开发人员交流时，他们放弃生态系统的概率更高; (2) 没有很强的社会和技术活动强度; (3) 沟通或承诺的频率较低；（4）在较长时间内不沟通或承诺。

此外，在区分每个生态系统的核心和外围开发人员时，我们发现了开发人员保留率的一些显著差异。例如，核心开发人员的贡献频率似乎并不影响他们贡献的寿命。

我们还发现两种生态系统之间的差异，其中的因素可能会影响开发人员的保留率。例如，在RubyGems中，社交频率这个因素似乎对预测开发者的放弃并不有用。另一方面，对于npm来说，提交频率的因素似乎对预测开发人员放弃没有帮助。