PHP settled an important governance question in November 2025: an RFC cannot be hurried from a lively rewrite into a ballot just because its author has run out of patience. By a vote of 24 to 6, with one abstention, the project accepted rules that formalized a minimum discussion period, required notice before voting, extended the clock after material changes, and kept vote endings out of the year-end holiday window.[1]

It did not settle the question underneath the ballot: who, exactly, belongs to the electorate? The operative voting document still describes a population rooted in old php.net version-control accounts, plus selected representatives of the wider PHP community. A 2024 proposal would replace that inheritance with explicit active and emeritus rolls, but the proposal remains marked Draft.[2][3]

That asymmetry is PHP's most revealing maintainer signal in 2026. The project has made the tempo of language change more legible without yet making membership in the decision-making body equally legible. Meanwhile, The PHP Foundation now pays enough core developers to affect what work can be attempted, even though the Foundation explicitly disclaims control over language decisions.[4] PHP therefore has three different kinds of power in view: time to do the work, procedure to test a proposal, and standing to cast a vote. They overlap in people, but they are not the same thing.

The cover photograph shows PHP creator Rasmus Lerdorf at a 2014 community conference.[7] It is not a photograph of a governing body. That is precisely why it fits. PHP's authority accumulated through contributors, mailing-list arguments, repository access, implementations, and gatherings long before anyone could point to a modern foundation or a maintained voter register.

The new clock turns custom into a public promise

The 2025 process RFC began from an awkward admission: PHP's written policy no longer matched the process experienced contributors expected. Important practices were being upheld as custom, leaving newcomers to discover them during conflict and giving participants room to argue that an underspecified rule permitted a faster path.[1]

The accepted update made that tacit protocol inspectable. Every RFC now gets at least two weeks of discussion, including proposals that do not directly alter language syntax. A significant edit requires more time for review. The author must announce substantive changes to the Internals list, send an intent-to-vote notice before opening the ballot, and include the relevant discussion and voting archives. The policy also accounts for stale discussion and the end-of-year period, when an apparently open ballot can in practice exclude people who are away.[1]

These are not decorative meeting rules. An RFC may define a new operator, alter type behavior, deprecate an API, or move a compatibility cost into the next release. If the text changes late, a voter may be responding to yesterday's contract. If discussion happened in a thread that the RFC does not link, a future maintainer cannot easily reconstruct why a tradeoff was accepted. The cooldown creates time for extension maintainers, tool authors, framework developers, and implementers to notice consequences before a Yes or No freezes the proposal's public meaning.

The vote on the process update demonstrates another useful property: procedure had to pass through the procedure it was revising. Six people opposed it and one abstained; acceptance was not presented as effortless consensus.[1] That dissent does not weaken the rule. It leaves evidence that the community considered costs such as delay, author burden, and the difficulty of specifying every exceptional case.

The inherited voting policy supplies the numerical gate. A primary RFC vote needs a two-thirds majority: the number of Yes votes must be at least twice the number of No votes. Secondary implementation choices can use plurality once the main proposal clears its threshold. Voting must remain open for at least two weeks.[2] In effect, PHP now has both a review clock and a supermajority brake. One protects deliberation before a ballot; the other makes a narrow win insufficient for changing a language used far beyond the people in the thread.

The voter definition still points backward

The same voting document is much less exact about the denominator. It names two eligible audiences: people with php.net VCS accounts who have contributed code, and community representatives chosen by those account holders, such as leaders of PHP-based projects or regular Internals participants.[2] That description conveys intent, but it does not provide a current roster, an activity threshold, or a routine admission and removal process.

This is not a new criticism manufactured from outside. The draft Who Can Vote RFC says the original VCS account system has fallen out of use and that its proposed community-representative path never became a practical route into the electorate. Its remedy would initialize an active roll from roughly 140 people who voted between August 2021 and August 2024, place roughly 1,650 older account holders on an emeritus roll, and let active voters nominate new members through a seconded, public process. Inactive voters would move to emeritus status after three calendar years without a vote.[3]

Those numbers describe a proposal, not the current constitution. The page is still a draft, has no recorded ballot, and deliberately leaves the substantive criteria for admitting people to the future membership itself.[3] Treating its roster design as adopted would erase the very governance distinction the proposal is trying to create.

LWN's 2020 history of PHP governance helps explain how the project arrived here. Repository credentials were once distributed with little gatekeeping, then became the basis of voting eligibility as the project adopted an RFC process and moved away from founder-centered decisions. Participation in consequential ballots was much smaller than the universe of accounts that might be eligible, so practical authority often belonged to the contributors who showed up and defended a position.[6] That history produced working software and permitted prominent figures to lose votes. It also tied institutional memory to credentials created for a different era.

An explicit roll would not automatically make PHP more representative. Activity rules can remove dormant privilege, but they can also reward people whose jobs give them time to follow Internals. Nominations can widen the room, but an electorate that chooses its own successors may reproduce its existing network. A public list would at least make those tradeoffs measurable. Today, an observer can count votes on one RFC; it is harder to say who could have voted, who recently became eligible, or which parts of the ecosystem remain structurally absent.

Paid time changes the agenda without changing the ballot

