Drupal is dying!

I was running Adyax for 10 years, a digital agency that quickly became one of the top 10 worldwide Drupal experts. I gave talks and participated in all major Drupal conferences.

I sold the agency in 2018, when we reached 350 people and more than 13M€ in revenue, only doing Drupal sites.

Today, I’m running code.store, a next-generation agency, where we mainly use SaaS and no/low-code tools, building cloud-native apps for our beloved clients.

I do not recommend Drupal to them anymore.

Drupal was the largest open-source project in the world, fueled by more than 1.000.000 developers, millions of sites, hundreds of top 1000 sites, and thousands of modules, translated into 193 languages.

But Drupal is dying. Let’s see why and why you should not use Drupal anymore.

Drupal is dying because it’s too complex

I used to say to my clients:

“You can everything with Drupal, there is always a module for any feature you might need.“

At Adyax we did Drupal sites factories, Drupal B2B e-commerce portals, ERPs, CRMs, and media sites.

The problem?

After a few years, every single project became way too complex and costly to maintain.

Adding more and more features to a single Drupal monolithic instance under tight deadline pressure generated a horrible codebase. Teams change over time, and requirements too. You simply cannot fight against the ever-growing projects’ entropy, without permanent and costly refactoring.

After a while, clients start to question your estimates.

— Why the hell does adding a new content type require 10 man-days of work?

— Well, it’s because of the 200 modules we’ve built during the 3 last years…

The main selling proposition of Drupal is that you can do anything with it.

This ability is also Drupal’s main problem.

If you need newsletters, polls, comments, reviews, or e-commerce, there are always one or even multiple Drupal modules you could use. None of these modules is good enough to fight against Mailchimp, Typeform, Disqus, or Shopify. So your client gets an average product value, high maintenance costs, and a terrible monolith with hundreds of modules.

Drupal’s ubiquitous capabilities make it also very hard to understand for contributors (try to modify a landing page with Panels…), with inconsistent UX, navigation, and app logic.

So you basically start to create UX and UI for admin pages, which doubles the budget and maintenance costs.

Drupal is dying because it’s running on PHP

This one is easy but seems that Javascript and Typescript (with Python and Go) won the battle. It’s complicated to find and hire PHP developers, as the most talented ones probably turn to Go, Rust, Python, or Node. It’s even more complicated to find Drupal developers now.

Drupal is dying because it missed the MACH architecture trend

Drupal was very innovative when introduced structured content management by design with the famous CCK, which became later Field API once introduced into Drupal Core.

But Drupal totally missed the MACH (Microservices, API-first, Cloud, and Headless).

While some level of API support was introduced in Drupal 8 core, the modular and generic architecture of Drupal made it extremely complicated to integrate for front-end teams and didn’t work with most of the available modules.

Drupal 9 is still a large modular monolith, with many modules depending on others. This makes changes, security updates, and refactoring exponentially costly as your project grows.

Look how scary a Drupal instance module interdependence may look :

Drupal is dying because of fierce competition from SaaS editors

When we started doing Drupal back in 2008, there were a few extremely costly and poor editor’s solutions like Sitecore, Adobe CQ5 (now AEM), Oracle, or Magnolia.

Even a simple project would cost companies hundreds of thousands of dollars in licenses, and twice as more in the build itself. So Drupal seemed a powerful and flexible solution without license costs and lower implementation costs.

Another unique innovation Drupal had is the ability to manage structured content rather than full-page HTML editing. It was a real game-changer in the industry in 2008 as iPhone and mobile apps arrived on the market, with the necessity to provide multi-channel content distribution.

Today, however, the market had changed dramatically.

We see hundreds of SaaS CMS covering every single use case and adapted for different company sizes. More importantly, most of the SaaS CMS platforms are open through their extensive APIs and Webhooks, providing structured content management out of the box. It is also possible to create plugins and extensions in case of a custom feature that would block your project otherwise.

Those platforms offer flexible price models with affordable starting plans usually around 500USD per month. Those plans include licenses, new features updates, and hosting.

When analyzing the total cost of ownership of a CMS project, most of the editors beat Drupal-based projects, where you need to care about back-end maintenance and hosting.

But most importantly SaaS CMS offer a thrilling user experience from a contributor's point of view. Each admin screen is carefully designed and tested against thousands of use cases and clients.

Focusing on their core audience, almost every editor solution out beats Drupal's clunky admin.

Drupal is dying because it’s open-source

It’s a bold statement I know. But let’s see why Drupal was such a successful project then and why it’s not anymore today.

Back in 2016, I wrote a similar statement about open-source e-commerce. It happens now in the CMS space too.

Open-source thrives in developer-oriented products (NodeJS, MongoDB, Qovery, …). But it’s almost absent from the end-user space (who uses Gimp or Libre Office) with some exceptions like Strapi or WordPress.

The reason is quite simple: economics. Any project needs motivated people to write code, maintain documentation, and hunt bugs.

Inside open-source products, most of the contributions come either from the editor (freemium model with a limited community product, so I don’t consider them as real open-source projects) or from services companies using those products inside projects they build for their clients.

These service companies use their contributions for marketing & sales purposes (if you were about to contract with an agency to build a Drupal site, you will probably check how active they are in the Drupal community).

Back in 2005–2015, the CMS space was still quickly evolving with a “try and error” approach for testing new features. Companies were experimenting a lot, so a product like Drupal was a perfect match.

Drupal provided a set of tools like structured content management, authentication, modules, i18n, etc.. which were assembled together by agencies to fulfill clients’ changing ideas.

Today, however, content management is mature.

Marketing departments of companies, know exactly what they need in terms of features. CMS is a solved space. Experimentation happens now in ML, Data, blockchain, or AR/VR, not in the CMS industry, which became mature. That means there is less and less ‘service’ inside a CMS project. A set of editors can roll out a fully functional platform within weeks, fully satisfying customers' needs. There is no more place for open-source projects, there are no more needs for them.

Where Drupal is still relevant?

At code.store we address only private companies, we never recommend Drupal preferring building modern MACH architectures using as much as possible Low/No-code and SaaS products.

I think that Drupal might still be relevant in the Public sector, with long-living platforms (> 8 years compared to 5 years max for the private sector) and specific regulations, code audits, security, GDPR, and so on.