The history and evolution of PHP governance

The PHP language is widely used in solving some of the most interesting technical problems on the web. But for a language with widespread use, it is unique — or at least an outlier — in the way it's governed compared to other open-source projects. Unlike others, PHP governance has grown into something fairly democratic for a project its size, allowing almost anyone to bring an idea to the table. If it's popular enough, that idea can find its way into a future release. That is, of course, as long as there is a developer to put in the work to make it happen. Understanding the governance of the project can help answer questions on why things are the way they are, and add context to the challenges the project will face in the future.

The early days of PHP governance

Looking back to the early 2000s, as was true for many open-source projects at the time, the governance and direction of the project was largely dictated by the simple concept of what has been known in the PHP community as "karma". That is to say, the more contributions you made to the project the more clout you had when it came to deciding which features made it into a release. Especially early on, there was little to no gatekeeping when it came to handing out repository credentials to people who wanted to contribute something interesting. If a developer wanted to add something, the biggest barrier was often only having the technical understanding to do so correctly. A good example of this is SimpleXML, which provides object-oriented mapping of XML documents. The experimental implementation of that feature more or less just appeared in the code base one day without much of any discussion at all. Back in the early 2000s, if you knew how to do it and it seemed reasonable, most of the time your code made it into a release.

From the beginning, PHP was a language born of an itch to scratch. Solutions, rather than concerns over consistency or academic purity, have always been a main goal of the project. This show-me-the-code approach can certainly be credited for the vibrant community at work on the project still today, but it has also led to plenty of problems in regards to governance.

Sidestepping the occasional argument over a relatively minor commit in the early days, the first real struggles PHP had was around the time of the release of PHP 4 with the introduction of the Zend Engine. Written by contributors Zeev Suraski and Andi Gutmans, it replaced the implementation of the language found in PHP 3 with a more robust engine and API for PHP 4. By itself, the value of the contribution to the project is undeniable. However valuable, the engine and control over it quickly became a point of conflict with the community as those same two developers founded Zend Technologies in order to sell closed-source technology for PHP based on the open-source engine they introduced to the language.

The contribution itself rocketed Suraski's and Gutmans's standing in terms of clout when deciding the future direction of the language, but it left many of the other contributors uncomfortable. For starters, especially early on, the number of people who even understood the engine's implementation was limited and documentation was scarce. Perhaps more significantly was that Zend's product line included features that arguably belonged in the language, such as debugging and performance enhancements. These circumstances caused a certain amount of resentment among other community members as they started to get the impression that the two developers were preventing features that competed with their commercial offerings from getting into the open-source code base.

This feeling of the project being run by benevolent dictators with commercial interests rose to the point that a significant portion of the contributors began secret discussions on how to separate themselves from Zend through a fork in 2002 — the effort fell apart after Suraski discovered it. Rather than a fork, by 2003 two new projects started to provide open-source alternatives to Zend's offerings: xdebug to provide debugging services and APC, which cached the compiled form of PHP code between requests.

In the years since, there have been multiple efforts to integrate these technologies into PHP's core and none of them have been successful. Today, the xdebug project is still alive and well, continuing to be maintained by its original author, Derick Rethans. As for APC, Zend released as open-source its implementation of the caching and optimization technology called opcache ten years later in 2013, at which point it was promptly bundled into the language and released as part of PHP 5.5; this effectively ended the need for the APC project altogether.

Things have changed significantly, and arguably for the better, since those tense years. As PHP has matured both as a language and project, it has moved away from the haphazard practices of the past and adopted a Request For Comments (RFC) process to govern the discussion of how new features, both ideas and implementations, are brought into the language. The original RFC process itself is nothing new and roughly ten years old, but looking back, its impact has been remarkably positive. Recently a number of changes have been made by the community to improve the process, which makes it worth examining.

The RFC process

The basic steps for getting new code into a PHP release via the RFC process are fairly straightforward today — the first step is to document the proposal in the RFC section of the PHP wiki, followed by sending an email to the Internals mailing list. It is strongly recommended a preemptive e-mail to Internals be sent before a proposal is written as well, in order to ensure time is not wasted on something that isn't fundamentally viable. The matter is discussed (or not) for a minimum of two weeks, changes made as necessary to the RFC, and ultimately the author of the RFC opens the issue up for a vote or the RFC is withdrawn. If the measure passes, then a new thing in the PHP community is approved. If not, there are opportunities to try again in the future.

