Monday, 13 October 2014

Who is driving this thing ?

Fig 1. A car crash
If nobody has acceptable control over a project, that project will crash. This year PHP celebrates 20 years of existence. For many years PHP has been the most widely used programming language on the web. I think we can say with some certainty that PHP is under control.

Quite often I come across the following sentiment:

Fig 2. A passionate individual

In a recent inspiring talk, given by Anthony (@ircmaxell) at #phpnw14, he encourages us to look upon what we normally perceive as trolls, to be passionate individuals.

I'm really trying to take this advice seriously; it has obvious benefits; even if that comment was made to flame and annoy, an opportunity has presented itself to ask and answer some important questions.

Specifically, the following:
  • Who controls PHP ? 
  • What are those people with control aiming for ?
I'm going to attempt answering those questions this morning.


Who controls it ?

In recent years, the PHP project has adopted an RFC (request for comments) based proposal system: Every time somebody wants to make a change to PHP, they have to write an RFC outlining their plan, communicate to all of the voting members what justifies their proposed changes, discuss on open mailing lists the implications and details of their proposal with the community at large. All of that has to happen before a vote is taken to decide if the proposed changes will be integrated into the PHP distribution.

Voting members are, for the most part, made up of internals developers, documentation maintainers, extension maintainers, and other systems designers and administrators.

To become a voting member, you do not need to be a C programming god, you don't even need to know C in any detail. What you do need to do is dedicate some of your time to trying to improve the PHP project.

One of our greatest strengths is definitely the documentation project, it is a huge part of what makes PHP so accessible, and remain so accessible. Being a documentation maintainer equips you with all kinds of intricate knowledge, it teaches you an enormous amount.

Some of the most valuable input during the RFC process comes from those individuals that don't actually write in C, but have bibliographic knowledge of the way PHP works in the real world; because they have dedicated so much of their time to documentation bugs and maintenance.

What are those people with control aiming for ? 

There is no answer I can give that applies to everyone, nor should there be.

If a person really thinks that their favourite framework, component, or package is not being represented in the decisions being made, then they need to appeal to the leaders of that community to do what it takes to get involved, or even do it themselves.

It might seem unfair, unfair that in some sense you have to earn a right to vote.

Facta, non verba.

You are familiar with this concept, it means "deeds, not words".

Words are cheap, it seems obvious that just because someone is talking doesn't necessarily mean they are worth listening too.

There are a lot of people talking; we should take seriously individuals that have proven they have the kind of knowledge it takes to make good decisions when it comes to RFCs, knowledge you can only get by being really involved.

Enough words, get involved.


  1. just fix the function name and parameter order inconsistencies already. it's the one thing _every_ developer I have _ever_ worked with has complained about. Year in year out I hear this. I have to double check it every time myself.
    We dont care about BC breaks, that's what version numbers are for.
    and no it's not "a cute quirk" about the language as many high profile PHP people seem to think...

    (third time I'm writing this, comment box keeps deleting it to log in...)

    1. So, honest question:

      If parameter order was changed. Say changing the order of needle-haystack to be consistent across strings and arrays.

      How would you write code that worked on multiple versions? Or would everything have to be "this or that", and have compatibility (in any way) be out of the question?

    2. you have pre version x and post version x code, yes. I think being on the brink of a major version bump, it's a better than ever time to finally get this out of the way.

    3. @Anthony You could use a userland compatibility abstraction layer for the string/array functions in that scenario to write cross-version code.

      I'd much rather see the OO scalar API RFC implemented in PHP7, though.