Clearly, PHP is one of the most important open-source technologies on the
planet.  In this interview, we talk with Zeev Suraski, CTO of Zend (twitter) and
co-creator of PHP about where PHP has come from, and where it's heading.

• The development of the Zend Framework and Zend the company
• On the rise in popularity and the lasting success of PHP
• The history and future of PHP adoption and innovation
• The evolution of the relationship between PHP and Microsoft
• The future of cloud computing as it intersects with PHP

Scott Swigart: First, could you please introduce yourself, and tell us a little about Zend Framework?

Zeev Suraski: Sure. I’m co-founder and CTO for Zend Technologies, one of the principal contributors to PHP. I’m also responsible for the Zend Framework project, and I lead the R&D organization at Zend.

PHP is obviously at the base of our technology stack. My colleague Andi Gutmans and I became involved with PHP as students back in 1997. We actually used PHP/FI v2 two beta, which was written by Rasmus Lerdorf.

We ended up rewriting it from scratch, and that was the beginning of the PHP project in a form similar to what it is today: a community project with a lot of different contributors at many different levels. We’ve been involved ever since.

I spearheaded the development of PHP 4, and Andi spearheaded the development of PHP 5. And five is where we are today, with six on the horizon but not quite baked yet.

Zend Framework is an open source project that we started in 2005 with a mandate to provide infrastructure classes for PHP applications. Zend Framework was definitely not the first framework to exist for PHP, but in a relatively short amount of time it became one of the most popular, and it’s probably the most popular in commercial environments.

Scott: What are some of the factors that have helped make Zend Framework popular?

Zeev: Developers appreciate the fact that Zend Framework is designed to work well with other frameworks so they can use it for the parts of a project that they want to, and they are free to use other frameworks or custom code for other parts of that same project.

It’s an easy choice to make, because a developer can get started with Zend Framework and then use it more extensively as he or she sees fit.

Interestingly, just last week, there was a conference in France called Symfony Live, which is the yearly conference of Symfony, another very popular PHP framework. They announced that, in the next major version of Symfony, they’re going to use parts of Zend Framework as the basis, instead of reinventing the wheel again.

I think, in a nutshell, that gives a pretty good indication of how far Zend Framework has come in terms of becoming somewhat of a standard for building PHP applications, so that even other frameworks sometimes decide to rely on it.

Scott: How does Zend the company fit into the equation?

Zeev: Andi and I founded the company in 1999, with a broad mandate to provide solutions around PHP. That’s kind of the mile-high view of the company.

At ground level, there are several interesting facets of business. First, we are very deeply involved in the open source projects that I mentioned. That includes PHP itself, for which we’re still major contributors, and we’re probably the biggest contributor and maintainer of the engine, called the Zend Engine.

In addition to that, there’s the Zend Framework, a community project for which we are leading the way and contributing alongside countless other contributors outside the company.

There are some other open source projects we’re involved with, like PDT, the Eclipse PHP Development Tools project that we’re leading, and a couple of others, but those are the major ones.

Zend also provides commercial software on top of the open source software. For instance, for development, we offer Zend Studio, which is an advanced version of PDT with a broader set of features.

On the server side, we offer Zend Server, which provides an easy-to-use, easy-to-install version of PHP, plus quite a few additional features around performance optimization, proactive monitoring and root-cause analysis, job-queuing, scalability, and so on. We offer both a free and a commercial version of Zend Server for Windows, Linux and IBM i. The free version is not entirely open source, though, so it’s not in the open source line.

Scott: Can you tell the story of how you got involved in PHP originally?

Zeev: OK. In 1997, Andi and I were students in the Technion, a technology university in Israel. While in school, both of us were also working part-time at Internet service providers. Early on, we found that we preferred the practical aspects of our work in the ISPs over our more theoretical studies.

Obviously, as part of the curriculum, we had to develop several projects, and one of the projects we decided to take on was to develop a shopping cart application. Today, one can choose from various shopping carts available to just download and maybe hack a bit to make it one’s own; but back in 1997, this kind of work was considered cutting-edge technology.

