The Past, Present and Future of the PHP-FIG

The PHP Framework Interoperability Group (PHP-FIG, or just FIG for short) is at a crossroads. Many electrons have been sacrificed talking about FIG’s tribulations of late, but sadly much of it has been FUD, with little effort spent on the positive. At SitePoint’s invitation, I’d like to offer a more positive outlook on FIG and the PHP community, and demonstrate why FIG can, and should, continue to have a positive impact on the PHP ecosystem.

By way of introduction, I am the FIG representative for Drupal and have been continually since November 2009, just shy of 7 years now, making me one of the longest-running FIG representatives. I was the Editor of PSR-6 and the current Editor of PSR-13, and also helped on the PSR-3 and PSR-7 specifications in particular. Along with Phil Sturgeon I helped design the current FIG workflow for PSRs. On the Drupal side, I was one of the main drivers behind Drupal 8 adopting PSR-0 and PSR-3.

Key Takeaways

• FIG, initially criticized and sidelined, has evolved into a crucial standards body for PHP, impacting the broader community and fostering interoperability across diverse projects.
• The introduction of PSR standards has significantly influenced PHP development, with standards like PSR-0 enabling tools like Composer, and others becoming defaults in development environments.
• FIG’s structural evolution, including the shift from a chaotic beginning to a more structured organization with clearly defined roles and processes, underscores its maturation and increasing influence in the PHP community.
• The proposed FIG 3.0 aims to further democratize the process, allowing broader participation and ensuring that standards are informed by those directly impacted by them, not just project leads.
• Despite some opposition, the trajectory of FIG suggests a movement towards greater inclusivity and effectiveness in standard setting, which could continue to shape PHP development positively.

An Uncomfortable Beginning

FIG was founded in 2009 under the name “PHP Standards Group” after an initial meeting at php[tek] in Chicago in May. Initially it was setup with a mailing list at standards@lists.php.net, with the purported goal of establishing its first spec — the PSR-0 autoloading standard — and presumably others as community-wide standards.

The unsurprising “who do you think you are?” backlash to that presumption was swift and decisive, and the group was quickly thrown off of lists.php.net, instead setting up a Google Group for coordination. Little else was done by the PHP Standards Group for the next few years, other than admitting a few additional people/projects in late 2009 (including yours truly, representing Drupal). The PHP Standards Group hadn’t yet earned the right to call itself that in the eyes of the community.

Slow but Steady Growth

Fast forward to October 2011. After being completely dead for 2 years, the group started to come alive again. It renamed itself to the hopefully-less-controversial “Framework Interoperability Group”, although it still had no effective bylaws nor a defined mission statement, working instead on “whatever we decide to work on.” Among the specs that were tackled in that period were the PSR-1 coding standards, PSR-2 coding style standards, and PSR-3 logging interface.

There was some debate around whether interfaces were even “fair game” for FIG to define, since it had no mission statement. Therefore, in March 2013 I ran a poll to gauge whether those involved in FIG (both project members and otherwise) favored “soft specs” (like coding standards) or “hard specs” (like interfaces), and the results came back solidly for “all of the above, but with lean toward interfaces”. A similar poll, shortly afterward, showed a modest lean toward forward-looking but practice-informed specs (rather than “only document what’s been done” or “build new stuff from whole cloth” extremes).

Despite the “framework” in the name, FIG was also never limited to just “framework-ish” projects. Aside from being an extremely ill-defined word to begin with, FIG’s membership quickly grew to the point that pure-framework members were a decided minority alongside stand-alone libraries, CMSes, Wikis, e-commerce suites, and other stand-alone applications. The benefits of collaboration and interoperability are not limited to “frameworks”.

