PaperlayerView exact revision on arXiv

Source-linked AI summary

On the abandonment and survival of open source projects: An empirical investigation

Guilherme Avelino, Eleni Constantinou, Marco Tulio Valente, Alexander Serebrenik

arXiv:1906.08058v1cs.SE

TL;DR

Open source projects can depend on a small number of core developers, so their departure may threaten maintenance, while new maintainers may allow projects to survive. The paper combines repository analysis of popular GitHub projects with a survey of developers who assumed maintenance. In its sample, detachments occurred in 16% of projects and 41% of those projects survived.

  • Problem

    The study addresses limited understanding of how often key-developer departures occur, whether projects survive them, and what happens when influential developers leave.

    Source: §I · p. 1

  • Method

    The authors combine repository-mining methods for identifying detachments and survival with a survey of developers who assumed project maintenance.

    Source: §I · p. 2, A. Truck Factor Calculation · p. 2

  • Results

    16% of the 1,932 GitHub projects experienced a TF developer detachment, and 41% of those projects survived by attracting new core contributors.

    Source: §IX · p. 10

  • Takeaways & Limitations

    Potential replacement maintainers may include project users or company-based developers with prior project contributions.

    Source: §VI · p. 9

Abstract

from arXiv · show

Background: Evolution of open source projects frequently depends on a small number of core developers. The loss of such core developers might be detrimental for projects and even threaten their entire continuation. However, it is possible that new core developers assume the project maintenance and allow the project to survive. Aims: The objective of this paper is to provide empirical evidence on: 1) the frequency of project abandonment and survival, 2) the differences between abandoned and surviving projects, and 3) the motivation and difficulties faced when assuming an abandoned project. Method: We adopt a mixed-methods approach to investigate project abandonment and survival. We carefully select 1,932 popular GitHub projects and recover the abandoned and surviving projects, and conduct a survey with developers that have been instrumental in the survival of the projects. Results: We found that 315 projects (16%) were abandoned and 128 of these projects (41%) survived because of new core developers who assumed the project development. The survey indicates that (i) in most cases the new maintainers were aware of the project abandonment risks when they started to contribute; (ii) their own usage of the systems is the main motivation to contribute to such projects; (iii) human and social factors played a key role when making these contributions; and (iv) lack of time and the difficulty to obtain push access to the repositories are the main barriers faced by them. Conclusions: Project abandonment is a reality even in large open source projects and our work enables a better understanding of such risks, as well as highlights ways in avoiding them.

I. INTRODUCTION

This study asks how often key-developer departures occur, whether projects survive them, and what characterizes and motivates those who assume maintenance. It frames this risk through Truck Factor, the minimum number of developers a project depends on for maintenance and evolution.

I. INTRODUCTION

  • OSS sustainability is a concern because projects are often managed by few developers without financial support, and the paper notes a case linking single-developer maintenance to a major security bug.The cited example is OpenSSL and the Heartbleed bug.Source: §I · p. 1

II. TRUCK FACTOR

  • Truck Factor (TF) is the minimum number of developers a project depends on for its maintenance and evolution.A TF developer set is the minimal set corresponding to the TF; TF developer detachment occurs when all of them abandon the project.Source: §I · p. 1, §II · p. 2

I. INTRODUCTION

  • The study investigates detachment frequency, project survival and survivor characteristics, then surveys developers who assumed maintenance to examine their motivations and difficulties.The authors describe repository-mining methods for identifying detachments and surviving projects as a contribution.Source: §I · pp. 1–2

II. TRUCK FACTOR

  • A surviving system is one that attracts new TF developers who assume maintenance after a TF developer detachment.The paper defines detachment as the departure of all TF developers, not simply one key developer.Source: §II · p. 2

A. Truck Factor Calculation

The study estimates Truck Factor from repository authorship, identifies detachments using developer inactivity, and treats a return to active status through new TF developers as survival.

A. Truck Factor Calculation

  • The selected TF algorithm estimates file-level developer expertise, then identifies TF developers as main authors of at least 50% of the system’s files.Degree of authorship compares a developer’s file expertise with that of other developers; more than one main author may be counted per file.Source: A. Truck Factor Calculation · p. 2

B. Identifying Truck Factor Developers Detachments

  • A developer is classified as having abandoned a project when their last commit is at least one year before the repository’s most recent commit.The authors tested five inactivity thresholds and selected one year as least sensitive to error.Source: B. Identifying Truck Factor Developers… · p. 2
  • In the composer/satis example, Alice and Bob’s departure by December 2015 marks detachment after the TF set grows from one developer to two.The example places Alice’s last commit in August 2015 and Bob’s in December 2015.Source: B. Identifying Truck Factor Developers… · p. 2