Since RFCs can be anything from a new feature to procedural changes, what happens next depends on the RFC. For code changes, a working implementation prior to the RFC being accepted is strongly preferred but not a hard and fast requirement if being proposed by an established contributor. For RFCs from less known contributors, patches would be reviewed by the community during the RFC process prior to voting. RFCs from less known contributors without a patch or that give the impression someone other than the proposer is going to be doing the work for them have little chance for success. For procedural changes, upon approval the official relevant documentation is updated to reflect the new policies.

The devil, of course, is in the details. Who gets to vote, and what constitutes a passing majority are both questions whose answers have evolved in recent times.

When it came to how a RFC is accepted, originally there were two different sets of criteria depending on the subject. RFCs that affected the language itself (such as a new syntax) required 2/3 of the voting population in favor of the change, while anything else (such as adding a new function) required a simple majority. In PHP governance, the total voting population is defined by who shows up to vote rather than a well-defined population. In terms of a supermajority for an RFC to be approved, the number of "yes" votes must be greater than or equal to the number of "no" votes multiplied by two. This means a vote could have ten or a hundred participants, and the number of participants has historically been an indicator of how contentious the subject of the RFC is in the community.

These rules, specifically the concept that so many decisions could be made by a simple majority, has been something that has bothered members of the internals community for quite some time and a RFC to remedy it was introduced in 2016. That RFC laid largely dormant however until 2019. The issue finally came to a head in early 2019 when contributor Joe Watkins took issue with Suraski's perceived abuses of the simple majority clause in an echo of the conflicts of old. On the internals mailing list, he accused Suraski of abusing the spirit of the rules:

In the end the RFC to remove simple majorities for future RFCs won adoption, with a clear majority of thirty in favor and two against. Suraski was one of the two opposed to the measure; he wrote at the time:

Interested readers can examine the exact changes to the RFC procedure that resulted. In short, under the new rules, all RFC votes require a 2/3 majority of participants in the vote, effectively preventing changes from passing with a slim majority. If a RFC meets the 2/3 overall majority criteria, simple majority votes are allowed for related items within that RFC (such as implementation details of a feature).

As for who has the right to vote on RFCs, PHP only requires a GitHub account and code contributions to the project, with no limitations on when those contributions were made. Exceptions are made to grant voting rights to developers of large projects using the PHP language but not necessarily involved in internals. This means the PHP project's nearly 2,000 contributor accounts may qualify as potential voters on any given RFC. As a result, language features and procedure changes are generally decided by those who show up to cast their ballot. Generally speaking, a random sampling of accepted RFCs hint that relatively simple measures like a new function have between 20 to 30 participating voters, while more meaningful changes like anonymous classes had 52 votes cast.

Democratic coding

This democratic approach to language features for PHP has its benefits. A relatively low bar of entry helps encourage new contributors while making sure the evolution of PHP doesn't stagnate. Where in a top-down organizational structure momentum depends on the those at the top to advance the project, PHP's governance rules are set up in such a way that any of a large group of voters could conceivably reach the 2/3rd of votes needed.

Guard rails of sorts still exist, although less officially now, through the contributions of longtime internals community members who hold significant abilities to influence opinion during discussions. When compared to the governance of PHP before the RFC process, that influence is now much farther from absolute. Earlier we saw how this was true in procedural matters, but even for major language features it holds true. One example is the implementation of Scalar Type Declarations introduced in PHP 7, where even PHP founder Rasmus Lerdorf and other prominent contributors were overruled in a vote of 108 to 48 after heated debate.

In the final analysis, PHP governance continues to be a messy endeavor with various camps of thought on how the language should move forward at constant conflict with each other. The RFC process has done a great deal to democratize these conflicts and move away from the benevolent dictator approaches of the past, but little to remove the conflicts themselves. One welcome thing it does provide is a clear path for new contributors to make small contributions, such as a single useful function, and succeed in seeing their ideas make it into releases without a great deal of turmoil. For the contributor who is looking to become involved in heavier project decisions however, they will still find it to be at times a discouraging process and should expect to defend their ideas when attempts are made to tear those ideas asunder by more seasoned contributors.

Ultimately as messy as it is (as democracy can be), PHP governance's track record speaks for itself in its continued production of important and useful code. While PHP governance has dramatically improved over the years, it is unlikely to ever fundamentally change from the bare-knuckle exchange of ideas course it began with — merely simply refine it. As Lerdorf has said, "Ugly problems often need ugly solutions because the pretty solution is sometimes just too much of a hassle for everyone involved." At the time Lerdorf wasn't speaking about governance, but at least when it comes to the PHP project the sentiment continues to have influence today.