Zend Guard and PHP 7

This is going to be a bit of a long post but I would like to begin with the end – after much deliberation, we’ve decided not to port Zend Guard to PHP 7 and beyond. Throughout the rest of this blog I’m going to cover both the history of Guard and what led us to this decision, as well as what it means to current customers.

If you’re using Guard and only care about the implications, you may jump to the last section. Even if you don’t care about Zend Guard at all, this might be an interesting read if you care about the history of PHP.

The story of Zend Guard

Zend Guard dates back to 2001, and was actually the first commercial product idea Zend had, and arguably, the one that got us to start the company in the first place. To give credit where credit’s due, the idea for the product actually wasn’t Andi’s or mine; with the explosive growth PHP was experiencing in the turn of the century and the dotcom boom, companies were actually coming to us, asking for a solution that would allow them to sell their apps without giving away their source code. For us, the fact PHP was becoming such an enormous success was already a bit difficult to get used to – we actually had a very hard time believing the statistics we were getting from Netcraft back in the day about just how rapidly PHP was growing. We thought they must have a measurement error and were off by at least an order of magnitude or two. But as these stats kept on staying consistent, and as the requests for a source-code protection solution – coming from real people, not just numbers in reports – became more and more numerous, Andi and I thought that maybe, just maybe, we could do something about it.

PHP 3, the first version I was involved with, is arguably the first version that bears strong resemblance to what PHP looks like today, even at 7. Of course, it’s missing almost two decades of evolution – but still, most PHP 3 source code would run on PHP 7 with relatively minor modifications. But with all of its revolutionary features – that triggered the popularity boom – it had some significant shortcomings as well. One of the key deficiencies was its execution engine, which in addition to being slower the more complex an app became – also made the whole concept of distributing an app in any form other than its original source code practically impossible.

This changed with PHP 4, which came out in mid-2000. PHP 4, which featured the first version of the Zend Engine, was the first version whose execution engine resembled in many ways the execution engine that is still with us to this date – throughout PHP 5 and even PHP 7. Conceptually, the Zend Engine compiles PHP source code into an in-memory representation, called Intermediate Code; a separate component then iterates over this intermediate code and executes it. While this engine evolved greatly in the last 15+ years, these principles, and even most of the way that Intermediate Code looks like, haven’t changed since its introduction. This new execution model had many benefits – most notably performance, which exploded through the roof compared to PHP 3. But it also paved the way to language-plugins, plugins that tie in very closely to the execution engine, and perform the equivalent of ‘brain surgery’ on it. Concepts like an opcode cache, debuggers, whitebox performance monitoring, as well as executing apps distributed in forms other than source code – suddenly became possible.

With the market need clearly established, and the technological barrier now gone – we went ahead and created the product whose maiden name was Zend Compiler.

As the years went by, the Zend Compiler evolved. It was renamed Zend Encoder, and later renamed into Zend Guard – as its source code and licensing capabilities increased. It has been a successful product for us that served thousands of customers, but as the company evolved, our focus transitioned more and more towards two key areas – improving the experience of production, business-critical apps and boosting developer productivity. While Guard was not a high-maintenance product, with every new release of PHP, we had to invest significant resources into porting it to the new version. With the growth of our production and developer productivity business, the relative importance of Guard gradually went down, making these efforts more and more difficult to justify – taking our developers’ time away from these key products our customers cared about the most. And with the recent release of PHP 7, that underwent the most far-reaching internals refactoring since the transition from PHP 3 to 4, we knew we hit a crossroads – the efforts required to port Guard to support PHP 7 are much greater than the efforts that were needed in the past to add PHP 5.5 or 5.6 support.

Another data point is that in recent years, open development around PHP has exploded, and even more so since the introduction of Composer. Modern PHP apps, both proprietary and open source, tend to have significantly fewer proprietary components – and instead reuse a growing number of open source components, making the need for a product like Zend Guard gradually decline.

After countless discussions and analysis, we reached the conclusion that our team’s time would be better spent in improving our core technologies – Zend Server and Z-Ray, than porting Guard to PHP 7. And as much as it’s difficult to make a decision that will eventually discontinue the product that triggered the founding of Zend, we feel it’s the right decision.

