A Tale of Two PHP Devs

Recently I had an email conversation with someone about PHP, and how to market a new product to PHP developers, specifically through getting major PHP projects to adopt it. The details of that conversation are not really relevant, but in the course of the discussion a familiar topic came up that I feel warrants a blog post of its own.

There is a schism in the PHP community. A big one. One so big that I don't think many realize it's there, because the gulf across it is just so wide. See, there's not one "thing" called a "PHP Developer"; there are two, and they are so unalike that I have never seen them really see eye to eye.

Root Devs

The first group I will call Root Devs; their defining attribute is that they have root access on the production server, and permission to use it. Or, alternatively, the person who has root will do whatever the Root Dev says.

Root Devs have a lot of leeway. For them, PEAR was always a viable option; install a new package? No problem. Install a PECL module? Say the word. Write your own custom PECL modules? Go for it. Select exactly what PHP version you want to run? But of course. Recompile Apache, or PHP, or tweak php.ini? Sure, if you want.

Root Devs have a lot of power. That flexibility leads to a mindset that PHP is glue code between various C libraries, which is exactly how PHP began. (That's why most of PHP's old functions are syntactically weird; they're just 1980s POSIX code with dollar-signs added.) Or, at the very least, the assumption that the environment that code runs in is part of the design of an application.

Shared Devs

The other group I will call Shared Devs, as most of the code they write ends up on a shared server. It doesn't have to be a 90s-era over-sold shared host, although it usually is. This group also includes developers whose production server is controlled by the corporate IT department, and the settings on it are set "by policy" and the developer may not customize them. Even if the production host is a VM that may still be the case. The defining attribute here is, simply, that the runtime environment of the application is not under the developer's control.

Life is very different for Shared Devs. For this group, PEAR has always been marginally useful at best. Composer/Packagist, however, is a godsend. They have to rely on user-space code to compensate for the rather pathetic level of variation in PHP installation configuration. Magic quotes? Register globals? Allow_url_fopen? You have to compensate for both. Do you have GD or Imagemagik installed? Guess. Is Curl available, making outbound HTTP requests worth bothering to do? Maybe. And let's not even ask about what PHP version it has to work with; the answer is "all of them", aka, "lowest-vaguely-common-denominator."

Which are you?

One very common fallacy I see, in some form or another, is that the really good professional developers are Root Devs while Shared Devs are more amateur, low-market, less-paid, or some other dismissive statement. However, nothing could be further from the truth.

I would anecdotally estimate that about 95% of the PHP Internals team are Root Devs. "Upgrade your PHP version" or "compile with a different setting" are as natural a thing to do as "check your code into Git" or "upload your SSH key".

I would estimate the Shared Dev population at, conservatively, 14,000 times larger than the Root Dev population. And that includes every... single... major... Open Source... project. If you're writing PHP code for use by customers, users, or clients, then odds are you're a Shared Dev. If your customer, user, or client is a Shared Dev, then so are you.

That makes virtually all of the major projects Shared Dev projects. Drupal, Cake PHP, Wordpress, Zend Framework, Aura, Symfony... they're all Shared Dev projects, because they target "people who don't have root on production". (The lone exception I can think of is Midgard, which is shipped as a PHP extension.) Those are hardly amateur "low-end" developer communities. Many people in them do know C (as if that meant anything as far as "professional developer" was concerned), but that's not really useful or applicable.

That in turn means that the overwhelming majority of PHP developers do not have control over their production environment. And to the overwhelming majority of PHP developers, this is not news.

So what?

It does, however, have very important implications for the way the PHP community continues to evolve. PHP now has a much faster development cycle, with a significant release annually and older versions going out of support much faster. Those are all great news for Root Devs (and for Internals, which doesn't want to have to maintain old PHP versions on a volunteer basis, something I can't really fault them for), but it's a major catch-22 for Shared Devs when PHP 5.3 is already on security-only life support and will lose all support in a few months, despite only just recently climbing to 50% of the market. (PHP 5.2 is still holding on; PHP 5.4, the legacy version, has yet to reach 10%.)

This is what life is like for front-end developers dealing with old versions of Internet Explorer. It's not fun.

The repeated calls from Internals folks to "try new versions of PHP and see if they work before they're released" are entirely reasonable, logical, and the same as what most Open Source developers say. But since that requires compiling things, you immediately lose 95% of the Shared Dev market; they have no use for a compiler in their normal job, so never developed the skills needed to compile PHP from scratch on a VM to experiment with it. And why should they? Trying out PHP.next is the only time they'd ever use those skills in the first place.

The idea of experimenting with a component in PECL for a while and then moving it back to mainline PHP if it works out is, while a nice theory, completely useless. The people who could use such experimental extensions are few and far between, and none of them have large install bases. (They may have millions of users on a small number of sites, but won't have tens of thousands of sites.)

Experimental tools like HHVM (the successor of HipHop) offer huge potential, in terms of performance, deployment, and syntactic improvements to the language. But just like a new version of PHP itself, 99.9% of the market doesn't care because they can't use it, no matter how much they want to.

In practice, the entire PHP ecosystem is subject to the following user story:

As a user who doesn't know what root or a compiler are
I want to upload this PHP project to my cheap web host and have it "just work"
So that I can share pictures of my cats without having to learn anything new

Even if you have no interest in cat pictures, if any of your users do then you are bound by that same requirement. If they aren't, then congratulations, you're a Root Dev.

Any attempts to improve PHP development, or the PHP ecosystem, in the short-term or long-term need to be mindful of this fact of life. It's a fact of life that will be completely alien to a small group of very important and influential people: Those who are in a position to improve PHP development and the PHP core ecosystem.

And that is, perhaps, one of the biggest challenges we face as a community.