When should you eat your marshmallow? The boom and bust cycle of Drupal

If you are familiar with the Web Content Management industry, you might have noticed that Drupal has been increasingly popular in the enterprise world. There's been a significant shift in the way this solution is being perceived by businesses across the world. It used to be considered as an entry level platform, good for small scale use cases. Today, more and more large organizations are adopting it, moving away from proprietary enterprise Web Content Management systems.

 

I have seen similar trends with other technologies and I can't help but think that we're dealing with a Drupal boom and bust cycle. Before I explain what I mean by that, let me set the stage by describing one major issue with community-driven Open Source software that Drupal is a prime example of.

 

The problem with Drupal

 

I've led a number of Drupal website implementations and Drupal-based web-application development projects. Typically, all goes well at first. Your work is delivered on time, your stakeholders are happy, you're developing it at a fraction of the cost of a heavy-weight enterprise platform. You are killing it.

 

And then, out of nowhere comes the day when your development team comes to you to have The Talk. You find out that the community-driven modules your team want to use are incompatible with the version of the platform you're on, you find out you need to upgrade Drupal. And this is where things start going south.

 

As many people have already found out, large Drupal sites are virtually un-upgradeable. The official upgrade guide is point-blank about that, by recommending to reimplement your site every time you do a major upgrade of a complex site.

 

Yes, you read it correctly: the official guide tells you to start from scratch every time you do an upgrade. How many business people who decide to go with Drupal are aware of that? How many of them have budgeted for it? 

 

The boom and bust cycle of agile technology

 

How does all of this allow me to call out a Drupal business cycle? There are many theories about what causes economic bubbles, but the one that convinces me the most has to do with market information. To make the long story short, false information about the price of capital (a.k.a. the interest rate) causes malinvestment.

 

Similarly, commonly underestimated Total Cost of Ownership of Open Source technology causes people to overestimate the ROI of their projects. I believe that this is where a lot of the large Drupal implementations have its origin.

 

 

Another way in which the bubble can grow is through platform fragmentation. As the time goes by, different installations of Drupal are being deployed by different business units in different data centers, in-house and off-premise. The barrier of entry is so low that everyone prefers to create their own platform without having to worry about a coordinated release cycle and other dependencies. It's so easy to spin out a new instance of Drupal, so why wouldn't we do it for each and every micro-site we release?

 

Before you realize, you are dealing with dozens of instances of the solution and the total cost of their maintenance has skyrocketed. Then your new CIO or SVP of IT comes aboard and announces a platform consolidation initiative. The cycle starts all over again. Sounds familiar?

 

The marshmallow experiment of IT

 

I've chosen Drupal as my whipping boy, but I've seen the same mechanism apply to many other pieces of seemingly lightweight technology. Most recently I've seen it in cloud computing, where AWS / Azure footprint quickly goes through the roof. Anyone with a credit card and an expense account can now spin-out a new server, so why not create a new VM for every new project instead of waiting for the Server Ops team who take forever? Cloud is cheap, right? Initially - yes, but it gets out of control very fast.

 

The Open Source vs. Enterprise software dilemma is the IT equivalent of Stanford's marshmallow experiment. It's a matter of your time preference. The real question to ask is: do you want something cost-effective over a 6 month period or a 36 month period?

 

It’s time that businesses started thinking about technology choices in terms of real-life Total Cost of Ownership. Until that happens, we will all see more and more ‘cheap’ technology bubbles.

 

Feel free to comment and let me know what you will do with your marshmallow.

article by Łukasz Szostak