PHP Foundation Running on a Single Employee: The Open Source Dependency Crisis

A programming language that runs much of the web is resting on the shoulders of almost a single person. According to figures shared by the PHP Foundation, the number of full-time employees handling the language's ongoing maintenance is one. This puts a concrete example on the table for a dependency problem the open source world has been discussing for years.

What happened?

With a history spanning more than thirty years, PHP is one of the core languages of web servers. It runs across a wide range of use cases, from content management systems to e-commerce platforms. The PHP Foundation, meanwhile, is the organization that coordinates the language's development, security patches and release management. According to the disclosed figure, only one developer works on the language full-time within the foundation; the rest of the contributions come from volunteers and the partial support of sponsor companies.

Why does it matter?

In the software world this is called the "bus factor": a rough indicator measuring how many people would have to leave or disappear for a project to grind to a halt. When the factor drops to one, the project becomes dependent on a single person's time, health and motivation. For a language serving billions of requests to be this fragile is not a technical detail but a systemic risk.

The problem isn't specific to PHP. When the Log4j vulnerability erupted in 2021, it became clear that the library ran on critical Java systems worldwide yet was maintained by a handful of volunteers. OpenSSL's encryption infrastructure was run for years on an inadequate budget by just a few people; the Heartbleed vulnerability was the price of that picture. The 2024 xz Utils case was even more striking: through a years-long social engineering operation targeting a single burned-out maintainer, an attempt was made to slip a backdoor into the codebase. In every example the common denominator is the same: a thin human layer beneath massive enterprise use.

The real issue here is a paradox. Big tech companies consume this infrastructure for free and build billion-dollar products on top of it; yet contributions back to the source code often remain symbolic. Open source is treated like a commons, but no one wants to bear the cost of maintaining that commons alone. The result is a structure with very high public value but chronically insufficient funding.

Who does it affect, and how?

When a language's maintenance capacity narrows, the impact cascades. Security patches slow down, new releases are delayed, support for older versions ends early. And that comes back as a cost to everyone using the infrastructure.

By way of comparison, some languages solve this risk through corporate ownership. Go has Google behind it, while Rust has a broad foundation and numerous sponsors. PHP, by contrast, historically grew through a more scattered, volunteer-heavy model. That model carried the language to where it is today; but as the scale grows, the limits of volunteerism are becoming visible too.

What's next?

There are a few things worth watching. First is whether the foundation can broaden its sponsor base; what will be decisive is not a one-off donation from a few large companies but a sustainable, institutionalized funding stream. Second is whether the headcount will grow: distributing the maintenance burden from a single person to several full-time developers is the most direct way to lower the bus factor.

In the broader frame, the real question is whether corporate and public mechanisms for open source funding will mature. After the xz case, this debate made its way onto government and big-company agendas as well, but concrete and lasting steps are still limited.

It would be an exaggeration to think PHP will collapse tomorrow; the language has a large volunteer community and a mature codebase. But the "single employee" picture clearly shows just how fragile the foundations are on which the modern internet is built. The real risk isn't a sudden collapse; it's a quiet erosion, that is, maintenance slowly falling behind. For that reason this should be read not as the funding problem of a single language but of the entire open source model.