Participation in FIG was also ill-defined. The initial founders were mostly project leads, but not entirely. Early on, there were many debates on whether members were “people” or “projects”; that is, were FIG members ambassadors acting on behalf of their projects, or were they simply people determined “cool enough” to have a vote for life by virtue of happening to lead a project? That was put to a vote in April 2013, and the bylaws clearly amended to make voting representatives ambassadors on behalf of their project. Despite the clear result, a select few refused to acknowledge that decision and act as though it never happened; there was some validity to their claim as in practice one is always interacting with a person, not with a “project”, and humans are humans, but the group and the bylaws had spoken.

Another issue that arose was the ownership of a spec in development. Technically no one was responsible for anything, so multiple specs (those which became the PSR-4 autoloading standard and the PSR-6 caching standard) had multiple competing versions from different people and no one could keep track of which was the “real” version. Clearly that was suboptimal.

In July of 2013, therefore, the group adopted a new workflow bylaw, authored primarily by Phil Sturgeon and myself, which defined a clear Editor, Coordinator, and Sponsor for a PSR in draft, creating the skeleton of a working group. Under that model, the group passed the PSR-4 autoloading standard, PSR-6 cache standard, and PSR-7 HTTP messaging standard.

A Community-Wide Impact

The various PSRs that FIG has published have, of course, impacted the PHP community far beyond the handful of member projects. Defined standards in a vacuum have a way of doing that.

• PSR-0 was a key enabler for Composer, which has transformed the PHP ecosystem.
• PSR-1 and PSR-2 together are now a preset in many IDEs, which makes them the default coding standard for nearly all PHP projects (except a select few with massive code bases that predate PSR-2, for whom switching is impractical despite pressure to do so).
• The PSR-3 logger has been installed, according to Packagist, over 37 million times. For PSR-7, it’s around 11 million.
• The PSR-7 HTTP messaging standard has spawned a cottage industry of experimentation with HTTP middleware that has already been adopted to some degree or another by many if not most major projects.

Despite its contentious beginnings, FIG has effectively become the standards body for PHP. It took time for it to earn it, but it did, thanks to the work of dozens of people, both FIG members and not. A Reddit thread started last January showed that, while not universal, there was a clear preference for FIG to step up and accept that role formally.

Today, FIG has a number of specs in various stages of development, ranging from just-getting-started to nearly-complete, including:

• PSR-9 (background) and PSR-10 (background) – Security reporting and automated security advisories.
• PSR-11 (background) – Dependency Injection Container interoperability.
• PSR-12 (background) – Revised coding standards to take PHP 7 into account.
• PSR-13 (background) – Hypermedia link handling.
• PSR-14 (background) – Event manager/dispatcher.
• PSR-15 (background) – HTTP Middleware for PSR-7.
• PSR-16 (background) – A simplified, simple-case cache interface (designed to easily wrap PSR-6).
• PSR-17 (background) – HTTP Factories for PSR-7.

Most of the Editors of those proposals are not themselves FIG members. Whatever the intent of the initial half dozen people, FIG has long since grown beyond its humble beginnings.

Growing Pains

Nevertheless, FIG’s internal process hasn’t grown up with the group as well. Initially modeled on the free-for-all chaos of PHP-Internals, it has adopted process as needed. (Although it might be more accurate to say that it initially wasn’t modeled on anything other than “we haz a mailing list”.) Many people in recent years have pointed out FIG’s structural issues.

• Being a project lead doesn’t necessarily make someone the best at designing standards, whether interface standards or more “soft” specs.
• Most project leads, or their representatives, have plenty of things on their plate besides FIG and so frequently pay attention only during votes, even if then. Several votes have failed simply due to lack of quorum, and many mundane administrative tasks simply went unaddressed as no one knew who was supposed to even do them.
• Although the single Editor makes for a clear point-of-authority, that person may not be the only, or best, authority on the topic of a given spec. In an ideal case, many people directly involved in or impacted by a spec would have an equal seat at the table.
• The process is still too opaque to outsiders, and even to some insiders. It’s sometimes difficult to tell where to get involved in a given spec, as there’s no consistency at all.
• The membership rules still privilege project leads over anyone else; the PHP community has dozens upon dozens of smart, skilled developers who would be valuable to have working on specs, but because they’re not a project lead or a lieutenant of a project lead, they’re never allowed a vote.
• Despite that, the idea that FIG’s work impacts only member projects has become, as shown above, almost comically naive. Yet only a select few are even welcome at the table.