We were the only two students who asked our instructor for permission to use PHP/FI as our language for developing the project. All of the other students asked for Perl, which was the undisputed king of the web at that time.

I was familiar with PHP/FI through my part-time job, and thought it would be easier than Perl with its headaches, so Andi and I decided to use it. It wasn’t easy to convince our instructor to let us use this thing called PHP that she’d never heard of. Eventually, she agreed, but with a warning to us that, “If you bump into issues, because this is not very standard, then it’s your problem.”

We started implementing the project, and about 30 or 45 minutes into it, we started bumping into the kinds of issues that forced us to eyeball the source code to figure out where things were going wrong.

We were looking at parse errors, syntax errors and such, from all different sides, and trying to trim and cut the code and see how it behaved. After a while, we concluded that we weren’t doing anything wrong; there were parser issues that made it reject perfectly valid code.

We sent an email to Rasmus Lerdorf, because it had become clear to us that the language didn’t understand its own basic syntax. He came back to us and said, “Look, guys, I’m not a CS major. I just hack this around. Feel free to propose patches.” We decided to give that a try. We dove into the source code, trying to understand it more deeply, and we were pretty stunned by what we saw.

On one hand it was pretty amazing that Rasmus managed to create something that worked as well as it did, given the lack of architecture. On the other hand, the experience was like opening the hood of one’s car and, instead of an engine, there were mice running to move the wheels. Very impressive if those mice could make the car drive reasonably well, but still not the kind of engine one would choose to power the car on the highway…

Since we preferred the practical elements of computer science to the theoretical ones, we decided to try to implement it from scratch, to see how far we could go. We managed to write it from scratch, and during that time, we not only changed the implementation; we also turned PHP/FI, which was sort of a partially defined pseudo language, into a much more well-defined one. By the way, Rasmus did fix the parse error we bumped into very shortly after we reported it, but the seeds were already sown.

We literally eliminated the possibility for the language not to understand its own syntax, by using the compilation tools the right way. I want to add here that our compilation techniques professor, Michael Rodeh, pushed us to touch base with Rasmus and convince him to move over to our implementation. That in itself is interesting.

Rodeh had a firm view that there are too many development languages in the world, and he didn’t want to be in any way responsible for the creation of yet another one. He hoped we’d convince Rasmus to replace his version of the language with ours, and join us in working on the new implementation.

We weren’t sure that Rasmus would do it, but he was actually quite happy to, and that’s the story of how the modern incarnation of the PHP project was born. Rasmus had been working almost solo on PHP/FI 1 and 2 between ’95 and ’97.

Scott: It’s interesting, because PHP is such a long-lived language, whereas so many other web-programming languages have sort of risen and fallen, although PHP has obviously gone through a lot of evolution, as well.

I worked as a developer for a long time, and like many developers, I often found that I just wanted to use a new programming language or a new framework on the next project, so I could learn more. And so, over the years I have explored all kinds of UNIX shell commands, scripting languages Tcl/Tk, web-development languages, low-level C++ and more.

PHP is really as much here to stay as it’s ever been. Why do you think it has been so successful and long lived?

Zeev: I don’t pretend to know the complete answer to that question, because at the end of the day, a lot of this has to do with dynamics that are too big to analyze.

But, if we put aside a strictly scientific answer, I think that the key ingredient from a technology standpoint is the focus on simplicity. Trying to really solve the web problem in the simplest possible way, and not necessarily always the most ‘elegant’ way.

I think that some people might look down on PHP, because it might not always do things in the elegant way that they expect. Another way to put it is that I think Perl prides itself on the ability to do one thing in many different ways, and to do so in a way that looks very elegant.

At the same time, some people would look at that same piece of code and while they might find it elegant, they might also find it very difficult to comprehend.

With PHP, we have avoided that and focused instead on keeping things simple. We have not tried to create a general-purpose language, but rather a web-specific language. From the beginning, the PHP community started to thrive, and we had a self-nurturing cycle.

