PHP-FIG, Quo Vadis?

Many thanks to Andrew Carter, Younes Rafie, and Scott Molinari for peer reviewing this post!

The Polish writer, Henryk Sienkiewicz, was awarded the 1905 Nobel prize for Literature for his epic novel Quo Vadis, which is a Latin phrase meaning “Where are you going?”. In the face of any dilemma, a brief pause and redefinition of one’s goals may be therapeutic.

The PHP Framework Interoperability Group (PHP-FIG) has come of age. With the acceptance of more PHP Standards Recommendations (PSRs), PHP has attracted further positive attention and admiration of the programming community. PSRs governing coding standards, coding style guides, autoloading, logging, caching and HTTP messages have been accepted.

Other proposals at different stages of draft and review cover hypermedia links, PHPDoc standard, event management, caching and security issues. There’s even one on Huggable Interfaces (PSR-8) which, among other things, talks about huggable objects and mutually-assured hugging!

However, the future isn’t as bright as painted, as a recent ruckus within the organization has thrown its continuing existence under doubt.

Origin

The seed of PHP-FIG was sown at php|tek in 2009 when some developers got together to share ideas. This was out of concern over the fragmentation within the PHP community that has congregated on different islands of frameworks and applications. FIG should be the PHP equivalent of the Java Community Process, a platform for the development of standard technical specifications for Java.

Their intention was the creation of a forum for discussing common issues faced by PHP projects and by working together, find ways of cooperation and interoperability. They wanted to make it easier to share the work done between different projects.

Organization

Participating is as simple as subscribing to the Google group mailing list or joining the IRC channel. The ability to vote on deliberations requires a voting membership.

The general administrative duties are performed by a triumvirate of secretaries elected at different months of the year for a two-year term. Details of the day-to-day running of the organization are available on the Bylaws section of the PHP-FIG website.

Successes

As noted above, PSR-4 (Autoloading Standard) describes a specification for autoloading classes from file paths. It’s designed to be fully interoperable, and can be used to supplement any existing autoloading specification, including PSR-0 (the deprecated Autoloading Standard). This PSR also describes the location of files that are to be auto-loaded in accordance with the specification.

With Composer (a voting member of PHP-FIG), installing and using a PSR-4 compliant package is seamless. A framework-agnostic package such as Carbon can be dropped into any PSR-4 compliant application without any problems.

In the same way, PSR-7 (HTTP Messages) has opened the door for interoperability wider by proposing a specification for the description of HTTP requests and responses. PSR-13 (HTTP Middleware) will build on PSR-7 and further push back the frontiers of interoperability between compliant frameworks and applications.

The laudable goals of the pending PSRs may not be realized, as the very foundation of the organization is under threat.

Disputes

The current situation can be summarized in this post to the mailing list: “The increase in legalistic bureaucracy has taken front stage, and is impeding the good work that this group was set up to do. Put more bluntly, the FIG has become increasingly toxic in recent months, making effective participation nearly impossible.”. Bureaucracy. Toxicity.

The mailing list receives lots of messages outside the scope of technical discussion of interoperability. Here’s a sample of topics: “Secretary conflict of interest”, “Harmony between secretaries”, “Bylaw Amendment for Expulsion Votes”, “How can you tolerate this guy?!”, “Expulsion Bylaw Change”, “Request a vote to expel xxxxxx”, “Nullification of xxxx membership” etc.

There’s even a recent thread – Alternative to FIG 3.0 – Is it time to call FIG complete?. The premise is, FIG has completed its work, no need for FIG 3.0, so let’s disband PHP-FIG. The FIG 3.0 proposal is a rewrite of the complicated bylaws, structure and processes of the organization. Some, including the author of the post on disbanding the group, would argue that FIG 3.0 is trying to replace a bureaucracy with more complex bureaucracy.

The departures of high-profile projects and individuals such as Laravel, Doctrine, Propel, Guzzle, PHP League and Assetic haven’t helped matters. An attempt to expel one of the three secretaries fell at the voting hurdle. Perhaps in protest, the PHP Community-driven Standards (PHP-CDS) was formed with a very loose structure and lower-entry level for proposals.

According to them: “PHP CDS is not a group or organization, it’s a concept. Its core idea is for the community to create RFCs, discuss them, then hold a vote on their acceptance as a community standard.” The term PHP Community Standard (PCS) echoes the Java Community Process (JCP) but setting up the organization in the first place, might prove to be just a protest against the discord in FIG.

