The maintainer's dilemma | spf13
Search for Blog
The Maintainer's Dilemma<br>Steve Francia<br>20 May 2026
Open Source<br>AI<br>Maintenance<br>Community
A protected branch requires a second person to review a change before code ships. The rule exists because humans make mistakes, and a second pair of eyes catches what the first one missed. But what happens when one of those reviewers is a robot? What if both are?<br>Currently I can ask an AI to open a pull request on my repository and then merge it myself. Or I can write the code and ask an AI to review it. In both cases, the branch is technically “protected.” But what does that even mean now?<br>Those are questions worth asking. But they tend to get all the attention while a more immediate problem goes unaddressed. Right now, across my repositories, there are open pull requests from people who took time to understand the codebase, write tests, and submit clean patches. I haven’t reviewed them. Sadly, the ironic part is I haven’t reviewed them because I deeply care. I know how big of a deal it is to take the time to open a pull request on a project, and even more so on a popular one. I know that each one deserves an honest review and that that takes time I don’t have for projects I maintain as a volunteer. For every open source project with a funded maintainer, there are millions with an unpaid human staring at a growing backlog, wondering whether the right thing to do is spend their weekend triaging issues or just close the laptop and go outside.<br>AI tools can now do credible code reviews, write patches, and triage issues. The question is no longer whether they’re good enough to be useful. The real questions are where “useful” becomes “liability,” and whether leaning on them breaks something we can’t easily rebuild — the trust between maintainers and contributors, the judgment that comes from experience, and the community that forms around that exchange.<br>118 Open Pull Requests<br>I checked my GitHub notifications last week and closed the tab. Cobra has 243 open issues and 118 open pull requests. Afero has 114 issues and 55 PRs. I created both projects. I haven’t meaningfully reviewed a PR on either in months.<br>In spite of my inaction as a reviewer, these are actively maintained projects. Cobra powers kubectl, GitHub CLI, Hugo, and hundreds of thousands of other tools. When you type kubectl get pods or gh pr list, Cobra parses your command. Afero sits inside Hugo, inside Cobra itself, inside hundreds of thousands of other projects. A careless merge on Cobra could break Kubernetes tooling. A bad review on Afero could open a filesystem vulnerability that quietly propagates through everything downstream.<br>I created Cobra because I needed a specific CLI UX for Hugo and no existing library could support it. I split it out as its own project, thinking others might find it useful. I never imagined I’d still be maintaining it a decade later, or that both projects would become critical infrastructure for so many others. I just wanted to build something useful for me and maybe a few friends. But does open sourcing code mean I’m obligated to maintain it indefinitely? With each new project I release, there’s less time for the existing ones. Some of those PRs have been waiting for years. There’s a reported security vulnerability in Afero’s BasePathFs that’s been sitting open since June 2025 — which, until I wrote this post, I didn’t realize was there, because the backlog is that overwhelming.<br>The math of maintenance doesn’t work. It’s a well-known problem across open source (relevant XKCD). The number of contributions grows faster than the number of maintainers, and the time required to review each one grows with a project’s complexity and impact. Some projects attract volunteer co-maintainers, but that brings its own problem: no one is clearly responsible, so everyone picks what matters to them and the rest just sits. Cobra is intentionally slow to change — too many projects depend on it to casually merge anything — so each change requires more thorough review, not less. Many of my other projects fall into the gray area between maintained and abandoned. I’d describe it as optimized maintenance around the most critical paths, but that distinction matters a lot more to me than it does to the person who submitted a fix eight months ago and never heard back.<br>This isn’t just my problem. GitHub hosts over 420 million repositories. I was very fortunate to be a part of the inaugural cohort of the Secure Open Source Fund — a real investment that made a real difference. But even after expanding to several cohorts, it covers about 200 projects. OpenSSF scans a million critical projects weekly. Tidelift pays maintainers. Add it all up and you’re covering thousands of projects. It’s meaningful work. It’s also a rounding error against the actual...