99.999% Freeloading Rate: Only 4,200 of 300 Million Companies Using Open Source Pay Maintainers Anything

[product_david]

The Most Staggering Stat in Tech Right Now

Let me put a number in front of you that should make every product leader lose sleep.

Of the roughly 300 million companies estimated to use open source software today, only about 4,200 participate in GitHub Sponsors. That is a freeloading rate exceeding 99.999%. Not a typo. Five nines — but instead of uptime, it measures the rate at which the global economy takes from open source maintainers and gives back absolutely nothing.

I have spent fifteen years building products. I have sat in boardrooms where executives approved seven-figure contracts for proprietary software without blinking. But suggest allocating even $50K annually to the open source foundations those products are literally built on, and suddenly everyone needs a business case.

The Numbers Tell a Devastating Story

At FOSDEM 2026 in Brussels, the keynote “Free as in Burned Out: Who Really Pays for Open Source?” laid out the crisis in unflinching detail. Maintainers are burning out while the companies extracting billions in value from their work contribute nothing. According to the 2024 Tidelift State of the Open Source Maintainer Report, 60% of open source maintainers remain unpaid, and 60% have quit or considered quitting their projects.

A Harvard Business School study found that 96% of commercial programs rely on open source software, with the total value of open source code estimated at $8.8 trillion. Let that sink in: an $8.8 trillion ecosystem sustained largely by volunteers.

Who Is Actually Paying?

Sentry has been leading the charge with their Open Source Pledge, which sets a floor: $2,000 per year per developer at your company, paid to open source maintainers of your choosing. Sentry themselves committed $750,000 this year, up from $500,000. The initiative has attracted about 20 companies pledging roughly $1.3 million collectively.

Microsoft runs its FOSS Fund distributing up to $12,500 per quarter to projects nominated by its engineers. Spotify allocates €100,000 annually through its own FOSS Fund. These are real programs from real companies.

But let us do the math. $1.3 million across the entire Open Source Pledge. Against an $8.8 trillion ecosystem. That is like tipping a penny on a $6,700 meal.

This Is a Product Problem, Not Just an Ethics Problem

As a VP of Product, I frame everything through the lens of risk, dependency, and sustainability. And from that lens, our industry’s relationship with open source is a ticking time bomb.

Consider the pattern: When the left-pad package was removed in 2016 and a chunk of the JavaScript ecosystem collapsed, people laughed. When Log4Shell was disclosed in December 2021 — a critical vulnerability in a library maintained by a handful of volunteers that sat inside 60% of Java projects as an indirect dependency — people panicked. When four new vulnerabilities were found in Kubernetes Ingress NGINX in early 2026 (CVEs with CVSS scores of 8.8), and Kubernetes leadership announced the project would stop receiving security patches starting in March 2026, people scrambled. Roughly 50% of cloud-native environments rely on that tool.

We treat open source like infrastructure that maintains itself. It does not.

What a Real Solution Looks Like

The Open Source Pledge’s $2,000/dev/year minimum is a reasonable starting point. For a company with 500 developers, that is $1 million per year. Sounds like a lot until you calculate the replacement cost of the open source software you use — which, for most companies of that size, easily exceeds $40-50 million annually.

But adoption is minimal. Twenty companies out of 300 million. The question I keep asking product leaders and finance teams is simple: If every open source maintainer you depend on quit tomorrow, what would your product roadmap look like?

The answer is always the same stunned silence.

The Business Case Is Obvious

This is not charity. It is supply chain management. We audit our vendors. We negotiate SLAs. We do due diligence on every third-party integration. But for the open source libraries that form the literal foundation of our products? We just assume someone will keep the lights on for free.

From a product perspective, every dependency on an unfunded open source project is unmanaged risk in your portfolio. Every burned-out maintainer is a potential Log4Shell waiting to happen. Every company that freeloads is betting that someone else will pay to keep the ecosystem alive.

That bet has worked so far. The question is: for how much longer?

---

I would love to hear how other organizations are thinking about this. Are any of you budgeting for open source contributions? Have you made the business case internally? Or is this still treated as someone else’s problem?

[alex_infrastructure]

David, this hits close to home. Let me give you the infrastructure perspective because I live this every single day.

My team depends on dozens of open source tools in production. Kubernetes, NGINX, PostgreSQL, Redis, Prometheus, Grafana, Terraform, Ansible — the list goes on. These are not nice-to-haves. They are the load-bearing walls of our entire infrastructure. And I can trace the exact pattern you are describing through three escalating disasters.

2016: left-pad breaks. An 11-line JavaScript package gets unpublished and a huge chunk of the npm ecosystem goes down. The response? Memes. Jokes. “How could anyone depend on an 11-line package?” Nobody took it seriously as a systemic problem.

2021: Log4Shell drops. A critical RCE vulnerability in Apache Log4j, maintained by a small team of volunteers, and embedded as a transitive dependency in 60% of Java projects. Suddenly it was not funny anymore. My team spent three weeks during the holidays doing emergency patching across hundreds of services. The maintainers who had been working for free were now expected to fix a crisis on an enterprise timeline — with no SLA, no contract, no compensation.

2026: Kubernetes Ingress NGINX is being deprecated. Four new CVEs disclosed in January, two with CVSS scores of 8.8. And here is the kicker: starting in March 2026, the project will no longer receive active maintenance, security patches, or bug fixes. Roughly 50% of cloud-native environments depend on this component. My migration plan is already 47 pages long and I have three months to execute it.

See the pattern? We only care about open source funding after disasters. We laugh, then we panic, then we scramble. And each time the blast radius gets bigger.

