The words “open source sustainability” seem to imply that the whole open source ecosystem has a systemic problem. Even the European Commission mentions “sustainability” as a generic issue of “open source“ in its “Open Source Strategy” document. Lumping together behemoth projects like Kubernetes with VLC and XZ Util is a mistake that confuses users and customers: the differences cannot be ignored.

No one ever sends you an invoice for pure open source software. That’s most of its appeal. When you pull a library to build into your product or a database to run in production, nothing shows up in your inbox promising to bill you later for the three jobs you’ve taken on:

• building the features you’ll need,
• patching the vulnerabilities that will surface, and
• keeping the thing alive on a timeline that has nothing to do with whether a volunteer maintainer feels like showing up this month.

Those jobs don’t disappear because nobody’s charging for them. They move somewhere you’re not looking: into your own engineers’ time, your own on-call rotations, your own risk tolerance, until the day they resurface all at once, during an incident. At that point, those open source components you rely on look less like a gift than a bill you didn’t know you’d been running up.

Why “open source sustainability” is wrong

That invisibility is the whole reason “open source sustainability” is the wrong phrase for what’s going on. Because the cost never arrives as a line item, people don’t experience it as “this specific project hasn’t found a way to get paid”. They experience it as a vague, ambient unease about the health of open source itself; as if the model were one company with one balance sheet, wobbling under its own weight every time a project gates a feature or asks users to start paying. It isn’t. Open source is not a company with one balance sheet.

Individual projects are either sustainable or they aren’t. Linux is sustainable. So is Postgres. So are hundreds of other projects with foundations, corporate backers, or business models that work. Some never will be because they haven’t created much value to begin with. But plenty of others are a different case: they’re creating value at scale, and still looking for a way to capture it. “Open source sustainability” flattens all of that into a single mood. What needs asking is narrower, and much more answerable: does this project have a way to thrive, and has the organization using it decided who’s paying for that?

Log4Shell is where that invisible bill arrived. In December 2021, a security researcher found a critical vulnerability in Log4j, a Java logging library sitting quietly inside an enormous share of the world’s enterprise software — used, by most accounts, in a large majority of enterprise Java applications, most of whose owners had no idea they were running it at all, let alone that a handful of volunteer maintainers were the ones standing between them and a remote-code-execution hole. Those maintainers worked nights and weekends, unpaid, to ship a fix while security teams across the planet scrambled in parallel. Nobody who depended on Log4j had budgeted for that moment, because nothing about using a free logging library had ever felt like a financial decision. It was one anyway. No one had priced it.

But notice what happened there: a handful of volunteers chose to absorb the cost on everyone else’s behalf. Nothing obligated them to. If they’d walked away instead, burned out, moved on, decided this wasn’t their problem to solve for free at 2 a.m., every organization running Log4j would have had a vulnerability with no one coming to fix it. Remember the XZ Util incident, where the original maintainer gave the project to what turned out to be a malicious actor. The cost absorption isn’t a guarantee, and that’s easy to miss. It’s a favor, extended by people who owed you nothing, and it can stop.

If it breaks, you keep the pieces

If you run open source software in production with no support contract and no vendor relationship besides the repo and the README, picking it made you its long-term owner. Not the maintainer. Not the community. You. That’s a legitimate thing to choose. Some of the best infrastructure teams in the world run this way, on purpose, with real engineering depth behind the decision and eyes wide open about what it costs them.

The problem was never choosing to own open source code. The problem is backing into that ownership without noticing, treating “free and open source” as a synonym for “no ongoing responsibility,” and then feeling betrayed when a maintainer narrows what’s free, or burns out, or ships a fix eight months after the CVE instead of eight hours. None of that is a betrayal. It’s a project trying to find a way to keep existing, running into an audience that had quietly assumed existing was free as in beer. The unexamined assumption is the antagonist here, not the maintainer who finally has to charge for something, and not the user who never got a bill and so never thought to ask who was paying.

So if you’re the one inside your organization who gets to decide whether to adopt an open source tool for something that matters, the question was never “is this free?” It’s who is going to own those three jobs (features, security, continuity) for as long as we depend on this thing? There are only two good answers:

• Your organization is. You have the engineering capacity and the institutional will to build what you need yourselves, patch vulnerabilities on your own schedule, and take over maintenance outright if you ever have to. You’re choosing that on purpose, not discovering it after the fact.
• A vendor you pay is. You’re buying that ownership, ideally from the maintainers themselves, since nobody knows the codebase better, because you’d rather spend money than engineering hours, and because you want someone contractually on the hook when something breaks at 2 a.m on a Saturday.

Every answer that isn’t one of those two is a hope, an assumption that the maintainers will keep responsibility for the cost of development, security, and level of service, forever, without a relationship with your organization and regardless of how much you depend on their work.

Leaving the question unanswered was never a good strategy. Ask it before the bill comes due, not after.