The PHP Foundation adds a second governance layer because it converts donations into developer hours. Its 2025 transparency report records 11 contracted developers at the start of 2026, roughly 42% of commits to PHP core authored by Foundation developers during 2025, and 536 sponsors and individual contributors. The Foundation reported $730,534 in contributions, $645,191 received after fees, and $784,376 in expenses. It deliberately spent about $139,000 more than it received that year to preserve technical headcount while working on fundraising.[4]

Those figures show meaningful capacity, not ownership. The same report says the Foundation neither controls community decisions about PHP nor governs the language. Its contractors fix bugs, review code, work on security, implement features, and participate in RFC discussion as individual contributors.[4] A sponsor does not buy a ballot, and a Foundation board decision does not merge a language feature.

Still, formal neutrality should not be confused with zero influence. Paid time determines which difficult prototype gets written, which migration analysis reaches the mailing list, which neglected subsystem receives review, and which accepted idea has an implementer. In 2025, Foundation-funded developers supplied a large share of core commits; even when every RFC vote is procedurally independent, that labor changes the menu of proposals capable of becoming real.[4] This is an inference from the contribution data, not evidence of sponsor control.

The healthy version of that influence is visible agenda capacity. A contractor authors an RFC in public, discloses the design, waits through the same cooldown, responds to objections, and needs the same supermajority as anyone else. The dangerous version would be less dramatic than a corporate takeover: too few people with time to propose alternatives, review Foundation-backed work, or contest a direction before the ballot opens. Process legitimacy depends on funding enough maintenance while preserving enough independent attention to examine it.

One 2025 ballot makes the distinction concrete. Foundation contractor Gina Peter Banyard authored an RFC, with a working php-src implementation, to deprecate implicit type juggling to and from bool in function calls and typed properties. It received 10 Yes votes and 11 No votes and was declined.[5] Paid time carried a difficult compatibility proposal far enough to be specified, implemented, debated, and tested. It did not carry the proposal through the vote. That is stronger evidence of institutional separation than a mission statement alone.

The report's fundraising signal therefore matters. Sponsor participation fell substantially from the previous year, expenses exceeded receipts by design, and balancing spending with durable funding became a stated 2026 goal.[4] A reserve-funded year can protect continuity; it cannot be the permanent operating model. The Foundation must diversify and renew financial support without turning large donors into a shadow roadmap, while Internals must keep review capacity broad enough that paid implementation does not become approval by momentum.

What a stronger signal would look like

PHP's next governance improvement does not require replacing argument with a central technical committee. It requires finishing the accounting that the 2025 clock began.

First, the project needs an adopted answer to voter lifecycle, whether or not it resembles the 2024 draft. A useful policy would expose the active electorate, make admission attainable to current contributors, retire dormant standing without erasing history, and record removals and restorations. Second, RFC pages should continue to preserve discussion, amendments, implementation state, and final votes as one traceable chain. Third, Foundation reporting should keep separating paid output from formal language authority while showing sponsor concentration, contractor capacity, review work, and reserve use.

For downstream maintainers, the practical reading is simple. A Foundation announcement means resources are moving. An RFC marked Under Discussion means the contract can still change. Voting means the text has reached a defined decision window. Accepted establishes community approval, not necessarily a merged implementation. A release is the point at which users inherit the behavior. Collapsing those states into “PHP decided” hides who did what and when.

The falsifier for the optimistic view is also visible. If late RFC rewrites routinely escape fresh review, if the draft electorate question stays indefinitely unresolved, or if Foundation-funded work becomes difficult to challenge because independent review capacity shrinks, then the new clock will have formalized waiting without broadening legitimacy. If PHP can pair its explicit deliberation rules with an equally explicit voter lifecycle—and sustain the labor that makes proposals testable—it will have something better than tidy governance branding: a decision process whose time, work, and authority can each be inspected.

Sources

1. Tim Düsterhus, PHP RFC, “Clarify discussion and voting period rules” — accepted November 2025 with a 24–6 vote and one abstention; scope, cooldown, amendment, notice, archive, and holiday-window rules.
2. PHP Wiki, “Request for Comments: Voting on PHP features” — operative proposal initiation, voting duration, two-thirds primary threshold, secondary votes, and eligible-audience description.
3. Jim Winstead, draft PHP RFC, “Who Can Vote (2024)” — diagnosis of inherited VCS-account eligibility and the unadopted active/emeritus voter-roll proposal.
4. Elizabeth Barron, The PHP Foundation, “Impact and Transparency Report 2025,” May 27, 2026 — contractor, contribution, sponsor, financial, governance, and 2026 sustainability disclosures.
5. Gina Peter Banyard, PHP RFC, “Deprecate type juggling to and from bool type within the function type juggling context” — declined 10–11 in August 2025 despite a working implementation.
6. John Coggeshall, “The history and evolution of PHP governance,” LWN.net, June 2, 2020 — independent history of repository access, RFC voting, supermajority reform, participation, and contributor influence.
7. William Stadtwald Demchick, “Rasmus Lerdorf August 2014 (cropped),” Wikimedia Commons — archival photograph made at the New Zealand PHP Conference on August 28, 2014.