I ran an audit last quarter. My infrastructure stack uses 142 distinct open source projects in production. Of those, 23 are maintained by three or fewer people. Eleven of those maintainers have shown signs of reduced activity — fewer commits, longer issue response times, public statements about burnout. These are the canaries in the coal mine, and nobody is listening.

The Ingress NGINX situation is particularly instructive. This is not some obscure library. It is a core Kubernetes component used by half of all cloud-native deployments. And it is being deprecated partly because of insufficient maintainer bandwidth. When your critical infrastructure dependency is one burned-out volunteer away from abandonment, you do not have a technology problem. You have a supply chain crisis.

David is right that $2,000/dev/year is a reasonable floor. From an infrastructure perspective, I would argue it is laughably cheap insurance. We spend more than that per developer on monitoring tools alone — monitoring tools that are, ironically, built on open source.

[finance_carlos]

I want to bring the finance perspective here because the economics of this situation are genuinely absurd once you lay them out on a spreadsheet.

Last quarter, I ran an exercise with our engineering leadership. We catalogued every open source component in our production stack and estimated the replacement cost — what it would cost us to either build equivalent functionality in-house or purchase proprietary alternatives. The number came back at $47 million in annual value. That is not a rough guess. We priced out commercial equivalents for our database layer, our orchestration platform, our monitoring stack, our CI/CD pipeline, our web frameworks, our cryptographic libraries — all of it.

Our total annual contribution to open source maintainers? $0.

Zero. Not a rounding error. Literally nothing.

We spend $3.2 million per year on Salesforce licenses. $1.8 million on Datadog. $900K on our cloud provider’s proprietary services. We have a $400K annual contract with a vendor whose product is essentially a thin wrapper around three open source projects. We pay them. We do not pay the maintainers of the projects their product depends on.

When I presented this analysis to the CFO, the reaction was telling. She understood immediately that we are getting $47 million in value for free. But her first question was: “What is the contractual obligation?” And the answer, of course, is none. Open source licenses do not require payment. So from a strict fiduciary perspective, why would we pay?

Here is why: risk-adjusted value.

If you carry $47 million in dependency value with zero contractual assurance of continued maintenance, your risk exposure is enormous. We buy insurance for far smaller liabilities. We pay maintenance contracts on hardware that costs a fraction of this. We budget for disaster recovery scenarios that are less likely than a critical open source maintainer burning out.

The Open Source Pledge’s $2,000/dev/year target works out to about $340,000 annually for our engineering organization. That is 0.72% of the replacement value we receive. It is less than what we spend on office snacks. It is a third of what we pay for a single enterprise software license that a dozen people use.

I am now building a proposal for our board that frames open source contributions as supply chain risk mitigation, not philanthropy. The line item will sit next to our cybersecurity insurance and our vendor management budget. Because that is what it is — it is the cost of ensuring that the $47 million in value we depend on does not evaporate when a volunteer decides they have had enough.

David framed this as a product problem. Alex framed it as an infrastructure problem. From where I sit, it is a financial governance failure. We have a $47 million unmanaged liability on our books that does not appear in any risk register. That is not a business strategy. That is a subsidy from burned-out volunteers, and it is embarrassing that it took me this long to see it.

[eng_director_luis]

Great thread. David, Alex, and Carlos have covered the product, infrastructure, and financial angles thoroughly. I want to add the engineering leadership and culture perspective, because I think that is the lever most of us actually control.

Two years ago, I made a deliberate decision: open source contributions became part of my team’s OKRs. Not as a vanity metric. Not as a side project. As a first-class engineering objective, tracked and measured alongside feature delivery and reliability targets.

Here is how it works in practice:

Upstream contributions count. If an engineer fixes a bug in a library we depend on, improves documentation for a tool we use daily, or adds a feature we need to an open source project instead of building a proprietary wrapper — that counts as delivered work. It shows up in sprint reviews. It appears in performance evaluations. It gets recognized publicly in our engineering all-hands.

Dedicated contribution time. Every engineer on my team gets one day per month explicitly allocated for open source work. Some use it to fix issues in projects they depend on. Others contribute to projects they are passionate about. A few have become regular contributors to major projects and are now recognized members of those communities.

Hiring signal. Engineers who contribute to open source get recognized in our hiring process too — not as a requirement, but as a strong positive signal. And here is what I have found: the companies that contribute to open source attract the best engineers. Senior engineers want to work at places that value the ecosystem. When candidates see our GitHub contributions and our public commitment to upstream work, it differentiates us from companies that just consume.

The results after two years have been significant:

• 23 upstream bug fixes contributed to projects we depend on, several of which would have required painful workarounds otherwise
• 4 engineers became recognized contributors to major projects, giving us direct influence over roadmaps that affect our infrastructure
• Retention improved. Engineers tell me that the contribution time is one of the reasons they stay. It is professional development that actually matters.
• Recruitment pipeline strengthened. Our open source contributions are now mentioned in every recruiter pitch and every job posting. Multiple hires have cited it as a deciding factor.

But I want to be honest: this is not enough by itself. Culture without funding is still freeloading with better PR. We also adopted the Open Source Pledge this year and are allocating budget to our most critical dependencies. The culture piece makes engineers want to contribute. The financial piece ensures the maintainers they are contributing to can keep the lights on.

Carlos is right that the financial case is obvious. What I would add is that the talent case is equally compelling. The engineers who care about open source sustainability are, in my experience, the engineers who write the best code, think most carefully about dependencies, and take the most ownership of their systems. Building a culture that values giving back is not just the right thing to do — it is a competitive advantage in hiring and retention.

The companies that figure this out first will have a compounding advantage. The rest will keep freeloading until the next Log4Shell forces them to care — temporarily.