Software development is a knowledge-intensive industry. For this reason, concentration of knowledge in software projects tends to be very risky, which increases the relevance of strategies that reveal how source code knowledge is distributed among team members. The truck factor (also known as the bus factor) is an increasingly popular concept—proposed by practitioners—that indicates the minimal number of developers that have to be hit by a truck (or leave the team) before a project is incapacitated. Therefore, it is a measure that reveals the concentration of knowledge and the key developers in a project. Due to the importance of this concept, algorithms have been proposed to automatically compute truck factors, using maintenance activity data extracted from version control systems. However, we still lack large studies that assess the results of truck factor algorithms. To fulfill this gap in the literature, this paper describes the results of three empirical studies. In the first study, we validate the results produced by three algorithms to estimate truck factors. To this purpose, we build an oracle of truck factors, gathered via a survey with 35 open-source project teams. In the second study, we provide a comparison between truck factors and core developers, a related concept commonly used to denote the key developers of open-source projects. Our results indicate that truck factor developers are in most cases a subset of core developers. Finally, as the algorithms proposed so far are based in commit data, in the third study, we investigate other factors that may impact the computation of truck factors.

中文翻译：

---

估计卡车因素的算法：比较研究

软件开发是一个知识密集型行业。出于这个原因，软件项目中的知识集中往往是非常危险的，这增加了揭示源代码知识如何在团队成员之间分配的策略的相关性。卡车因素（也称为巴士因素）是一个越来越流行的概念——由从业者提出——表示在项目丧失能力之前必须被卡车撞到（或离开团队）的开发人员的最少数量。因此，它是一个衡量项目中知识集中度和关键开发人员的指标。由于这个概念的重要性，已经提出了使用从版本控制系统中提取的维护活动数据来自动计算卡车因素的算法。然而，我们仍然缺乏评估卡车因子算法结果的大型研究。为了弥补文献中的这一空白，本文描述了三项实证研究的结果。在第一项研究中，我们验证了三种算法产生的结果来估计卡车因素。为此，我们通过对 35 个开源项目团队的调查收集了卡车因素的预言机。在第二项研究中，我们对卡车因素和核心开发人员进行了比较，核心开发人员通常用于表示开源项目的关键开发人员的相关概念。我们的结果表明，卡车因素开发人员在大多数情况下是核心开发人员的一个子集。最后，由于迄今为止提出的算法基于提交数据，在第三项研究中，我们调查了可能影响卡车因素计算的其他因素。为了弥补文献中的这一空白，本文描述了三项实证研究的结果。在第一项研究中，我们验证了三种算法产生的结果来估计卡车因素。为此，我们通过对 35 个开源项目团队的调查收集了卡车因素的预言机。在第二项研究中，我们对卡车因素和核心开发人员进行了比较，核心开发人员通常用于表示开源项目的关键开发人员的相关概念。我们的结果表明，卡车因素开发人员在大多数情况下是核心开发人员的一个子集。最后，由于迄今为止提出的算法基于提交数据，在第三项研究中，我们调查了可能影响卡车因素计算的其他因素。为了弥补文献中的这一空白，本文描述了三项实证研究的结果。在第一项研究中，我们验证了三种算法产生的结果来估计卡车因素。为此，我们通过对 35 个开源项目团队的调查收集了卡车因素的预言机。在第二项研究中，我们对卡车因素和核心开发人员进行了比较，核心开发人员通常用于表示开源项目的关键开发人员的相关概念。我们的结果表明，卡车因素开发人员在大多数情况下是核心开发人员的一个子集。最后，由于迄今为止提出的算法基于提交数据，在第三项研究中，我们调查了可能影响卡车因素计算的其他因素。在第一项研究中，我们验证了三种算法产生的结果来估计卡车因素。为此，我们通过对 35 个开源项目团队的调查收集了卡车因素的预言机。在第二项研究中，我们对卡车因素和核心开发人员进行了比较，核心开发人员通常用于表示开源项目的关键开发人员的相关概念。我们的结果表明，卡车因素开发人员在大多数情况下是核心开发人员的一个子集。最后，由于迄今为止提出的算法基于提交数据，在第三项研究中，我们调查了可能影响卡车因素计算的其他因素。在第一项研究中，我们验证了三种算法产生的结果来估计卡车因素。为此，我们通过对 35 个开源项目团队的调查收集了卡车因素的预言机。在第二项研究中，我们对卡车因素和核心开发人员进行了比较，核心开发人员通常用于表示开源项目的关键开发人员的相关概念。我们的结果表明，卡车因素开发人员在大多数情况下是核心开发人员的一个子集。最后，由于迄今为止提出的算法基于提交数据，在第三项研究中，我们调查了可能影响卡车因素计算的其他因素。在第二项研究中，我们对卡车因素和核心开发人员进行了比较，核心开发人员通常用于表示开源项目的关键开发人员的相关概念。我们的结果表明，卡车因素开发人员在大多数情况下是核心开发人员的一个子集。最后，由于迄今为止提出的算法基于提交数据，在第三项研究中，我们调查了可能影响卡车因素计算的其他因素。在第二项研究中，我们对卡车因素和核心开发人员进行了比较，核心开发人员通常用于表示开源项目的关键开发人员的相关概念。我们的结果表明，卡车因素开发人员在大多数情况下是核心开发人员的一个子集。最后，由于迄今为止提出的算法基于提交数据，在第三项研究中，我们调查了可能影响卡车因素计算的其他因素。