4 MIN READ
The spare time software project has been the backbone of the modern stack. Most open source work starts as a weekend build. The maintainer has a problem, solves it, open sources the solution because they think someone else might find it useful. A fraction of those projects grow into slow grown libraries that pick up contributors, features, and users, and end up as the dependency the industry cannot replace. Almost all of them depend on a single maintainer carrying the issue tracker, the pull request queue, and the release cadence, while the company that depends on the project at scale never writes a cheque.
Here is the thing. The thank you arrives in the maintainer’s inbox, the issue tracker fills up, the pull request queue grows, and the next quarter arrives with the maintainer quietly calculating whether the project is still worth the burnout. The arrangement stays informal because no one at the buying company ever sat down to formalise it. This piece runs as the field guide to what that arrangement actually looks like, what it costs, and how the industry should respond.
What the project actually is
Most spare time projects start as a weekend build. The maintainer has a problem, solves it, open sources the solution because they think someone else might find it useful. A fraction of those projects grow into slow grown libraries that pick up contributors, features, and users, and end up as the dependency the industry cannot replace. Almost all of them depend on a single maintainer carrying the issue tracker, the pull request queue, and the release cadence. The maintainer has been doing this for years. The company that depends on the project at scale has been doing nothing. The arrangement stays informal because no one at the buying company ever sat down to formalise it.
What it costs the maintainer
The costs compound. The weekend that was supposed to go to family, rest, anything else, now goes to the critical bug the maintainer has been putting off. The support load grows with the user base. Issues, questions, feature requests, the maintainer has been fielding them for free. The context switching, between the day job, the family, and the project, has been quietly draining the cognitive budget for years. None of this shows up in the project’s README. None of it shows up in the procurement spreadsheet at the company that depends on the library.
How the industry should respond
Pay for the support. GitHub Sponsors, Open Collective, Tidelift, pick one. A funded hour for the maintainer amounts to more than a thank you note, and the subscription costs less than the day the project goes unmaintained. Companies that depend on a library at scale should be on the maintainer’s sponsor list at a level that reflects the dependency, not at the level of a coffee a month.
Contribute the code. Pull request, documentation, triage, anything that gives the maintainer breathing room. The maintainer has been carrying the entire project alone, and the contribution serves as the chance to share the load. Even a few hours a month from a few engineers on the consuming side would unblock the maintainer in ways the thank you notes never will.
Hire the maintainer. Contract, retainer, full time role, whatever fits the company’s procurement setup. The maintainer’s spare time project becomes the day job, and the project stops being a weekend obligation. For a small handful of libraries, this has already happened and the projects in question are healthier for it. Most libraries the industry depends on have not had this conversation yet.
The bottom line
Pay for the support, contribute the code, hire the maintainer. Spare time software runs as the backbone the industry has been taking for granted, and the day the maintainer walks away, the company that depended on the library at scale finds out the cost.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
