The Maintainers Behind Your Stack

01The Invisible Layer

Pull up the dependency tree of almost any application and you will find, somewhere near the roots, a library maintained by one or two people in their spare time. This is not an edge case. It is the normal condition of open-source software, and it has consequences that reach from a developer's laptop all the way to production servers handling millions of requests.

The small, often-unpaid teams keeping critical software alive.

The Debian Project ships tens of thousands of packages, each with a named maintainer responsible for tracking upstream changes, applying patches, and keeping the package in a releasable state. Many of those maintainers work without pay. The same is true across the Arch Linux project's Arch User Repository, where community packagers absorb the labour of chasing releases and resolving build conflicts so that no one else has to. Canonical and Red Hat employ dedicated engineers for their core stacks, but even commercial distributions depend heavily on upstream projects where the "team" is one exhausted person with a day job.

The stakes became impossible to ignore after the 2014 Heartbleed vulnerability in OpenSSL — a library securing a significant fraction of the web's encrypted traffic, maintained at the time by a tiny group with minimal funding. The shock prompted the formation of the Core Infrastructure Initiative, later reorganised as the OpenSSF, specifically to route money and developer time toward underloved critical projects. Progress has been real but uneven.

What makes the situation structurally fragile is the mismatch between consumption and contribution. Companies build products on freely available code, ship them to customers, and rarely send anything back — not a patch, not a bug report, not a donation. The maintainer absorbs the support burden and the security pressure while the value flows elsewhere.

The fix is not complicated to describe: audit what your stack actually depends on, report bugs properly, contribute patches where you can, and if your organisation profits from a project, consider funding it. Maintenance is not glamorous work. It is, however, the work that keeps everything else running.