Fordel StudiosThe npm package that has 47 million weekly downloads is maintained by two engineers who have never been paid for the work. The issue tracker has 400 open items. The last commit was six months ago. One of the two maintainers just posted that they need to take a break from open source due to burnout. The other maintainer responded that they understand and also need to reduce their involvement.
Your production application depends on this package. You have not thought about this until now.
How We Got Here
Open source software was built on an assumption that turned out to be false: that the people who use software and the people who build it have enough overlap that the work of maintaining software will naturally be distributed across the community of users. For some large, high-visibility projects — Linux, Kubernetes, React — this assumption holds because the commercial interests are large enough to fund dedicated engineering time. For the vast middle layer of the software ecosystem — the parsing libraries, the utility modules, the adapters and connectors that everything depends on — the assumption does not hold. The users are mostly corporations. The maintainers are mostly individuals.
Corporations benefit economically from the work of individual maintainers. The individual maintainers benefit socially — reputation, community, the satisfaction of building something people use. This exchange worked when the individual maintainers were young, motivated, and did not yet know what burnout felt like. As the ecosystem aged, the maintainers aged with it, and the exchange increasingly fails to be sustainable.
“The open source ecosystem is built on a transfer of value from individuals who are motivated by reputation to corporations who are motivated by revenue. The corporations got a much better deal.”
The Security Dimension
An unmaintained open source library is not a neutral risk. It is a compounding liability. Vulnerabilities are discovered but not patched. The dependency ecosystem around it drifts. The version that your application pins to gradually accumulates known CVEs while your team does not update because updating is a risk and the library "still works." Eventually the library does not still work, either because a vulnerability is exploited or because a transitive dependency breaks it in a way that nobody anticipated.
The XZ Utils incident in 2024 was not an isolated event. It was a demonstration of what bad actors already understood: the open source ecosystem has critical dependencies maintained by single individuals under personal and financial pressure, and those individuals can be targeted. The entire supply chain is as strong as the weakest unmaintained library in it.
What Corporations Owe
If your business runs on an open source library, you have a maintenance obligation. Not a legal one — an ethical one, and increasingly a practical one. The obligation can be discharged in different ways: sponsoring the maintainer financially, contributing engineering time to the project, funding the infrastructure the project depends on, or at minimum triaging and responding to issues in a way that reduces the maintainer's load.
The companies that fund open source maintenance are not doing charity. They are paying for the reliability of their software supply chain. Companies that do not are free-riding on the goodwill of individuals who are increasingly aware of what they are providing and decreasingly willing to provide it indefinitely without acknowledgment. The open source sustainability conversation has been happening for a decade. The urgency is real and has not been adequately addressed by the industry that benefits most from the status quo.