Where are the PHP 4 developers?

Posted: 10 January 2008

• PHP
• Drupal
• Web development
• GoPHP5

Marco Tabini, of php|architect magazine fame among other things, has been openly disappointed at the death of PHP 4. Not because he likes PHP 4, but because of the "OMG you're discontinuing something that everyone's still using!" argument.

I like your magazine, Marco, but I have to disagree with you on this one. :-)

The problem is the source for that "everyone" claim. The most widely referenced stats are the Nexen stats, and according to them 70%+ of the world still uses PHP 4. Horrors! That means, as Marco claims:

that nearly three quarters of the developer population is essentially being hung out to dry.

Except that is not what the Nexen stats say at all. Let's have a look at the collection methodology (French, English). The data is based on HTTP headers only. Not on number of servers that are actually in use rather than just happen to have PHP installed, not on number of domains showing .php files, not on the number of pages returning headers indicating they were actually build with PHP of some version; just on the number of servers whose Apache header happens to say PHP in it.

Of course, the methodology listed doesn't say if it checks IIS headers, too. Or what severs were even polled, other than 11 million were used out of 28 million polled. Does it count virtual hosts separately or not?

Even if we assume that the Nexen stats are completely valid, however, they are valid for what they are testing, which is the number of servers returning a given PHP version in their header. That is not the same thing as the number of PHP developers in the world. At absolute best, one could argue that 3/4 of the Apache servers in the world are "being hung out to dry". That, of course, is assuming that they're all actually using PHP rather than just have it installed.

That also assumes that there's a single PHP developer market, which is also not true. I'd group PHP developers into a few categories, market-wise:

• Dedicated app, controlled server. The developer gets to pick the version of PHP they want to use, so they'll pick whatever they want. Even if you're not doing OOP, anyone who has chosen to start new development on PHP 4 with no regard for PHP 5 in the past 2 years or so has simply not been paying attention. Dropping PHP 4 is not a problem here.
• Dedicated app, uncontrolled server. The sysadmin dictates the version of PHP that is run, and the little developer peons say "thank you sir, may I have another". The sysadmin in this case is likely either demanding that they use the latest security release, in which case they should now be on either 4.4.8 or 5.2.5, or refusing to budge from what came pre-installed on their Red Hat box. Well, even the latest RHEL now ships with PHP 5.1.6. Red Hat agreed to provide support for older versions of RHEL for 5 years, not the PHP dev team. I'm sure Red Hat (and SuSE, Canonical, etc.) will be happy to "maintain" PHP 4.2 or whatever they ship with if you pay them a big enough support contract. Nothing wrong with dropping PHP 4 here, either, as someone else is already contractually required to support them if they want.
• Custom app, shared server. This was the big stumbling block for most general-market developers, as they needed to remain compatible with some mythical majority of shared hosts that users (who neither know nor care what a PHP version is) were using. Well... there is no shortage of PHP 5-friendly hosts. This argument is gone, too. If someone is "forced" into PHP 5, there are plenty of places they can go for hosting, from tier-one professionals through mom-and-pop.
• Off-the-shelf app. Whether commercial or open source, these apps had the same challenge as the previous group where they needed to run on any conceivable server. As a result, any worthwhile ones have run just fine thank you on PHP 5 for years now. If they don't, even today, that means they've been abandoned and you're SOL anyway (unless it's an open source app, in which case you can maintain it yourself; which still has nothing to do with PHP 5). Moving to PHP 5 here is no longer an issue with any program worth mentioning, and in fact will soon be a requirement for nearly all of them.

So uh, where's that 70%? The only people "hung out to dry" are those with legacy code that they never tested on PHP 5 whose sysadmins are going to now, suddenly, upgrade to PHP 5.2.5 and break everything. Of course, the PHP project has no legal relationship with those users. Red Hat may, in which case it's up to Red Hat either way. And the there's that "break everything" claim, which is FUD. Yes there are some issues, but if you were writing decent code in the first place then cleaning it up to make it PHP 5-friendly (as opposed to PHP 5-dependent, which no one is requiring you to do) should take maybe a day or two. All of the potential pitfalls are documented.

As an aside, that's yet another reason to leverage existing open source projects and communities rather than rolling your own proprietary code: Long before you need to upgrade someone else probably will, and so much of the work will be done for you. And if you help out, much of the work will be done for them, too, with a huge number of testers just waiting to find bugs. Drupal, Joomla, Typo3, WordPress, Squirrelmail, Gallery, Zend Framework, Qcodo, Cake, Symfony, and the many other open source PHP projects of note have long since either gotten PHP 5 compatibility or been abandoned (by definition, remember)? And when PHP 6 comes out, I'm quite confident that they will all be PHP 6 compatible long before most custom apps are.

So then, even if we assume that 70% of PHP developers are using 70% of random servers running PHP, and that they're all using proprietary, one-off applications on a server with a sysadmin who refuses to upgrade at a company that has no support contract with any distribution vendor... Where are they?

cricket cricket cricket