The PHP Community Starts the PHP 4 Sunset, Gears Up for PHP 6
February 18, 2008 Timothy Prickett Morgan
The community behind the PHP scripting language that controls much of the Web application infrastructure out there on the Internet and on corporate networks has been evolving for a number of years. And now PHP 4, the language that put Zend Technologies on the map and was replaced two years ago by PHP 5, is being sunsetted by the PHP community. PHP 5.2 is the products customers need to be using as they ready for PHP 5.3 this year and PHP 6 next year.
PHP 5 was a pretty bold upgrade, with object oriented programming and Web services built in, among many other technologies, but it got off to a bumpy start because of scalability and stability issues. But Zend says that PHP 5.2, launched last fall, cleared up those issues, and now it is tackling bigger problems with the upcoming PHP 5.3 and PHP 6. Andi Gutmans, one of the founders of Zend and its chief technology officer, explained that is going on in the PHP community in a recent interview.
Timothy Prickett Morgan: So it looks like PHP 4, which was announced eight years ago, is riding off into the sunset.
Andy Gutmans: The PHP community decided–and Zend is obviously contributing there–to stop PHP 4 development on January 1, 2008, and then in addition has also decided to stop doing any bug fixes on PHP 4 by August 8, 2008. So that will be the day when the community will completely stop maintenance on PHP 4. Obviously, the product is open source, so if there are any organizations that need to get support beyond that, they have the source code available.
The community decided to stop support on PHP 4 for a few reasons. First of all, PHP 5 has such huge advantages over PHP 4. Plus we are working towards a “big” minor release of PHP 5 and a major release, PHP 6, that it just didn’t make a lot of sense for us to maintain three different development branches. In addition most of the new application development in PHP is being done in PHP 5. There is still a huge installed base of applications on PHP 4, but when you look at new development, this is being done in PHP 5. Also, all of the hosting providers today will give you PHP 5 support if you ask for it, so that isn’t an issue any more. And finally, we have an initiative called GoPHP5.org, which is an initiative from the community where a lot of the application vendors whose applications up until now have not supported PHP 5– Symfony, Typo3, phpMyAdmin, Drupal, Propel, and Doctrine–have joined this initiative and have decided to move their applications to PHP 5.
TPM: That was my main question, really. I did not choose Typo3 as the content management system for IT Jungle because it did not support PHP 5 a few years ago, but only PHP 4. How quickly can these application programs be moved over? There is a pretty big change in programming model in moving from PHP 4 to PHP 5.
AG: A lot of people had the same reasons as you did for not moving to PHP 5, and it held them back. The GoPHP5 initiative runs on PHP 5 and Drupal, and you can go there and see the amount of progress we have made.
TPM: There’s usually an 80-20 rule in any kind of software stack or business model. So it is always the key 20 percent of applications that drive 80 percent of the revenue in a business that get ported over first. In Unix environments, there are typically around 3,000 key applications that really drive the platform, for instance. Is there a magic number for PHP for the key applications that need to be ported and how close are you to that number?
AG: There are probably around 10 to 15 key applications, and all of them are part of the GoPHP5 initiative, but the initiative also has a longer tail of projects that have committed to being on PHP 5. As of February 5, more than 100 projects and 200 service providers are on PHP 5. If you go to SourceForge, you will see thousands and thousands of PHP applications, but all of the popular ones are now supporting PHP 5.
One more thing about the transition to PHP 5.2, which is the latest release. It is actually not a very painful migration for most customers, and Zend has migration services to help in the move to PHP 5.2. We have some homegrown code that looks for potential breakages when applications move from PHP 4 to PHP 5.2. This is a strategic initiative for Zend, of course, because this is where we see the future. The faster we can get our customer base onto PHP 5, the better.
The commercial adoption of PHP 5 has been much more rapid than among the ISVs. We saw a huge uptake in PHP 5 among our customer base, just watching what they were downloading and what support tickets they were opening with Zend, that was much faster than you could see among the ISVs. Today, the vast majority of our commercial customers are building on PHP 5, and that is understandable given the challenges they have in coding for the modern Web. They need the technologies offered in PHP 5–object oriented programming, Web services, and so forth–to get to the next level.
I think that the biggest pain point for most customers is that they have to go through another quality assurance cycle. For those who are not using a lot of object oriented programming, the move to PHP 5 doesn’t make almost any difference. And for those who are, it usually only takes one or two days to migrate the application over and then you have to do the testing, of course. XML is another piece that is pretty easy to port over.
TPM: So what is cooking with PHP 5.3 and PHP 6? PHP 5.2 seems to have cleared up some initial stability and performance issues in PHP 5.0 and performance issues with PHP 5.1.
AG: Right now we are cooking another “major minor” release with PHP 5.3, by which I mean it is pretty major even though it is a minor release. One of the big projects for PHP 6 is native Unicode support, which is something that takes a long time to fully bake and to get right. So we are anticipating a long rollout cycle for PHP 6, and we did not want to take the same route that the Perl project did, with project contributors still working on Perl 6 I think six years later. People make fun of Microsoft, but take a look at Perl 6. . . .
We didn’t want to be caught in the same situation, so what we are shooting for a pretty major release in PHP 5.3, where we are going to have things like namespaces, and we are going to have a big piece of the internationalization support that was planned for PHP 6 pulled forward into PHP 5.3. The good news is that we have had some corporation contributions for this work, from Yahoo and Live Nation, for this effort. And then we are going to add in some smaller features, such as garbage collection.
TPM: What are the estimated launch dates for PHP 5.3 and PHP 6?
AG: As we are an open source project, it is very hard for me to give you a date. The talk right now is to release PHP 5.3 beta 1 in the first quarter, and if it is not going to be Q1, then I don’t think it will be far beyond Q1. Historically, we probably do around two betas and then two or three release candidates. I am hoping PHP 5.3 will be done by the third quarter, but that depends on how much feedback we get back from testers.
PHP 6 is probably a 2009 launch. I would like to betas of PHP 6 starting around the time we launch PHP 5.3, so we can start getting feedback. Unicode support is a very big deal, and it also has the potential to break a lot of applications, so we are going to take much more time with that roll out to make sure that anything we can do in the language to prevent breakage and to make the migration easier, we will be able to do. We are not going to pressure ourselves with PHP 6. We’re going to do it right. Doing PHP 5.3 the way we are planning it gives us a breather.