Choosing an open-source CMS: it's about the people, not the platform

We at Digital Loom are finally going to take on the age-old question:  how do I choose an open-source CMS? But first, here’s what we’re NOT going to do.

We are not going to provide a point-by-point analysis of the merits and drawbacks of Drupal, Wordpress, and Plone because other very smart people have already done so. You’d be wise to download Idealware's open-source CMS report before you do anything.

And even though we are Drupal aficionados, and have built sites exclusively with Drupal for the past decade, we are also not going to tell you that Drupal is the only sane choice and you’d be a fool to consider any other. In fact, when people call us up asking if they should switch their current CMS to Drupal, we often advise against it. Why would we do such a thing? Don’t we believe in the platform that we ourselves use?

Of course we do. But the more conversations we have with many people who build and maintain websites, we are increasingly convinced that it’s all about the people, not the platform. When you’re choosing a CMS, there are four groups of people you need to be concerned about.

The people who build the site

All the open-source CMSes have one thing in common: they are flexible. A competent developer can configure your site in various ways, make it look exactly the way you want, and create custom tools that do what you need. An incompetent developer, or one who just doesn’t care that much, can use the same CMS to build a site that makes you dread coming to work in the morning.

Often the only difference between a site that is frustrating to use and one that works like a charm is the people who set it up for you.

For example, I recently spoke with the manager of a small online magazine with a Drupal site. She explained that in order to add an image to one of their articles (something they do pretty frequently, being a magazine and all) they have to crop and resize the image in Photoshop, upload it to their server using FTP, copy a link to that image, create their article, click the image tool, paste in the link, then position the image relative to the text.

“I’m so sorry,” I commiserated. “It doesn’t have to be that way.” I explained to her that we routinely set Drupal up to let people easily upload, crop, and resize images (including multiple sizes for thumbnail and large views) right within their article, without any outside software.

“That’s what I thought!” she said. “But when I asked our current developers, they said it couldn’t be done.”

Do you see what I’m getting at here? Same CMS, different people. Tools are only as good as the people using them.

You might be wondering, “OK, so how do I make sure the developers know what they’re doing and care about providing an excellent experience for their clients?” Two tips:

  1. Check references. Make sure you talk to someone who actually uses the site these developers built on a routine basis. Ask how easy or hard it is.
  2. Ask for a demo. Ask the developer to demonstrate a number of routine tasks using a site that they built. If it looks hard to you, it probably will be.

The people who maintain the site

If the content managers you have on staff all know and love Wordpress, you could be doing your organization a major disservice by switching to Drupal. If you have in-house developers with strong PHP chops, it doesn’t make sense to use Plone, which is written in Python. And so on.

But what if there are things you don’t like about your Wordpress site, and you have heard Drupal is “better” in some way? Before you do anything rash, ask a good Wordpress developer about how your site can be repaired, upgraded, or customized to address those concerns. Not only will you spare your in-house staff a potentially steep learning curve, you could save a ton of time and money by fixing up what you already have. You wouldn’t make over your entire bathroom just because the sink is clogged, right?

The people who support the site

In many cases, the people who build your site might be the same people who add new features for you in the future, install security updates, and do minor fixes as needed. But with many of our higher education clients, their choice of CMS may impact whether they can take advantage of campus support, training, testing, and other resources.

Wellesley College is a great example. Impressively, their IT department has managed to get almost every group and department website on campus to happily coexist on a single Drupal installation, and at the same time offer each the freedom to choose from different features and themes. If a Wellesley department wants a Wordpress site, they can certainly get it, but they’ll be losing out on the opportunity to receive ongoing support and security updates from the IT folks—which could cost them thousands of dollars a year in support and maintenance costs from an outside vendor.

The people who contribute to the CMS

In the land of open-source software, a CMS’s developer community is important—not only the developers who build sites using Drupal, like us, but the developers who create new tools and functions for it. The last thing we want is for clients to be “stuck” working with us if, for whatever reason, they weren’t happy with our work. We want them to have the freedom to work with any developer, and to reap the benefits of a thriving community that’s constantly releasing new tools.

In summary. . .

We certainly advise that you do your homework to educate yourself about the technical differences between various open-source CMSes. But we also advise you do a thorough assessment of:

  • Your in-house staff’s strengths and experience
  • Outside designers and developers you’ll hire
  • Any support resources you may have available
  • A CMS's developer community

In short, focus on getting the right people on your side, and the rest will follow.

Share the Love