I spent the weekend at FrOSCon in Sankt Augustin, where I helped staff The PHP Foundation's booth. Two days of that means a lot of conversations, and I had expected most of them to be about the language. They were not.
Nobody asked me about pattern matching. Nobody asked when partial function application ships. What people wanted to know was who owns PHP now, whether the Foundation decides what goes into the language, how long a release is supported, and whether they will still find someone to maintain their system in five years. Several of those conversations were with people who do not write PHP themselves. They were asking on behalf of a decision somebody in their organisation has to make.
I had been thinking about those questions already, because of a comment Volker Dusch sent me after Four out of five was published:
While your post makes sense to me, I think a lot of the sugar isn't what drives the language.
We're community owned and driven, not beholden to cooperate interests, have a great track record of scaling, of getting projects out quickly and sustainably, high quality standards and experienced practitioners.
I replied that these were excellent topics and that I planned to cover them in a future article. He corrected me:
I was more referring to what I think matters about the language for readoption. But both are good, of course.
That correction is the reason this article exists. I had read his message as a suggestion for a topic list. He was making a sharper point: the previous article answered a question nobody actually decides on. The booth at FrOSCon then spent two days confirming it.
Measured against Rhombus's checklist of closures, objects, pattern matching, and type parametricity, PHP scores four out of five. That is a fair answer to "is PHP a modern language?" It is not an answer to "should we build on PHP?"
Choosing a language is an architecture decision, and architecture decisions are dominated by non-functional requirements. A goal statement describes what a language is. It says nothing about what it is like to bet a decade on it: who can change the terms, how upgrades arrive, whether the thing you ship stays shippable, and whether you can hire someone in year six who has done this before.
Those are the language's non-functional requirements. Here is how PHP answers them, and what each answer costs.
Ownership: who can change the terms?
The first question is the one a risk register would ask. If the owner of your platform decided tomorrow to change the license, what would happen to your roadmap?
The last eight years have made that question concrete rather than theoretical. MongoDB moved to the SSPL in 2018. Elastic followed in 2021, then reversed course in 2024 by adding the AGPL. HashiCorp relicensed Terraform, Vault, Consul, Nomad, and Packer to the Business Source License in August 2023; the community forked Terraform into OpenTofu, which the Linux Foundation accepted the following month, and IBM acquired HashiCorp for $6.4 billion in February 2025. Redis left the BSD license in March 2024, and Valkey appeared within weeks. In every case the pattern was the same: a single entity held the copyright, the trademark, and the roadmap, and eventually exercised that position.
PHP moved in the opposite direction, and it did so this year. From PHP 8.6 onwards, PHP is distributed under the PHP License, version 4, which is the Modified BSD License, BSD-3-Clause, with nothing else attached. Ben Ramsey went through the change clause by clause. What version 4 drops from the old PHP License 3.01 are the restrictions on the names "PHP" and "Zend", an advertising acknowledgment clause, and the provisions that gave only the PHP Group and Zend Technologies the authority to publish a new version of the license at all. The name clause is the one that had left packagers such as Debian unsure what they were allowed to call a patched build. Zend Technologies, now a subsidiary of Perforce Software, did the same thing to the Zend Engine License at the same time, after 25 years in which engine and language grew too entangled to license apart. Two vendor-specific documents became one plain, GPL-compatible, OSI-approved permissive license.
That is a governance event rather than a legal footnote. An industry-wide trend ran toward restriction, and the parties who held whatever special standing existed in PHP's license gave it up. What remains is a codebase whose copyright is spread across hundreds of contributors, none of whom can relicense the whole. The PHP Foundation states the position plainly in its 2025 transparency report: it does not control the decisions the community makes about the language, and does not assume governance over the language itself.
That is the strong version of Volker's first point, and it is stronger than "community owned" usually sounds, because it is structural rather than cultural. There is no entity to be acquired. It is also, I noticed at the booth, the part people are least sure about: the question "does the Foundation own PHP now?" came up often enough that I stopped being surprised by it.
Now the costs, of which there are three.
The first is funding. In 2025 the Foundation received $730,534 from 536 sponsors and individual donors, spent $784,376, and deliberately drew about $139,000 from reserves to keep its technical headcount. Its eleven contracted developers authored roughly 42 % of all commits to php-src that year. So while no company owns PHP, a substantial share of the paid maintenance capacity depends on an income stream concentrated in a small number of sponsors, and the sponsor count fell year over year. That is a dependency rather than ownership, and it deserves to be named rather than waved away. Part of the money is public: the Sovereign Tech Agency funded both PHP's security audit and a 530-hour modernisation of the stream layer, treating PHP as digital infrastructure rather than as a product.
The second is the electorate. Every language change passes through a public RFC with a public vote and a two-thirds majority, which is genuinely more transparency than most languages offer. But the group that actually votes is small: the draft Who Can Vote (2024) RFC counts roughly 140 people as having voted on any RFC in the preceding three years, against about 1,650 accounts nominally eligible. That RFC is still in draft. The people deciding PHP's future are self-selected volunteers, and design by rolling majority buys independence at the price of coherence. A language with a design team is more consistent than a language with an electorate.
The third cost is the one I ran into at the end of the previous article. Community ownership means work happens where somebody's interest lies, not where the ecosystem's need is greatest. PHP needs a database driver that yields instead of blocking. Nobody can be assigned to write it. That is not a flaw in the governance model; it is the bill for it.
Sustainability: the upgrade as a scheduled event
The second non-functional requirement is whether the platform will still be there, and on what terms, for as long as the system lives.
PHP ships one feature release a year, in November, and has done so for a decade. Each branch gets two years of active support and two years of security fixes, a window extended from three years to four in March 2024, with end-of-support dates aligned to 31 December. You can put PHP 8.2's end of life, 31 December 2026, into a project plan two years in advance and be right.
The framework layer matches that discipline. Symfony publishes a long-term support release every two years, with three years of bug fixes and four years of security fixes, on a May/November cadence and behind an explicit backward-compatibility promise. Laravel ships a major version annually, with 18 months of bug fixes and two years of security fixes. None of that is exciting. It is what lets an organisation build a five-year maintenance budget out of published dates.
What makes those dates actionable is that the upgrades are mostly mechanical. UPGRADING files, Rector, and static analysis turn a major version bump into a task with an estimate. Compare that with ecosystems where a major version was a rewrite: Python 2 to 3, AngularJS to Angular. PHP 7 to 8 was, for most codebases I have seen, a sprint rather than a project.
The cost here is that PHP's own history supplies the counterexample. PHP 6 was announced and never shipped. The 5.x years ran long, and the migration to PHP 7 was where a great many codebases stalled, several of which are still running. The predictable cadence is a decade old, not three. "The PHP most people remember" exists because upgrading once genuinely was awful, and a decade of good behaviour does not erase the memory of the decade before it. It only makes the plan credible going forward.
Scale: the floor, not the achievement
The third requirement is the one Volker put as a track record of scaling, and it is the one I need to say least about, because the previous article already made the argument: PHP's shared-nothing, request-scoped execution model gives you fault isolation per request and horizontal scaling as the default. Other ecosystems assemble those properties from frameworks and operational discipline. In PHP they are the floor.
The public numbers hold no surprises. As of 15 August 2026, W3Techs puts PHP at 70.3 % of websites whose server-side language is known; the next entries are JavaScript at 7.2 % and Ruby at 7.0 %. That number is not an argument that PHP is good. It is an argument that the scaling question has been answered empirically, at a range of workloads, for a long time, and that nothing about it is going to surprise you in year three.
The cost is the same one as before: scaling out is solved, scaling within a request is not. That remains the open item, and it is the reason the concurrency gap matters more than the pattern-matching gap.
Delivery: fast is easy, sustainable is the requirement
"Getting projects out quickly" is the claim I trust least when I hear it about PHP, because it has always been true and has never been the whole story. Speed is exactly what produced the codebases I am called in to modernise. The claim worth examining is the second half of Volker's sentence: quickly and sustainably.
What makes the second half plausible is not the language. It is that PHP's supporting infrastructure is old, boring, and interoperable. Composer solved dependency management once and correctly: a resolver, a lock file, and reproducible installs. Packagist now indexes around 460,000 packages across 5.7 million versions, with roughly 189 billion installs since 2012, which makes it the third-largest package registry of any language after npm and PyPI. The quality toolchain, PHPUnit, PHPStan, Psalm, Rector, Infection, and php-cs-fixer, is mature, widely adopted, and designed to run in the same pipeline.
The most valuable property of that toolchain is its age. I have been releasing PHPUnit for 26 years. Tools that old have had their conventions settled, their edge cases found, and their integrations written. A team starting a PHP project in 2026 does not have to decide how testing works, how dependencies are pinned, or how static analysis runs in CI. Those decisions were made, argued about, and standardised years ago, and the cost of that is now zero.
The cost, and it is the real one, is that none of this is automatic. The same low barrier that gets a project into production in a fortnight also lets a team skip every one of those tools and still ship. Fast and sustainable are separate properties, and the second one is a matter of discipline rather than of language design. The ecosystem makes that discipline cheap to have, and it remains a decision somebody in the team has to make.
Practitioners: staffing as a non-functional requirement
The last requirement is the one that decides whether a system survives its second maintenance generation: can you hire someone who has done this before?
The scarce thing is not people who know the syntax. It is people who have kept a system alive for ten years, seen a framework major upgrade through, and know what a slow query looks like at 3 a.m. On that measure PHP's pool is deep. JetBrains's State of PHP 2025, based on 1,720 developers who named PHP as their main language, reports that 88 % have more than three years of experience, with the largest single group in the six-to-ten-year range. 89 % are on PHP 8.x. 58 % have no plans to move to another language.
And here is the same number read the other way, which is the honest reading: 88 % with more than three years of experience means barely over one in ten with less. A pool that is experienced because it is not being refilled is a different asset from a pool that is experienced and growing. I do not know from this data which of those PHP has, and neither, I suspect, does anyone else. The parent report that the PHP figures come from described PHP as being in long-term decline while the PHP-specific report described a stable and evolving ecosystem, a contradiction JetBrains never explained. Both readings are defensible from the same survey, which is a good reason to hold this one loosely.
What I would say with confidence is narrower and still useful: for the next decade, staffing a PHP system is a solved problem, and the people available to do it are unusually senior. What happens after that is a question the ecosystem should be asking out loud, rather than answering with market-share charts.
Where this leaves us
The two checklists measure different things. Rhombus's tells you whether a language is good. This one tells you whether it is safe to bet a decade on. Readoption decisions are made on the second list, which is why a language can score four out of five on the first and still lose the decision, and why PHP keeps winning decisions it is given no credit for.
On the second list PHP's answers are strong and not unqualified. Nobody can relicense it, and its license moved toward fewer restrictions in the same years the industry moved toward more. At the same time, a large share of its paid maintenance rests on a shrinking sponsor base, and its electorate is about 140 people. Upgrades arrive on a published schedule and are mostly mechanical; the schedule is ten years old, not thirty. It scales out by construction and not yet within a request. It ships projects fast, and whether it ships them sustainably is up to the team. It is staffed by practitioners with real depth, and the intake behind them is a question nobody has answered.
None of that required me to argue that PHP is alive, either. It required only that the criteria an architect actually decides on be written down and applied, with the same willingness to record a gap as a strength. That is also the version of the answer that was useful at the booth. "PHP is fine, look at the release notes" convinces nobody who has to defend the decision to a steering committee. A list of what is guaranteed, what is merely likely, and what is unresolved does.
Volker is himself listed as a contributor on the PHP 8.5 deprecations RFC, without being paid by anyone to be there. That is the mechanism he was describing, working, in the one form that matters: somebody who uses the language showed up and changed it.
