A fig tree

A fig tree (Photo credit: Giorgos~ (moving to Google+))

Recently, Anthony Ferrara posted “Open Standards – The Better Way“, a blog post questioning the operation of the PHP Framework Interoperability Group (FIG). The FIG is a body representative of PHP “frameworks” (with a broad definition since it includes phpBB, Drupal and even more divergent members) which issues PSR standards such as the PSR-0 standard which governs requirements for autoloader interoperability and the upcoming PSR-1 and PSR-2 standards which, together, form a coding standard for PHP.

Anthony, whose views always make good reading, raises concerns about the way in which this group generates standards. He contrasts the current approach to RFC 2026 which defines the IETF’s Internet Standards Process. That approach evolved to balance conflicting requirements. On one hand the rapid evolving nature of the internet demands the timely production of standards while, on the other hand, the standards must be subject to an open and fair process, proper testing and technical development. Surrendering to either side of this conflict tends to give rise to poor standards.

Where Anthony’s arguments seemingly fall flat is that the FIG is not the IETF. The Framework Interoperability Group was founded to allow cooperating members to develop shared standards. It does not claim to be PHP’s standards body and so there is no obligation for any PHP programmer to adopt their standards (unless they work on a member project obviously!). On this simplified basis, the FIG doesn’t need to balance the conflicts described by the IETF. It serves its own interests, i.e. those of its members who may voluntarily adopt accepted standards at their convenience to boost interoperability between their software. If they be happy, they be happy.

However, the FIG is not a closed standards body. Anthony’s article simply targeted the FIG’s processes which have been slowly evolving from a semi-closed process (there was a time when the mailing list was not open) towards a more open process. By inches, the FIG is becoming a defacto PHP Standards Working Group and I’m skeptical of anyone who doesn’t see that. The only technical reason they can’t really use their original title as-is is probably because of licensing concerns in using the “PHP” moniker. The phrase “Framework Interoperability Group” is much…er… better. It’s catchy even if nobody will have a slightest clue what the heck it means.

It gets even more interesting though. While it’s easy to assume that the FIG is operated by some undetermined number of individuals one can ignore as a bunch of power hungry people, the truth is that the voting members are not people at all – they are nearly all open source projects. FIG is operated by individuals on the basis that they represent the interests of the FIG’s real members, i.e. projects which include Zend Framework, Symfony 2, Lithium, Aura, phpBB, Joomla, Drupal and even an individual who, as an honorific, represents “the community at large”.

This is why PHP programmers need to pay attention to what the FIG is doing. The Group is, by definition, an open standards working group. It does actually wield real authority and influence by virtue of the fact that its members represent a not inconsiderable number of open source programmers both within their projects and among those who build any sort of dependent library or plugin against those projects. Once PSR standards are issued, they also benefit from the reputation of the members, the knowledge that it was subject to an open process, and an assurance of independence since it was agreed to by a majority of the member projects and not just one of them.

In other words, the FIG is actually something really really good for PHP. PHP needs standards so we can make interoperability between various frameworks and applications a true reality. The hodgepodge of APIs and standards we’ve relied on to this point only serve to reinforce PHP’s NIH obsession (the bad type, not the good type that keeps PHP reinventing better variants of everything under the Sun). These days you can’t simply pick a library to replace another – they’ll have different APIs. Besides NIH, it also encourages stagnation since different APIs generate a barrier to new replacements. Thankfully, that whole APIs are copyrightable lark is now officially dead in the EU (and close to it in the US!).
But let’s not forget Anthony’s article. Can the FIG improve its processes for creating standards? I’d venture that it could and articles like Anthony’s are part of that improvement. Far from being a case of “pitchforking”, questioning the open process of FIG should be as acceptable as having some weird people called Mr. Grumpy ranting and raving on an open source mailing list. Open source projects embrace the programmer community as their most valuable resource. Open standards bodies are no different – they derive their authority and influence from the communities they serve.

What the FIG should do, in my opinion, is clearly define its purpose and better document its bylaws/processes. At the moment, the messaging is confusing. Some member statements leave no doubt that the purpose of the FIG is to serve its member projects in producing shared standards but other statements demonstrate a hope that PHP at large will also adopt the same standards to improve PHP’s overall open source ecosystem. Do observers need to flip coins to figure out what the FIG’s mission is? Personally, I see absolutely nothing wrong with the FIG encouraging the PHP community to adopt its standards. It’s not a power grab or a selfish act to do so – it’s just a group of open source minded folk trying to promote greater cooperation among programmers. Documenting bylaws and processes would clear up any other elements of how the community can become involved and remove any perception of a closed network of individuals. What is the criteria for membership? Who can submit new proposals? How are member representatives selected, replaced, etc? How are proposals handled, reviewed and progressed? Why are proposed standards not obviously available in the Github repo under the proposed directory?

It really all comes down to better communication and pushing the community engage with the FIG. To this end, bear in mind that the FIG members are open source projects. The FIG membership is also growing (presumably it will stop growing eventually unless the group wants an unwieldy number of chefs in the kitchen). Each project has a voting representative who is assumed to represent the interests of that project. If you are a contributing member to or a user of any representated open source software, your first step should be to hold your representative accountable. Open source projects tend towards Meritocracy’s with an optional Benevolent Dictator – you may already have a voice in how the FIG operates and how your representative should be voting. You just have to use it!

On the flipside of this communication route, ensure your FIG representative keeps the project’s community involved and informed. They should be seeking your feedback, building support for their votes, and using whatever internal proposal mechanism exists (formal or informal) typical for such decisions prior to casting their vote. The FIG should never involve bypassing an open source project’s normal operations. Hold your representative accountable and ensure they represent that project’s interests. If they don’t – pitchforks can be bought at most reputable hardware stores.

Enhanced by Zemanta