C. Identifying Surviving Systems

  • A project survives when it returns from inactive to active after its last detachment, which occurs when at least one new TF developer is attracted.In composer/satis, Charlotte’s arrival in the TF set in January 2017 moves the project back to active.Source: C. Identifying Surviving Systems · p. 2

III. STUDY DESIGN

The study combines repository-data analysis with a survey and builds its quantitative dataset from popular GitHub projects. Filtering leaves 1,932 projects, which are typically large and popular systems.

III. STUDY DESIGN

  • The study uses a mixed-methods approach combining large-scale version-control analysis with a survey.The quantitative analysis addresses project detachment frequency, survival, and differences between surviving and non-surviving projects.Source: §III · p. 3

A. Dataset & Preprocessing

  • The dataset starts with the top 500 starred repositories in each of six languages and retains 1,932 projects after excluding incomplete histories, short histories, and non-software or unmaintained repositories.The analysis excludes projects that did not use GitHub throughout their history; the minimum historical-data requirement is two years.Source: A. Dataset & Preprocessing · p. 3
  • The retained dataset typically contains large systems with many developers, files, and commits, and projects are popular by star counts.The distributions are shown as violin plots with logarithmic scales and medians indicated.Source: Figure 3 · p. 3, A. Dataset & Preprocessing · p. 3

B. Aliases Resolution

The authors resolve developer aliases through GitHub account mappings and select a one-year abandonment threshold using a sensitivity analysis. That threshold has the strongest reported harmonic mean among those tested.

B. Aliases Resolution

  • Developers are treated as aliases when GitHub maps their commit-header email addresses to the same account; this does not catch people with multiple accounts.The median alias share per project is 11%.Source: B. Aliases Resolution · p. 3

C. Abandoner Threshold Sensitivity Analysis

  • The threshold analysis defines precision as the share of developers a cutoff never falsely classifies as abandoners, and improvement as errors corrected relative to the next shorter cutoff.The harmonic mean combines precision and improvement.Source: C. Abandoner Threshold Sensitivity… · p. 4
  • 66% harmonic mean made the one-year cutoff best; its improvement over six months was 55%, while a two-year cutoff still had 5% error.The authors therefore use one year to determine whether a developer abandoned a project after their last commit.Source: C. Abandoner Threshold Sensitivity… · p. 4

IV. SEARCHING FOR TFDDS AND SURVIVING PROJECTS

Across 1,932 popular GitHub projects, truck-factor developer detachment (TFDD) occurred in 315 projects, most often where the truck factor was one. TFDDs were concentrated in early project years, and the study also found repeated detachments in a few projects with higher truck factors.

IV. SEARCHING FOR TFDDS AND SURVIVING PROJECTS

  • In the 1,932-project dataset, 57% of projects had TF=1 and fewer than 6% had TF above 5.The highest estimated TF was 26, for edx/edx-platform.Source: §IV · p. 4, Figure 5 · p. 4

RQ1) How common are TFDDs in GitHub projects?

  • 315 projects (16%) experienced at least one TFDD, and 66% of TFDDs occurred in projects with TF=1.Most affected projects faced one TFDD (88%); 11% faced two and fewer than 0.1% faced three.Source: RQ1) How common are TFDDs in GitHub… · p. 4, Figure 6 · p. 4
  • Projects with two observed TFDDs had TF values above four: etsy/logster had TF=7 and PointCloudLibrary/pcl had TF=6.The examples differed in scale: etsy/logster had 13 files and 117 commits at TFDD time; PointCloudLibrary/pcl had 2,204 files and 9,568 commits.Source: RQ1) How common are TFDDs in GitHub… · pp. 4–5
  • 59% of first TFDDs occurred within the first two development years, including 23 projects whose TF developers left within six months.Most projects with TFDDs were 4–7 years old when studied.Source: RQ1) How common are TFDDs in GitHub… · p. 5

RQ2) How often open source projects survive a TFDD?

Of 315 projects with a TFDD, 128 survived their last observed TFDD. Most were sustained by one new truck-factor developer, usually attracted within the first year after detachment.

