Open Source And The Contribution Cemetery
Source: Dev.to
Contribution Cemetery Overview
A quick look at a few popular GitHub projects shows a common pattern of many open issues and pull requests (PRs):
- python‑requests – 145 issues, 80 PRs
- VS Code – 5 k+ issues, 1.8 k PRs
- Kubernetes – 1.8 k issues, 889 PRs
- Ruby on Rails – 518 issues, 1.1 k PRs
- Rust Language – 5 k+ issues, 1.1 k PRs
- lodash – 68 issues, 72 PRs
Even a relatively small library like lodash has dozens of open issues, illustrating how widespread this challenge is across popular open‑source software.
The Burden of Maintenance
While the code is free and publicly available, the cost of maintaining it remains very real. For example, python‑requests now has only two maintainers, down from a larger team. Projects like Kubernetes have more contributors, yet they still face a flood of issues and PRs. AI‑generated PRs have added further stress, and even the Linux kernel is beginning to remove code that isn’t well maintained due to the onslaught of security reports (LWN article).
A recent personal experience highlighted this problem: I tried to install LunarVim, a Vim distribution I used previously, only to discover it had been abandoned (GitHub discussion).
Contributor Dilemma
Potential contributors face a daunting landscape. Even when a clear bug exists, they must ensure their fix doesn’t conflict with hundreds or thousands of other PRs and determine which open issue (if any) their work addresses. The sheer volume can create a paradox: if everyone can contribute, no one can contribute.
Finding smaller, less‑overwhelmed projects isn’t always easy. While GitHub’s collections page categorizes repositories, many still suffer from high issue‑to‑PR ratios.
Where to Start
Solutions will vary depending on the size and nature of the community. Below are several approaches that can help mitigate the contribution cemetery.
Bug Wrangling
My first exposure to open source was the Gentoo Linux project, where I performed “bug wrangling”: reproducing bug reports, narrowing down causes, and guiding maintainers toward solutions. Scaling this practice—perhaps via dedicated volunteers or rotating “bug‑wrangling sprints”—could reduce the backlog of open issues.
Bug Report Timeouts
Some projects implement timers that automatically close stale issues after a period of inactivity. While not ideal for every repository, shorter timeout windows could encourage timely triage and prevent indefinite accumulation of unresolved reports.
Project Restructure
Large, monolithic projects (e.g., the Linux kernel) naturally generate many issues due to their breadth. Incremental restructuring—splitting components into smaller, more manageable sub‑projects—can lower the overall issue load and make maintenance more tractable. Clear project vision and stricter acceptance criteria also help.
Full Reset
A radical option is to close all open issues and PRs and start fresh. This approach risks alienating contributors whose work is discarded and may simply lead to the same backlog reappearing later. It should be considered only as a last resort.
New Tooling
Adopting an external issue tracker (e.g., Bugzilla) that integrates with GitHub via SSO could provide a cleaner UI for triaging and prioritizing work. Layering such a system on top of GitHub’s native issues/PRs might make the backlog more digestible.
Team Expansion
Growing the maintainer team to include dedicated “issue‑cleanup” members, adding more reviewers, and expanding automated linting can improve throughput. Mentoring programs that pair experienced contributors with newcomers can also accelerate onboarding and knowledge transfer.
What the Future Brings
The surge in AI‑generated contributions has intensified the problem, making it urgent to address before it leads to stagnation. Open source remains vital, but without effective strategies to manage the influx of issues and PRs, projects risk becoming unmaintainable. It’s time for the community to collectively explore and adopt solutions that keep open‑source ecosystems healthy and sustainable.