Open Source Needs a Maintenance Manual

It’s remarkable that open source works as well as it does. Developers could be getting paid well for their skills, yet many choose to write code for free and endure constant scrutiny from strangers. Most developers straddle both worlds, and there is clearly enough value in open-source work to keep them engaged. Still, the stories are everywhere: burnout, depression, abandoned projects. We have plenty of guidance on contributing to open source and even etiquette guides, but almost nothing about how to sustain a project over the long haul.

There’s plenty of write-ups on GitHub about how to start a new open source project, or how to add tooling, but almost no information or best practices on how to maintain a project over years. I think there’s a big education gap and opportunity here. GitHub has an obvious incentive to increase num_developers and num_repos, but I think it’s worthwhile to ease the burden of existing developers and increase the quality and security of existing repos. Open source maintenance needs a manual.

Maintenance Is the Missing Skill

Most of us can set up a repository, wire up CI, and write a README. But what happens when a project takes off? How do you budget time for maintenance? How do you mediate community disputes? When do you formalize a request for comments process? Who can you trust to help triage? What are the real monetization options? What about security reports? And when the project starts accumulating dozens, then hundreds, then thousands of open issues—what then?

Few maintainers have clear answers to these questions. Better education, more visible success stories, and guardrails from hosting platforms would go a long way. The absence of those things is why many developers, despite technical ability, stay away from maintaining projects altogether. They simply don’t know how to do it well, and the fear of doing it badly keeps them from trying.

Money Changes the Equation

Financing is central to sustainability. The open-source projects that thrive long-term tend to have meaningful revenue behind them. Vue receives substantial donations. Automattic built a complete business on its open-source core. Greensock offers an open-source library but funds its team through memberships and paid licenses for specific use cases.

Nicholas C. Zakas has been exploring how to make that happen in a series starting with “Making your open source project sponsor-ready, Part 1: Companies and trust”. His key insight:

While it’s possible to bring in a decent amount of money through individual sponsorships, the real path to open source sustainability is to get larger donations from the companies that depend on your project. Getting $5 to $10 each month from a bunch of individuals is nice, but not as nice as getting $1,000 each month from a bunch of companies.

A healthier funding ecosystem would make open source feel less fragile. Between corporate contributions and a proper maintenance playbook, maintainers might finally get the support structure they need—before the next inevitable incident reminds us how little of it exists.