RQ2) How often open source projects survive a TFDD?

  • 128 of 315 projects (41%) survived their last observed TFDD.A project counted as surviving if it survived its last observed TFDD.Source: RQ2) How often open source projects… · p. 5
  • 86% of surviving projects attracted one new TF developer, while 12% attracted two and 2% attracted three.The new developers were responsible for project survival as defined in the study.Source: RQ2) How often open source projects… · p. 5
  • 64% of new TF developers were attracted within the first year after TFDD, compared with 23% in year two, 10% in year three, and 2% in year four.The authors report that attracting new TF developers to assume maintenance becomes more difficult over time.Source: RQ2) How often open source projects… · p. 5
  • In 52% of surviving projects, all new TF developers were old contributors; 41% relied on newcomers and 7% on both groups.A newcomer was defined as a developer whose first commit came after the last observed TFDD.Source: RQ2) How often open source projects… · p. 5

RQ3) How surviving projects differ from non-surviving ones?

Surviving projects had more post-TFDD commits than non-surviving projects, while their characteristics at TFDD time showed few differences in size and age. Survivors were younger at TFDD time.

RQ3) How surviving projects differ from non-surviving ones?

  • Non-surviving projects could still have commits after TFDD, but those commits came from minor contributors and did not change the TF-developer set.Thus, post-TFDD commits alone did not mean that project maintenance was no longer at risk.Source: RQ3) How surviving projects differ… · p. 6
  • Survivors had a median 505 commits (56%) after the last TFDD, versus 126 (15%) for non-survivors.The difference was statistically significant for both commit counts and percentages; effect sizes were large (d=0.64 and d=0.79, respectively).Source: RQ3) How surviving projects differ… · pp. 5–6, Figure 11 · p. 6
  • At TFDD time, surviving projects were younger than non-surviving projects: 1,095 versus 1,460 median days (d=0.37).The authors conjecture that non-survivors may be feature-complete or may have failed to attract new maintainers, while noting that feature-complete systems can still need bug fixes.Source: RQ3) How surviving projects differ… · p. 6, Figure 12 · p. 6
  • Survivors had lower medians for developers (32 vs 47), commits (384 vs 694), and files (54 vs 85) at TFDD time, with negligible-to-small effect sizes.The file, commit, and developer effect sizes were d=0.13, d=0.25, and d=0.26, respectively.Source: RQ3) How surviving projects differ… · p. 6

V. SURVEY WITH NEW TF DEVELOPERS

The authors surveyed developers who became new TF developers in surviving projects to assess their awareness of discontinuation risk and their experiences. Most respondents perceived risk, while some did not, including one who cited company backing.

A. Survey Design

  • The survey asked new TF developers about perceived discontinuation risk, contribution motivation, helpful project practices, and barriers.The study identified 144 potential participants from surviving projects and received 33 responses, a 24% response rate.Source: A. Survey Design · pp. 6–7
  • Two authors independently performed the first three thematic-analysis steps, then jointly reviewed and named the final themes.The survey responses were analyzed through initial reading, coding, theme development, review, and naming.Source: A. Survey Design · p. 7

RQ4) Do new TF developers perceive risks of project discontinuation?

  • 18 respondents (60%) agreed that their projects faced discontinuation risk, and five (17%) partially agreed.Partial agreement included reports of slowed development or risk mitigated by another developer stepping in.Source: RQ4) Do new TF developers perceive… · p. 7, Table III · p. 7
  • Six respondents (20%) said they did not perceive their projects as being at risk; one cited support from a for-profit company.One answer (3%) was unclear, and four respondents did not answer this question.Source: RQ4) Do new TF developers perceive… · p. 7

RQ5) What motivates a developer to assume an open source project after a TFDD situation?

New maintainers most often assumed projects because they used them, while friendly, active maintainers were the most-mentioned facilitator. Lack of time and repository access were prominent barriers.

RQ5) What motivates a developer to assume an open source project after a TFDD situation?

  • 17 developers (53%) cited their own personal or professional use as motivation; 11 (34%) wanted to contribute to open source, and five (16%) sought to prevent discontinuation.One respondent did not answer the motivation question.Source: RQ5) What motivates a developer to… · p. 7

RQ6) What project characteristics most facilitate or hamper the work of recently arrived TF developers?

  • 12 developers (41%) identified friendly, active maintainers as a facilitator, alongside technical factors and external support.Technical factors included programming-language choice and software engineering practices (4 answers each); repository access permission (3) and company financial support (2) were also mentioned.Source: RQ6) What project characteristics most… · p. 8
  • Lack of time was the most common barrier (7 answers), while difficulty obtaining repository access was also frequent (5 answers).Other technical barriers included maintaining backward compatibility and avoiding bugs (4 answers); four developers reported no barriers.Source: RQ6) What project characteristics most… · p. 8

