Who Maintains It
PHP has a large, experienced developer population that is mostly not planning to leave, and the practices that population reports around testing and static analysis vary widely enough that “PHP developers” is not a single, uniform quality signal you can hire against. Both halves matter to a staffing decision, and the second one is the kind of finding a defensive version of this book would have left out.
What working PHP developers report about themselves
JetBrains’ “The State of PHP 2025,” part of a broader State of Developer Ecosystem survey fielded between April and June 2025, drew 1,720 PHP-specific respondents out of 24,534 developers surveyed overall. JetBrains states its own caveat plainly, and this book repeats it every time the survey is cited: results may skew toward JetBrains product users, which is not the same population as “all PHP developers everywhere.” With that caveat attached, the self-reported figures are still informative. Eighty-eight percent report three or more years of PHP experience. Fifty-eight percent say they do not plan to migrate away from PHP in the next year; of the smaller group that does plan to leave, Go and Python are the most commonly named destinations.
Read this chart carefully, because it is the one place in this book where the good news and the limit are the same data. Half of respondents report using PHPUnit, and seventeen percent report using Pest, the two testing frameworks this book names without ranking one above the other. Thirty-six percent report using PHPStan, up nine points from the year before, a gain that stands on its own. But thirty-two percent report no automated testing at all, and forty-two percent report no static analysis at all. A hiring manager reading only the adoption numbers would conclude PHP has a maturing testing culture. A hiring manager reading only the gap numbers would conclude the opposite. Both readings are true of different, overlapping parts of the same self-reported population, and an evaluation that only quotes one side is choosing its conclusion before looking at the data.
For a due-diligence review of a specific codebase rather than the language in general, this finding has a direct, practical use: it means “the team writes PHP” tells you almost nothing about maintenance quality on its own, and “can I see the test suite and the static-analysis configuration” is a more useful question to ask in an acquisition or a vendor review than any question about the language itself. The tooling to answer that question exists and is standard enough to expect: PHP-CS-Fixer and PHP_CodeSniffer for code style, PHPStan and Psalm for static analysis, Pest and PHPUnit for tests, all named here in the same alphabetical, non-competing order this book uses throughout. A codebase with none of them configured is not evidence that PHP itself is immature; it is evidence about that specific codebase, and the distinction is worth insisting on in the room where the decision gets made.
Version currency, self-reported
The same survey found 89 percent of respondents multi-selecting PHP 8.x as a version they work in, 33 percent still touching 7.x, and 8 percent still touching PHP 5.6 or older. This is a developer’s self-report of what they personally work in day to day, not a measurement of the installed base of running servers; Governance and Versions covers the server-side figure, from a different source, and the two numbers should not be blended into one, because they answer different questions about currency: one is about what a developer’s job asks of them, the other is about what is actually deployed and exposed to the internet.
Where local talent availability fits, honestly
A due-diligence review in a regulated or non-anglophone market often asks a narrower question than “how many PHP developers exist worldwide”: can you hire locally, without going remote-first or asking someone to relocate. This book does not have a clean, geography-broken-out, primary-sourced figure to answer that precisely, and it would rather say so than borrow one from a marketing page. What it can say, structurally rather than statistically, is that PHP has been a standard component of general web-development education, in university courses, in bootcamps, in vocational tracks, across most regions for two decades, which is the same adoption longevity already established in The Reputation and Who Runs PHP. That is a reasonable basis for expecting junior-to-mid PHP talent to exist locally in most markets; it is not a substitute for checking your specific local market before you commit a hiring plan to it.
The language’s core itself is maintained the same way: by a distributed base of contributors to the php-src project, overseen by the governance process described in Governance and Versions, rather than by a single vendor with a roadmap it controls unilaterally. That distinction matters for a different kind of risk than hiring risk: it means no single company’s acquisition, layoff, or strategy change can unilaterally end the language’s maintenance, the way it can for a project owned outright by one vendor.
Onboarding speed is part of a maintenance question too, and it is kept separate from the survey data above because it comes from the tooling rather than from a self-report. A new hire’s first task on a PHP codebase is usually running Composer (Cost covers what it manages) against a lockfile that pins every dependency to an exact, reproducible version. That is a mechanical, verifiable property of the toolchain, not a claim about how good any particular team’s engineering culture is, and it is the same category of guarantee npm gives a Node.js team or cargo gives a Rust team: a new machine can reproduce the exact dependency graph the rest of the team is already running, which is a smaller but real contributor to how quickly a new maintainer becomes productive.
The limit. This book cannot give you a precise, sourced, PHP-versus-other-language salary or job-demand comparison. The two obvious sources, Stack Overflow’s and JetBrains’ own survey data, render the relevant breakdowns as interactive charts rather than as fetchable text at the precision this book requires, and a widely repeated older figure for the total global PHP developer population is stale enough that this book declines to repeat it rather than reprint a number it cannot stand behind. Where precision is not available, this book says so instead of rounding a guess into an authoritative-looking statistic.
What to verify yourself. Read the current JetBrains State of Developer Ecosystem survey yourself and check whether the caveat about its own respondent skew is still attached the way this book has attached it; a survey that drops its own caveat in a later year is a signal worth noticing. Separately, github.com/php/php-src publishes its contributor activity in the open: look at the actual pace and diversity of commits yourself before forming a view, in either direction, about the health of the language’s core maintenance.
Talent answers who can build and maintain a PHP application. What that talent, that infrastructure, and that testing culture actually cost to run is the next question, and Cost is where the evidence for it lives.