My thoughts on the number of visible PHP jobs versus Drupal-specific ones


I originally posted this as a comment on here:

But, I thought the concepts were more general, and deserved more visibility.

This is basically discussing the reason that there are more people looking for PHP developers than Drupal developers, specifically.

Marketing and buzzwords

PHP has been around for a long time, and there are a lot of clients that have heard of PHP/MySQL/LAMP, etc. They know that they need someone adept in one or more of these buzzwords to build their widget, and in order to run the widget on their own server. They may not know why, but they know that this is the technology that should be used.

Drupal, on the other hand, doesn't have the same kind of 'brand name recognition' that PHP or Rails have, nor should it necessarily. Drupal has not been 'marketed' as a development platform. The goals are different than, say, that of Rails or CakePHP. Personally, I think that using Drupal vice one of these other frameworks gives a developer a greater edge when developing a widget for a client. As a simple example, in your standard PHP (or Ruby or JSP) framework, I may have some plugin/module/etc. that allows for a login/authentication box. This code may have some basic functionality that (on the surface) seems to do what's needed, but what happens when you need to consider granular permissions. Oh right, I have to write that functionality. Create a table, relate it to users, determine how I'm going to enforce them, etc...

Yes, you can write a blog using Rails in 20 minutes, but will it have all the functionality of the Drupal 'blog' module? 'blog api'? No way.

So, let's consider the other 'marketing' issue that I see:

Perceived value of performance over development costs

I recall a discussion I had with a potential client that wanted everything done with PHP. He was technical enough to get something like Drupal installed, but didn't really know where to go from there. He had some social network application built for him using PHP (no framework), and it was (mostly) fast. The DB tables were simple, the PHP code was a mess, but the application was responsive. It was a nightmare to change anything, but that wasn't his concern.

This particular person was so hung up by the fact that a simple PHP application with a simple database could outperform Drupal on the same hardware that he wasn't open to any suggestion. The problem here, of course, is code maintainability, and time-to-market. Any feature he wanted on the PHP site had to be hacked into the application, since there was no solid framework to build from. Everything was done from scratch. Using yet-another-example, if you had to add blog functionality (and I actually did in this case) to this PHP application, you have to consider everything about the blog posting. Comments (add/delete/edit), XSS issues, categorization, embedding images, etc. It becomes a huge mess!

So, this is site performance versus time to build. Drupal can be optimized, and in the right hands and hardware, will perform just fine. Look at some of the huge Drupal-based sites out there... SonyBMG, WB Music, etc.

To me, I'd rather spend the time building the unique aspects of a client's site rather than building (and debugging) basic functionality that you get from just Drupal core. Add in the multitude of modules, and it's a no-brainer.

No PHP developer in their right mind (obviously the guy in my example above was not one of these) would build a piece of software, be it web-based or standalone, without using a framework. If we can get more people to look at Drupal as the CMS Framework that it is (via marketing), you will see an increase in adoption.

I'm not saying that this is a goal of the Drupal community, or even a necessity for it to continue to flourish, just that this would be one way to gain visibility from the potential developers out there. Everything you do with an application is a piece of content, whether it's a blog post, or an advertisement. You can't maintain building sites without a good framework. Thus, why not use a framework that is based around the management of content?