The end-of-life announcement for PHP 4 has prompted a lot of discussion about whether PHP 5 is worth adopting at all, and even whether or not PHP 5 has hurt PHP as a whole. The technical arguments have been debated (and, alas, that will continue no matter who says what) on the Net for some time now.

What I’m not seeing are the commercial arguments to move to PHP 5 (/me points an accusing finger at the folks from Zend, with whom this discussion has been had before). Businesses will only make the move when there is something to gain from the effort, when the rewards of switching are more than the cost of doing nothing. So let’s see if we can find some reasons to chivvy them along!

Here are the arguments I’ve been making for the last 3 years to pointy-haired bosses that many technical folks ultimately have to answer to. What commercial arguments have you tried in your workplace? Post the good ones that have worked in the comments below, or on the Net on your own blogs for us all to share.

— Stu

Why Move To PHP 5?

Money. Spending less of yours, and taking more from your customers.

You will spend less of yours, because PHP 5 is a more mature, more robust, and more reliable version of PHP – especially if your favourite buzzwords are XML, XSL, or OO. There are better tools available for your developers to use to make sure that the quality of their work is proven.

You will take more money from your customers, because your developers will be able to deliver more work more quickly (especially if they program using objects), and because you can do more with PHP 5 than you can with PHP 4. You can take advantage of emerging frameworks that can be used to reduce the amount of code that your developers have to create for themselves. Adopting a framework, or building your own in-house, gives you a competitive edge. Witness the rise in popularity of Ruby on Rails as evidence of that.

If you sell services rather than software products, there are opportunities to be had. There’s an awful lot of code out there that needs moving from PHP 4 to PHP 5, and someone needs to be paid to do it … ๐Ÿ™‚

I’ll be the first to admit that the case for moving to PHP 5 is quite weak. It’s been perfectly possible to build great websites on PHP 4 up to now, and any responsible manager isn’t going to sanction a move to PHP 5 just because it exists. Until now, doing nothing about moving to PHP 5 has cost nothing. But this is now changing, because the gig is up for PHP 4, and doing nothing now has some real costs associated with it.

What’s The Cost Of Staying On PHP 4?

First and foremost – security. Security on the web is an arms race. The good guys come up with something neat, and the bad guys find a way to twist that to their own purpose – breaking into your customers’ servers, and stealing your customers’ data. For the moment at least, the bad guys are always finding new ways to attack your applications, and also to attack the PHP engine that powers your applications. Responsible suppliers are always releasing updates to their applications to close those security holes – and you see yourself as a responsible supplier. Don’t forget that you need to be keeping the PHP engine up to date too, otherwise you’re leaving security holes open. Staying with PHP 4 is going to be a problem for that.

From the end of the year, the PHP 4 engine will no longer be updated. If something really nasty comes along before 8th August 2008, maybe there will be another PHP 4 release with the fix your customers need. Perhaps, but perhaps not. You can be damn sure that there will be another release of PHP 5.

Second – loss of opportunities. Today, if your web app doesn’t work with Firefox, it’s more difficult to sell. The days of IE-only solutions are over. Tomorrow, if your web app doesn’t run on PHP 5, it will be more difficult to sell. Your customers will have moved on, and will be running PHP 5 on their web servers. Your product isn’t going to work … unless you upgrade.

Third – loss of face. The web is all about the Next Big Thing. How are you going to look, trying to sell something that runs on a platform (PHP 4) created in the year 2000? Especially one that the bell as well and truly tolled for? It’ll be like trying to sell a web app that thinks framesets are still a good idea, or that tables are the One True Layout Tool.

What Are The Barriers To Moving To PHP 5?

By and large, PHP 5 is backwards compatible with PHP 4. There are some things that you’ll need to address, but unless you were heavily into XML, XSL via Sablotron, or the PHP/Java bridge, they’re quick enough to sort out.

Managing your code base is probably going to cost your more than adding PHP 5 support in the first place. If you’re in the product space, that’s not too bad – simply pick your cut-off point, and everything going forward from there is released for PHP 5. If you’re in the solution / consultancy space, chances are each customer’s got a unique solution, and managing each of those is going to consume a lot of time. Upgrading your customers from PHP 4 to PHP 5 is going to take a lot of time too, especially if you manage installations and upgrades on their behalf. These are not PHP problems; they are standard release management problems that all firms face.

Running both PHP 4 and PHP 5 on the same server is a pain. This is probably the biggest barrier to entry, and probably the biggest fustercluck that the PHP Group made when they introduced PHP 5 three years ago. (Time will tell whether or not they have learned their lesson for PHP 6 …) By largely making it an either/or choice, they inadvertently held up PHP 5 adoption. Hopefully, your hosting company will be making the switch to PHP 5 soon (many have not yet). If they’re not, it’s time to find a new hosting company. If you’re doing your own hosting, or your customers are, then a clear switchover is the best way forward. To save on loan hardware costs, use virtual machines for your customers to do UAT on.