What does that mean for you?

This is the easy part. Zend Guard is still available on our store and if you’re already using it to protect your PHP 5 applications, you can continue using it and we’ll continue supporting it. For us, that means maintaining a team available to answer questions and help you get the most out of it. You still get all the source code and licensing protection that you’ve always relied on.

That’s the history of Zend Guard (and a little PHP) and where we are today. Feel free to reach out if you have further questions.

The following two tabs change content below.

    Zeev Suraski

    Zeev Suraski is CTO and VP of engineering at Rogue Wave Software, leading the Zend research and development teams. One of the principal authors of the PHP programming language, Zeev’s involvement with PHP dates back to 1997 when he co-created the foundation for PHP 3 - the first version of PHP that resembles modern PHP. Zeev later spearheaded the PHP 4 project - which made PHP the most popular development language in the world for web apps, contributed to PHP 5, and is to blame for the sixth version of PHP being named PHP 7. Zeev co-founded Zend Technologies (later acquired by Rogue Wave) in 1999. He holds a bachelor's degree in computer science from the Technion, Israel Institute of Technology.

    About Zeev Suraski

    Zeev Suraski is CTO and VP of engineering at Rogue Wave Software, leading the Zend research and development teams. One of the principal authors of the PHP programming language, Zeev’s involvement with PHP dates back to 1997 when he co-created the foundation for PHP 3 - the first version of PHP that resembles modern PHP. Zeev later spearheaded the PHP 4 project - which made PHP the most popular development language in the world for web apps, contributed to PHP 5, and is to blame for the sixth version of PHP being named PHP 7. Zeev co-founded Zend Technologies (later acquired by Rogue Wave) in 1999. He holds a bachelor's degree in computer science from the Technion, Israel Institute of Technology.

    • Tomáš Fejfar

      Reading the whole article – one obvious conclusion comes to my mind that you haven’t mentioned. Have you considered making Zend Guard opensource? That would lift the burden of maintaining it from Zend’s shoulders, still allowed Zend to supply support services for it, but most importantly would allow companies and developers to contribute to porting it to newer PHP versions. Or are there any downsides to it from your point of view?

      • http://www.roguewave.com Roy Sarkar

        We are considering it. For now, we’re fully committed to supporting the 5.x platform.

      • http://www.php.net/ Kalle Sommer Nielsen

        That could be an interesting approach, much like opcache was open sourced. However I think in all fairness for customers it shouldn’t be until the last security release of PHP 5.6 and PHP 5 finally goes EOL, and I realize this is December 31st, 2018.

    • Richard

      Not only have we now architected around the fact that our PHP code is encrypted but we have paid Zend for a lifetime licence for Zend Guard on the understanding that this product. And further, we have BEEN SITTING WAITING FOR ZEND TO UPGRADE ZEND GUARD, being forced to make coding compromises that we would not have had to had we moved to PHP 7.

      It is completely disgraceful that I have to find out about this move only because I ask AGAIN when it’s coming. Zend does not even have the courtesy to inform actively paying customers of a move that SIGNIFICANTLY changes the playing field regarding PHP strategy.

      This is not how you encourage customer loyalty!

    • Richard

      Zend is still selling Zend Guard as a product and, as at 25/01/2017 on the Zend site:

      – There is no reference to the fact that Zend Guard is a stagnant product.

      – The Zend Guard download page explicitly states the following: Get upgrades and support from the PHP experts at Zend, the PHP Company

      The above can at best be considered seriously negligent and at worst fraudulent. Either way it is completely disgraceful.

    • Otto Monnig, ZCE

      “the efforts required to port Guard to support PHP 7 are much greater than the efforts that were needed in the past to add PHP 5.5 or 5.6 support.”

      It’s too hard? Then let the open source community have it. Some of us still need to encrypt our IP.

      Glad I read this before I paid for another license. Thanks for nothing, Rogue Wave.

    • paυlιcy crιтιc

      well, you’ve got my last $600 Zend. I thought we had a partner that was vested in securing PHP for the long haul.