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.

Comments

Disagree

I was going to write up a whole elaborate post about how I disagree with this at a fundamental level, but then I realized that it wouldn't really accomplish anything. So instead I'll leave you with one point:

If shared devs have such little power and influence, how did the GOPHP5 movement work so effectively?

I'll give you a hint: It's because the majority of shared devs have the exact same power and influence as the "Root Devs", but they (for one reason or another) don't use it.

You mentioned that the majority of users are still stuck on 5.2. That's not because the shared devs don't want it upgraded. That's because they don't want to put their foot down and mandate it. And projects like WordPress still supporting ancient (and security vulnerability riddled) versions of PHP simply exacerbate the problem.

This is very much not a "fact-of-life" as you put it. This is simply complacency. Complacency and shunning of responsibility. And if you want to improve the situation, let the developers realize that they do have a choice, and that they aren't a second-class (as you imply in your post).

As someone who would like PHP

As someone who would like PHP to be more than "just 1980s POSIX code with dollar-signs added," I welcome the accelerated pace of development. Yes I am a root developer too :)

The decline in support for older versions may cause some trouble for shared developers. But that doesn't mean they will forever look on in despair. The root developers are the early adopters - like the people who bought HDTVs in the 90s - and help move those improvements from "maybe someday it will be implemented if we haven't switched to Angular Ruby on the JVM yet" to "we'll get it as soon as the server is upgraded". That jump takes no small amount of work and it's understandable that the PHP core team needs all their resources to make it happen.

More improvements in the new versions that are as-yet unattainable for many developers mean more improvements they will eventually get when they do have access. And the root developers will be the ones who test the early releases, while others just wait until they are more stable. For that reason alone a lot of shared developers may be perfectly happy with their limitations. Even as a root developer moving among many projects I have only used a non-distribution version of PHP once in the last few years.

As for the shared developers who feel left out, maybe they could start an open-source project? It's a lot of work, yes. But if you have a common need and a large number of people willing to put in a bit of work for the good of all...

I hadn't thought of that either...

Well, I'm a Shared Dev. I've got root on a lot of my development ecosystem but I manage a lot of projects and only control a fraction of them so a Shared Dev I am.

This article is definitely food for thought; especially in light of the variance in versions of PHP that are powering the great majority of websites.

I was shocked recently to receive a notice that Drupal 6 is dropping support for PHP4 later this year. I was surprised to think that anyone was still using PHP4. This article brings home the irony of that thought... I'm using PHP 5.4 for a number of production projects but I'm using PHP 5.3 for the rest of them, which are the majority because that's what is available to me. A Root Dev would look at that and think, "Wow, people are still using PHP 5.4?".

Definitely food for thought.

Exactly

A Root Dev would look at that and think, "Wow, people are still using PHP 5.4?".

Exactly. That's the mindset difference I'm talking about. Shared Devs are still fighting to kill off PHP 5.2 in many cases; root devs don't remember what PHP 5.4 looks like. It's just a different worldview, and one we need to bridge.