The Sustainability Paradox

The title comes from the Free Software Song, written by Richard Stallman in 1991, set to the tune of a Bulgarian folk song. It was meant to be rousing. It is. The part the song didn't get to was what happens when the software has been shared, widely, and the people sharing it have not been paid, and a Fortune 500 company's entire revenue pipeline runs through a library maintained by one person in their evenings.

The open source sustainability problem is not a secret. It has been written about extensively, presented at conferences, and discussed in threads that accumulate hundreds of comments suggesting governance structures and grant programs and dual licensing arrangements. The threads generate more discussion than patches. The maintainer burns out or doesn't. The library keeps running critical infrastructure either way, because once something is embedded deeply enough in the dependency graph, it continues being used long after the person maintaining it has stopped wanting to.

The specific way Amazon, Google, and Microsoft consume open source infrastructure is worth naming directly: they run it at scale, they find the bugs at scale, and they fix the bugs in forks that are optimized for their infrastructure, which they then release as "their" distributions with "their" support commitments — Corretto, Cloud Logging, Azure SDK. This is not theft. The licenses permit it. The licenses were written before anyone understood what "at scale" was going to mean for the economics of software maintenance. The Free Software Song does not have a verse about this.

The LICENSE file in your dependencies is the document that governs the most important software in your stack. Most engineers have never read one. The ones who have read them have usually read them because something went wrong.

We'd love to contribute back but we just don't have the bandwidth right now.
— Fortune 500 company, closing a bug report as WONTFIX on a library that processes their entire payment flow