I remember the exact moment I decided to quit. It wasn’t a dramatic crash or a single angry email. It was a Tuesday afternoon, and I realized I hadn’t felt excited about the project in months.
Pluto.jl is a reactive notebook environment for Julia. It’s used by researchers, data scientists, and educators. It’s free. It’s powerful. And for the last few years, it lived in my brain rent-free. But I’m done now.
Open-source isn’t free. It’s paid for in exhaustion. And the industry is only just starting to notice the bill.
If you’ve ever used a library, framework, or tool without paying a cent — you’ve stood on the shoulders of a few tired humans. We don’t talk about that. We talk about innovation, community, and the magic of collaboration. We don’t talk about the 2 a.m. bug fixes, the endless GitHub issues, the silent guilt of not responding fast enough.
This isn’t a plea for sympathy. It’s a warning.
We treat maintainers like infinite APIs — until they hit their rate limit. And when they do, the whole ecosystem stumbles. Not because the code is bad, but because the model is unsustainable.
You’ve probably built software that depends on open-source tools maintained by one person in their spare time. You didn’t think about it because you weren’t supposed to. The whole system is designed to feel frictionless — as long as you ignore the friction it creates inside the maintainer.
I’m not special. I’m just the one who stepped away. Others will follow. And each departure leaves a crack in the foundation of something millions rely on.
The most dangerous software in the world is the one maintained by a single tired person who can’t quit. I quit so I could sleep again. That’s the real story.
What happens when the next person doesn’t?
FAQ
Q: Isn't open-source maintenance just a volunteer activity? Why expect compensation or recognition?
A: It is often volunteer work, but that doesn’t mean it’s cost-free. The labor is real, and it’s increasingly professional-grade. When a tool is used by thousands of companies and research institutions, treating the maintainer as a hobbyist is a willful delusion. The industry extracts value and then acts surprised when the source dries up.
Q: What practical steps can companies take to avoid this kind of maintainer burnout?
A: First, identify the critical open-source dependencies you rely on and check who maintains them. Second, fund them — either through direct sponsorship, paid development time, or hiring the maintainer part-time. Third, reduce single points of failure by having internal expertise or contributing fixes yourself. Treating maintainers like free APIs is a risk management failure.
Q: Isn't the real problem that people depend too heavily on a single maintainer? Shouldn't the solution be better bus factor and community redundancy?
A: That’s part of the answer, but it shifts the blame. The deeper issue is that the economic model of open-source incentivizes individual heroism. Redundancy is great, but it still requires people to do the work without sustainable support. The contrarian take: instead of just asking maintainers to ‘get more help,’ the ecosystem should make it normal to pay for critical infrastructure. Until then, any fork or contribution is still unpaid labor.