In addition to the language itself being simple and easy to use, and very fit for web applications, developers have been very enthusiastic about it and helped others move into PHP. Those were the two key factors for success: a self-nurturing community and PHP’s simplicity. There are many factors, but honestly, they’re all that unique to PHP, such as good support for databases. We had very good support for MySQL very early on.

Probably, the reverse is also true, and MySQL may owe some of its success to PHP in much the same way. It’s difficult to say which project contributed to which other project more.

Scott: I saw something similar happen with Visual Basic, which also set out to be simple. Its initial goals were to be very approachable and learnable, helping people become better programmers and get more done.

I would imagine that PHP probably faced a little bit of tension because of its focus on simplicity and giving people an easy way to get things done. Specifically, it was relatively easy for people who didn’t have computer science degrees to pick it up and be productive with it.

I imagine that PHP really had to evolve to try to be very approachable and learnable by amateur and hobbyist developers, while also meeting the needs of some of the best developers. Is that where something like the Zend Framework comes in? Talk a little bit about how PHP has addressed that tension over the years.

Zeev: PHP 3 became very popular very quickly. We designed it as a powerful language, but with simple, small apps in mind. In practice, though, more and more people were using it for fairly complex applications with growing needs for performance. It quickly became apparent that Andi and I weren’t two geniuses that got it right the first time around.

Almost immediately after PHP 3 was out, Andi and I realized that we could have done things differently. Developers were beginning to use PHP for really complex and demanding scenarios. Basically, the language was playing catch up between functionality and performance. It was capable, but slow, so with PHP 4, we made a lot of progress to solve that problem.

In PHP 5, which was the next step, we really re-invented and re-implemented the whole object-oriented model, almost from scratch. That was perhaps the biggest downwards-compatibility breakage that we’ve ever made in PHP. PHP 5 brought the language to new realms. Beforehand, it was largely ignored by the architects of the world; after the release of PHP 5, some of the mega-vendors, including IBM, Oracle and Microsoft, took notice and have become very much involved with PHP.

The next step in the evolution was the frameworks, specifically Zend Framework, where we went one level above the model and introduced a classier key that provides the building blocks and design-pattern implementations to help developers get productive quickly and create very maintainable applications.

Every step of the way, we kept existing users and existing types of code in the front of our minds. Even though it’s becoming less popular, one can still write a PHP procedural application today. My gut-feeling estimate is that it still accounts for at least half of the lines of PHP code in use.

People often ask me whether I envision the procedural support of PHP ever being deprecated in favor of a purer object-oriented code, and the answer is no. I don’t expect it to ever happen, and not only because I think we would be breaking God knows how many billions of lines of code, but also because I think that for many developers, that’s actually quite a nice way to start in scripting.

Scott: Yeah, exactly.

Zeev: I think we will generally move at the framework level as the place where innovation happens. The language has all the essential building blocks needed to provide frameworks to do most of the innovations.

We will continue to introduce major new language features, as we did with PHP 5, yet that is clearly not where most of the innovation happens today. I think taking a look at frameworks, and maybe extensions that connect PHP to all sorts of data sources and portals, is where the vast majority of innovation is going to happen going forward.

Scott: If you feel that a lot of the innovation is happening outside the core, that is a good thing in a lot of ways. It provides reassurance to the market place so people know they can write code on it and it’s likely to continue to run into the future.

I think you’re exactly right about keeping procedural support. You end up with different factions, and there are always people who will say that if somebody can’t do object-oriented programming, then they have no business writing code.

On the other hand, you’ve got the entrepreneur in a small business who just wants to modify the company web site, and is able to get it done without hiring an expensive consultant. I think that if some people want to do everything with object-oriented code, that’s great. But there is a legitimate community out there using it as a procedural scripting language that makes a lot of sense to them, and enabling them to get their job done is important too.

