Open Source Under Pressure
There's a well-known comic showing all of modern digital infrastructure as a tower of blocks, balanced on one tiny block labelled "a project some random person in Nebraska has been thanklessly maintaining since 2003." It's funny because it's barely an exaggeration.
The pressures
Burnout. Many critical open-source projects are maintained by one or two people, often unpaid, in their spare time. They receive bug reports, feature requests and occasionally abuse from users at companies worth billions. Some maintainers simply walk away, and projects go quiet.
Security. High-profile incidents have shown how much depends on small projects. A serious vulnerability in a widely used logging library sent companies scrambling over a holiday season. In another case, an attacker spent a long time gaining a maintainer's trust in a compression library before inserting a backdoor, which was caught almost by luck. These were wake-up calls about how fragile trust in the supply chain can be.
Licence changes. Several companies that built products on open-source licences later switched to more restrictive licences, often to stop cloud providers from selling their software as a service without contributing back. Communities sometimes responded by forking the last open version. Users were left working out what they're allowed to do.
"Open" AI models. The term "open source" is now used loosely for AI models whose weights are downloadable but whose training data, code or licence terms don't meet traditional open-source definitions. The debate over what "open" means is still active.
What companies owe the commons
If your business depends on open source (and it almost certainly does), consider:
- Know what you depend on. Keep a software bill of materials. Track your dependencies and their health.
- Fund maintainers. Through sponsorship platforms, foundations or direct contracts. Small amounts from many companies add up.
- Contribute engineering time. Fix bugs you find, upstream improvements, help with reviews and documentation.
- Report vulnerabilities responsibly, and be patient and kind with volunteer maintainers.
- Don't treat maintainers as unpaid vendors. A volunteer owes you nothing, including a fix by Friday.
What individual developers can do
- Say thank you. Seriously. Maintainers mostly hear from people when something breaks.
- Write good bug reports: version, minimal reproduction, expected vs actual behaviour.
- Contribute documentation; it's often the most neglected part.
- Before adding a new dependency, ask if you really need it. Every package is a long-term relationship.
Why it matters
Open source is one of the most remarkable collaborative achievements in human history: millions of people building shared tools that anyone can use, study and improve. Its success is exactly why the pressure on it matters. A public good that everyone uses and nobody maintains doesn't stay good for long.
The person in Nebraska deserves better. So do the thousands like them, everywhere, including the ones whose small library you installed this morning without noticing.