Last week the folks at PHP.net announced that support for PHP 4 would end at the end of 2007:
The PHP development team hereby announces that support for PHP 4 will continue until the end of this year only. After 2007-12-31 there will be no more releases of PHP 4.4. We will continue to make critical security fixes available on a case-by-case basis until 2008-08-08. Please use the rest of this year to make your application suitable to run on PHP 5.
In parallel, a group of developers working on open source PHP projects have created GoPHP5, a site and community of projects all of which have agreed to drive PHP5 adoption. In order to be listed on the site, the project must:
Make an announcement on your site that by February 5, 2008 you will accept PHP 5.2 features into your codebase and will no longer provide support for lesser PHP versions. (versions or branches of your software already released by that date may continue support for older versions; this resolution applies only to new development.)
The idea is that unless a certain critical mass of key projects begins to require PHP 5, most shared web hosts won’t upgrade the version of PHP they make available to their users. Because the web hosts still run PHP 4, the developers of PHP projects still have to support PHP 4 – but so long as the developers continue to support PHP 4 there is no incentive for the hosting providers to upgrade:
It is a dangerous cycle, and one that needs to be broken. The PHP developer community has decided that it is indeed now time to move forward, together. Therefore, the listed software projects have all agreed that effective February 5th, 2008, any new feature releases will have a minimum version requirement of at least PHP 5.2.0. Furthermore, the listed web hosts have agreed that effective February 5th, 2008, they will include PHP 5.2 (or a more recent version) in their service offer.
WordPress, however, is not (and will not be) one of the projects on this particular PHP bandwagon. Ticket #4591 has been marked closed, wontfix:
This has been brought up probably half a dozen times, and our position is the same.
* PHP5 does not yet have sufficient penetration. On many hosts where it is available, it is not the default.
* We’re not going to turn WordPress into a protest piece at the expense of our users.
* We’re not going to set a date for the end of PHP4 support when there is no evidence to suggest that the hosting landscape will be any different on that date.
Matt Mullenweg also weighed in on the issue on his blog, arguing that:
Now the PHP core team seems to have decided that the boost their failing product needs is to kill off their successful one instead of asking the hard questions: What was it that made PHP 4 so successful? What are we doing to emphasize those strengths? Why wasn’t PHP 5 compelling to that same audience? Are the things we’re doing in PHP 6 crucial to our core audience or simply “good†language problems to solve? Will they drive adoption? How can we avoid releasing (another) PCjr?
(Tell us how you really feel, Matt.)
While I can understand the desire of the GoPHP5 folks to encourage web hosts to make available new language features, I have to say ultimately Matt’s right on this one. Explicitly choosing not to provide support to a group of users in order to force adoption of a new version is putting the cart (developer interests) before the horse (user needs).
That said, how can the PHP community get PHP5 more broadly deployed? (And deployed as the default at hosts which need to provide support for both 4 and 5, which will be the case at many shared hosts)? What do you do when the older version is successful people don’t see a good reason to migrate to the newer version?
I remember the bad old days of Netscape Navigator 4.x, and how terribly long it took for the number of users on NN 4.x to reach a low enough level that they could be “unsupported” from a web development point of view. Ajax would never have taken off so widely as a technique had it not been so easy to talk about supporting “All major browsers, 5.x or later” – dropping the old Netscape stack and supporting only Mozilla based browsers (and that MS thing). But that happened more or less accidentally – no one continued to develop NN 4.x as the company failed, and new and more compelling options (Firefox, Safari, Opera) appeared.
How do we get beyond PHP4 without leaving users behind?
More generally, how do you crank the adoption cycle to move faster, without forcing end-of-life?
Ubuntu‘s LTS releases “will be supported with security updates for 5 years on the server and 3 years on the desktop” – part of a deliberate strategy to reduce user’s risk of obsolescence and increase adoption of Linux. But PHP5 is already three years old – PHP4 was launched in May of 2000!
(Update: Just coincidentally came across this: 4 Years Ago Today – Netscape Corporation Killed, Mozilla Foundation Born. – I thought netscape’s death was even longer ago than 4 years. How quickly time flies).
I think there is something wrong with Matt’s argument in that he overlooks the fact that we are talking about open source here. The developers of said applications are probably all among the people that have servers available.
They are also the people that slow down their development process because they have to support the old OO model, cannot leverage things like PDO, iterators or simplexml. By not having these features available they have to waste time working around the limitations of PHP4. Now the end users do not feel their pain directly.
Indirectly they do however. More bugs due to userland implementations of things available in PHP5, slower code or more time needed to make the same features fast enough without using PHP5 features.
So yes, the problem with PHP5 adoption is that it did not really make anything new possible. Instead it focused on making life easier for developers. Mostly on the OO side of things, but also in other areas as well. As a result you can give your end users everything with PHP4 already, then again you could also with assembler.
By moving to PHP5 developers can more easily make the code lean, fast and reliable. The benefits to the end users might not be immediately apparent, but they should not be denied. What is the effort on the end users side? Well in all honestly very little. They need to keep updating their software today already as security releases are made available. Same goes for the hosters when it comes to keeping their PHP4 installs uptodate.
So while I do realize that there will be some pains here, I do not see that as significant enough to continue to slow down development of PHP apps.
Thanks for the comment Lukas. When I hear from someone who knows much more about the differences between PHP4 and PHP5 than I do – which you undoubtedly do – it makes me think I may be wrong on this.
Without question, the call to migrate to PHP5 comes from the development community. While the user community suffers *indirectly* from remaining at PHP4, they aren’t the ones calling for change, I don’t think – it is the development community.
What I’m reacting to, and I think Matt Mullenweg is as well, is the sense that the GoPHP5 approach holds users hostage in a debate between developers and web hosting providers.
Another way of looking at the problem is that PHP doesn’t have a single vendor who can force upgrades, as would proprietary, closed software. As a result, the only way we’ll ever get to using the new version is to stop improving apps in the old version.
But there’s still something about the language of the GoPHP5 manifesto (for lack of a better term) which seems to be saying that what developers want is more important than what users need.
Yeah, like I said .. end users do not need PHP5. But since they are using open source, they might see more happy/productive developers. This thing is meant as a way to break the chicken and egg situation that new major versions always bring. And yes, the end users will suffer a bit from having to upgrade their PHP version along with their next application update. But I think its a necessary step in order to give developers a chance at leveraging new tools for increased productivity.