On the Two Sides and the Spectrum That Is Open Source Maintenance
Published on Jun 11, 2026, filed under development, management. (Share this post, e.g., on Mastodon or on Bluesky.)
Maintaining open-source projects is a challenge: One cannot not maintain, so projects do require some attention, and software is never finished, meaning there’s always something meaningful to do, too.
The challenge grows, the more successful a project is: More users may find more bugs and will have more suggestions and requests for features.
This is the maintainer side of open source.
On the other side, there are the users and consumers.
They also face a challenge, and theirs, too, gets bigger, the more successful the project is they’re using: It’s hard to get one’s issues fixed and suggestions considered by a project that gets flooded with bug reports and feature requests.
The Conflicting Interests of Maintainers and Users
Here’s what typically happens in a successful open-source project:
The more reports and requests it gets, the more bureaucracy is being introduced.
This is human and entirely understandable: The project most likely is understaffed and underfunded, so to process, maybe only triage the requests, there needs to be some system to mitigate the load.
Contribution guidelines, CLAs, issue templates, requests for MREs, and so on are being introduced as part of the bureaucracy.
However, the load is only shifted, to the user:
For the open-source user, what is most convenient is to be able to report issues or requests in the format easiest for them. Just file an issue, add a comment, file a report.
While it doesn’t make them better contributors (as engineers we know that there’s something to a good bug report, for example), granting users this flexibility honors their time.
Every requirement that benefits the open-source maintainer takes away some of this flexibility: It makes issues cheaper for maintainers but costlier for users.
Open-Source Maintenance as a Spectrum
The price-shift metaphor is useful to describe open-source maintenance as a spectrum:
On one end of the spectrum, users pay close to nothing for a report (they file it how they please) and maintainers pay most of it (they assess, reproduce, write tests, &c.).
On the other end of the spectrum, users pay almost all of the report (especially, though that’s voluntary and rare, if they propose a PR), and maintainers pay very little.
This spectrum is there and it makes sense. However, as so often, awareness for it is useful.
Use the Spectrum Wisely
Both maintainers and users can overdo it:
If maintainers feel they need to shift all the burden over to the user, and even go as far as reject issue reports or feature suggestions for bureaucracy reasons *, they run two serious risks:
They may alienate their users to the extent that these users stop reporting issues or making suggestions.
They engage in poor engineering, because the merit of an issue or a feature has nothing to do with it fitting an issue template.
Users can overdo it, too:
Sharing insufficient or even duplicate bug reports and suggestions is an actual drain for maintainers. If users do this too often, they deprive themselves from being able to influence the direction of a project by helping to make it better. Just as much as no open-source project is entitled to its users, no user is entitled to a project.
What this means is that the spectrum is there to reflect the staffing and funding situation as well as the popularity of the project. If everything is green, err on the side of granting flexibility to users, restricting their communication as little as possible. But even if the project is under strain, be aware that any such restriction comes at a price—ask for too much from your users, and you may lose not only them, but also your grip on your codebase.
* Prompting this post, I experienced this just recently again with the Astro project. While closing issues right away is their decision—I’m not entitled to being heard by the Astro team—, they dismissed a well-prepared suggestion out of reasons of bureaucracy, thereby also severing the connection. But while you might think this sentiment is because I had the door slammed in my face, what reactions like that really do is shatter confidence in engineering practices, because it shows how issues are not assessed on their merit.
About Me
I’m Jens (long: Jens Oliver Meiert), and I’m an engineering lead, guerrilla philosopher, and indie publisher. I’ve worked as a technical lead and engineering manager at various companies, including Google; I’m an open-source developer and a contributor to web standards (like HTML, CSS, WCAG); and I write and review books for O’Reilly and Frontend Dogma.
I love trying things, not only in web development and engineering management, but also with respect to politics and philosophy. Here on meiert.com I talk about some of my experiences and perspectives. (Please share feedback—interpret charitably, keep it friendly, but do be critical.)