Open source software powers the global economy. Linux runs most servers. React powers millions of applications. PostgreSQL stores critical data. Yet the maintainers of this infrastructure are often unpaid volunteers, burned out from thankless work.

The sustainability crisis has reached a breaking point. Understanding it helps developers, companies, and the industry work toward solutions.

Open Source Critical infrastructure maintained by tired volunteers is a systemic risk

The Scale of the Problem

Statistic Impact
96% of codebases Contain open source components
70-90% of modern applications Built on open source foundations
Median maintainer compensation $0 (most are unpaid volunteers)
Average maintainer tenure before burnout 3-5 years

Companies worth trillions depend on projects maintained by individuals earning nothing.

How We Got Here

The Original Model

Open source began as:

  • Hobbyist projects for personal use
  • Academic research shared freely
  • Corporate releases for ecosystem building
  • Idealistic "software should be free" philosophy

This worked when projects were small and maintainers had other income sources.

The Scale Problem

Modern open source:

  • Powers production systems at massive scale
  • Requires ongoing security patches
  • Needs compatibility with evolving ecosystems
  • Demands documentation, support, and communication

The scope changed; the funding model did not.

High-Profile Burnout Examples

  • core-js: Powers 75% of websites, maintainer jailed for a car accident, project nearly abandoned
  • event-stream: Maintainer handed off to attacker due to burnout
  • Log4j: Critical vulnerability in project with minimal funding
  • left-pad: 11-line package broke the internet when unpublished

These are symptoms of systemic underinvestment.

Current Funding Models

1. Corporate Employment

Maintainers employed by companies that benefit from the project.

Pros Cons
Stable income Dependent on employer priorities
Full benefits May lose maintainership if job changes
Dedicated time Company may not value all projects

Examples: Linux kernel (many corporate contributors), Kubernetes (Google/CNCF)

2. Foundations

Non-profit foundations provide governance and sometimes funding.

Foundation Focus
Linux Foundation Linux, Kubernetes, many others
Apache Foundation Apache projects
OpenJS Foundation JavaScript ecosystem
Python Software Foundation Python language
Rust Foundation Rust language

Foundations help with governance and legal but often do not directly pay maintainers.

3. GitHub Sponsors / Patreon

Direct donations from individuals and companies.

Reality Implication
Most sponsors donate $5-20/month Volume needed for meaningful income
<1% of users sponsor Massive free-rider problem
Sponsors often drop off Unreliable income

Works for some, but rarely replaces full-time income.

4. Open Source Grants

One-time grants from companies, governments, or foundations.

Source Examples
Corporate Google Open Source, Microsoft FOSS Fund
Government Sovereign Tech Fund (Germany), EU NGI
Foundation Mozilla, Ford Foundation

Grants help but are often one-time and require significant application effort.

5. Open Core / Commercial Services

Free core + paid features or services.

Open Core Model
├── Open Source (free)
│   └── Core functionality
│
└── Commercial (paid)
    ├── Advanced features
    ├── Hosted service
    ├── Enterprise support
    └── Consulting

Examples: GitLab, MongoDB, Elastic, Grafana

Works well for some projects but requires business skills and product-market fit.

6. Fair Source / Source Available

Visible source code with commercial restrictions.

Examples: Sentry, HashiCorp (post-license change), Elastic (post-license change)

Controversial but increasingly common as companies try to capture value from their work.

Emerging Solutions

Tidelift

Subscription model: Companies pay Tidelift, Tidelift pays maintainers.

How It Works
Company pays subscription
Tidelift aggregates payments
Maintainers commit to security, maintenance
Maintainers receive ongoing income

Promising but scale limited.

Thanks.dev

Automated dependency-based distribution.

How It Works
Company donates to fund
System analyzes dependency tree
Funds distributed proportionally to dependencies
Automated, low-friction

Solves discovery problem — funding finds projects automatically.

Sovereign Tech Fund (Germany)

Government funding for critical open source.

Investment Focus
€10M+ annually Infrastructure projects
Multi-year grants Sustainable funding
Security focus Critical vulnerability prevention

Model for government involvement in open source sustainability.

Open Source Pledge

Companies commit to paying maintainers per developer.

Commitment
$2,000 per developer per year
Distributed to open source projects
Public accountability

Voluntary but creates social pressure and norm establishment.

What Companies Should Do

Minimum

  1. Inventory dependencies. Know what open source you use.
  2. Fund critical dependencies. GitHub Sponsors, Open Collective, direct grants.
  3. Contribute back. Bug reports, documentation, code contributions.

Better

  1. Allocate budget. 0.1-1% of engineering spend to open source.
  2. Allow contribution time. Let engineers contribute during work hours.
  3. Hire maintainers. Employ people to work on dependencies.

Best

  1. Sponsor maintainers directly. Long-term relationships, not one-time donations.
  2. Fund foundations. Support ecosystem-wide sustainability.
  3. Release your own code. Contribute back to the commons.

Budget Framework

Open Source Investment (per engineer)
├── Minimum: $100-500/year
│   └── GitHub Sponsors to key projects
│
├── Meaningful: $500-2,000/year
│   └── Distributed across dependency tree
│
└── Serious: $2,000+/year
    └── Direct maintainer relationships

For a 100-person engineering team at $2,000/engineer = $200K/year — a rounding error in most tech budgets.

What Developers Should Do

As Consumers

  1. Sponsor projects you use. Even $5/month helps.
  2. Contribute. Documentation, bug reports, code reviews.
  3. Be kind. Maintainers are humans, not free support.

As Maintainers

  1. Set boundaries. You do not owe infinite free labor.
  2. Ask for funding. Add sponsorship links, funding.yml.
  3. Consider sustainability from the start. What is the long-term plan?
  4. Build community. Distribute responsibility.

As Employees

  1. Advocate internally. Push your company to fund open source.
  2. Use your open source budget. Many companies have it, few use it.
  3. Contribute during work. If allowed, use work time for contributions.

The Path Forward

Open source sustainability requires systemic change:

1. Normalize Payment

Open source is not "free." Someone pays — either maintainers through unpaid labor or eventually through critical failures.

2. Government Involvement

Digital infrastructure is public infrastructure. Governments fund roads; they should fund open source.

3. Corporate Accountability

Companies profiting from open source should contribute proportionally.

4. Better Funding Mechanisms

Automated, low-friction funding that follows dependency graphs.

5. Maintainer Self-Advocacy

Maintainers should ask for compensation and set sustainable boundaries.

The Stakes

What happens if we do not solve this:

  • More security vulnerabilities in unmaintained code
  • More burnout and project abandonment
  • More hostile takeovers of abandoned projects
  • More critical infrastructure failures
  • Slower ecosystem innovation

The free lunch is ending. Open source sustainability is everyone's problem — companies, governments, and developers. The question is whether we invest proactively or pay the price of neglect.

The infrastructure is too important to leave to chance. Fund your dependencies.

Comments