Maintaining an open source project is hard. It requires managing a group of people who are largely working for free to build something that other people profit off of, usually distributed across the globe, with limited resources.
The whole time you’re doing this, you’re receiving demands from users and businesses alike for features or bug fixes on a timeline that works for them, not you and your (possibly very limited) group of contributors that you can’t exactly order around, since they aren’t being paid. It’s stressful, and it can be overwhelming.
When one of these projects is the victim of an attack that takes advantage of the fact that there are only one or two maintainers, or eventually has to shut down due to rising technical debt and falling contributor numbers, the public blame falls on us, not on the businesses that didn’t offer contributors in time.
The Open Source Dependency Problem
According to a 2022 Linux Foundation study, open source software makes up 70-90% of any given modern software solution. So, if that much of the world’s digital infrastructure is reliant on open source software, why do so many projects both large and small struggle to attract and maintain contributors?
We’ve all heard the morality and community arguments for contributing back to open source projects, but we’re still seeing critical projects fall victim to attacks that take advantage of a small, overworked team of maintainers or shut down entirely because they didn’t get help until it was too late. So maybe it’s time we look at the business value of open source contribution from another angle.
Not contributing to open source is a security problem for your business.
The success of your business and the safety of your users’ data relies heavily on the stability of the open source software you build your product on top of. So, you should be motivated to ensure those open source projects remain healthy and secure, right? However, historically, only the very largest of projects has received this treatment.
We’ve seen it time and time again. A small but widely-used project has only one or two maintainers. Because they’re overworked, unpaid, and desperate for help, they’re easy to take advantage of. They may not review a PR as thoroughly as they should, and it may be easier for a bad actor to slip into a trusted position over time. Technical debt piles up, and with it, unresolved CVEs. Sometimes this is a one-off issue and a wake-up call for an industry to begin contributing to that specific project, or at least begin doing more investigation into the health of a project before relying on it. Sometimes, that offer of help comes too late and the project is unrecoverable.
A Real-World Example: Ingress NGINX
Ingress NGINX is an example of this. Roughly 50% of cloud native environments rely on this small but mighty utility for managing Kubernetes traffic. Despite its popularity and importance to the ecosystem, it has been steadfastly maintained by only two people for years. Calls for help have long been ignored, even in the face of a vulnerability with a 9.8 CVSS score. There is now no choice but to archive the project.
The fundamental architecture of Ingress NGINX is, to quote Kubernetes Security Response Committee member Tabitha Sable, “a never-ending CVE piñata.” No number of maintainers could reasonably be expected to keep it in a secure state, and it is no longer possible to get it to a point where it would be easier to maintain. If the project received a donation of an entire engineering team today, that engineering team would still just be used to ensure a more graceful shutdown.
This wasn’t always the case. There was once active development on a more modern implementation that would have resolved a lot of Ingress NGINX’s design issues, but the project maintainers were never able to attract more contributors and development stalled.
Had the businesses who are operating large cloud native environments reliant on Ingress NGINX begun contributing back to the project two years ago when asked, we might not be where we are today. Instead, the only responsible option left is to archive the project. Help came too late, and now users are faced with the choice between running an outdated Ingress NGINX deployment (and accepting the attack risk that comes with it) or spending the time and money necessary to migrate to another solution.
If You Rely on Open Source, Help Maintain It
Contributing upstream isn’t just for feel-good community points. It isn’t charity. It isn’t for clout. It’s a necessary part of maintaining a secure and reliable software supply chain. Businesses that rely on open source should treat upstream projects as part of their infrastructure. That means dedicating engineering time to contribute fixes and improvements, funding maintainers or foundations that support critical projects, prioritizing contributions to the dependencies their products rely on most, or hiring engineers or DevRel practitioners whose role includes contributing upstream.
Individual engineers can help too. Contributing documentation, reviewing pull requests, reporting bugs, improving tests, or helping with issue triage are all meaningful ways to reduce the burden on small maintainer teams. Engineers can also advocate within their organizations and push the companies they work for to support the projects their products depend on.
Open source projects rarely fail overnight. They usually show warning signs long before that point: maintainer burnout, unanswered issues, stalled development, and growing technical debt. Contributing upstream helps address those problems before they turn into security incidents, project shutdowns, or expensive migrations.
Because when a critical open source project fails, the impact doesn’t stay upstream. It spreads to every company, product, and user that depends on it.
Top comments (6)
the infrastructure framing is right but I think the harder problem is that companies only realize they depend on something after it breaks. log4j was the same - nobody audited their transitive dependencies until suddenly there was a CVE affecting half the internet. treating OSS as infrastructure means funding it before you need it, which is genuinely hard to make the budget case for internally
The line that matters: "Help came too late." That's not a technical failure. It's a collective action failure. Every company that depended on Ingress NGINX treated it as free infrastructure until it wasn't. The cost of maintaining wasn't the problem. The assumption that someone else would handle it was.
This resonates. I've seen teams treat critical OSS dependencies as free forever, then scramble when a maintainer burns out or a license changes. The infrastructure framing is exactly right. If you'd pay for hosted Redis, you should budget for the OSS projects your stack actually depends on.
The ingress-nginx CVSS 9.8 example is damning, but I'd push back slightly — even well-funded projects accumulate CVEs. The real gap might be that companies track SLA uptime for their cloud providers but have zero visibility into maintainer burnout for the OSS they depend on just as heavily.
Well said. The tragedy of open source burnout is that the warning signs are almost always visible years in advance stalled PRs, unanswered issues, overworked maintainers. Companies just choose not to look until it's an emergency. 'If you rely on it, help maintain it' should be written into every engineering team's charter, not just as a nice-to-have but as a security requirement.
This hit close to home. I run a financial data platform built entirely on open source — Astro for static generation, Supabase for the database, yfinance for market data — serving thousands of pages across 12 languages. My entire business literally depends on volunteer maintainers I've never met.
The Ingress NGINX example is chilling because it shows the failure mode isn't gradual degradation but sudden architectural dead-ends. Two maintainers for something 50% of cloud-native environments depend on is a systemic risk that no amount of post-incident funding can fix once the technical debt becomes structural.
What I think gets overlooked in the corporate contribution discussion is that small-to-medium builders like me are in an awkward middle ground — we depend on OSS just as heavily as enterprises, but we can't exactly dedicate an engineering team upstream. The most realistic contribution for indie builders might be documentation, issue triage, and actively reporting bugs we find rather than quietly working around them. Even that would be a massive signal boost for maintainers trying to make the case that their project needs more support.