By Deji Akala

PHP-FIG, Quo Vadis?

By Deji Akala

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.


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.


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.


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.


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.”


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.

  • Larry Garfield

    I’m afraid the above article has multiple incorrect or misleading statements.

    The recent expulsion vote was not for a secretary. It was for the Aura project rep/project lead Paul Jones, who is not a Secretary. He later ran for election as Secretary but was not elected. We have never had a recall vote on a Secretary. (The position is less than a year old.)

    No one has forked the Linux kernel due to Linus’ abrasive behavior, true. But also how many people have been turned off and avoided working on the kernel as a result? A project can be harmed in many ways beyond a fork. Forks are an extreme case.

    GitHub’s recent HR problems… have nothing to do with FIG whatsoever, so I don’t know why they’re even mentioned.

    FIG 3 is grossly misrepresented in this writeup. It’s only mentioned as the thing to which the calls to disband FIG are responding, without properly explaining what it is other than “moar bureaucracy”. In actuality, half of the changes in FIG 3 are simply acknowledging the reality that FIG is not, nor has it been for years, limited to “just” member projects in its impact. Look no farther than PSR-2’s built-in settings in PHPStorm, for instance. Many PSRs are now being developed by larger teams (which is a good thing!), and FIG 3 embraces that by expanding the Working Group from 2-3 people to at least 5, all of whom can have a direct influence on the spec.

    The other half, the Core Committee, has the twin goals of accepting that the 40-ish project reps are not, and will not, pay attention to most specs and giving the broader PHP community more influence in how FIG is run. When votes now fail on simple lack of quorum and then get responses of “I didn’t realize it was up for a vote” or “Oh yeah, I forgot”, there’s a problem. And when the community is always impacted by FIG’s specs and actions, yet has no actual voice at the table, that’s a problem. FIG 3 addresses both of those problems.

    That’s not “moar bureaucracy”, it’s “adapting to reality.”

    The only “drama” it creates is from those who feel that the broader community should *not* have input into FIG, and would rather see FIG shut down than allow non-project-leads to have a voice. I find that position to be far more “drama prone” than suggesting the community at large have a place at the table.

    Honestly, I expect better research and focus from SitePoint, who I normally trust to do a better job than this.

    • Bruno Škvorc

      Thank you for the clarifications and thoughts, we’ll reply in kind soon, and will fix the slip-ups as soon as possible.

      When you say ” A project can be harmed in many ways beyond a fork.” – do you feel like Linus’ behavior has harmed the project? If so, in what way? Please disregard the offended people, I mean the project directly, code-wise, people are unimportant in this context.

      > “When votes now fail on simple lack of quorum and then get responses of “I didn’t realize it was up for a vote” or “Oh yeah, I forgot”

      That is definitely a problem, but not one I would solve with writing more rules. Rather, with a better system of communication, preferably a non-archaic one, which lets everyone be notified of upcoming votes and their importance in a way they prefer to be notified (if they opt for email, they’re to blame if they miss the email). A simple push notification that’s sent out to every member project’s preferred service when their input is needed, and a score tracker that reduces that project’s vote impact by 50% after they miss more than 3 votes in a row, all implemented in a simple website (we’re all web developers, are we not?) would, I believe, solve this no-vote problem much, much sooner.

      I believe the FIG also needs to work more on their own humanization. I do not feel like interacting with an organization which has rules written in a dialect the common person needs a law degree to understand. But if the FIG had an actual human-facing part (call it PR) which would put out, and this is just one example, tutorials using their proposed standards to make them both approachable to the general public and clarify their use cases (even before being voted on, to give people a proper demonstration of what they’re voting for or against), I think its perception of being a cauldron of bureaucracy would diminish greatly. I volunteer SitePoint as an outlet for such writeups. In fact, we’ll pay for such posts. Then, use the money to fund the PR side further. Get a good logo. Get good hosting. Print FIG shirts. Make the organization lovable. Get people paid to develop the site I mentioned above.

      As for drama-prone-ness, I appreciate very much what the FIG used to do, but the last 10 topics there have hardly been productive. Increasing the voting pool to “everyone else” won’t help with that – it’ll sow more discord, and lock proposals up in eternal discussions along the lines of whether the color black should even be allowed to be called black now. What *should* happen is the projects that need to vote should be *forced* to do so under threat of diminished voting effectiveness in the future, and everyone else should merely have a voice in discussing a proposal, never voting on it.

      My 2 cents.

      • Larry Garfield

        > When you say ” A project can be harmed in many ways beyond a fork.” – do you feel like Linus’ behavior has harmed the project? If so, in what way? Please disregard the offended people, I mean the project directly, code-wise, people are unimportant in this context.

        I disagree emphatically. People are of the utmost importance in software development, and in Open Source especially. Software is written by people for people. The impact of toxic personalities on communities is well-documented, as is the “it only takes one” effect to poison the well. Hostile behavior drives off all but the most hostile, emotionally closed off, non-empathetic people. If you curate a community of those who “don’t give a shit”, then they won’t “give a shit” about users, either. Linus is correct that quality of the product needs to trump making people feel good, and I fully agree with that; the same is true of FIG, where I firmly believe we should strive for the best quality specs that will be adopted by the most projects, even if it annoys someone. But in both cases that can, should, and must be done without being a jerk about it.

        FIG 3’s answer to poor voter turnout isn’t “more rules”. It’s simply acknowledging that representing the interests of a given project and curating specs that are useful to all stakeholders are different skills requiring different amount of time. We don’t, can’t, expect all 40-ish project reps/leads to stay on top of every discussion. That’s been shown empirically. We can, however, explicitly put that into the job description of 12 people who know they’re signing up for that job.

        Nor would I propose that the whole world vote on every spec. That would be a terrible idea, and I certainly do not propose it. Rather, those involved in FIG’s work, whether they’re a project lead or not (which is defined in the proposal), should have a say in who those 12 people are who are signing up to steer the direction of spec proposals. It’s a basic republican (small r) concept, and one that is used by, well, only a few million organizations of many orders of magnitude of size. :-)

        The FIG 3 proposal was not written by a lawyer. I wrote most of it, and I’ve never been to law school. I’m an engineer, and know from experience that explicitness leads to correctness. I’ve seen that in bylaws for other organizations I’ve worked with in the past, too. FIG 3 is more verbose than the current bylaws, sure, but only because it includes all of the exception handling that we currently lack. :-)

        FIG PR is, as of this past winter, explicitly part of the Secretaries’ job. Our first round of secretaries have done a good job so far, I feel, in that direction, although I completely agree there is far, far, far more work to do on that front. I sincerely appreciate the offer to to use SitePoint to help in that, and may take you up on that in the future. (Or rather, nudge the Secretaries to do so.) We’ll see how that plays out.

Get the latest in PHP, once a week, for free.