PHP-FIG Alternatives: The Pros and Cons of Various Visions

Many thanks to Cal Evans, Nate Abele, and Larry Garfield for peer reviewing this article. We appreciate our amazing peer reviewers for continuously making SitePoint content the best it can be!

(Disclosures: I am one of the founders of the FIG. Along with Nate Abele, I am the longest continuously-serving Voting Member in the group. I was the primary driving force behind PSR-1, PSR-2, and PSR-4; their wide adoption has contributed greatly to the legitimacy of the FIG. I am recorded as the coordinator or sponsor on other PSRs as well. I assisted in creating some of the bylaws that hypothetically guide the members of the group, including a prominent role in writing the voting rules themselves. I was the subject of the secretaries’ first, and currently only, temporary ban from posting to the FIG mailing list. I was also the subject of a failed attempt to have me removed from the group. I oppose the FIG 3.0 proposal to re-constitute the group in place.)

Alternative Futures

In his article The Past, Present and Future of the PHP-FIG, Larry Garfield gives a whirlwind tour of his impressions of the FIG, from its founding to one of its possible futures. I encourage you to read it in its entirety before continuing.

Herein, I will attempt to address some of the errors and omissions in Larry’s article, and offer two other possible futures for the FIG.

PHP-FIG 3.0: Too Revisionary?

I have stated elsewhere that what I have called the “founding” vision of the FIG was to focus on member projects, find commonalities among them, and codify those commonalities. Larry condemns my statement as “revisionist history” and asserts the true founding intent was more in line with what I have called the “grand” vision (that is, an overarching standards group for all PHP coders, member projects or not).

To support his position, Larry quotes David Coallier’s post of Brett Bieber’s meeting notes.

The goal of this meeting was to develop a set of common standards which PHP projects can strive towards adopting.

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.

Larry also draws from Travis Swicegood saying something similar. I will quote a little more of Travis’s post than Larry did:

Below is what my vision is. It’s my vision and mine alone, but this is where I’m coming from. … I’d love to see an officially sanctioned standard come out of our work. … When code is published for public consumption in a year, 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.”

At first, this appears to be substantial evidence of Larry’s claim. However, one should remember that a “goal going into” a meeting is not the same thing as a “result coming out of” a meeting.

So it may well be true that some of the participants had something more like the “grand” vision in mind when they first arrived. But, having been at that initial meeting myself, I personally recall the decision by the end was not to pursue the “grand” vision. Instead, it was to adopt the more limited, “for the group members” approach.

To provide more support than my own memory of the discussion, I submit the following:

• Travis himself says in the same post linked above, “We decided to form an official group of our projects to oversee the creation of this standard and work toward better, more widely adopted standards across our projects.“

• Cal Evans, also present at the meeting, presents a summary narrative:

  • “To paraphrase the goal of this group, we are saying ‘Hey, we are all agreeing that we are going to code this way and we’d like you to do it to.'” (Does that mean Larry has it right after all? No, Cal corrects himself in a later email, stating “That should have read: To paraphrase the goal of this group, we are saying ‘Hey, we are all agreeing that we are going to code this way.‘”)

  • In that same later email, Cal also says, “This group is not setting itself above all others saying we know best. We are trying to find common ground between a lot of projects so that PHP developers world-wide can move between the code in those projects and not have to re-learn standards each time. … While I would love to see the the standards agreed upon by this group be widely adopted by the PHP community at large, that is not a goal of the group.”

• Matthew Weier O’Phinney says, “We represent a large number of component libraries and frameworks, with many thousands, if not millions, of users. We are representing those users within this group. … Third, these standards are not compulsory. You can adopt them or not. We are simply recommending them, and also committing that our representative projects will be using them. … If anything, we’re keeping a very close eye on the community, and involving them as much as possible — via our individual projects.“

• Nate Abele’s recollection of the initial meeting is similar: “The point of coming together on the standards which we agreed to was to provide our collective user community with some semblance of interoperability between our projects, and provide a way forward for other projects who’d like to interoperate with ours as well.”

  Nate goes on to say, “Everyones has an individual choice whether or not they even find these standards useful for them, but we as project leaders have elected to use these standards in our code, so if you plan on using any of our projects, you’ll be using the standard anyway, so we might as well be open with people about what those standards are, just in case others do find them useful (which, in my arrogance, I’m going to suggest that, if we as lead developers and prominent community members do, then yes, others might as well).”

(All emphasis above is mine; spelling and grammar errors in quotes are as-written.)

