Moaning About the FIG (Again)

I’ve spent a lot of recent weeks moaning about the FIG (again), and I feel that it’s only fair to all involved that I solidify my thoughts about exactly what I feel is wrong with the current direction, and what needs to be done to fix things.

Part One – Member Projects

Note: These are my opinions, sometimes I’m speaking from a position of ignorance. Forgive me. The FIG has done groundbreaking work that has helped me code better, use exterior packages, and ultimately made it easier for me to earn money, and for that, I thank them.
Note 2: The FIG started as an interoperability group, but it’s been internally acknowledged that they are now a standards body. If you disagree with this premise, please stop reading now or you will disagree with everything.
Note 3: I intended this to be one long post, but I wrote nearly 1000 words on just the membership, so I guess I’ll split this into 2-3 posts instead.

Take a look at the list of member projects, does anything strike you as odd? I find this member project list baffling for many reasons. The number one reason for me is that the most popular PHP project of all time; WordPress, is not on that list.

I’m speaking from a position of ignorance here, but I’d like to ask a question — Why are the WordPress developers so uninterested in being involved in the group? Anecdotally I’ve heard they have no interest in the PSRs, and they are put off by all the perceived drama. I, for one, would LOVE to hear the opinions from WordPress’s development team on proposed new standards. WordPress as a community is working hard to shake off their image of having bad code, and I’d very much like to see this huge, vibrant community represented in the FIG.

Also noticeable by their absence are the testing frameworks.

I’m unsure of any history between PHPUnit and the FIG, but quite simply it needs to be there. It’s the number one defacto testing framework for PHP, and all of the member projects SHOULD be using this software to test their own libraries and frameworks, yet it has no voice in the self-elected standards body of the community. This is just wrong.

I know that recently PhpSpec got proposed for membership, but it appeared that the voting members were just too busy to vote the project in. Out of 40 listed member projects, only 12 projects voted (all +1 for what it’s worth). I’m unsure if this is because the project is not wanted in the group but projects didn’t want to be seen to be voting -1, or if there was genuine apathy in this vote, but it’s a crazy state of affairs either way.

It seems to me that the process of being a voting member project in the FIG is too convoluted, and too much of “look at me I’m in the FIG!” for the current member projects to be taken as an accurate reflection of the developer community as a whole.

Aside from the notable omissions (I covered 3, but I could go on, recently departing, Doctrine, Laravel and Guzzle all NEED to be represented in a standards body), some projects just seem odd to be represented with a vote.

I need to be blunt and say I have no ill will towards the projects I’m going to name here, but I feel that discussion needs to be opened up around existing projects, and the only way to do that is to name the projects I feel should not be represented by a member vote.

Looking down the list, after the recent controversy, it’s obvious to most that PHPixie should not be a voting member of the FIG. I really don’t want to cover off what has been a pretty widely reported story, but suffice to say that even without the accusations of mailing list fraud, the fact is that their install numbers have been inflated mean it’s really not widely used enough to warrant a vote.

Along similar lines, I feel that PPI framework is just not a real enough project to be a voting member. Paul (the project’s maintainer) has long been a fantastic servant of the FIG (and the larger community), but I just feel that a hobby project that is not used much (if at all) on production websites should not be granted a vote. If I’m wrong here, and PPI is used in production in thousands of live sites, I owe Paul an apology.

EDIT: I owe Paul an apology, in his Tweet he explains the project is used in live sites, I’m not convinced that changes my opinion sadly.

I know there are historical reasons here, but much as Cal Evans recognised that his community vote which was granted early in the FIGs life was no longer required, it may be time to reevaluate all projects, particularly those who were voted in the earliest.

I’m sure there are more; there are names on the list I’ve never heard of, but it would be remiss of me to comment on anything that I have no idea about, so I’ll stick to commenting on things I know very little about ;).

It seems crazy to me that Flysystem, a package that has  7,370,380 installs at the time of writing gets it’s vote bundled into the League’s member vote (their choice I know), whereas Agavi with 4,519 installs has a full vote. The fact that Doctrine, Laravel, PHPUnit, Guzzle, PhpSpec, Faker, Mockery, Swiftmailer, etc., etc., etc. are unrepresented is frightening. Browse through the first 10 pages of Packigist’s most popular packages and look which are represented. See for yourself.

I understand that the existing members have spoken, that this list is self-selecting, and frankly that’s the problem here. Unless all the projects are as big as Cal Evans, and can admit that the group has outgrown their project, it’s unlikely that this list will ever be trimmed down to a group of projects that deserve to have a voice in the community. Without a defacto “leader” it’s going to be impossible for any person (or people) to ensure that the right people are approached about getting a voice.

