We’ve dropped Drupal.

Picking Drupal

Cast your mind back to 2007. In the year that Apple first released a phone, we decided to replace our home-grown CMS offering, RationalMedia. We needed something powerful, something open-source, something with a global developer community. We needed Drupal.

We quickly built one of the largest Drupal teams in the UK and developed a host of technically complex and award-winning sites.

D7 to D8

By version 7 in 2011 Drupal was, unequivocally, the 800-pound, open-source CMS gorilla for our key, not-for-profit sector clients - where it was very much a case of “no one ever got fired for choosing Drupal.”

Trouble is, for us, Drupal has slowly become an 800-pound monkey on our back: squishing our productivity and squeezing our bottom line - and Drupal 8 hasn’t made things better.

Why we stopped believing

In simple terms we think Drupal is too slow to develop with, too hard to use and maintain, and costs too much as a result. We’re not alone. Other developers agree. But let’s unpack this a bit based on what we've learned over the course of 11 years:

• The module ecosystem is a mixed blessing. Whilst they can prevent “reinventing the wheel”, all too often contributed modules don’t quite do what you need, and add to the maintenance overhead. There are 50% fewer modules actively maintained for Drupal 8 than 7.
• It’s opinionated about markup. Even with the improvements that Twig has brought to the table you still need to be a specialist Drupal frontender to be an effective themer. Just like in 2011.
• Drupal 8’s adoption of Symfony has brought it into line with the broader PHP community, but it now has an even steeper developer learning curve. And PHP is in long-term decline.
• Upgrades between major version are epic. Semantic versioning is a positive move but the 6-month release cycle between minor versions has already led to potential data loss and security issues.
• The UI is still complicated, despite a massive push to improve Drupal’s usability in version 8. When we have to train users to do basic content management tasks - or expend large amounts of effort customising the interface to make it user-friendly - something’s wrong.
• Drupal is increasingly moving to an enterprise space, making it a more questionable value proposition for not-for-profit organisations.

Wagtail for the win

In case you don’t know, Torchbox contributes to and runs the core developer team for the Django-based open-source CMS, Wagtail. For several years, we happily ran Drupal and Wagtail teams hand in hand, which has given us a really important point of comparison.

It wasn’t just that we felt we were delivering bad value for our clients or that projects were over-running and making us lose money. It was also that our developers were increasingly telling us how frustrated they were with Drupal.

Once we’d made our decision to switch our focus, we offered our eight full-time Drupalistas the chance to retrain - and work on Wagtail and Django projects with us. We’re thrilled that all but one decided they wanted to move from Drupal to Wagtail, and stick with Torchbox.

One of our developers, Kevin Howbrook, had already written about his first steps on this journey, and he’s now written a more technical article that looks at the fundamental differences between developing in Drupal and Wagtail from the perspective of someone who, until this year, was a badge-wearing Drupal evangelist.

Have a look at Kevin’s article.

The toughest consequence of this decision is that it’s meant saying goodbye to a number of hard-won, valued, and amazing clients who we’ve worked with for many years. We’re also sorry to say goodbye to the Drupal community, which still epitomises the true spirit of open-source collaboration.

But, we’re looking forward to a future with Wagtail. If it’s good enough for the NHS, NASA, and Google, it’s good enough for us. And our developers agree.