Making Drupal More Enterprise Friendly

Dries has a very interesting post up asking how we can make Drupal more competitive with the enterprise level CMS systems out there like SiteCore, Vignette and SDL Tridion.

While open source solutions like Drupal are making a gaining major traction in the content management world, it still has a big hurdle to get over when it comes to competing with these proprietary systems. Drupal has major selling points over these systems, with cost savings being the top one. Open Source projects also tend to stay ahead on technological changes more than these proprietary systems or at least in a more financial friendly sense.

Then there’s the issue of extensibility and customization. These are two of the biggest winners when it comes to Drupal, but are they also the losing points?

Customization as a foe

One thing Drupal does that most other systems don’t is allow developers to design a totally custom user interface. The foundation of any CMS is the content authoring pages. If you do authoring on one SiteCore powered site, you can go to another and be presented with the same authoring interface in another SiteCore powered site. The same can be said with Vignette, Tridion and even Wordpress. They might not be exactly the same, as some sites might have added a few features or taken away some, but the basic screen is the same.

Now take Drupal. I have taken over numerous projects in the past. These have all been setup by other Drupal shops and everyone has a different node editing screen. Some might use BUEditor or FCKEditor over TinyMCE. Other’s may use a system like IMCE to handle image uploads, while others go the CCK route. One site may allow their writers to just paste in video embed code, while others might require you to use a CCK field to include an embed.

The possibilities are limitless when it comes to the workflow of creating content in a Drupal powered site. This has always been one of the attractions of Drupal, but let’s look at it from a business point of view.

If I own a web publishing company built on Vignette, I am going to focus on finding writers with experience in Vignette. Finding these people means less time and money needed to train them. If they worked in this system before, they can quickly login to our admin interface and instantly be familiar with it.

The same isn’t true for Drupal. I could hire a new writer who used Drupal in a previous job, but they enter our backend and find out that our Drupal is totally different. This means I got to spend more time, which means more money, to train this person to use our Drupal.

Training alone provides a pretty major hurdle. We now live in a world where telecommuting is becoming more popular. You don’t have writers all sitting in the same office. They can be scattered all over the planet. Training on a new system no longer means calling everyone into a conference room and giving a course. Now you got to rely on people watching or teleconferencing with a trainer, which brings other issues like time zones into play. I always go the extra length when training clients on their system. Usually these involve a series of screencasts and some cheat sheets, but making sure everyone watches them is never a given, unlike people sitting in that conference room.

Does this mean Drupal is doomed to compete? Absolutely not, but the solution isn’t all that clear-cut either.

Installation Profiles To The Rescue

If you aren’t familiar with installation profiles in Drupal, then you are missing out. Instead of having to spend hours searching for, downloading and configuring modules, you can grab an installation profile for something such as a blogging site and Drupal will handle all the work for you.

To provide a more uniform experience amongst Drupal installations, profiles should be used more often. That of course means making more sound installation profiles and giving them a higher visibility on Drupal. These can be referred to as “primary” or “a class” profiles.  They would become the building blocks for all different style sites, rather it’s a blog, an eCommerce store or a newspaper site.

Installation profiles, along with modules and themes, could even be developer to more closely mimic the proprietary systems out there. That would make a transition over to Drupal a lot less painful for the client when it comes to training their employees. I did something very similar when I moved Crooks and Liars from Wordpress to Drupal three years ago. I spent a few extra days to theme the backend and create the node editing screen so it closely mimicked Wordpress. The result was a team of over a dozen writers that were able to quickly adapt to the new system and the bumps from the change were minimal.

By building a more robust installation profile system and getting Drupal shops to embrace it, Drupal can really start to compete with these systems. We’ll have a more unified approach to common CMS tasks, while maintain the freedom of customization that Drupal has always offered. When a client needs to hire a new web editor, admin or writer, then they can confidentially hire someone with past Drupal experience and know they can be quickly brought up to speed on their own Drupal system. This is why those of us that develop Drupal sites need to think more like an end user and less like a developer. If we can come together and develop more unified systems, then we’ll be able to really push the product we love. It’s not really that complicated of a task, but it will require some changes by all of us who do professional development and a new thought process when we lay out a new project.