Log4j is a Java logging library embedded in millions of applications — from enterprise servers to industrial systems to video game consoles. The Log4Shell vulnerability discovered in December 2021 was rated 10/10 on the CVSS criticality scale. It potentially affected hundreds of millions of systems worldwide. Log4j was maintained by a handful of volunteers, without structured commercial funding. The emergency response to the vulnerability relied on these same volunteers, forced to work without pause for several weeks on a problem whose resolution benefited billion-dollar companies that had contributed nothing to their funding.

The global software industry is built on an inverted pyramid: billions of dollars in market capitalisation rest, at their base, on open source libraries maintained by dozens or hundreds of people without proportional funding. This pyramid is stable as long as no critical vulnerability appears in the lower layers. When one does, it reveals that the base of the pyramid was made of cardboard.

A comic strip published by the webcomic XKCD depicts all the world's digital infrastructure as a stack of building blocks, one of which — tiny, at the base — is labelled "a project maintained since 2003 by a person in Nebraska". This image went viral in 2021 during Log4Shell because it accurately describes reality: somewhere in the dependency chain of every critical system, there is a library maintained by someone whose name nobody knows.

The vulnerability of unfunded open source is not only technical — it is human. A maintainer who burns out, changes jobs, falls ill, or decides to stop abandons a library that thousands of projects depend on. This library will no longer be maintained, new vulnerabilities will no longer be fixed, new language versions will no longer be supported. The "maintainer abandonment" risk is documented but rarely integrated into infrastructure risk analyses.

Google maintains Kubernetes, Angular, TensorFlow. Microsoft acquired GitHub and contributes massively to VSCode, TypeScript, .NET open source. Meta maintains React and PyTorch. Amazon contributes to OpenSearch. These contributions are real and significant — they do not cover the full funding debt of the open source ecosystem on which these companies depend.

Hyperscaler contributions concentrate on projects they control or whose visibility serves their image. Critical but low-visibility projects — compression libraries, file format parsers, network protocol implementations — remain maintained by individuals without structured funding. These libraries are used by millions of projects, including those of the hyperscalers themselves. The selection of what is funded is strategic, not altruistic.

Open source foundations collect membership fees from corporate members, employ full-time developers on critical projects, and organise governance. This model works for projects visible and widely-used enough to attract sufficient paying members. It fails for critical but low-visibility projects that cannot build a sufficient member base to self-fund.

Companies like HashiCorp, Elastic or Redis Labs adopted models where the base code is open source and advanced features are proprietary (open core) or the code is available under a restrictive licence for commercial use (dual licensing). These models fund development but create community tensions and compatibility breaks between versions.

Germany created the Sovereign Tech Fund in 2022 — a public fund that directly finances the maintenance of critical open source libraries identified as national digital infrastructure. This model treats open source as public infrastructure — on a par with roads or electrical networks — and funds it accordingly. It is the model most coherent with this study's thesis. It remains marginal at European scale.

Know the critical libraries your infrastructure depends on, their maintenance level (date of last commit, number of active maintainers, presence of a foundation or sponsor), and their vulnerability history. This audit should be as standard as a security audit — because it is security. A tool like Dependabot or Renovate automates part of this tracking.

The risk that a critical maintainer abandons their library should appear in infrastructure risk analyses, alongside the risk of supplier bankruptcy or OS end-of-support. This risk has a response: internal fork of the library, migration to a better-maintained alternative, or contribution to the maintainer's funding.

Companies that use open source can contribute through code (bug fixes, new features), through funding (donations to maintainers, foundation membership), or through time (engineers dedicated to maintaining critical libraries). These contributions are not philanthropy — they are risk management. A better-funded library is a less risky dependency.

On the model of the German Sovereign Tech Fund, a European open source critical funding fund — endowed with a budget proportional to the size of the European digital economy — finances the maintenance of libraries identified as critical infrastructure. This fund is fed by public contributions and by mandatory contributions from companies whose turnover exceeds a defined threshold and who use these libraries in production.

Companies beyond a certain size should annually declare their critical open source dependencies — in the same way as declaring critical suppliers in business continuity plans. This transparency would identify at-risk libraries (few maintainers, little funding, many users) and prioritise collective funding efforts.

Every public digital services contract should integrate a criterion of contribution to critical open source in its award conditions. A provider who contributes to the funding of the open source libraries they use in their service is a more reliable provider — and their contract should reflect it.