The best advice I can give is that it’s going to hurt whatever it hurts. It’s a cost of doing business. Get over it, and get on with what needs doing to move from PHP 4.

How Do I Cover My Costs Of Upgrading?

Hopefully, you’ve understood that this day was coming, and you’ve been putting money aside to cover at least some of this work. The software you sell has depreciated, like any other asset, and you should have budgeted for that. If there’s a shortfall, you do have a few options.

Can you directly pass the costs on to the customer? Sell them your product as a brand new version, with a suitable license fee attached. Then use your Professional Services team to charge them for any installation and server-configuration work that you have to do.

If you can’t pass the costs on, take the costs out of the money earned by the support contract. If you’re in this situation, your support contract is supposed to be offsetting these costs anyhow. You’ve been charging in advance for this moment; one could argue you now have a moral obligation to pony up the goods.

Find new services, products, or components that you can sell to the customer after they have upgraded. Maybe there’s a particular pet feature they’ve wanted, but you’ve put it off because it was too much trouble to implement in PHP 4? Find out if they’ve got the budget, and sell them the new stuff to offset the costs of the upgrade.

Give them the upgrade for free, deliberately. Use it as a tool to win more work from the customer.

Find new markets to sell the upgrade into. Maybe you’ll decide it’s not worth continuing to sell the product into your old markets, because they can’t afford to buy your upgrade, or they’re costing you too much to service. This could be your opportunity to improve your earnings per customer and save face all round at the same time.

What Are The Alternatives To PHP 5?

You can’t stay with PHP 4. That doesn’t mean that you have to go with PHP 5. You can choose to jump ship entirely, and switch to a different technology. There’s a much wider choice than there was back in 2000 when PHP 4 was released, and each choice brings its own opportunities and risks.

Ruby on Rails is the up and coming technology that everyone’s looking at. Despite what Terry says about it, there is good money to be made by adopting Rails as a solution. You can create solutions in Ruby that are a pain in the arse to create in PHP, or which aren’t possible at all. You can sell Rails solutions to customers who won’t touch PHP with a bargepole, because Rails is seen as ‘enterprisey’ and a valid competitor to Java and .NET. Developers of all skill levels can be productive with Rails in a matter of hours, and most of them will prefer it over PHP. You can create Rails applications that run on Java (via JRuby) and .NET (via IronRuby); these in particular are emerging markets where competition is still thin on the ground.

Ruby’s performance isn’t what it could be atm, and the language authors are working hard to address that. Many of the third-party plugins for Rails are of limited quality and capability. Use what you can, but be prepared to adapt (or create for yourself) what you must. Keep on top of licensing issues, especially when selling solutions to government agencies or other organisations who need to be able to protect themselves from IP violation lawsuits. Watch out for performance bottlenecks in badly-crafted code. Ruby can lend itself to Perl-like impenetrableness (but can also lend itself to beautiful code too). Be prepared for reluctance if your developers are expected to return to working with PHP at some point.

Java’s still there as a solution, and although lots of folks hate it, the J2EE stack just won’t go away and die. In fact, companies like Red Hat and organisations like Apache are putting more weight than ever behind Java. Java is accepted in plenty of places that PHP isn’t, and in particular is backed by a whole host of developer tools that PHP developers can only drool over. Sun is fighting hard to keep Java alive and relevant (especially in the face of the threat from Ruby), and has recently opensourced Java in an attempt to breathe new life into the language and the platform.

Java is a language for pendants first and foremost. Not the ones who keep you out of trouble because they know where the problems lie, but the ones who secretly wish they were able to control every tiny aspect of what you do. Everything done in Java seems to take twice as long as in any other language, if your developers don’t give up in frustration first at the hoops that they have to jump through to try and get anything done. Java should have taken over the world, but it somehow missed the boat, and in the medium term it may well decline in importance.

.NET from Microsoft completes the list of major alternatives to PHP. Lots of companies choose Windows as their platform of choice, a platform that PHP sadly sucks on when compared to Linux. Like Java, .NET has particularly strong development tools, and is accepted by organisations that won’t adopt PHP. It’s just as at home creating web-based applications as it is desktop applications. The saying goes that no-one ever got fired for buying a Microsoft solution; by embracing the Microsoft ecosystem, you gain access to a large cross-section of pointy-haired bosses who live by sayings like that one.

Online documentation can be disappointing with .NET, especially for folks used to the excellent PHP manual. Although .NET does include ASP.NET, many .NET solutions also end up using the C# language, which can be difficult for folks to switch to from PHP. The cost of developer tools is an issue, as is the cost of support from Microsoft; going down the Certified Partner route is a popular solution, but that involves retaining staff who have passed specific Microsoft certification exams. (I have to say, though, that I’ve found Microsoft’s support absolutely first rate each and every time I’ve had to call on it).

There are other alternatives too, but they are nowhere near as mainstream or as acceptable to potential customers.

Making The Move

