Open Source Sustainability: Funding, Governance & Burnout

Open Source Sustainability

Almost every modern application is mostly open-source code. Much of that code is maintained by a handful of volunteers — sometimes one person — with no budget, no on-call rotation, and no obligation to keep going. Open source sustainability is the question of how those projects stay healthy: funded, governed, secure, and staffed by maintainers who aren't burning out.

It matters to maintainers, who need a path that doesn't end in exhaustion, and to every company that ships software, because an abandoned or compromised dependency is their incident too. The xz-utils backdoor in 2024 — a multi-year social-engineering campaign against a lone, overworked maintainer — made that risk impossible to ignore.

TL;DR

Most critical projects have tiny maintainer teams. A bus factor of one is common, even for widely used libraries.
Money helps but isn't everything. Funding buys time; governance, contributors, and boundaries keep projects alive.
Pick a governance model on purpose — BDFL, maintainer council, or foundation — and write it down.
Maintainers are allowed to say no, set support boundaries, and step back.
Companies should pay for what they depend on — through sponsorship, paid maintainer time, or upstream contributions.
Security is part of sustainability. Signed releases, 2FA, and multiple maintainers reduce supply-chain risk.

Quick Example

A small but widely used library can publish its governance and funding in two short files at the repository root.

Neither file costs anything to write, but together they tell contributors how to gain responsibility and tell companies exactly how to pay.

Core Concepts

Funding Models

Governance Models

BDFL (benevolent dictator for life) — One founder decides. Fast and coherent, but fragile if that person leaves.
Maintainer council / meritocracy — A group with commit rights decides by consensus or vote. Scales better and survives turnover.
Foundation-hosted — Projects join the Apache Software Foundation, Linux Foundation, CNCF, or OpenJS Foundation for neutral ownership of trademarks, legal support, and governance templates.

Bus Factor

The bus factor is the number of people who would have to disappear before a project stalls. Raising it is the single most important sustainability task: document release processes, grant commit and publish rights to more than one trusted person, and deliberately mentor contributors toward maintainer roles. See Community Management.

Maintainer Burnout

Maintainers face an endless issue queue, entitled users, and security reports with deadlines — often unpaid and outside working hours. Burnout leads to abandoned projects or, worse, projects handed to strangers without vetting.

Supply-Chain Obligations

Popular projects are targets. Account takeover, malicious maintainers, and typosquatting all exploit trust in open source. Sustainability now includes security basics: two-factor authentication on registries, signed releases and provenance (Sigstore, npm provenance), a security policy, and more than one person reviewing releases.

Best Practices

For Maintainers

Write down governance, contribution, and security policies (GOVERNANCE.md, CONTRIBUTING.md, SECURITY.md).
Set support boundaries — issue templates, a "we don't do free consulting" note, and saved replies.
Automate the chores — CI, release tooling, dependency updates, and stale-issue triage.
Grow successors by giving triage and review rights to regular contributors.
Enable funding with a FUNDING.yml and a clear statement of what money pays for.
Step back gracefully — mark the project as seeking maintainers or archive it rather than going silent.

For Companies That Depend on Open Source

Inventory critical dependencies using your SBOM and identify projects with a bus factor of one or two.
Fund what you use through sponsorships, foundation membership, or tools like thanks.dev.
Give engineers paid upstream time to fix bugs and review pull requests in the projects you depend on.
Upstream your patches instead of carrying private forks.
Report vulnerabilities responsibly and help fix them.

Common Mistakes

Treating Popularity as Health

Download counts say nothing about how many people maintain a project. A library with 50 million weekly downloads can have one exhausted maintainer.

Handing Over Publish Rights to a Stranger

Maintainers looking to step back have transferred packages to helpful newcomers who later shipped malware. Vet successors, or transfer to a foundation or known organization.

Taking Funding Without a Plan

Money that arrives without a stated purpose creates awkward expectations. Say what it funds: release management, security work, or maintainer hours.

Companies Only Filing Issues

Opening demanding issues without contributing code, review, or money adds load to already overloaded maintainers.

FAQ

What is open source sustainability?

It's the ability of an open-source project to keep being maintained, secured, and improved over time. It depends on funding, governance, a healthy contributor community, and maintainers who can do the work without burning out.

How do open-source maintainers get paid?

Through sponsorships and donations, employment by companies that depend on the project, open-core or hosted-service business models, paid support, and grants from foundations or public funds such as the Sovereign Tech Fund.

What is a bus factor in open source?

The number of people who could leave before the project can no longer function. A bus factor of one means a single person holds all the knowledge or publishing access.

Should my project join a foundation?

Consider it when a project has multiple corporate users and contributors who want neutral governance, trademark protection, and legal support. Foundations add process, so small single-author projects usually don't need one.

How can my company support open source?

Identify your critical dependencies, fund them directly or through foundations, give engineers time to contribute upstream, and share fixes back instead of maintaining private forks.