PHP-FIG Alternatives: The Pros and Cons of Various Visions
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.
Continue reading %PHP-FIG Alternatives: The Pros and Cons of Various Visions%