Sweet harmony

The Open Source community has epitomized goodwill and harmony over the years and the model has won the admiration of corporations that peddle proprietary solutions that are often closed-source.

The Apache Software Foundation that supports a wide range of projects including the extremely popular Apache HTTP Server remains strong. The Linux Foundation provides a home for the Linux kernel project which is probably the world’s largest and most important open source project. Then there are strong communities that congregate around excellent software such as Symfony, Drupal, Composer, Guzzle, etc.

Perhaps it is projects that develop around or which are supported by corporate entities that do well. Maybe it’s projects started and led by a personality that commands respect and admiration.

Bitter discord

If the open source community has seen the best of humanity it has also seen its fair share of verbally-brutal attacks and civil strife. People often disagree – neighbors don’t always see eye-to-eye. Motorists on the motorway find a way to express their displeasure at each other. That’s a fact of life as social animals.

Linus Torvalds is undoubtedly a genius but you wouldn’t want to put him at the top of the list for a diplomat position. Surely not someone who apparently wrote to a mailing list, “Can we please get rid of the brain-damaged stupid networking comment syntax style, PLEASE?”. Or, in another message, “nice” comments like, “I’m a bastard. I have absolutely no clue why people can ever think otherwise. Yet they do. People think I’m a nice guy, and the fact is that I’m a scheming, conniving bastard who doesn’t care for any hurt feelings or lost hours of work, if it just results in what I consider to be a better system. And I’m not just saying that. I’m really not a very nice person. I can say ‘I don’t care’ with a straight face, and really mean it.” Well, nobody has been so annoyed by such words or his comments on pull requests to have gone ahead to fork the Linux kernel.

Github was hit by its own earthquake around 2014 when a female employee made some claims of sexism, harassment and intimidation at the office. The story had several dimensions, not least of which involved some ladies hula-hooping to music during office hours while the male geeks were multi-tasking – coding away and at the same time gawking at the dancers. Beyond the frivolity, she claimed: “I had a really hard time getting used to the culture, the aggressive communication on pull requests and how little the men I worked with respected and valued my opinion.” She was alarmed when her “character started being discussed in inappropriate places like on pull requests and issues.”

There were other facets to the Github story but it goes to show that where two or three developers are, disagreement is there in their midst. Discord is a part of human experience. How we deal with perceived obnoxiousness in people around us reveal a lot about us.

Way forward

PHP-FIG is on the delicate path of implosion. The good that we have witnessed since its emergence is the strongest argument for its continued existence. However, the thought of replacing a so-called broken bureaucracy with some neo-bureaucracy in the guise of FIG 3.0 is based on the premise that there is good bureaucracy. The bylaws page on the FIG website and voting process are way too complicated. How about simplifying the running of FIG? How about only focusing on interoperability and not implementation details?

Perhaps the way forward is in less bureaucracy and more concentration on how to improve communication and discussion of PSRs. Maybe it should be easier for “non-experts” to be able to chip into the process in order to facilitate inclusiveness? Some PSRs were in the pipeline for 5 years of more. Does it really have to take so long?

Admire Linus Torvalds as a human being or not, let’s pause and listen. He’s been quoted as saying: “I think it’s been part of what’s been great about Linux, the fact that I haven’t had a vision, and very few people had a vision. I take that back. Lots of people had visions, but they’re completely different. People know where they want to drive Linux, but there’s no coherent plan, and it’s actually, I think, what made Linux be a fairly well balanced system, because there was nobody who said, ‘This is the direction, and we’re going that direction, whether it’s right or wrong.’ We just spread out and did a little bit of everything.”

Conclusion

PHP-FIG need to pause and consider the question, “Quo Vadis?”. If the answer is anything other than the original goal of interoperability, its continuing existence may be in doubt. It’s interesting to note that the “toxic” secretary still believes in open source and won’t jump even though he survived being pushed through the expulsion vote. Everybody’s opinion counts. Not every opinion can be accepted but they all deserve attention. Let’s focus less on things like governance, operations, bylaws and administration.

We are programmers. Here’s one more Linus’ quote: “Talk is cheap. Show me the code.” And another one – “Those that can, do. Those that can’t, complain.” I can’t, but I won’t complain. The less talking in FIG and more code that interoperates, despite different implementations of a concept, the better the future.

Frequently Asked Questions (FAQs) about PHP-FIG and Quo Vadis