As someone has appreciates the value of open source, I'd like to touch on a rather troubling issue I've found. An issue which has been further made problematic with the recent explosion of AI. It's something I refer to as the contribution cemetery.
Thar be dragons here
I'm going to show you some stats for a few projects on GitHub.
- python requests 145 issues 80 pull requests
- vscode 5k+ issues 1.8k pull requests
- kubernetes 1.8k issues 889 pull requests
- Ruby On Rails 518 issues 1.1k pull requests
- Rust Language 5k+ issues 1.1k pull requests
- lodash 68 issues 72 pull requests
lodash, a popular NPM module, has what seems to be a small amount. However, 68 issues is quite a lot to go through. This is a fairly common pattern among popular open source software.
The burden of maintenance
While the code for open source projects is free and available, the cost of maintaining it is still very real. Python requests currently has 2 maintainers, though it used to have more. Some projects, such as kubernetes, have a decent amount of individuals handling the project. Yet still we have these fairly large amounts of issues and PRs. To make matters worse, AI powered PRs have caused further stress on maintaining a popular open source project. Even the Linux Kernel is starting to remove code that isn't well maintained due to the onslaught of security reports.
Just recently I was even going to install lunarvim, a vim distribution I used a while back, only to find out it was abandoned.
Contributor dilemma
So let's say there's someone who wants to contribute to one of these projects. Even if there was something to fix they would need to make sure it didn't conflict with several hundred/thousand PRs and figure out which of several hundred/thousand issues might cover it. Given the huge popularity of GitHub within development communities this seems to almost be a "if everyone can contribute no one can contribute" type situation.
I'd also say it can be difficult to find projects to contribute to if you're looking for something smaller in popularity. The bigger question is if they actually need help or if it's just someone who wants to share code for educational purposes and has no interest in maintaining it. While GitHub does have a collections page categorizing certain repositories, I've found that many of them fall under the same issue/pr ratio.
Where to start
As far as what to do about the issue it's pretty difficult. Most of the solutions will vary depending on how big the community is.
Bug wrangling
My first exposure to open source was the Gentoo Linux project. I spent a lot of time there doing something called "bug wrangling". Essentially I would go into bug reports, try to reproduce the issue (I had access to a lot of architectures), and try to point the maintainer in the right direction as to where the problem might be. Something like this on a larger scale could help bring issues to a more reasonable count. Larger projects may need to do it over several periods to prevent too much volatility being pushed to users.
Bug report time outs
While certainly not ideal, I've seen many projects have timers on when an issue will expire. Thought I'm not sure if that could easily be retrofit. Some projects may benefit from slightly shorter bug report timeouts.
Project restructure
Sometimes it's simply the scale of the project. The Linux kernel, for example, supports several years worth of hardware. This monolithic design naturally increases how many issues and PRs are required to support it. Most projects would require gradual restructuring as an all and one approach would be too risky. It may also be a case of what constitutes the project vision and if they need to be more strict with it in terms of what PRs to accept.
Full reset
This would essentially be closing everything and starting from scratch. The main issue is doing it at scale and if everything would simply pile up again in numbers. Some contributors also might not be too thrilled seeing their work was closed out. There's also the question of if this could be done at scale.
New tooling
Utilize a different system, such as bugzilla, to track issues. PRs would be looked at only if they had an entry in the new project issue tracker. Having an SSO login that could utilize GitHub's authentication would help alleviate the pain of having to go to a separate site for issues. It could also be something that layers on top of GitHub issues/PRs with an easier to digest UI
Team expansion
Expand project teams to include people who just handle issue cleanup, more maintainers to approve PRs, expand linting to catch common issues, etc. It might be a good idea to have some form of a mentoring program. This would allow frequent contributors to help potential new contributors know how the project's particular development process works.
What the future brings
While this has certainly been an issue for a while, I believe that the recent surge in AI adoption means it's a problem that should be considered sooner rather than later. While open source is certainly far from dead, stagnation due to a surge of contributions isn't very healthy. I hope it's something the community as a whole starts seriously looking into.
Top comments (0)