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.