In late 2015, FIG added a 3-person Secretary position, elected by project reps, to handle managerial tasks but stay out of technical tasks. I personally feel that change has been a resounding success, as managerial tasks are actually getting done now, and the secretaries have been able to help standardize and formalize much of the necessary paperwork around creating specs. (There’s more to it than just talking a bit!) Still, though, FIG is incomplete.

That came to a head in December 2015 and into January, with several threads discussing FIG’s various shortcomings. I tried to draw them together into a broader view of the “State of FIG” in mid-December, which spawned a lengthy but lively conversation, largely with agreement on the problems. That included discussion of the process followed by other standards bodies, including ISO and IETF. That, in turn, led me to post, in mid-January, a proposal concept inspired by IETF that I dubbed “FIG 3.0”. (FIG 2 being the Editor/Coordinator/Sponsor model from 2013, FIG 1 the total free-for-all before that.) I encourage those who are interested in the subject to read at least the start of those threads for background.

The proposal met with widespread approval, although not universally so. I therefore set about turning the brain dump into a more formal change to the bylaws, with a great deal of help from Michael Cullum, which was posted to the list in April.

FIG 3.0

The full proposal is viewable in the pull request, and Michael has written a very good summary of its major changes. I will summarize them only briefly here.

First, and most importantly, it adds a for-reals mission statement to FIG:

The PHP Framework Interoperability Group (The PHP FIG) aims to advance the PHP ecosystem and promote good standards by bringing together projects and people to collaborate. It develops and publicises standards, informed by real-world experience as well as research and experimentation by itself and others, to form PHP Standard Recommendations (PSRs).

That is not actually a new concept. It is formalizing, in writing, what FIG is already doing and has been for some time, and supported by the polls conducted previously.

Second, Working Groups become larger with a minimum size of 5. Those Working Group members can be project-affiliated or not, but are intended to be those with a direct stake in a given spec. Cache library authors for a caching library, for instance, or asynchronous library implementers for a PSR on Promises. Those directly-impacted people have a clear “seat at the table”, and a vote in the Working Group itself before a PSR is approved, even if they’re not a member project. Moreover, the final vote cannot happen until there are at least two implementations in existence that demonstrate that a proposal is both viable and likely to be adopted by someone. This change is derived directly from IETF.

Third, the final vote on the spec, after the Working Group is done with it, is handled by an elected 12-person Core Committee. The Core Commitee’s job is to maintain consistency and excellence in all of FIG’s work, balancing both established patterns and forward-looking developments, and act as semi-outside reviewers of the Working Group’s efforts. They may be project representatives or not; that opens up FIG participation even further to the many experts in PHP who are not project leads. Moreover, they are elected not just by project representatives but by anyone who has been actively involved in FIG; that includes all Working Group members, who may or may not be project representatives.

The project representatives, then, need only be involved at select times for voting on the Core Committee and when their project is relevant to a Working Group, which they can then join. If not, then their silence or uninvolvement doesn’t impact quorum or otherwise hinder the development of a spec that’s irrelevant to them anyway.

The Secretary position continues essentially unchanged; The Core Committee and Secretaries are peers, equals handling different parts of FIG. The Secretaries keep the machinery working while the Core Committee provides both technical oversight for the Working Groups and an “outsider’s view” to a given spec.

That addresses, I believe, most of FIG’s structural challenges today while creating an environment in which the PHP community can work more efficiently and effectively to everyone’s benefit.

Too visionary?