I’m definitely not advocating starting again, but I’m not sure the FIG 3.0 which is currently in discussion is the right direction either. I’ve waffled on for over 1,000 words so I’m imagining that 92% of people have stopped reading by now, but I’ll cover some other problems (in my opinion) in further posts.

G

15 thoughts on “Moaning About the FIG (Again)

  1. Very good points Gary. I would say that if the FIG continues down it’s current path to become THE standards body for php it is vital that more get involved. However, I am not sure I agree with your stance on what projects should be involved. If it indeed will become THE standards body, then I do not think the limitations based on size of project are valid. In fact I would say that the group be more opened up to include people regardless of being a part of a project. Community != Project Contributor.

    On the other hand, if the FIG is to remain an “interoperability” centered group, I think that size of project is not as important as being an active group with more than a single contributor. And, as I’ve stated before, the popularity of a project cannot be determined by Github and Packagist alone.

    • I agree with all your points Adam. At some point there needs to be a cutoff though, or the number of projects with votes becomes rediculous. I believe that the number of users a project has is valid in whether or not it gets a vote, and while packagist may not be a completely true metric, it’s a good starting point. I know, for example, that the IBMi library has many more users than Packagist would have us believe.

      • The problem IMO is that this model doesn’t work with the current voting system. It’s inconceivable that an unanime -1 from the Doctrine team had the same weight as any other voting member that may not have any real experience in cache systems when the PSR-6 has been voted. I can understand that some bureaucracy is required to keep things running and having a fair vote, because it’s unlikely that everyone will always agree with everything; But at some point common sense is required. PSR-6 was a perfect example of where lots of things have gone wrong, and bureaucracy just made the killing move by allowing it to pass where it shouldn’t have.

        Same goes for PSR-7. Don’t get me wrong, I really like the PSR-7. But what is not acceptable is dismissing a huge chunk of the community which is using HttpFoundation (Symfony, Laravel, Drupal8, eZPublish). None of them can easily switch without major breaking changes which are not likely to happen before a while and with a lot, lot of pain. I’m not saying PSR-7 is wrong, but it shouldn’t have been passed without having a good migration path ready. There is a bridge between HttpFoundation and PSR-7, but every libraries aiming at Symfony, Laravel & co. as first-class citizen will rely on HttpFoundation instead of PSR-7 because of poor performances the bridge provides.

        For such mistakes to be prevented, it’s only fair to try to get the right voices for it. A minor project is not fit for it. I’m not saying the guy working on it shouldn’t be able to work with the FIG, I dare say anyone should be able to start a PSR or heavily involves himself with one, but he should not be able to vote.

        It is wrong to give a voting seat as the only way to get someone involve in the project.

        • Hey! Got some feedback on these comments, hope you don’t mind me shoving them in here, I just want to avoid any potential confusion.

          … what is not acceptable is dismissing a huge chunk of the community which is using HttpFoundation (Symfony, Laravel, Drupal8, eZPublish). None of them can easily switch without major breaking changes which are not likely to happen before a while and with a lot, lot of pain. I’m not saying PSR-7 is wrong, but it shouldn’t have been passed without having a good migration path ready.

          Is there an alternative? Isn’t the migration path “You can change things on major versions.”?

          I would look at it this way: instead of trying to build code that supports literally unlimited different implementations of HTTP Messages, you only only need to support PSR-7 and – for now – Symfony HTTP Kernel. I’m ok with that, as is seems like the only alternative is: Stick a PSR badge on the Symfony package and call it done.

          The FIG do try and avoid just making stuff up and knocking it out, although that is admittedly what happened with PSR-6.

          A minor project is not fit for it. I’m not saying the guy working on it shouldn’t be able to work with the FIG, I dare say anyone should be able to start a PSR or heavily involves himself with one, but he should not be able to vote.

          For this reason a lot of voting members do consider usage metrics before voting. 🙂

          I’m not sure if you’re aware, but literally anyone can start a PSR and be an editor. Also literally anyone can contribute to the discussions and give feedback. If voting members are ignoring people just because they’re not voting members then tell somebody, the sponsors of the PSR or the secretaries. That shouldn’t be happening.

          I agree with “It is wrong to give a voting seat as the only way to get someone involve in the project.” wholeheartedly, and that’s why the FIG works this way 😀

          The FIG 3.0 will solve a lot of problems, and inactive projects need to be kicked out for sure.

  2. Hey Gary! You’re making a lot of great points. I think the recent lack of interest in certain votes is down to general apathy with the level of drama being caused in the group. Luckily the new secretaries are fixing this from a bunch of angles.

    Self-throttling is being enforced instead of simply politely reminded. You Know Who posted about ten times in the same thread after I asked him to stop spamming, so they gave him a 24 hour ban.
    ( See Paul Jones get a 24 hour ban: https://groups.google.com/forum/#!topic/php-fig/LO8sG5SPPd4 )
    Secretaries are accepting complains from people – voting members, onlookers, ex-members, anyone! This means action can be taken against people causing problems, and those people will get a perm boot if they can’t stop being ridiculous.
    ( Complain to secretaries if somebody is causing problems: http://www.php-fig.org/members/ )
    Hopefully (I’ve requested it) Secretaries will soon start booting projects that don’t actually vote, making quorum easier to hit.
    ( Read more: http://www.php-fig.org/bylaws/voting-protocol/ )

    Kick Agavi: David already stepped down. I just sent a PR to get them off the website. https://github.com/php-fig/php-fig.github.com/pull/206

    Kick PPI: I have had a similar concern for a while. I’m a big fan of Paul D, but it does seem like a hobby project. Paul was one of the most active people for a really long time, but his work on PSRs could continue as a general community member, and he was doing a lot of secretary work which is now being done by the secretaries. Maybe he’d step down.

    Get WordPress: Already on the case, just sent a DM.

    Get PHPSpec: Try another vote after a few inactive projects get cut. I’m certain it would pass again. This has happened a few times and really is no big deal.

    As for other popular things, I’m not sure if Mockery and Faker would really add any value to being voting members. Are they interested? Do they need to be on there? You’re quite right that we should be trimming barely used projects, but I don’t think begging projects to join just because they’re popular is such a good idea.

    Now that the drama is being cut out by the secretaries, we’ll hopefully see an increase in constructive conversation, people will stop filtering the emails from their inbox to some dusty folder they never check, votes will be better represented and everything will get better. Recent improvements plus the upcoming improvements solve most of it, and when projects see this hopefully Laravel, Guzzle and Doctrine will find the time to come back.

    Or maybe I’m delusional and we should set it all on fire. Who knows. ¯_(ツ)_/¯

    • Thanks for the feedback Phillip. Just a point of note, some of the projects I named specifically, others were more as examples — I probably should have made that more clear.

  3. Great write-up.

    There is one thing that bothers me a lot however and that you didn’t mention directly: why should PHPUnit (for example) vote on a standard HTTP interface? (I don’t have anything against PHPUnit of course)

    Yes, some projects need to be represented, and others kicked out. But to me the core of the issue is that the FIG was born from global problems (autoloading, code style, logging maybe…), but there are not so many left. That time is gone.

    IMO the best thing would be: some projects get together and standardize something between themselves. Projects that don’t have any business with it should stay out of it. The FIG could be a great place for that, but that would mean acknowledging that not everyone votes on everything. The consequence would be that PSRs could loose their “value”, because small projects could work out a PSR for themselves, which would not necessarily be used by bigger projects. But that’s fine IMO, there just needs to be a transition.

    The usefulness of PSRs for the global PHP ecosystem will only go downward. The problems left to solve are more specific, so we can’t hope for one-size-fits-all great solutions (see PSR-6 or PSR-11 for example). But that’s fine, we need to acknowledge that and work locally, in smaller groups.

    Example from my experience with PSR-11: it has been very useful with Slim, Zend Expressive and other micro-frameworks (not to mention containers themselves). However it will most probably never be useful to Symfony, but that’s fine! (and I admit it took me quite some time to realize that) It’s already super helpful if it helps a non-negligible part of the community. That’s also why we created container-interop: projects that are actually interested in the standard take part into it, and it allows us to be quite productive (especially with our latest work on service providers for example).

    • Quick comment here: I think that those are great points, but I don’t think that creating side-groups (like container-interop) every time would solve this problem. On the contrary, I think (and hope) that the FIG 3.0 proposal is addressing this issue and will solve it.

      • If the FIG was a better place to work on such “small-scale” standards then I agree with you. We created container-interop originally to experiment, then it turned out to work and now it’s a standard on its own, but the goal was always to turn it into a PSR. If it had been easy to make the PSR then container-interop would be long dead now but unfortunately there was resistance against the PSR and container-interop ended up being used as a standard directly 😦

        • I do think that right now the “small scale” is an issue inside FIG, but I also think that the 3.0 proposal will address this. The resistance in the container-interop case it’s a separate issue, IMHO…

  4. Great write-up. I’ve been a lurker on the PHP-FIG list and okay I admit I found the train-wreck drama entertaining to hit my mailbox once a day in the digest. I think the self-throttling is ridiculous, come on this is the internet and it’s a discussion group. I felt compelled to post a reply tonight and then came across this article just now from Paul Jones twitter. Like the guy or not, I actually agree with many of his viewpoints.

    Thanks for the writeup.

  5. Pingback: Community News: Recent posts from PHP Quickfix (06.08.2016) – SourceCode
  6. Pingback: PHP Annotated Monthly – June 2016 | PhpStorm Blog

Your Comments are Awesome, Please Leave Them!

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s