4 Reasons why Drupal Should Fork PHP

Dear Reader,

I attended my first DrupalCon earlier this year and was amazed by the fact that I was surrounded by people who were using a project built on top of PHP  – a project I dearly love – and many had no idea. In fact, out of 3,000 people in attendance, I ran into 2 members of what most of us consider “the PHP  community”. Granted, I didn’t meet everyone but I did expect to run into more PHP  developers. What I discovered throughout the ‘Con was that there are many developers there that are intimately familiar with PHP  but identify with Drupal ; they are Drupal  developers, not PHP  developers.

With that thought in mind, I began to think back to MSWDC’09. A discussion “errupted” there during one of the sessions that was quite telling. A core PHP developer challenged a core Drupal developer with the statement “What would happen if development stopped on PHP tomorrow?” The Drupal developer retorted “Then we would move Drupal to another language.” The room got quiet for a second as what he said sunk in. The Drupal core is interested in Drupal, if PHP becomes a pain-point for them, they feel they can switch to something less painful.

That conversation (which went on for a while longer) has stuck with me. Drupal is obviously an important project. The United States Government has begun adopting it at the highest levels, major sports leagues are adopting it, and yet it is still available for local businesses to use. Obviously moving the functionality – not to mention the existing userbase – to a new language would be a herculean task; but what if the new language was just a version of the old. What if Drupal forked PHP and began working on its own version?

With that thought in mind, I began to think hard about reasons they would want to do this. Here are the four best I came up with.

Improved development process

As I sat at DrupalCon ’11 and watched Dries’ keynote, I began to understand that the core Drupal developers really do understand large-scale, distributed software development. I began to contrast the new methodology he laid out for Drupal 8 with the way the PHP is developed.

PHP’s methodology is a choice made by the core developers. It works for them and the results are usually pretty good. It is a process that has matured over the years to one that is stable, if still a bit unsightly to watch. I have never been in on an IRC discussion for the Drupal core developers, so I don’t know if it is much different in reality than the PHP process. However, I was very impressed that in the keynote Dries acknowledged that the process was broken, owned it, and proposed a new system that will keep development moving while ensuring that it is moving in the right direction.

If Drupal forked PHP, they could apply these same methodologies to the language itself. Improving the quality of the process would improve the language.

Tailor made language

Most developers I know do not compile PHP manually. Some that I know don’t know that you can compile it manually. (Granted on Windows, it’s a lot more difficult) On Linux, however, it is not difficult. With a little poking around, you can create an instance of PHP that is tailor made for your server. Only the modules you want, none of the extras. As more and more modules are moved into the core, it is harder and harder to remove the ones you don’t want or need. If Drupal forked PHP, they could remove everything from the core that wasn’t necessary to make Drupal run. The resulting binary would be much smaller and – since there are fewer features in it – there are fewer ways to compromise the system at the PHP level.

Tighter integration between the language and the application

Once all the modules unnecessary for Drupal were removed from the core language, they could start adding Drupal specific modules. These modules would take select pieces of the Drupal core and move them into the language itself. This would not speed up any parts of Drupal that were slow because of accessing the file system or a datastore, but parts that are processor intensive could benefit from the speed of C. Very selective integration of Drupal into the base language could provide speed improvements not available any other way.

Control their own destiny

I remember when I was working at Zend, Sun Microsystems bought MySQL for one billion dollars. There was a lot of speculation that Zend would be next. The difference however, between Zend and MySQL is night and day. MySQL the company owned MySQL the database. The controlled it, how it was licensed and distributed. They controlled their own destiny. Zend on the other hand did not own PHP. They contribute to it but they do not own it. Owning their own version of PHP would ensure that the language is always developed in Drupal’s best interest. With the language and the project tied at the hip, they no longer have to worry if the version of PHP they are building on will be EoLed.

Conclusion

I am not suggesting that the Drupal community fork  PHP. I personally believe the loss to Drupal and the Drupal community would far outweigh the loss to the PHP community. However, I do hope this post has caused you to stop and think for a minute, regardless of which community you are in. The conventional wisdom is that like Java, PHP has too much momentum to be unseated as the most popular scripting language on the web. However, unlike Java, PHP can be forked. If PHP has problems – process or otherwise – that complicate the lives of the developers of major projects, those projects can simply take PHP and leave. Given that Drupal developers don’t consider themselves PHP developers, the only problem would be migrating hosts to the new version of the language. That is not so much a problem as it is a business opportunity.

Until next time,
I <3 |<
=C=