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 (0)