Open source has a hero problem.
Not a talent problem. Not a tooling problem. Not even, primarily, a money problem.
A hero problem.
Too many projects still function because one impossibly dedicated person is answering issues at midnight, reviewing drive-by pull requests over breakfast, patching security problems on a Sunday, and somehow also being expected to smile through all of it like community labor is its own reward.
People call that inspiring.
I call it a warning sign.
We have romanticized the wrong thing for years. The mythology of open source still loves the brilliant maintainer who carries the whole project on grit, taste, and a borderline alarming tolerance for interruption. Users admire them. Companies build on their work. Everyone says thank you right up until the day that person burns out, disappears, or decides they are done being a free operations department for the internet.
Then everybody acts shocked.
Please. We saw it coming.
Hero culture is a systems failure in a nice outfit#
When a project depends on one person knowing all the context, making all the calls, and cleaning up all the messes, that is not resilience. That is organizational debt.
The problem is that hero culture looks efficient from the outside.
One maintainer can move fast. Decisions are consistent. The roadmap has a point of view. Things feel coherent. And to be fair, some of the best open source projects in the world did start because one stubborn person refused to lower the bar.
But a project cannot stay healthy if all of its quality, judgment, and responsiveness live in a single human nervous system.
That is not stewardship. That’s a bottleneck with good branding.
“Just contribute” is not a strategy#
Every time maintainership comes up, someone says: well, if users care so much, they should contribute.
Yes. Obviously.
But contribution is not magic.
Most projects are much harder to contribute to than maintainers think they are. Context is scattered. Expectations are implicit. Review standards exist mostly in someone’s head. The issue tracker is either abandoned, hostile, or a digital junk drawer. Then we wonder why only a tiny inner circle sticks around.
If you want more contributors, you need more than a CONTRIBUTING.md and a vague promise that beginners are welcome.
You need:
- clear boundaries on what the project will and will not do
- triage that reflects reality, not aspiration
- docs that explain the architecture, not just the install command
- release processes that don’t require private ritual knowledge
- maintainers who feel allowed to say “no” without writing a dissertation
Open source does not become sustainable because people are nice. It becomes sustainable because the project is legible.
Companies love open source right up until it’s time to act like adults#
This is the part where everyone gets a little uncomfortable.
A shocking amount of modern software depends on volunteer labor wrapped in enterprise confidence. Companies are delighted to consume open source as infrastructure, but far less enthusiastic about funding maintenance, reducing support burden, or assigning actual employees to help carry the work.
And no, sending one engineer to file a typo fix every six months does not count as stewardship. That’s social theater.
If your product depends on an open source project, then your relationship to that project should look a lot more like ownership and a lot less like fandom.
That can mean money. It can mean review time. It can mean docs, testing, sponsorship, governance help, or simply being the adult in the room when something boring but essential needs doing.
Projects need systems, not saints#
The healthiest open source projects are not the ones with the most heroic maintainers. They’re the ones that make heroics less necessary.
They distribute context. They set expectations. They close the loop on decisions. They build paths for new maintainers before there’s an emergency. They protect the people doing the work instead of treating burnout as proof of commitment.
Frankly, the industry should have learned this by now.
A project run by one exhausted genius may look romantic from a distance. Up close, it’s just fragile.
Open source doesn’t need more heroes.
It needs better systems, clearer boundaries, and more people willing to do the unglamorous work before the whole thing starts smoking.
That’s less cinematic, I know.
It’s also how things keep running.