Drupal is a lot like enterprise software. Before you think this is a bad judgement on Drupal or a slur please hear me out. It’s more a description of Drupal based on my experience with it for nearly 8 years and my last couple years dealing with enterprise software. I want to dive into some specific points that may be good, bad, and even make us unhappy with some of the things that make us happy.
One of the surprising things about enterprise applications is that I’ve found one architect in the application often doesn’t know how the whole thing works. The software is complicated and applications can end up with numerous people who have architect in a title. Drupal has a similar experience. With all of the things going on, even the wisest of contributors and initiative leads don’t know how the whole thing works.
Drupal is complicated like enterprise software.
It recently struck me that Drupal is a fairly monolithic application. A trend in applications is to have small parts that operate together to create a whole. For example, one application provides the user interface. That application talks to an API server. The API server schedules things to happen via a queue. Workers grab items from the queue and act on them. In this picture each of the different types of things is a different application.
Or, you could have a small application. I think of Wordpress as a fairly small application and it comes in around 200k lines of code. For a small application it does a lot.
Drupal is nearing 950k lines of code. I won’t be surprised when it passes 1 million lines of code. This is just core and no one just builds a site with core anymore.
Drupal also does a lot. Sites can have a message queue (using Drupal), caching (using database caching through Drupal), and so much more. It’s big.
Drupal Specific Terms and UI
I’ve had the opportunity to teach people about Drupal who have had years using web applications, have worked with content and other CMS, and some who write applications. I’ve learned there are a lot of Drupalisms. A whole vocabulary has grown around Drupal and you have to have domain knowledge to use Drupal, build with it, or just understand conversations around it. In addition the UI isn’t intuitive to outsiders. Someone needs to understand the product down to the major version to perform everyday tasks.
These are both elements I’ve found in enterprise software. In many ways these custom aspects lock users into the product because it raises the barrier to go to other products due to change. If successful it can help build an ecosystem around the product (more on that later).
Major Version Update… What?!?!
Have you tried to update major versions of a Drupal site? How about updating when you jump a major version? Going from Drupal 7 to 8, much less Drupal 6 to 8, is going to be a huge effort for anyone who tries to take it one. The architecture changes that happen between major versions means custom code needs to be rewritten, contributed modules need to work and have an update path, and the data needs to be migrated because it often can’t just be updated.
This can be costly. It can end up in the hands of consultants to handle the upgrade just to keep the same base functionality. That doesn’t even mean adding support more responsive design.
Ecosystem - Consultants and Partners
Many enterprise software applications will have an ecosystem around them. There will be partners that sell the software. There will be partners that support the software. There will be consultants who help those who implement the software do so. When you have a complicated piece of software someone new to implementing it needs the ecosystem.
Does this sound at all like Drupal (with the exception of selling Drupal)? Drupal has an amazing ecosystem around it with many fantastic people. And, many companies could not implement Drupal as a solution without them.
I’m Not Complaining
I could continue on this thread but many people won’t continue to read (short attention spans). I’m not complaining but merely observing what Drupal has become.