Is Drupal a Standard?

I’ve been working in the CMS arena for 10 years, and the whole time I’ve been expecting one or more “industry standard” CMS’s to come along, but instead we’ve seen thousands of competing products with almost every web agency claiming to have CMS product.

While development costs have come down a long way due to greater experience and code re-use they still haven’t come down anywhere close to the level that people are used to from purchasing shrink-wrapped mass market software.

Clients have been getting fed up of high costs and vendor lock-in.

In this context I’ve seen many clients specifying Drupal as a requirement when putting projects out to tender – in the hope of saving cost and avoiding lock in.

It’s really exciting to see an open source project taking on this role.

However, having used Drupal on projects like this for the last couple of years I have to question whether it actually fits the bill.

Drupal has ben seen to promise a standard solution such that if the current development team were run over by the proverbial bus any other team familiar with Drupal could be parachuted in and pick up where the previous lot left off.

Having taken over quite a few projects in my time (both Drupal and others) I have to say that I haven’t found the Drupal projects any easier to pick up.

Drupal does offer a large amount of code that other developers may be familiar with but Drupal is very flexible, one Drupal website can be very different from the next.

Drupal does not follow many common programming conventions and experienced developers faced with Drupal for the first time sometimes resort to some ugly solutions because “the Drupal way” is not an obvious one.

I’d certainly rather take over a ‘custom’ project that followed best practise than a Drupal project that’s been put together by a team that didn’t know what they were doing.

If you want to keep your development team up to date, able to work on other systems and ready for future changes in technology – then Drupal’s idiosyncratic patterns are a barrier to be considered. There is a danger that they will spend their time learning Drupal, rather than gaining experience of programming (OO, design patterns etc) that is more likely to be applicable on other systems or even in other programming languages.

A Drupal project only remains standard if it can be implemented with relatively little customisation, otherwise Drupal’s idiosyncratic programming practises together with heavy reliance of the database for composition and integration of modules can rapidly erode the benefits of standardisation.

There is also the problem that Drupal releases are not compatible with each other, each new release is in effect a completely new product. There is enough commonality between releases that the development team does not have to learn a whole new system from scratch (though there is significant re-learning required). However clients may easily find themselves with an out of date system, or facing an expensive ‘upgrade’ process.

I’m reflecting my own experience here, which has all been on highly customised Drupal installations with either a lot of custom functionality or unusual design requirements. I’ve picked up quite a few Drupal projects part way through.

I’m sure that for more standard websites which can use readily available modules Drupal can offer a good degree of standardisation.

The point I would like to make is that Drupal is not a silver bullet for standardisation – you still need to take care to ensure that Drupal is actually a good fit for your project, that the team know what they are doing, and that best practises are adhered to.