I guess another testament to the success of PHP is as the “P” in the LAMP stack, even though it’s not just a Linux technology. Probably a lot of PHP code ran on UNIX back in the day and still does.

Microsoft has obviously also taken a pretty strong interest in it, doing real engineering work in Windows 7 to make PHP run better and supporting PHP up on Windows Azure. Are you involved in any of that? And what do you think of PHP on platforms that aren’t Linux?

Zeev: We are very involved with bringing PHP to non-Linux systems. Initially, we developed PHP on Linux, but then moved to Windows when we started working on PHP 4. I think it was Windows 2000 and Microsoft Visual C++ 6. That was in 2000, or maybe 1999, so the relationship between PHP and Windows started a long time ago.

It really materialized relatively recently, in the last three years or so. In 2001, Andi and I were invited to Redmond by Microsoft to see if we could significantly improve the performance and reliability of PHP on Windows.

We were invited by a team called the “Dotcom SWAT Team,” which was formed to convince Dotcoms using Linux to move to Windows Server. They were bumping into a lot of people who were very open to Windows Server but wanted also to use PHP.

We stayed there one week and made some progress, but the next step actually took a few years to complete. I think real progress started when Microsoft and some other big organizations felt that it was really important to support PHP, and to make PHP run well under Windows.

Microsoft has changed in the way it perceives its involvement with open source projects, and has started putting lots of resources into making open source projects run well on Windows.

Scott: How did your involvement with Microsoft evolve after that initial contact?

Zeev: We at Zend worked together with Microsoft in 2006 and 2007 to really improve the stability and performance of PHP on Windows. We introduced the use of an architecture that wasn’t new, but it wasn’t very common, called FastCGI to deploy PHP on Windows.

We changed the PHP build and the way it’s actually running on Windows to run as a single server application with multiple processes, as opposed to as a single process with multiple effects, which is more similar to what you find on Linux. It goes much faster, and more importantly, it has reached production quality in terms of reliability. We have been working with Microsoft ever since, and today Windows is a viable deployment platform for PHP apps.

The Zend product line evolved from a situation where Linux was perhaps our main supporter operating system–along with Solaris and a couple of others–so that today both Windows and Linux, as well as Mac OS X on the development side, are first-class citizens.

We’ve seen quite a lot of uptake of PHP on Windows, and we are very happy about it. Zend has always been very pragmatic, and we wanted to see PHP running on as many systems as possible.

Scott: PHP is a higher-level language, as opposed to something like C, so it insulates the developer in a lot of ways from OS-specific APIs and that kind of stuff. I mean, you don’t have to know a lot about POSIX-compliant C libraries to be a PHP developer.

Another factor is that companies are now starting to look at what percentage of their applications make sense to run in the cloud. That’s kind of an extension to thinking that they want to partner with a hoster, rather than necessarily wanting to run every application in their own data centers, so the hoster can manage and maintain the system, guarantee uptime, and that sort of thing.

To me, cloud is an extension of that, but with some important differences. For instance, cloud basically gives you an API that lets you remotely stop and start instances. Or if it’s more of a Platform-as-a-Service like Google or Azure, it does scaling silently and automatically.

As you consider cloud providers, at one end there is Google App Engine, and it seems like the fact that they didn’t support PHP was an enormous hole, since a lot of things like Drupal, Jumbla, and WordPress are written in PHP.

For a lot of people, that’s the starting point, and obviously with Amazon Web Services, PHP runs just fine, because it is kind of an Infrastructure-as-a-Service that can run whatever they want. What are the opportunities and challenges around cloud development and PHP’s place in the cloud?

Zeev: As you said, the basic stuff already works, because in the most naive way, one can look at cloud as just another way to host applications. Obviously, that works pretty well already, except for Google App Engine, which doesn’t support PHP.

If we look a little deeper and try to see the opportunity here, I think we have done some interesting work around cloud to make PHP even more attractive for developing web applications. We started an initiative called the Simple Cloud API several months ago, partnering with IBM, Microsoft, and several other cloud vendors, with the goal of creating an exceptional layer on top of cloud services.

