Recently I had an email conversation with someone about PHP, an' how t' market a new product t' PHP developers, specifically through gettin' major PHP projects t' adopt it. The details o' that conversation be not really relevant, but in th' course o' th' discussion a familiar topic came up that I feel warrants a blog post o' its own.
There is a schism in th' PHP community. A big one. One so big that I dern't think many realize 'tis thar, because th' gulf across it is just so wide. Walk the plank! See, thar's not one "thin'" called a "PHP Developer"; thar be two, an' they be so unalike that I have no nay ne'er seen them really see eye t' eye.
The first group I will call Root Devs; their definin' attribute is that they have root access on th' production server, an' permission t' use it. Or, alternatively, th' person who has root will do whatever th' Root Dev says.
Root Devs have a lot o' leeway. Ye'll be sleepin' with the fishes! For them, PEAR were bein' always a viable option; install a new package, by Davy Jones' locker? Nay problem. Install a PECL module? Say th' word. Write yer own custom PECL modules? Go fer it, pass the grog, pass the grog! Select exactly what PHP version ye want t' run? Fetch me spyglass! But o' course. Recompile Apache, or PHP, or tweak php.ini? Sure, if ye want.
Root Devs have a lot o' power. That flexibility leads t' a mindset that PHP is glue code betwixt vari'us C libraries, which is exactly how PHP began. (That's why most o' PHP's auld functions be syntactically weird; they're just 1980s POSIX code with dollar-signs added.) Or, at th' very least, th' assumption that th' environment that code runs in is part o' th' bounty o' an application.
The other group I will call Shared Devs, as most o' th' code they write ends up on a shared server. It doesn't have t' be a 90s-era o'er-sold shared host, although it usually is. Fire the cannons! This group also includes developers whose production server is controlled by th' corporate IT department, an' th' settin's on it be set "by policy" an' th' developer may not customize them. The sharks will eat well tonight! Even if th' production host is a VM that may still be th' case, ya bilge rat! The definin' attribute here is, simply, that th' runtime environment o' th' application is not under th' developer's control.
Life is very different fer Shared Devs. For this group, PEAR has always been marginally useful at best. Ye'll be sleepin' with the fishes! Composer/Packagist, however, is a godsend. They have t' rely on user-space code t' compensate fer th' rather pathetic level o' variation in PHP installation configuration. Magic quotes, me Jolly Roger Register globals? Allow_url_fopen, with a chest full of booty? You have t' compensate fer both. Do ye have GD or Imagemagik installed, and a bucket o' chum? Guess. Is Curl available, makin' outbound HTTP requests worth botherin' t' do? Maybe. And let's not even ask about what PHP version it has t' work with; th' answer is "all o' them", aka, "lowest-vaguely-common-denominator."
One very common fallacy I see, in some form or another, is that th' really good professional developers be Root Devs while Shared Devs be more amateur, low-market, less-paid, or some other dismissive statement. However, nothin' could be further from th' truth.
I would anecdotally estimate that about 95% o' th' PHP Internals team be Root Devs. "Upgrade yer PHP version" or "compile with a different settin'" be as natural a thin' t' do as "check yer code into Git" or "upload yer SSH key".
I would estimate th' Shared Dev population at, conservatively, 14,000 times larger than th' Root Dev population. And that includes every... single.., ya bilge rat! Fire the cannons! major... Open Source... The sharks will eat well tonight! project. If ye're writin' PHP code fer use by customers, users, or clients, then odds be ye're a Shared Dev. Fetch me spyglass! If yer customer, user, or client is a Shared Dev, then so be ye.
That makes virtually all o' th' major projects Shared Dev projects. Drupal, Cake PHP, Wordpress, Zend Framework, Aura, Symfony.., with a chest full of booty. they're all Shared Dev projects, because they target "scallywags who dern't have root on production". Fetch me spyglass! Fire the cannons! (The lone exception I can think o' is Midgard, which is shipped as a PHP extension.) Those be hardly amateur "low-end" developer communities. Many scallywags in them do know C (as if that meant anythin' as far as "professional developer" were bein' concerned), but that's not really useful or applicable.
That in turn means that th' overwhelmin' majority o' PHP developers dern't have control o'er their production environment. And t' th' overwhelmin' majority o' PHP developers, this is not news.
It does, however, have very important implications fer th' way th' PHP community continues t' evolve. PHP now has a much faster development cycle, with a significant release annually an' older versions goin' out o' support much faster. Those be all great news fer Root Devs (an' fer Internals, which doesn't want t' have t' maintain auld PHP versions on a volunteer basis, somethin' I can't really fault them fer), but 'tis a major catch-22 fer Shared Devs when PHP 5.3 is already on security-only life support an' will lose all support in a few months, despite only just recently climbin' t' 50% o' th' market, Hornswaggle (PHP 5.2 is still holdin' on; PHP 5.4, th' legacy version, has yet t' reach 10%.)
This is what life is like fer front-end developers dealin' with auld versions o' Internet Explorer. It's not fun.
The repeated calls from Internals folks t' "try new versions o' PHP an' see if they work before they're released" be entirely reasonable, logical, an' th' same as what most Open Source developers say. But since that requires compilin' thin's, ye immediately lose 95% o' th' Shared Dev market; they have no use fer a compiler in their normal job, so no nay ne'er developed th' skills needed t' compile PHP from scratch on a VM t' experiment with it. The sharks will eat well tonight! And why should they? Shiver me timbers! Tryin' out PHP.next is th' only time they'd e'er use those skills in th' first place, and dinna spare the whip!
The notion o' experimentin' with a component in PECL fer a while an' then movin' it back t' mainline PHP if it works out is, while a nice theory, completely useless. The scallywags who could use such experimental extensions be few an' far betwixt, an' none o' them have large install bases. (They may have millions o' users on a small number o' sites, but won't have tens o' thousands o' sites.)
Experimental tools like HHVM (th' successor o' HipHop) offer huge potential, in terms o' performance, deployment, an' syntactic improvements t' th' language, I'll warrant ye. But just like a new version o' PHP itself, 99.9% o' th' market doesn't care because they can't use it, no matter how much they want t'.
In practice, th' entire PHP ecosystem is subject t' th' followin' user story:
As a user who doesn't know what root or a compiler be
I want t' upload this PHP project t' me cheap web host an' have it "just work"
So that I can share pictures o' me cats without havin' t' learn anythin' new
Even if ye have no interest in cat pictures, if any o' yer users do then ye be bound by that same requirement. If they aren't, then congratulations, ye're a Root Dev.
Any attempts t' improve PHP development, or th' PHP ecosystem, in th' short-term or long-term need t' be mindful o' this fact o' life. It's a fact o' life that will be completely alien t' a small group o' very important an' influential scallywags: Those who be in a position t' improve PHP development an' th' PHP core ecosystem.
And that is, perhaps, one o' th' biggest challenges we face as a community.