Contra Larry’s assertions, then, one can see that from the very beginning, the group resolved to focus on its own members. At the same time, we were aware not only that others would be watching and might choose to adopt our practices, but also that the group could speak only for its own members, and not for anyone else. That is, some might choose the FIG’s work as a “role model”; but then, the nice thing about role models is that yours do not have to be the same as everyone else’s.

To conclude: While Larry accuses me in his article of “protect[ing] a ‘fictional’ vision”, it would be more accurate to say that I strive to honor the true founding vision of the group — one that Larry appears to disagree with.

The FIG 2.0 Workflow

Larry seems to think that the new workflow bylaw model is quite a success:

Under that [new workflow bylaw] model, the group passed the PSR-4 autoloading > standard, PSR-6 cache standard, and PSR-7 HTTP messaging standard.

Larry’s narrative here is somewhat misleading. While it is true that PSRs 4 and 6 passed after that bylaw was put in place, those PSRs were transitional cases. PSRs 4 and 6 began before the workflow bylaw, saw significant work, and then were re-adopted by the group after the workflow bylaw was instituted around 2013 Aug.

To this date, there have been four PSRs that began and finished before the workflow bylaw, two PSRs produced that began before the bylaw and finished after its institution, and only one that began and finished after the workflow bylaw:

• Pre-bylaw (“FIG 1.0”) – PSR-0 (2010 Nov) – PSR-1 (2012 Jun) – PSR-2 (2012 Jun) – PSR-3 (2013 Jan)

• Transitional (started under 1.0, finished under 2.0) – PSR-4 (2013 Dec) – PSR-6 (2015 Dec)

• Post-bylaw (“FIG 2.0”) – PSR-7 (2015 May)

So, it is difficult to show as yet that the workflow bylaw is a significant aid to producing completed PSRs.

Measuring FIG’s Impact

Larry tries to quantitatively measure the impact of FIG across all of PHP-land:

The various PSRs that FIG has published have, of course, impacted the PHP community far beyond the handful of member projects. … The PSR-3 logger has been installed, according to Packagist, over 37 million times. For PSR-7, it’s around 11 million.

Number of downloads sure seems like a good objective metric, one that quantifies the impact of a package. But you have to be careful to make sure that a metric measures what you think it does. Counting “downloads” can be confounded by a small number of very popular packages that use a PSR package. Further, it is misleading to present numbers without context; they should always be presented in comparison to something else.

I offer a modified way of measuring the number of authors affected by PSRs: the number of dependent packages. This will tell us how many different packages, regardless of their download popularity, use the PSR packages. This should give us some indication (though imperfect) of the number of developers who integrate the FIG work into their own work.

Since Larry used Packagist, I’ll use that as well. Here are the “installs” (number of downloads) and “dependents” (number of Composer requires in other packages) for the FIG-originated PSR packages:

PSR Package	Installs	Dependents
psr/cache	0.8m	165
psr/log	38.0m	1943
psr/http-message	11.3m	711
(total)	50.1m	2819

So: the authors of 165 packages use psr/cache, 1943 use psr/log, and 711 use psr/http-message.

By way of comparison, here are three non-PSR packages originating outside of FIG. (These are not randomly selected; they are merely the first ones that came to my mind.)

Non-PSR Package	Installs	Dependents
doctrine/dbal	21.1m	1313
nesbot/carbon	15.9m	792
vlucas/phpdotenv	9.9m	711
(total)	46.9m	2816

This is to say that the authors of 1313 packages use doctrine/dbal, 792 use nesbot/carbon, and 711 use vlucas/phpdotenv. These packages are not the result of FIG deliberations. They exist entirely outside of the PSR process. And yet they have a comparable number of installs, and almost identical reach (in terms of dependents) across the wider PHP landscape.

Again, I recommend caution when interpreting the “dependents” count. There can be confounding factors there as well to bias the results. For example, some of the non-FIG packages have been around longer than the FIG ones, so perhaps the PSR packages will catch up given time. Or, one author could create a large number of packages with the same dependents.

But even so, this comparison should give proponents of the “grand” vision pause. The FIG’s reach across the entire PHP community may not be as great as they think it is. The attempt to position the FIG as a standards group over all of PHP-land, in light of this comparison, seems presumptuous and conceited.

FIG’s Source of Legitimacy

Larry claims that FIG has a responsibility to live up to:

FIG has effectively become the standards body for PHP. It took time for it to earn it, but it did …

It’s time for FIG to embrace that reality and help build a better PHP ecosystem for all.

