The spare time software project has been the backbone of the modern stack. The project the maintainer built on the weekend, the project the maintainer has been maintaining alone, the project the industry has been depending on for free, the project that is one burnout away from the deprecated notice. The honest framing matters here, because the spare time project the developer depends on at work sits as the spare time project another developer has been maintaining for free, the developer the industry has not been paying, the developer the next quarter may lose to the burnout the industry should have prevented.
What follows runs as the working version of the field guide. The shorter version is what the maintainer, the user, the funder actually have time to read.
What the project actually is
Three things, in roughly that order of how much each one matters. The first runs as the weekend build, where the project the maintainer started as the weekend project, the project the maintainer built to solve the problem the maintainer had, the project the maintainer open sourced because the maintainer thought someone else might find it useful. The second runs as the slow grown library, where the library that grew over the years, the library that picked up the contributor, the feature, the user, the library that became the dependency the industry depends on without the maintainer ever planning for the scale. The third runs as the single maintainer, where the project that depends on the single maintainer, the maintainer who has been carrying the issue tracker, the pull request review, the release, the maintainer who the industry has been leaning on without the industry ever formalising the arrangement.
What it costs the maintainer
Three things, in roughly that order of how much each one hurts. The first runs as the time, where the weekend that the maintainer was going to spend on the family, the project, the rest, the weekend that the critical bug forced the maintainer to spend on the fix, the time the maintainer has been giving up for years. The second runs as the support load, where the issue the user filed, the question the user asked, the feature request the user expected, the support load that grew with the user base, the support the maintainer has been providing for free. The third runs as the context switching, where the maintainer has the day job, the family, the project, the context switch the maintainer has been paying for every time the maintainer opens the laptop after dinner, the cognitive cost the maintainer has been underestimating for years.
How the industry should respond
Three moves if you are the user or the funder of the spare time software and want the project to survive past the next maintainer burnout. Pay for the support, because the support tier the maintainer offers (the GitHub Sponsors, the Open Collective, the Tidelift), the tier that gives the maintainer the funded hour the maintainer would otherwise squeeze in on the weekend, the tier the user should subscribe to if the user depends on the project at work, the subscription that costs the user less than the day the project goes unmaintained. Contribute the code, where the contribution the user can make, the pull request the user can submit, the documentation the user can improve, the contribution the user can make that gives the maintainer the breathing room the maintainer would otherwise not have. Hire the maintainer, because the maintainer that the user’s company hires, the contract the user’s company offers, the retainer the user’s company sets up, the hire that the maintainer can turn the spare time project into the day job, the hire that the user’s company should make if the user’s company depends on the project at scale. The industry that pays, contributes, and hires serves as the industry that has actually responded to the spare time software sustainability problem.
The bottom line
Spare time software in 2026 sits as the backbone the industry has been taking for granted. The weekend build, the slow grown library, the single maintainer, those three are what the project actually is. The time, the support load, the context switching, those three are what it costs. The paid support, the contributed code, the hired maintainer, those three are the response. The industry that does the three keeps the backbone. The industry that has not done the three serves as the industry that finds out the cost when the project goes away.
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.
