a‡Y Is PHP running out of itches to scratch?
Over on his blog, my partner Cal has been wondering aloud whether Drupal should simply fork PHP, or get rid of it altogether. I hesitate to add anything to the discussion because I don't want it to look like we're feeding troll material to each other, but he does raise some interesting points.
I think it's fair to say that the pace at which PHP core is being developed has slowed down considerably over the past couple of years, while the development of many projects based on it, like programming and application frameworks, has sped up and continues to grow at a fast pace.
But this doesn't mean that we're running out of steam. The PHP ecosystem is simply refocusing outside of core, where it has a lot more freedom of action.
This is primarily a consequence of two items. The first is the fact that PHP core has no strong leadership that can take the base language in a specific direction.
This has always been a primary design feature of the project-one, I may add, that has produced some great results. Without anyone to force PHP in a specific direction, the language has evolved haphazardly but comprehensively, which is what makes it so appealing to so many.
However, the decision was made some time ago to close the door on building new libraries into core and instead shift them to PECL. This was probably the right decision (who wants a bloated and increasingly difficult to audit core?), but it was implemented without considering the fact that the average PHP user has neither the knowledge or inclination to understand how to install and run external libraries that they can't download in PHP form and include in their scripts.
This is crucial, because PECL and PEAR are, despite the valiant efforts of many brilliant developers, a complete mess. Obscure to work with, poorly supported, and unduly complex, they are simply irrelevant to the vast majority of PHPers.
This, in turn, affects downstream application developers, who, faced with a client base who can't deal with PECL and PEAR, simply opt for building their own plugin architectures-and, to be frank, often do a pretty good job of it.
The risk facing us, as I see it, is not that Drupal, or WordPress, or whoever may decide to fork PHP or abandon it altogether. Rather, the problem is that there is no real way for these projects to provide upstream positive feedback to PHP core.
As I pointed out that the meeting that Cal references (I was the instigator of the discussion), core developers can't improve PHP if they don't know what needs improving, and downstream developers are forced to resort to needlessly duplicate functionality that they could instead feed into and pull out of core. This, in turn, would enable the latter to focus on what really makes their projects unique and make the whole PHP ecosystem better in the process.