Perhaps FIG has come to be seen as that, correctly or not. If it has, any legitimacy the FIG has earned has come specifically from not being a formal standards body. The FIG has already helped to “build a better PHP ecosystem for all”, and it has done so by concentrating on its member projects, per the “founding” vision.

The benefits of that work under the “founding” vision have been adopted throughout that ecosystem, indirectly and voluntarily. It did so without being a self-appointed standards body over all PHP programmers. Thus, to claim that a formal body is necessary to achieve “a better PHP ecosystem” is an unsupported assertion.

Alternative 1: Independent Interop Groups

Larry makes several observations about how FIG works, and who works on what, in his article. His observations there are difficult for me to summarize.

However, Michael Cullum (the other author of the FIG 3.0 proposal) has written a TL;DR of FIG 3.0 that does provide a relevant summary:

• Everyone has equal say on FIG PSRs, no matter their expertise or their project’s relevance in the PSR’s problem space

• There are lots of clever awesome people involved in the FIG who are not > project representatives

• Member projects find it difficult to engage in everything going on in the FIG

• There is an ongoing question if the FIG produces PSRs for member projects or for the wider community; especially when the wider community pays it so much attention due to its de-facto status as ‘the php standards body’.

As for the fourth point, I hope my commentary above has shown that there is no reasonable question that the FIG PSRs are intended primarily for its member projects; others are free to adopt or ignore them as they see fit.

The first three points, though, are all solvable by encouraging *-interop groups, along the lines of container-interop and async-interop. Doing so would solve the top three TLDR points with almost no changes at all to the current FIG structure:

• A *-interop project concentrates on its particular problem, and can invite (or draw the attention of) those who have relevant expertise. Both container- interop and async-interop were able to this successfully.

• A *-interop project need not be limited to only project representatives. It can bring in anyone it wants, according to the desires of the project leads.

• Interested parties can engage in as many, or as few, *-interop projects as they like, choosing their own level of involvement.

Encouraging independent interop groups solves all the TLDR points with less bureaucracy, less centralization, reduced hierarchy, fewer committees, more flexibility, and greater openness. It also gives some level of proof that the proposal put forth by the interop group has actually been adopted across multiple projects, and is ready for recognition. When the interop group is ready, it can come to the FIG (if it wishes) with a well-vetted proposal in place.

However, encouraging independent interop groups does not solve the unstated problem of “early prestige”. That is, forming an independent interop group does not give your work the character of being “a standard for all of PHP land” before anyone is actually using your work. For some proponents of FIG 3.0, I opine that “early prestige” is a feature, not a bug.

Alternative 2: Disband the FIG

A second alternative is to declare that the FIG, as originally envisioned, no longer serves a useful purpose, and should disband, perhaps to make room for some other organization.

As a founding member of the group, I do not suggest this alternative lightly. However, doing so would give recognition to several realities, as I discuss in my “FIG Follies” blog posts (part 2 and part 3). Those realities are:

• There are currently two rival visions competing within the FIG: one that holds to the “founding” vision, and one that holds to the “grand” vision of FIG 3.0 as a standards body for all of PHP-land.

• Just because a change has been voted in, does not mean it cannot be voted out again later. As such, mere votes will not be enough to settle the matter, since the losing side will be well within its rights continue to press its case. The problem is one of world views.

• The best long-term solution is for one set of vision-holders to explicitly renounce their vision, and perhaps also exit the FIG. However, neither set of vision- holders is willing to withdraw, since the FIG’s legitimacy and reputation (as earned under the “founding” vision) are too great an asset relinquish.

As such, it may be better to disband the group entirely. This effectively means that the different vision-holders surrender to each other simultaneously, rather than continue their rivalry over the FIG.

When disbanding the group, the FIG should entrust its assets to an archivist to maintain the PSRs, website, and so on, all in their current state. This leaves the actual productive output of the FIG (i.e., the PSRs) available for posterity. The archivist would hold the FIG name and accounts in trust, and guard them from ever being used again. The archivist might also merge errata and insubstantial changes on existing accepted PSRs.

Disbanding also leaves the field open for another group to form. If another standards-related group does arise after FIG disbands, that group will need to earn its own way, with its own achievements, under a new name.

I discuss more details about this alternative in my FIG Follies Part 3 post.

Conclusion

Larry has recently called a vote on the FIG 3.0 proposal, which means it is now in the hands of the FIG voting members. If it passes, the above two alternatives may no longer be possible.

In my opinion, voting for the proposal means that the FIG’s official opinion of itself will change from “we think we know what’s best for us” to “we think we know what’s best for you.” I believe this would be a change for the worse.