Source-linked AI summary
Why Modern Open Source Projects Fail
Jailton Coelho, Marco Tulio Valente
TL;DR
Modern open-source projects are failing at unprecedented rates, but evidence about why remains limited. This paper surveys maintainers of failed popular GitHub projects and examines maintenance practices, impacts, and recovery attempts. It identifies nine failure reasons and associates contributing guidelines and continuous integration with project success or failure.
Problem
Open-source development is expanding while projects face unprecedented failure rates, and few studies explain these failures.
Method
The paper surveys maintainers of failed GitHub projects, compares maintenance practices, measures failure impacts, and analyzes attempted recovery strategies.
Results
The study identifies nine failure reasons and reports important differences in contributing-guideline availability and continuous-integration use between failed and successful projects.
Takeaways & Limitations
The findings support assessing failure risks involving project teams, environments, and project characteristics, alongside recommended maintenance practices.
Takeaways & Limitations
The study’s validity is constrained by participant omissions, subjective theme classification, and thresholds used to define the survey sample.
Abstract
from arXiv · showhide
Open source is experiencing a renaissance period, due to the appearance of modern platforms and workflows for developing and maintaining public code. As a result, developers are creating open source software at speeds never seen before. Consequently, these projects are also facing unprecedented mortality rates. To better understand the reasons for the failure of modern open source projects, this paper describes the results of a survey with the maintainers of 104 popular GitHub systems that have been deprecated. We provide a set of nine reasons for the failure of these open source projects. We also show that some maintenance practices -- specifically the adoption of contributing guidelines and continuous integration -- have an important association with a project failure or success. Finally, we discuss and reveal the principal strategies developers have tried to overcome the failure of the studied projects.
1 INTRODUCTION
Modern platforms accelerated open-source development while projects increasingly failed, despite limited evidence on failure causes. This paper investigates failed projects, maintenance practices, failure impacts, and recovery strategies.
- Modern platforms and workflows, especially GitHub, enabled faster open-source development through forking, local changes, and pull requests.
- Open-source projects are failing at unprecedented rates, while few studies investigate why they fail.
- The study surveys maintainers to identify failure reasons, compare maintenance practices, measure impacts, and examine attempted recovery strategies.
- The first research question selects inactive or explicitly abandoned GitHub projects and categorizes developers’ responses into nine failure reasons.
- The study compares maintenance practices, measures issues, pull requests, and dependent projects, and manually analyzes issues for recovery strategies.
- The paper contributes a nine-reason failure taxonomy, evidence about maintenance practices, and documentation of three unsuccessful recovery strategies.
2 DATASET
The dataset focuses on popular GitHub projects and identifies inactive or explicitly deprecated repositories through automated selection, manual inspection, and cleaning. The final dataset contains 618 selected projects, with limitations in platform and popularity coverage.
- The dataset starts with GitHub’s top 5,000 projects, using stars as a popularity proxy to focus on highly popular projects.
- 628 repositories lacked commits during the previous year, while README searches identified 76 additional projects with explicit deprecation messages.
- Manual inspection removed false positives, non-software repositories, non-English projects, moved repositories, and empty repositories, leaving 618 projects.
- Selected projects were older than the top-5,000 set but had fewer contributors, commits, and stars at median values.
- The dataset excludes popular projects on other platforms and projects that failed before attracting substantial developer or user attention.
3 WHY DO OPEN SOURCE PROJECTS FAIL?
Among 104 failed projects, failures most commonly involved competitors, obsolescence, contributor time or interest, and outdated technologies. The study groups causes by project, team, and environment, while documenting limited funding and few reactivation plans.
- Some projects were considered complete, with 17 developers reporting no need for further features beyond sporadic bug fixes.
- Competitors included major ecosystem organizations such as Google and Apple, creating risks for tightly integrated projects.
- Other reported causes included acquisition, legal problems, insufficient expertise, excessive trivial user demand, and unclear answers.
- Only 18 participants (15%) planned to reactivate their projects, while 82 of 118 funding responses (69%) reported no funding.
- The five most common failure reasons were competitors (27 projects), obsolescence (20), contributor time (18), contributor interest (18), and outdated technologies (14).
- Project-characteristic reasons affected 41 projects, followed by team reasons affecting 39 and environmental reasons affecting 30.
4 WHAT IS THE IMPORTANCE OF OPEN SOURCE MAINTENANCE PRACTICES?
The study compares maintenance-practice adoption across failed, highly popular, least popular, and random GitHub projects. Failed projects resemble the least popular projects, while contributing guidelines and continuous integration show the strongest reported associations with project status.
- Methodology: The study compares 104 failed projects with top, bottom, and random groups of 104 GitHub projects each.The comparison uses projects selected from an initial sample of 5,000 top GitHub projects.
- Methodology: The analysis measures eight practices, including README and license presence, project websites, continuous integration, and contribution-related documents.The contribution-related documents include issue templates, codes of conduct, and pull request templates.
- Results: Failed projects follow README, license, and homepage practices relatively often, at 99%, 61%, and 58%, respectively.Top projects show 100%, 88%, and 87% adoption for the same three practices.
- Results: No failed project uses issue templates, codes of conduct, or pull request templates, whereas 15%, 13%, and 3% of top projects use them.These are the least followed practices across the compared groups.
- Results: Overall practice adoption follows Top > Random > Failed ≡ Bottom, with contributing guidelines showing a large effect and continuous integration a medium effect.Licenses, homepages, and issue templates show small effects according to the reported summary.
5 WHAT IS THE IMPACT OF FAILURES?
The paper assesses failure impact through abandoned issues, pull requests, and dependent projects. Failed repositories retain pending work and can leave client systems dependent on unmaintained code, although dependency counts vary substantially.
- Methodology: The impact analysis covers end-users, contributors, and client projects through issues, pull requests, and dependency counts.The data come from GitHub and a popular JavaScript package manager.
- Methodology: Pending issues leave bugs or requested features unaddressed, while pending pull requests leave contributors’ code changes unimplemented.Users may need to continue with bugs or migrate, and contributors may experience frustration when their work is not accepted.
- Results: The three projects with the most pending issues have 230, 173, and 160 issues; the top three for pending pull requests have 54, 45, and 38.These figures describe the upper end of the observed distributions.
- Results: 55% of the analyzed Ruby and JavaScript projects have fewer than five dependents, while some have 2,460 Ruby or 158 JavaScript dependents.Dependency coverage includes 10 Ruby and 28 JavaScript projects, with some JavaScript projects absent from npm.
6 HOW DO DEVELOPERS TRY TO OVERCOME THE PROJECTS FAILURE?
The study identifies three attempted responses to project abandonment and examines whether forks continue development. Most proposed responses did not restart the studied projects, while recovery cases were associated mainly with attracting new core developers.
- 6.1 Methodology: Maintainers and collaborators attempted three strategies: moving to an organization account, transferring projects to new maintainers, and accepting new core developers.The strategies were identified by analyzing issues from failed projects.
- Moving to an organization account: Moving to an organization account was proposed in five issues to ease maintainer recruitment and permission management.The strategy creates an organization account with a name similar to the project’s name.
- Transfer the project to new maintainers: Transfer to new maintainers was discussed for three projects, but the new maintainers did not make significant contributions despite minor commits.Two projects found new developers who assumed ownership.
- Accepting new core developers: Volunteers offered to become core developers in five cases, but none of the proposals was answered or accepted.One owner requested a detailed maintenance plan before accepting a proposed maintainer.
- 6.2 Results: Among 348 nearly failed projects, 182 failed the following year, while 35 showed recovery; 14 of those attracted new core developers.Two transferred to new maintainers and two moved to organization accounts.
- 6.3 Complementary Investigation: Forks: Failed projects typically had many forks, but most forks had few stars, and the study concludes that forks rarely continued development.The median fork counts were 244, 400, and 638 at the first, median, and third quartiles; the third quartile for the most-starred fork was 13 stars.
7 DISCUSSION
The discussion identifies competition, project and contributor constraints, and outdated technologies as major failure risks, while associating maintenance practices with successful projects. It also notes that some projects are intentionally completed and that maintainers try varied strategies to recover failed systems.
- Completed projects and first Law of Software Evolution: 17 systems (11%) were considered feature-complete, with developers reporting no planned evolution or adaptive maintenance.These projects were treated as completed rather than failed because their developers believed the systems already worked adequately.
- Competition in open source markets: 27 projects failed after being usurped by stronger competitors, especially major organizations in the Android and iOS ecosystems.The discussion warns that tight integration with established platforms can expose projects to competition from ecosystem owners.
- Practical implications: Open source projects face risks from small development teams, changing environments, project decisions, and outdated technologies.The proposed risk categories include limited contributor time or interest, environmental dependence, and technology choices.
- Practical implications: The study supports lightweight maturity models that continually assess open source project risk factors.The proposed models would be less complex and detailed than commercial-software models such as CMMI.
- Practical implications: Successful projects more often provide README files, contributing guidelines, licenses, issue templates, home pages, and continuous integration.Continuous integration supports automation of compilation, building, and testing tasks.
8 THREATS TO VALIDITY
The study’s validity is constrained by choices about measurement, sampling, participant selection, and the scope of analyzed services and languages. The authors describe mitigation steps but retain uncertainty about representativeness and classification.
- External Validity: The continuous-integration analysis considered only Travis CI, while dependent-project analysis covered only Ruby and JavaScript systems and one JavaScript package manager.Travis CI was used because it served more than 90% of repositories enabling continuous integration.
- Internal Validity: Survey responses may omit actual failure reasons because participants were project owners or highest-commit developers.The authors attempted mitigation by avoiding direct questions about failure causes.
- Internal Validity: Thematic categories for failure reasons and recovery strategies involve researcher subjectivity.The RQ1 themes were independently selected and refined by both authors; RQ4 themes were proposed and validated within the research team.
- Construct Validity: Defining projects as unmaintained after no commits for one year introduces a threshold and time-frame validity threat.The survey additionally included 36 projects whose README explicitly stated that they were unmaintained or deprecated.
- Construct Validity: Automatically detected maintenance documents may be missed because regular expressions cannot cover every filename variation and document quality was not checked.A contributing-guidelines document counted when it existed and was nonempty, regardless of its quality.
9 RELATED WORK
Prior research examined deprecated projects, developer motivation, community practices, commercial-project failure, and GitHub features. The paper positions its contribution as studying failure in modern GitHub-based open source systems.
- Deprecated open source projects: A study of 406 deprecated FreshMeat projects found that 57% had one or two developers and only 15% were active.Its measures covered developer and user communities, modularity and documentation, and software evolution.
- Community practices and software evolution: Research on codes of conduct found seven codes commonly used to support safe, inclusive, and diverse open source communities.Related work also reported that most empirical studies find Lehman’s first law applies to mature open source projects.
- Developer motivation: A GIMP case study identified learning as the major motivation for developer participation, but its applicability to newer GitHub systems was unknown.The cited work focused on one established project rather than the new generation of platform-based systems.
- Commercial software failure: Prior failure research proposed reasons and maturity-model motivations for commercial software projects.Other work observed software projects in a large telecommunications company, extending the related commercial-software focus.
- Modern open source research: Recent open source research focused on successful projects, newcomer retention, and GitHub features such as pull requests, forks, and stars.These topics differ from directly investigating why modern open source projects fail.
10 CONCLUSION
The conclusion reports five leading failure reasons, differences in maintenance practices between failed and popular active projects, unresolved activity in failed repositories, and three recovery strategies. It proposes validating lightweight maturity models and proactive maintainer recruitment as future work.
- Conclusion: 27 projects were usurped by competitors, 20 became functionally obsolete, 18 lost contributor time, 18 lost contributor interest, and 14 used outdated technologies.These are the study’s five most common failure reasons.
- Conclusion: Failed projects differed most from popular and active GitHub projects in contribution guidelines and continuous integration.The conclusion also reports that failed projects retained a non-negligible number of open issues and pull requests.
- Conclusion: The paper described three maintainer strategies attempted to overcome project failure.The conclusion names the strategies as a contribution of the study but does not enumerate them in the supplied passage.
- Conclusion: Future work should define and validate open source maturity models and investigate proactive recruitment of qualified maintainers.The proposed goal is to help minimize adoption risks and address projects threatened with deprecation.