VI. DISCUSSION

Only 41% of the abandoned projects studied fully recovered maintenance, despite code being public and open to contributors. Survey findings point to users’ needs and human and social factors in project survival, while company backing was viewed by some as reducing truck-factor concerns.

VI. DISCUSSION

  • Only 41% of projects fully recovered maintenance after truck-factor developer abandonment, and peripheral contributions cannot fully support project maintenance.The authors hypothesize that taking over maintenance requires time, technical and social skills, and familiarity with the project domain.Source: §VI · p. 8
  • At least two respondents viewed formal company sponsorship as making truck-factor concerns less relevant, contrasting with the risks facing projects without financial support.The cited responses describe a large project with formal company sponsorship and characterize most open source projects as lacking financial support.Source: §VI · pp. 8–9
  • 17 surveyed developers (53%) were attracted by prior use and personal needs, suggesting a connection between project users and resilience to abandonment.Their needs included obtaining features or fixes for projects they already used.Source: §VI · p. 9
  • Social factors accounted for 51% of reported attraction factors, while human and social issues made up 44% of reported barriers.The paper notes that contributions are often voluntary and made in developers’ free time.Source: §VI · p. 9
  • Maintainers considering departure can look to existing users or company-based developers with prior project contributions as potential successors.The paper identifies these groups as possible new truck-factor developers who could help prevent discontinuation.Source: §VI · p. 9

VII. THREATS TO VALIDITY

The study’s validity is constrained by choices in measuring truck-factor departures and by its focus on evolving, popular GitHub software. The authors describe checks and exclusions intended to mitigate several of these risks.

Construct validity:

  • The TF computations’ accuracy is a validity risk; new TF developers worked on a substantial share of files in surviving systems, supporting confidence in the algorithm.The reported median file share was Q2 = 41%.Source: Construct validity · p. 9
  • TFDD identification depends on the abandonment threshold, and a different threshold might produce different results.The study tested five thresholds and handled common sources of developer aliasing.Source: Construct validity · p. 9
  • Defining a TFDD as all TF developers abandoning the project is a potential threat, although more than 75% of survey respondents partly or fully recognized the project’s risk.The authors conclude that this threat’s effect is low.Source: Construct validity · p. 9
  • The analysis treats software as requiring continuous change, so mature software needing no changes could be misclassified; README inspection found one feature-complete system that still received bug fixes.Source: Construct validity · p. 9

Internal Validity:

  • Using full development histories makes TFDD identification sensitive to missing history, so projects with evidence of corrupted GitHub migration were excluded.Non-software projects, including books and tutorials, were also excluded.Source: Internal Validity · p. 9

External Validity:

  • Findings from selected popular GitHub projects cannot be generalized to other projects, particularly closed-source software, whose TFDDs may differ when financial support is involved.Source: External Validity · p. 9

VIII. RELATED WORK

Prior work developed truck-factor measures and studied developer turnover and contribution barriers, but had not examined whether TFDDs occur or what follows. The conclusion reports that they occur in the studied GitHub projects and that some survive through new core contributors.

VIII. RELATED WORK

  • Earlier truck-factor work proposed algorithms and addressed scalability and accuracy, but had not investigated whether TFDDs occur or what happens to projects afterward.The comparison by Ferreira et al. identified Avelino et al.’s algorithm [6] as the most accurate of three algorithms.Source: §VIII · pp. 9–10
  • Turnover research examined quality impacts, knowledge loss, retention, and disengagement, while this paper focuses on turnover among a project’s principal developers.Source: §VIII · p. 10
  • Prior studies covered contribution motives and barriers across developer profiles; this study found new TF developers motivated by their own use and saving projects, with human and social factors also relevant.The related-work discussion reports that 53% cited their own use and need to save projects, and 12 of 29 respondents mentioned friendly and active maintainers.Source: §VIII · p. 10

IX. CONCLUSION

  • In the studied sample, TFDDs occurred in 16% of 1,932 GitHub projects, and 41% of projects experiencing a TFDD survived by attracting new core contributors.Source: §IX · p. 10
  • Future work includes tools to assess abandonment risks for users, recommenders for potential TF developers, and publicizing successful recoveries to encourage contributions to at-risk projects.Source: §IX · p. 10

Related papers

Loading 1906.08058v1…