I’m not talking about the Infrastructure-as-a-Service APIs, but about accessing the cloud services that developers typically have access to for an application that runs inside the cloud, like knowledge tables and things like that. That goal is to create an accession layer on top of those services and what developers could look at as some sort of ODBC for cloud services.

We are half-way to implementing it, and taking a look at simplecloudAPI.org will show where we are in the process. When we finish and push it out, it’s probably going to be part of the Zend Framework. The implementations will be open, and developers will be able to implement it in other frameworks, as well as in other languages.

I think that introducing something like this into PHP, and the Zend Framework, is going to be a first, and it may help spur companies and ISVs not only to use the cloud but actually to develop for the cloud.

It allows developers to create applications in a slightly different way, if they need to create very scalable applications and things like big tables are very, very attractive probably more so than relational databases.

When ISVs and other companies start developing for the cloud and not just deploying on the cloud, I think that PHP, together with the Simple Cloud API, are going to be very effective choices.

Other than that, I think that the more obvious approaches are also going to happen. For example, Zend software could be provided as Amazon or Azure instances that developers would be able to deploy quickly, instead of having to provision a server and install Zend Server or PHP on it. They would be able to just go to the cloud, start up an instance, and boot an application there. Some of this functionality is already available.

We’re also thinking about how to bring forth innovation and change the way people develop applications once they have access to cloud services. And that is, perhaps, one not-so-obvious direction that we’re taking.

Scott: With the Simple Cloud API, is the idea partly to abstract the fact that different cloud providers have different ways of providing, for example, a table-driven distributed data store that’s non-relational? That abstraction layer would make it so programmers wouldn’t really have to code to the differences. They would be kind of coding to a common API.

Is the goal to make Zend PHP code more portable, or is it just to simplify development?

Zeev: It’s actually both. Look at the cloud APIs today. Simplicity is not the number one goal, and sometimes vendors may indeed want to differentiate.

So, our goal is really twofold: both to abstract and to make applications portable. I think both are important before using those services can become more mainstream. Having abstraction, so developers can take their applications easily from one cloud vendor to another, is an important step.

Equally important, making the use of these services easier is definitely also a goal of the Simple Cloud API, hence the name “Simple” in the name.

Scott: Right now, there’s a lot of interest in the cloud as a paradigm shift. It can be used for simple hosting, but it’s a lot more interesting when used around applications that really require a lot of elasticity.

People talk about the fact that there aren’t a lot of standards out there, and different cloud providers do things a different way, whether it’s a VMware vCloud partner, Amazon, Azure, or Google App Engine.

At the language level, or at the library level, it seems like a lot of people are tackling the problem of how to standardize and achieve portability. The angle Zend takes is interesting, because it sounds like a PHP developer wouldn’t really have to learn a lot of non-PHP technologies to get the portability they’re looking for.

Zeev: Most of the standardization efforts that I’ve come across around the cloud have to do with standardizing the Infrastructure-as-a-Service part of it: managing instances, starting and stopping instances, and so on. I haven’t come across a standardization effort for cloud services per se, regarding those services that one gains access to once inside the cloud.

That’s where we decided to focus, and it makes sense for a library to tackle that, for the framework.

Scott: This has been great, but I want to be sensitive to the time. Any closing thoughts from your end?

Zeev: On a personal note, it has been and still is an amazing ride. As you can understand from the origins of how our involvement began, neither Andi nor I had any clue whatsoever that PHP would be as popular as it is today. We would never have expected to see the White House website, Facebook, or Wikipedia standing on top of the technology that we helped get its start.

I’m confident that PHP has a bright future. Its popularity has never been higher, and it’s growing all the time, moving out into the mainstream. Many Java developers are now looking into scripting with PHP as a better way to tackle web applications.

Overall, I think we already are in a good position, and the road ahead looks very positive.

Scott: Thank you very much for taking the time to chat.

Zeev: You bet. Thank you.

Bookmark this: