Das Wochenende habe ich auf der FrOSCon in Sankt Augustin verbracht, wo ich am Stand der PHP Foundation mitgeholfen habe. Zwei Tage am Stand bedeuten viele Gespräche, und ich hatte erwartet, dass es in den meisten um die Sprache gehen würde. Das war nicht so.
Niemand hat mich nach Pattern Matching gefragt. Niemand wollte wissen, wann partielle Funktionsanwendung kommt. Gefragt wurde, wem PHP heute gehört, ob die Foundation entscheidet, was in die Sprache kommt, wie lange eine Version unterstützt wird und ob sich in fünf Jahren noch jemand für die Pflege des eigenen Systems finden lässt. Mehrere dieser Gespräche habe ich mit Menschen geführt, die selbst kein PHP schreiben. Sie fragten für eine Entscheidung, die jemand in ihrer Organisation treffen muss.
Über diese Fragen hatte ich ohnehin schon nachgedacht, wegen eines Kommentars von Volker Dusch, die mich nach dem Erscheinen von Vier von fünf erreichte:
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.
Ich antwortete, das seien ausgezeichnete Themen und ich hätte vor, sie in einem künftigen Artikel zu behandeln. Er korrigierte mich:
I was more referring to what I think matters about the language for readoption. But both are good, of course.
Diese Korrektur ist der Grund, warum es diesen Artikel gibt. Ich hatte seine Nachricht als Themenvorschlag gelesen. Sein Punkt war schärfer: Der vorige Artikel hat eine Frage beantwortet, über die niemand entscheidet. Der Stand auf der FrOSCon hat das dann zwei Tage lang bestätigt.
Gemessen an der Checkliste von Rhombus aus Closures, Objekten, Pattern Matching und Typparametrisierung erreicht PHP vier von fünf Punkten. Das ist eine faire Antwort auf die Frage „Ist PHP eine moderne Sprache?“ Es ist keine Antwort auf die Frage „Sollen wir auf PHP bauen?“
Die Wahl einer Sprache ist eine Architekturentscheidung, und Architekturentscheidungen werden von nichtfunktionalen Anforderungen bestimmt. Ein Goal Statement beschreibt, was eine Sprache ist. Es sagt nichts darüber, wie es ist, ein Jahrzehnt auf sie zu wetten: Wer kann die Bedingungen ändern, wie kommen Upgrades, lässt sich das, was du gebaut hast, weiter ausliefern, und findest du im sechsten Jahr jemanden, der so etwas schon einmal gemacht hat?
Das sind die nichtfunktionalen Anforderungen an eine Sprache. Hier sind die Antworten von PHP darauf, und was jede davon kostet.
Eigentum: Wer kann die Bedingungen ändern?
Die erste Frage ist die, die auch ein Risikoregister stellt. Was passiert mit deiner Roadmap, wenn morgen die Lizenz deiner Plattform geändert wird?
Die vergangenen acht Jahre haben diese Frage konkret gemacht. MongoDB ist 2018 zur SSPL gewechselt. Elastic folgte 2021 und hat 2024 wieder umgesteuert, indem es die AGPL hinzugenommen hat. HashiCorp hat Terraform, Vault, Consul, Nomad und Packer im August 2023 unter die Business Source License gestellt; die Community hat Terraform zu OpenTofu geforkt, das die Linux Foundation im Monat darauf aufgenommen hat, und IBM hat HashiCorp im Februar 2025 für 6,4 Milliarden US-Dollar gekauft. Redis hat die BSD-Lizenz im März 2024 verlassen, und Valkey war wenige Wochen später da. Das Muster war jedes Mal dasselbe: Eine einzige Organisation hielt Copyright, Markenrecht und Roadmap in der Hand und hat diese Position irgendwann genutzt.
PHP hat sich in die andere Richtung bewegt, und zwar in diesem Jahr. Ab PHP 8.6 wird PHP unter der PHP License, Version 4 verbreitet, und das ist die Modified BSD License, BSD-3-Clause, ohne jeden Zusatz. Ben Ramsey ist die Änderung Klausel für Klausel durchgegangen. Weggefallen sind gegenüber der alten PHP License 3.01 die Einschränkungen für die Namen „PHP“ und „Zend“, eine Klausel zur Nennung in der Werbung und die Bestimmungen, die allein der PHP Group und Zend Technologies das Recht gaben, überhaupt eine neue Version der Lizenz zu veröffentlichen. Die Namensklausel ist die, wegen der Distributionen wie Debian unsicher waren, wie sie einen gepatchten Build nennen dürfen. Zend Technologies, heute eine Tochter von Perforce Software, hat zur selben Zeit dasselbe mit der Zend Engine License gemacht, nach 25 Jahren, in denen Engine und Sprache zu eng zusammengewachsen sind, um sie getrennt zu lizenzieren. Aus zwei herstellerspezifischen Dokumenten wurde eine schlichte, GPL-kompatible, von der OSI anerkannte permissive Lizenz.
Das ist ein Ereignis der Governance und keine juristische Fußnote. Ein branchenweiter Trend lief in Richtung Einschränkung, und die Parteien, die in der Lizenz von PHP eine Sonderstellung hatten, haben sie aufgegeben. Übrig bleibt eine Codebasis, deren Copyright sich auf Hunderte von Mitwirkenden verteilt, von denen niemand das Ganze neu lizenzieren kann. Die PHP Foundation formuliert ihre Position in ihrem Transparenzbericht für 2025 unmissverständlich: Sie kontrolliert nicht, was die Community über die Sprache entscheidet, und beansprucht keine Governance über die Sprache selbst.
Das ist die starke Fassung von Volkers erstem Punkt, und sie ist stärker, als „community owned“ üblicherweise klingt, weil sie strukturell ist und nicht kulturell. Es gibt niemanden, den man kaufen könnte. Es ist auch der Punkt, bei dem die Leute am Stand am unsichersten waren: Die Frage, ob die Foundation PHP nun gehöre, kam oft genug, dass sie mich irgendwann nicht mehr überrascht hat.
Nun zu den Kosten. Es sind drei.
Die erste ist die Finanzierung. Die Foundation hat 2025 von 536 Sponsoren und Spendenden 730.534 US-Dollar eingenommen, 784.376 US-Dollar ausgegeben und bewusst rund 139.000 US-Dollar aus den Rücklagen entnommen, um ihre technische Belegschaft zu halten. Ihre elf beauftragten Entwicklerinnen und Entwickler haben in jenem Jahr rund 42 % aller Commits in php-src verfasst. Kein Unternehmen besitzt PHP, aber ein erheblicher Teil der bezahlten Wartungskapazität hängt an Einnahmen, die sich auf wenige Sponsoren konzentrieren, und deren Zahl ist im Jahresvergleich gesunken. Das ist eine Abhängigkeit und kein Eigentum, und sie sollte benannt und nicht weggewischt werden. Ein Teil des Geldes ist öffentlich: Die Sovereign Tech Agency hat sowohl das Sicherheitsaudit von PHP als auch eine 530-Stunden-Modernisierung der Stream-Schicht finanziert und behandelt PHP damit als digitale Infrastruktur und nicht als Produkt.
Die zweite ist die Wählerschaft. Jede Änderung an der Sprache durchläuft einen öffentlichen RFC mit öffentlicher Abstimmung und Zweidrittelmehrheit, und das ist tatsächlich mehr Transparenz, als die meisten Sprachen bieten. Die Gruppe, die wirklich abstimmt, ist aber klein: Der Entwurf des RFC Who Can Vote (2024) zählt rund 140 Personen, die in den drei Jahren davor über irgendeinen RFC abgestimmt haben, bei etwa 1.650 nominell stimmberechtigten Accounts. Dieser RFC ist bis heute ein Entwurf. Über die Zukunft von PHP entscheiden Freiwillige, die sich selbst dafür entschieden haben, und Entwurf durch wechselnde Mehrheiten erkauft Unabhängigkeit mit Kohärenz. Eine Sprache mit einem Designteam ist konsistenter als eine Sprache mit einer Wählerschaft.
Die dritte ist die, auf die ich am Ende des vorigen Artikels gestoßen bin. Eigentum der Community bedeutet, dass dort gearbeitet wird, wo jemand Interesse hat, und nicht dort, wo der Bedarf des Ökosystems am größten ist. PHP braucht einen Datenbanktreiber, der nachgibt statt zu blockieren. Niemand kann dazu eingeteilt werden. Das ist kein Fehler im Governance-Modell; es ist die Rechnung dafür.
Nachhaltigkeit: Das Upgrade als geplantes Ereignis
Die zweite nichtfunktionale Anforderung ist, ob die Plattform noch da sein wird, und zu welchen Bedingungen, solange das System lebt.
PHP liefert ein Feature Release pro Jahr aus, im November, und tut das seit einem Jahrzehnt. Jeder Zweig bekommt zwei Jahre aktiven Support und zwei Jahre Sicherheitsfixes, ein Zeitraum, der im März 2024 von drei auf vier Jahre verlängert wurde, mit Enddaten jeweils zum 31. Dezember. Du kannst das End of Life von PHP 8.2, den 31. Dezember 2026, zwei Jahre im Voraus in eine Projektplanung schreiben und liegst richtig.
Die Framework-Schicht hält sich an dieselbe Disziplin. Symfony veröffentlicht alle zwei Jahre ein Long Term Support Release, mit drei Jahren Bugfixes und vier Jahren Sicherheitsfixes, im Mai/November-Rhythmus und hinter einem ausdrücklichen Versprechen der Rückwärtskompatibilität. Laravel liefert jährlich eine Major-Version aus, mit 18 Monaten Bugfixes und zwei Jahren Sicherheitsfixes. Nichts davon ist aufregend. Genau das erlaubt es einer Organisation, ein Wartungsbudget über fünf Jahre aus veröffentlichten Daten zu bauen.
Brauchbar werden diese Daten dadurch, dass die Upgrades größtenteils mechanisch sind. UPGRADING-Dateien, Rector und statische Analyse machen aus dem Sprung auf eine neue Major-Version eine Aufgabe mit einer Schätzung. Vergleiche das mit Ökosystemen, in denen eine Major-Version eine Neuentwicklung war: Python 2 auf 3, AngularJS auf Angular. PHP 7 auf 8 war für die meisten Codebasen, die ich gesehen habe, ein Sprint und kein Projekt.
Die Kosten liegen hier darin, dass PHP das Gegenbeispiel selbst geliefert hat. PHP 6 wurde angekündigt und nie ausgeliefert. Die 5.x-Jahre zogen sich, und bei der Migration auf PHP 7 sind sehr viele Codebasen stehen geblieben, von denen etliche bis heute laufen. Der verlässliche Rhythmus ist ein Jahrzehnt alt, nicht drei. „Das PHP, an das sich die meisten erinnern“ gibt es, weil ein Upgrade früher wirklich schlimm war, und ein Jahrzehnt guten Verhaltens löscht die Erinnerung an das Jahrzehnt davor nicht. Es macht den Plan nur ab jetzt glaubwürdig.
Skalierung: Der Boden, nicht die Errungenschaft
Die dritte Anforderung ist die, die Volker als Erfolgsbilanz beim Skalieren beschrieben hat, und dazu muss ich am wenigsten sagen, weil der vorige Artikel das Argument schon gemacht hat: Das Shared Nothing-Ausführungsmodell mit Request Scope gibt dir Fehlerisolation pro Request und horizontale Skalierung als Standard. Andere Ökosysteme setzen diese Eigenschaften aus Frameworks und Betriebsdisziplin zusammen. In PHP sind sie der Boden, auf dem alles steht.
Die öffentlichen Zahlen halten keine Überraschungen bereit. Stand 15. August 2026 nennt W3Techs für PHP 70,3 % der Websites, deren serverseitige Sprache bekannt ist; danach folgen JavaScript mit 7,2 % und Ruby mit 7,0 %. Diese Zahl ist kein Argument dafür, dass PHP gut ist. Sie ist ein Argument dafür, dass die Frage nach der Skalierung empirisch beantwortet ist, über eine große Bandbreite von Workloads und über lange Zeit, und dass dich daran im dritten Jahr nichts überraschen wird.
Die Kosten sind dieselben wie zuvor: Skalierung nach außen ist gelöst, Skalierung innerhalb eines Requests nicht. Das bleibt der offene Punkt, und deshalb wiegt die Lücke bei der Nebenläufigkeit schwerer als die beim Pattern Matching.
Lieferfähigkeit: Schnell ist leicht, nachhaltig ist die Anforderung
„Projekte schnell rausbringen“ ist die Behauptung, der ich am wenigsten traue, wenn ich sie über PHP höre, denn sie war immer wahr und war nie die ganze Geschichte. Genau diese Geschwindigkeit hat die Codebasen hervorgebracht, zu deren Modernisierung ich gerufen werde. Die Behauptung, über die es sich zu reden lohnt, ist die zweite Hälfte von Volkers Satz: schnell und nachhaltig.
Was die zweite Hälfte plausibel macht, ist nicht die Sprache. Es ist die Infrastruktur um sie herum, die alt, langweilig und interoperabel ist. Composer hat Dependency Management einmal und richtig gelöst: ein Resolver, ein Lock-File und reproduzierbare Installationen. Packagist indiziert inzwischen rund 460.000 Pakete in 5,7 Millionen Versionen, mit etwa 189 Milliarden Installationen seit 2012, und ist damit nach npm und PyPI die drittgrößte Paket-Registry überhaupt. Die Werkzeugkette für Qualität, also PHPUnit, PHPStan, Psalm, Rector, Infection und php-cs-fixer, ist ausgereift, weit verbreitet und dafür gebaut, in derselben Pipeline zu laufen.
Die wertvollste Eigenschaft dieser Werkzeugkette ist ihr Alter. Ich veröffentliche PHPUnit seit 26 Jahren. Bei Werkzeugen dieses Alters sind die Konventionen geklärt, die Sonderfälle gefunden und die Integrationen geschrieben. Wer 2026 ein PHP-Projekt beginnt, muss nicht entscheiden, wie getestet wird, wie Abhängigkeiten festgeschrieben werden oder wie statische Analyse in der CI läuft. Diese Entscheidungen wurden vor Jahren getroffen, ausdiskutiert und vereinheitlicht, und sie kosten heute nichts mehr.
Die Kosten, und das sind die eigentlichen, liegen darin, dass nichts davon automatisch passiert. Dieselbe niedrige Hürde, die ein Projekt in zwei Wochen in Produktion bringt, erlaubt es einem Team auch, jedes einzelne dieser Werkzeuge zu überspringen und trotzdem auszuliefern. Schnell und nachhaltig sind zwei verschiedene Eigenschaften, und die zweite ist eine Frage der Disziplin und nicht des Sprachdesigns. Das Ökosystem macht diese Disziplin leicht verfügbar, und sie bleibt eine Entscheidung, die jemand im Team treffen muss.
Fachleute: Personal als nichtfunktionale Anforderung
Die letzte Anforderung ist die, an der sich entscheidet, ob ein System seine zweite Wartungsgeneration überlebt: Findest du jemanden, der so etwas schon einmal gemacht hat?
Knapp sind nicht die Leute, die die Syntax kennen. Knapp sind die, die ein System zehn Jahre am Leben gehalten haben, ein Major-Upgrade eines Frameworks durchgezogen haben und wissen, wie eine langsame Query um drei Uhr nachts aussieht. An diesem Maßstab gemessen ist der Pool in PHP tief. The State of PHP 2025 von JetBrains, basierend auf 1.720 Personen, die PHP als ihre Hauptsprache angegeben haben, berichtet, dass 88 % mehr als drei Jahre Erfahrung haben, mit der größten Einzelgruppe zwischen sechs und zehn Jahren. 89 % arbeiten mit PHP 8.x. 58 % haben nicht vor, zu einer anderen Sprache zu wechseln.
Und hier ist dieselbe Zahl andersherum gelesen, was die ehrliche Lesart ist: 88 % mit mehr als drei Jahren Erfahrung heißt, dass kaum mehr als eine von zehn Personen weniger hat. Ein Pool, der erfahren ist, weil er nicht nachgefüllt wird, ist etwas anderes als ein Pool, der erfahren ist und wächst. Ich weiß aus diesen Daten nicht, welchen von beiden PHP hat, und ich vermute, das weiß sonst auch niemand. Der übergeordnete Bericht, aus dem die PHP-Zahlen stammen, beschrieb PHP als langfristig im Rückgang, während der PHP-spezifische Bericht ein stabiles und sich entwickelndes Ökosystem beschrieb, ein Widerspruch, den JetBrains nie aufgelöst hat. Beide Lesarten lassen sich aus derselben Umfrage vertreten, und das ist ein guter Grund, diesen Punkt locker zu halten.
Sicher sagen lässt sich etwas Engeres, das trotzdem nützlich ist: Für das nächste Jahrzehnt ist die Besetzung eines PHP-Systems ein gelöstes Problem, und die Leute, die dafür zur Verfügung stehen, sind ungewöhnlich erfahren. Was danach kommt, ist eine Frage, die das Ökosystem laut stellen sollte, statt sie mit Marktanteilsdiagrammen zu beantworten.
Wo wir stehen
Die beiden Checklisten messen Verschiedenes. Die von Rhombus sagt dir, ob eine Sprache gut ist. Diese hier sagt dir, ob es sicher ist, ein Jahrzehnt auf sie zu wetten. Über den Wiedereinstieg wird anhand der zweiten Liste entschieden, und deshalb kann eine Sprache auf der ersten vier von fünf Punkten erreichen und die Entscheidung trotzdem verlieren, und deshalb gewinnt PHP laufend Entscheidungen, für die es keine Anerkennung bekommt.
Auf der zweiten Liste sind die Antworten von PHP stark und nicht ohne Einschränkung. Niemand kann es neu lizenzieren, und seine Lizenz hat sich in denselben Jahren in Richtung weniger Einschränkungen bewegt, in denen die Branche in Richtung mehr Einschränkungen ging. Zugleich ruht ein großer Teil der bezahlten Wartung auf einer schrumpfenden Sponsorenbasis, und die Wählerschaft umfasst etwa 140 Personen. Upgrades kommen nach einem veröffentlichten Zeitplan und sind größtenteils mechanisch; der Zeitplan ist zehn Jahre alt, nicht dreißig. Nach außen skaliert PHP von Bauart, innerhalb eines Requests noch nicht. Projekte liefert es schnell aus, und ob es sie nachhaltig ausliefert, liegt am Team. Getragen wird es von wirklich erfahrenen Fachleuten, und wer hinter ihnen nachkommt, ist eine Frage, die niemand beantwortet hat.
Nichts davon hat von mir verlangt zu argumentieren, dass PHP lebt. Es hat nur verlangt, die Kriterien aufzuschreiben und anzuwenden, nach denen in der Architektur tatsächlich entschieden wird, und dabei eine Lücke ebenso bereitwillig festzuhalten wie eine Stärke. Das ist auch die Fassung der Antwort, die am Stand nützlich war. „PHP ist in Ordnung, schau in die Release Notes“ überzeugt niemanden, der die Entscheidung vor einem Lenkungsausschuss vertreten muss. Eine Liste dessen, was zugesichert ist, was wahrscheinlich ist und was offen ist, überzeugt.
Volker ist selbst als Mitwirkender im RFC zu den Deprecations für PHP 8.5 aufgeführt, ohne dass ihn jemand dafür bezahlt. Das ist der Mechanismus, den er beschrieben hat, in Betrieb, in der einzigen Form, auf die es ankommt: Jemand, der die Sprache verwendet, ist aufgetaucht und hat sie geändert.