Although the proposal early on met with broad approval, it has more recently met with some opposition. The primary objection is that it is “too far” from FIG’s original purpose, and it should either therefore be abandoned or used as the foundation for a new group, possibly with FIG itself shutting down in response. Paul Jones in particular has repeatedly declared that it is against the “founding vision” of FIG, which was exclusively to standardize existing practice for member projects only.

However, the “founding vision” of the PHP Standards Group, according to the moderator of the original meeting where it was founded, was for a closed group without public involvement. At the same time, influencing new, not-yet-created, not-member projects was clearly a goal:

I would love it if the first comment on blog posts or mailing list messages announcing the new code is “wow, that’s great, but you should run it through phpcs.”

The first non-test post to the list, from David Coallier, stated unambiguously:

Each project may have specific standards which may extend and further define how these standards should be used, but the goal being a set of PHP standards provided as a resource for all PHP developers.

(emphasis added) and

A central, moderated mailing list to discuss PHP coding standards was proposed, to be hosted on lists.php.net. The list shall have public archives and unmoderated posting privileges will be granted by election by those with posting privileges. Each major project may have more than one member, but each project shall have only 1 vote towards standards decisions and membership.

(emphasis added).

It was only after the backlash, on the original php-standards list and elsewhere that the party line shifted to be “just for us”. However, if we want to look for the founder’s vision, there it is: A closed list creating standards “as a resource for all PHP developers.” And nowhere in those statements is there a claim to only standardize “what has already been done”.

The closed list idea was abandoned very early. The “just for us” line was mostly a defense against the (valid) accusations of over-reach. And no mention whatsoever of being only backward-looking.

Clearly to claim the vision of “the founders” was strictly a backward-looking, for-us-only organization is revisionist history.

A new group?

A number of people have proposed that the FIG 3 changes should not be adopted by FIG, but by a newly-created organization instead. The argument goes that FIG’s job is done, and a new group would be able to proceed without any of the karma that FIG has accrued, good or bad. That too, I feel, is an odd argument to make.

Today, FIG has no mission statement. So how can it be declared “done”? There’s no acceptance criteria defined! The closest we have is an entry in the FAQ on the website, which states FIG exists to “talk about the commonalities between our projects and find ways we can work together”. Given the number of PSRs in some stage of development right now, there still seems to be plenty to talk about.

Any good karma that FIG has built up over the past 7 years is not the property of a select few. It is the result of the blood and sweat of everyone that has worked on any spec that had been adopted and is in use, both project reps and not, everyone that has talked up FIG at conferences or in their projects, and everyone whose developer lives have been made better by FIG’s work. Most of those people were not founders of the group. In fact, most of the original founders stopped being active in FIG long ago.

Conversely, any bad karma that FIG has built up won’t magically go away by using a different name for a new group. If it’s obviously a continuation of FIG (which to anyone who cares it would be), few FIG detractors are going to suddenly reset their opposition to it. And those whose issue isn’t with FIG but with select members of FIG would only care whether or not those individuals are involved.

Could a new organization work? As long as FIG itself shut down and publicly stated that the new organization was its successor, it probably could. That seems an excessive amount of rigamarole and politics just to protect a fictional “vision”, however.

The worst case scenario would be for a new group to form yet FIG not shut down. Then PHP would end up with two competing standards bodies, which rather defeats the purpose of having a standards body.

Conclusion

FIG has had a tumultuous history, to be sure. However, is history has a very clear trajectory: toward more community participation and toward a more robust structure to support such participation. Its founding as “the PHP Standards Group” included publicly stated goals of being of use to the entire PHP community. In practice, it cannot be otherwise; PHP projects are no longer islands, so standards adopted by many projects eventually have an impact on almost all projects. The entire concept of interoperability cannot succeed if only member project “cool kids” adopt them.

FIG 3 is the next step in that evolution, and an important one. FIG has, over the last 7 years, earned a place as the de facto PHP Standards Group. It’s time for FIG to embrace that reality and help build a better PHP ecosystem for all.

Frequently Asked Questions about PHP-FIG