Why the Open Source Sustainability Question Is the Question

The open source sustainability question has been the question the industry has been postponing for a decade. The question the maintainer burnout, the xz utils near miss, the Log4Shell, the SolarWinds have all made impossible to postpone any longer. The…

Dark cinematic editorial image for Why the Open Source Sustainability Question Is the Question - abstract cyan and electric blue digital composition in deep black, hacker aesthetic, no text no logos

4 MIN READ

Here is the part buyers do not like to say out loud. Most of the software running in production was built by someone the buyer has never paid, and the someone is burning out. The xz utils near miss in 2024 was a single maintainer, paid nothing, who almost shipped a backdoor into every major Linux distribution on the planet. Log4Shell in 2021 was a single maintainer, paid nothing, whose library ran in millions of production systems. The pattern amounts to the cost of treating free labour as a permanent infrastructure layer.

The honest framing matters. The foundation funding, the GitHub Sponsors link, the Tidelift catalogue, all of those have been running for years. The funding has helped some maintainers and left the majority to manage on the same GoFundMe the community has been running since 2018. The question the industry has been postponing for a decade has now reached the point where the industry can no longer postpone it, and the question sits as whether the dependency the buyer depends on is the dependency the buyer is willing to fund.

Why the question is now unavoidable

Three events made the question impossible to defer. The xz utils backdoor was caught by Andres Freund at Microsoft, a researcher who noticed a 500ms latency anomaly in a beta release, and the backdoor was two commits away from shipping in Debian, Red Hat, and Ubuntu stable. If Freund had not noticed, the backdoor would have been in production across a large share of the internet by the next update cycle. The Log4Shell after action revealed the dependency tree most enterprises did not know they had, and the tree included a logging library maintained by a handful of volunteers. The maintainer exodus has been in slow motion for five years. Core-js, event-stream, colors.js, the maintainers who walked away from projects that were quietly running in billions of installs per week, and the projects continued working because nobody told them to stop.

What the funding has looked like so far

Three models, each with a different success rate. The foundation funding through the OpenSSF, the Linux Foundation, and the Apache Software Foundation has been the most visible, with corporate dues flowing into Alpha Anyhow improvements, security audits, and the maintainer stipend programmes. The funding is real, and the funding is not at the scale that lets a maintainer treat the work as a job. The platform sponsorship through GitHub Sponsors, Open Collective, and Tidelift has been the second model, with the buyer able to subscribe at a tier that pays the maintainer through the platform. Adoption has been slower than the marketing suggests. The paid maintainer model through Tidelift, HeroDevs, and the commercial open source companies (Sentry, Datadog, Elastic, MongoDB) has been the third, with the maintainer hired full time to maintain the project, paid market rate, with the cost recovered through the commercial product or the support contract. This model actually works, and the model only works when the project has a commercial angle to attach the cost to.

What actually has to change

Budget. The buyer that depends on the open source project should budget for the project, the way the buyer budgets for the AWS bill and the Salesforce renewal. The line item does not have to be large. A 0.1 percent allocation of the engineering budget, paid to the foundation the maintainer trusts, would close the funding gap on most of the critical projects in the Linux Foundation catalogue. The procurement lead can write the line item in a quarter.

Contract. The SBOM that the buyer requires from the vendor should trigger the funding commitment, the same way the SOC 2 requirement triggers the audit budget. The vendor ships the SBOM, the SBOM lists the dependencies, the procurement team funds the foundation behind the dependencies. The contract serves as the lever, and the procurement team is the one who can pull it.

Hire. The maintainer the industry has been leaning on for free should be hired full time, through the foundation, through the commercial open source company, or directly. The hire turns the spare time project into a day job, the day job keeps the project alive past the next burnout. The industry that budgets, contracts, and hires has actually answered the question.

Abstract open source sustainability as glowing cyan foundation columns on a dark navy surface, dramatic chiaroscuro lighting from above.
Open source sustainability in 2026: the xz near miss, the Log4Shell after action, the maintainer exodus. Budget, contract, hire.

The bottom line

Budget for the dependency, contract the funding through the SBOM, hire the maintainer full time. The free infrastructure layer was always a loan, and the loan has come due. Pay the maintainer, or explain to the next board meeting why the production system is down because the project folded.

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.

Continue reading