Skip to content

Four 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=

32 thoughts on “Four reasons why Drupal should fork PHP

  1. You left out the most important reason: the PHP community, the people that really care about PHP, would no longer have to live with being associated with low-quality software such as Drupal, Joomla, Magento, WordPress, etc.

  2. Except there are pretty much no Drupal developers who have any clue how to write solid C code. It would be a disaster if they attempted to fork PHP.

  3. @Anonymous I think at one time it was fair to say that Drupal, Joomla, WordPress, phpBB and a lot of other projects had a bad reputation for their code and they deserved it. However, these days it is not nearly as easy to make that assertion. All the projects listed above along with countless other ones like web2projects have really tightened up their code base. I don’t think it is far to characterize them as “low quality”.

    The PHP community, at least the tiny corner of it that I am involved with, doesn’t consider it a burden to be associated with these projects. To the contrary, for the past 2 years, we have been trying to figure out how to get more Drupal, WordPress phpBB, etc. developers to identify with the PHP community. We *want* to be involved with these communities and want them involved in ours; their success is our success.

    @Joe,
    I think if they actually decided to do that, they could probably find some C developers in their ranks. :) While I do not support the idea of forking PHP, I do think that if they wanted to, they could pull it off.

    Thanks to the both of you for writing!
    =C=

  4. Cal, you are missing the core concept of the PHP way. That is to create an extension. They could make pecl/drupal to do whatever they wanted to do and not have to fork PHP to get C level stuff that did Drupal stuff. FWIW, we did this for Phorum. We had a Phorum PHP extension for a while when we hit some bottle necks with some array sorting issues. We offered it as an optional install, making all the same code in PHP land as well that was less efficient. Drupal X could just require such a PHP lib. Not different that requiring other PECL extensions.

  5. @Brian!

    Thanks for writing. Yes, that does address one of the points. Again, I am not saying that they should fork PHP. It was more of a cautionary tale. Look at MySQL. MySQL got so big that there was a movement *inside of MySQL/Sun/Oralce* to create a smaller, lighter version called Drizzle. The feeling was that MySQL (the company) had lost their way and a significant portion of the user base just needed basic database functionality. What if Drupal decided that PHP had lost it’s way? Worse yet, what if features were added that actually slowed Drupal down? (not on purpose mind you) It is easy to see how Drupal *could* fork PHP and create their own version.

    @Eric!

    I appreciate you taking the time to write. I agree, eventually, the fork would veer so far from the PHP core that they could not patch DrupalPHP to incorporate new features of PHP. This is a very good reason for Drupal *not* to fork PHP and to adopt Brian’s idea of a Drupal module.

    Thanks again both of you for your comments,
    =C=

  6. Cal, I think you missed April 1st by 6 days.

    Seriously does anyone running a Open Source project want to undertake a second project. Also tons of Drupal sites are run on shared servers if you think it’s hard to get them to migrate from PHP4 to PHP5 imagine getting them to run PHPforDrupal on their servers. And I know others say “Those are the Drupal users that don’t matter” but they are the ones that scream the loudest.

    What was the inspiration for this post? Did you have a nightmare?

    I do agree it would be easier for Drupal to split off PHP than to move to another language.

  7. I don’t think the PHP language is that important to the Drupal project either. I was impressed with how meta the Drupal community thinks. They’re making tools to manage entire groups of Drupal installations with the same level of abstraction as individual nodes within a single Drupal project. http://www.aegirproject.org/

  8. Joe wrote: Except there are pretty much no Drupal developers who have any clue how to write solid C code. It would be a disaster if they attempted to fork PHP.

    Except that I spent 10 years of my life writing real-time operating systems, Java Virtual Machines and just-in-time compilers in C. I think you’d be surprised how many Drupal developers have a background in C. Also, I think you’d be surprised by our ability to recruit C developers.

  9. Pingback: Is PHP running out of itches to scratch? | The Accidental Businessman
  10. Really guys ? Drupal is an amazing project but hey : It’s a CMS !!! not facebook (and yet they didn’t fork) !
    If every CMS out there began to fork PHP, we should really move to python :-)

  11. Amine, I think that reimplementing the PHP runtime system for writting a tool which transforms any* php code to C++ is much bigger feat than making a PHP fork, and cutting out some unused features and adding a few improvements.

    *: except eval() and stuff

    I think that the drupal community could pull off something like forking php, but I think that both community would be better, if they would just start contributing to the upstream.
    somehow the php upstream is seemed as they would turn down any help, but I think that it’s just the opposite: we/they are incredibly low on manpower, and somebody who make the patched could easily got svn account in a few weeks/months.

    just beware the trolls lurking on the internal list. :/

    Tyrael

  12. That’s also my point ! no wonder Drupal is great :-)
    I asked him what he would change if he had the time to contribute to PHP core.
    I think this post was the motive behind his own !

    The point is that every language must benefit from successful software built on top of it to move foreward.

  13. Ah ah ah! So you work on a steaming pile of c..ode and since you are unable to fix it (Drupal is world famous for breaking everything every time a new version is released) you want to change the language. Great!

    And if that doesn’t work – why not invent new types of keyboard and monitor, for better Drupal development? That should fix things.

    It would be easy to create a Drupal keyboad to put developers in the right Drupal state mind. Split each key into subkeys. For example, e.g. one key for the left vertical stem of a H, one for the right one, and one for the horizonal bar), all in totally different places. To type an ‘H’ you would have to press all the three keys at once

    It would be a 2,342 keys keyboard – but don’t worry, caching will sort out all problems.

    In all seriousness, there are two types of PHP developers: PHP developers and Drupal developers. As anonymous said, most PHP developers will be overjoyed if you take your low quality softare away from PHP, so that we’ll be no longer associated with it.

  14. Facebook needs to fork php, not drupal. They have the money and the talent.

    I’ve been waiting for a PHP BDFL to take the language into the next version. Sure the open source community is very important, but PHP is large enough to have several BDFL’s working on it. Take control of the naming and problematic language constructs. Refine it so that when corporate folks even look at the language, they don’t wince. I’d even suggest javafy as much as you can so IT people can sell it to their boses that it’s enterprise ready.

  15. Hi Cal,

    I think there is one big consideration that makes this questionable: deployment.

    I’m doing a lot of Python web app work these days (one reason you may have noticed I’ve been quiet on the PHP front) and in my opinion ease of deployment is still one of PHP’s main strengths. In contrast there is quite a learning curve to setting up a server environment for Python applications. Consider all the Cpanel based hosts and other shared hosting setups that have PHP config and build scripts built in, etc. While Drupal could make a forked version of PHP or move to another language, the change would make them a much harder solution to host.

  16. Forking PHP just for Drupal would mean the Drupal project not only needs PHP developers, but C/C++ developers as well.

    Sounds like a solid plan.

    By all means though, go ahead and try it out. I’m sure it will be easy to integrate this new forked language into every distribution within a reasonable timeframe. We can have a race between it and a full-fledged switchover to IPv6.

    I am all for radical out-of-the-box ideas, but forking an upstream language to make your life easier seems a bit pointless. Choose a more “agile” language if that is your concern. I would love a PHP world without OO, namespaces, and all the other new-age junk that has been thrown in on top of the original PHP building blocks, so if you’re going to do it, please, start trimming the fat out there first. :)

  17. I think Brian and Bob might be on the right line of thought? Couldn’t devotion by Drupal (aka developers) be made to enhance Facebook’s HipHop so that partial application code could be made into a PHP extension? E.g core libraries. I somewhat assume that all this is performance related rather than the literal language itself?

  18. I think it would just be a waste of time, sure Drupal would be able to run, but what about all the plugins? Surely some of those would use core PHP features? Or would you ask your plugin developers to learn a whole new language syntax?

  19. I agree with Cal…while I’m in no hurry to start any new Drupal project, I also wouldn’t be so quick to dismiss everything about the project as “low quality”. In fact, I think it is a bit arrogant to do so. Drupal is a large project with a lot of moving pieces and if you’ve ever maintained a super large project, even if it is all under your control, you’d notice that it can still become a bit unwieldy.

  20. Let them do it!

    Hilarious idea.. bunch of PHP noobs writing C code!

    Hey.. let doopal, joomla, wordpress and what not fork PHP and call it somewhat different so we don’t have to get associated with crap like that.

  21. @Tyrael,

    You beat me to it. :) I almost didn’t release Jonny’s comment because it is such an obvious troll. It is obvious he didn’t bother to read the post and just read the title.

    I released it because, other than spam, I release all comments.

    @Jonny,

    From your comments, I am guessing you’ve not actually used Drupal or looked at it’s codeBase.
    Whether or not you like the project, it is impossible to defend your statement that the developers working on it are noobs. Dries himself comments above that he is a C programmer and that there are others like him in the community.

    This conversation breaks down quickly when we aren’t respectful of each other. It’s ok to disagree, it is not ok to denigrate.

    =C=

  22. This just seems silly, It is quite widely accepted that it is a waste of time to compile php. Yeah, I could go and compile and distribute some pre-compiled php binarys that are limited to just what Drupal needs, until someone wants to use a contributed module that uses something unexpected.

    I think there are plenty of other ways to improve performance and a fork of php for Drupal would be near the bottom of my list where performance gains are concerned.

  23. Hi didlix!

    Thanks for taking the time to write.

    I have to disagree with you about compiling PHP. It is no where near “widely accepted” that it is a waste of time. Personally, I have never run an instance of PHP in production that I did not compile personally. I’ve got a nice script that I use to do it but I turn off everything I don’t need and turn on a couple of things that are off by default that I want.

    I won’t make a generalization based on my experience but I can’t let your generalization stand either.

    But the article is not about custom compiling PHP, it is about forking it. Some people have said that I don’t understand the difference between forking and a custom compiled distribution so let me clarify for you and the others out there. Forking PHP would be the Drupal community taking a copy of the source code, setting up their own repo and commuting to maintaining and developing their copy, separate from the main Repo. They could, of course, take patches form the main repo and integrate them when it makes sense but eventually, the new source tree would be so different that it wouldn’t be feasible.

    Simply compiling a custom distribution that works well with Drupal could be accomplished with a lot less fanfare. That’s nothing more than checking out the source, running the config script with the flags set to turn on or off the necessary features.

    (Til, that was for you. yes, I do understand the difference between a fork and a custom distribution. It would have been nice if you took the time to read and understand my blog before going off on me.)

    Both ideas are sub-optimal though. A custom distribution would only be of benefit to those who administer their own servers. It also assumes that Drupal is the only thing running on those servers. In my opinion, this would just confuse people.

    As I said in the conclusion, forking PHP isn’t a good idea either. Yes, there are reasons that a project might consider it but they are short-sighted. In the long run, it is better for the leadership of these major PHP projects to get involved with the development of PHP than to create their own custom fork.

    Thanks again for taking the time to write!

    =C=

  24. If it were to be forked how would average Joe go on about installing it? Popularity would die off due to the complexity of the installation and it would be left with a few die hards.

    To me it would seem like an epic fail. Except for maybe sites on a server by themselves that can afford the luxury of it and have a very knowledgeable server admin.

  25. Forking PHP is Drupal suicide:
    – hosting support would be lost;
    – new features of PHP would be unavailable for Drupal;
    – PHP/MySQL brand woldn’t be applied for Drupal;
    – many more…

    If 90% of PHP based apps was based on Drupal, forking would be OK. However, in this situation it is a suicide.

Comments are closed.