Hopefully, I’ve convinced you to do something about your current dependence on PHP 4. Preferably, you’ll shift your products and services to PHP 5 (and PHP 6, which can’t be far away now), but there are viable alternatives if it’s time for a change in direction.

If I haven’t convinced you (or your boss!), let me know in the comments below. I’m very interested to hear how folks are going to justify sticking with PHP 4 in the future, and what arguments have worked for you in convincing your pointy-haired boss to make the move away.

No Comments

  1. nick says:
    July 31st, 2007 at 1:56 am

    I’m not sure the “update now or we won’t give you security updates” is going to fly well with decision-makers.
    But fortunately Debian has higher standards in that regard than the team.

  2. Mrasnika’s Lair » ????????? ?? ?????? ? ??????????? says:
    July 31st, 2007 at 5:34 am

    […] Arguments From The Boardroom, Not The Bedroom […]

  3. Fabien says:
    July 31st, 2007 at 11:36 am

    You can also give a chance to Django which is a Python web framework. It has been used for example in Pownce.

  4. » Stuart Herbert’s Blog: Arguments From The Boardroom, Not The Bedroom says:
    July 31st, 2007 at 3:26 pm

    […] Stuart Herbert looks today at some of the reasoning behind the push to move developers out to PHP5 – specifically that there’s a lack of commercial-related discussion about what issues there might be. What I’m not seeing are the commercial arguments to move to PHP 5 (/me points an accusing finger at the folks from Zend, with whom this discussion has been had before). Businesses will only make the move when there is something to gain from the effort, when the rewards of switching are more than the cost of doing nothing. So let’s see if we can find some reasons to chivvy them along! […]

  5. David Goulden says:
    August 2nd, 2007 at 9:37 pm

    If I wanted to be a nasty cynic I could say I’m not seeing is the commercial arguments for Zend to push PHP5 ๐Ÿ˜‰ – seriously, until the GoPHP5 campaign came up, there was little active community discussion about it and from our perspective, almost all new development is done in PHP5. It just wasn’t really an ongoing slog argument that we needed to have, it was a given, unless you were stuck with RHEL 3&4 official RPMs. If I’m already wearing a Zend apologist hat here’s a little more perspective (again, not a Zend corporate official blah blah blah):

    For a start, since 2005 we’ve offered Zend Core, first for IBM DB2, then Oracle, then for Microsoft Windows and also for IBM i5/OS. If you want commercially supported PHP with corporate backing from Big IT, we offer it and it’s PHP 5. Only.

    Frameworks. No need to go into Zend Framework details here, but of course one of the major considerations was to showcase PHP 5 goodies. The RoR thing you’ve mentioned before, but frankly from where I sit, I’ve seen 2 companies in the last 3 years move from PHP to Ruby: 1 was a Czech adult entertainment company, 1 was small British media-centric web dev company. Possibly I’m hanging around the wrong people but I doubt it, my customers are damn smart, make their technology choices very soberly and are very savvy about the business wisdom of adapting quickly to new technologies. Of course, your company is selling a solution, not a language and development process, so you’re inevitably having different types of discussions with customers.

    Lastly, moving to PHP 5 is something Zend of course actively push with larger customers (smaller ones tend to have less complicated IT set ups and can move quicker) especially via our professional services engagements such as training (PHP 5 certification for starters), architectural reviews and audits, and PHP industrialization projects. I pray you have no any idea how complicated, political and time consuming it is to get a large telecoms company to change it’s architectural choices. An example: It took 1 year to even get a decision made to move a large European telco from PHP4 ->5 (ironically the same company has the largest PHP5 cluster I’ve heard of in Europe with over 2500 servers) – those developers just went ahead and used it regardless. That’s 1 year of learning the company politics, countless meetings, developing a strategy and taking some (considerable) money in the meantime for other services & products. So there’s very little commercial reason for Zend to actively push PHP5 for it’s own sake. Of course we influence where we can, but when customers are stuck with PHP4 for whatever reason (generally a very large code base or geographically dispersed installed base) we have to respect that. They’ll move eventually and it’s just not worth the (very human intensive) effort on our part.

    Nick @1 – Debian may have higher standards, but from what I see, Red Hat flies well with the economic decision makers (and we do likes the Debian)

    Just waiting to see the Perl, Erlang and Lua fans start recommending their technology of choice here in response to Fabien @3 ๐Ÿ˜‰

  6. William Betts says:
    October 28th, 2007 at 5:43 pm

    I guess I’m lucky, because everywhere I’ve been at in the last 2 years has used PHP5. I can see why the pointy hairs wouldn’t want to change their entire code base. The cost of doing that would out weigh the benefits.

  7. Federico Feroldi’s blog » Blog Archive » links for 2007-11-12 says:
    November 12th, 2007 at 8:24 pm

    […] Stu On PHP – ยป Arguments From The Boardroom, Not The Bedroom (tags: php php5 business php4 migration ruby rubyonrails web frameworks) […]

This Month

July 2007
« Apr   Oct »