Follow Us

Content Management Systems just don't work.

by

Somebody asked me the other day what I thought of Recovery.gov using Drupal and it got me thinking about content management systems. In my consulting days, I watched companies and political campaigns and non-profits sometimes spend hundreds of thousands of dollars annually trying to make their content management system do what they wanted it to do for their online campaigns. As an honest developer and honest consultant, this made me apoplectic-- I knew that at the end of the day, technically what they wanted was fairly easy to build. But they had to pay hundreds of dollars an hour to get a "Drupal Specialist" at an outside consultancy to set up simple pages because they could not figure out how to get the stuff to work right.

Now, this experience isn't solely limited to Drupal. From working on the Dean Campaign to consulting for hundreds of clients at Blue State Digital, to working at a non-profit like the Sunlight Foundation, I don't think I've ever been happy with a content management system. I've tried dozens, from the ever so simple blog engines like TextPattern and Wordpress, to the more complex Drupal, MovableType, and ExpressionEngine, to the full-scale content management systems like Typo3, Bricolage, I feel like I've worked on and with as many content management systems as I possibly can in my career. And I can't help but feel as though I've never been satisfied with any of them.

Amazingly, I can't find anybody that's used their content management system that doesn't seem to either be resigned to using it, or have an amazing amount of contempt for it. People really hate their content management systems and I think the reason why is because full-blown Content Management Systems just don't work for any kind of sophisticated online presence. At the end of the day, you're probably going to want to do something that Content Management System can't do or worse-- you're going to run into something that your content management system can do and does poorly.

See-- the problem with a full scale Content Management System is that it has too many opinions. Those opinions were though of by somebody other than you and the needs of your organization. The more developed a content management system (or any piece of software, really) the more "opinions" it has. And the more "opinions" it has, the more likely one of them is going to really tick you off. Especially in the world of Content Management. Those opinions could be anything from "What should the admin interface of the website look like" to "how should workflow work for the editorial process" to "What kind of user registration system should there be" or a plethora of other opinions like "how should data be stored" and "how does a designer interact with me." More often than not, one of these pieces of functionality is bound to create frustration and anger-- potentially rage for either you or your users.

Our alternative is to take a step back from Content Management Systems. You have software frameworks-- generally a programmer's toolkit used to build things like Content Management Systems or other web applications. Instead of spending lots of money on a content management system and paying a specialist integrator to create and install and maintain it, you're better off finding a competent developer that is well versed in a framework like Django or Ruby on Rails. One competent developer using either of these frameworks can weave together a content management solution and constantly be developing tools inside of this solution that make sense for your organization.

With Government in particular you end up with even more problems going the standard CMS route. When Government picks a CMS over a framework, Government is basically saying that they're going to trust the CMS's standard way of delivering data or work to change those standards and replace them with new ones. It seems to me that especially in Government it is far more effective to be using frameworks than CMSes. Recovery.gov, for instance, isn't a content management problem but a data delivery problem. Government should be focused on delivering that data in the most thorough way possible and when you factor all the different data sources that recovery.gov is going to have to talk to, I'd much rather be using python than trying to hack within the confines Drupal to do the job.

There's some arguments against taking this route. The most knee-jerk one is "you're throwing away so much functionality" when you don't use something like Drupal. But the point of frameworks like Django and Ruby on Rails is so that much of the common functionality (user logins, registration, even things like social networks and shopping carts) can easily be baked in to any application in the way a developer and a customer chooses. They can be built custom or sewn together through components and plug-ins.

The second argument is: "But Drupal/ExpressionEngine/Silverstripe is a framework, too!" and it isn't. It just simply isn't. Drupal and the like are content management systems that may have modular hooks in them to build other software, but the software crosses the line into content management systems when it starts providing default user-experiences out of the box. This means you have to un-do the way default behavior works and apply what you want as desired behavior rather than writing behavior from scratch. That's where the primary difference is between a Content Management System and a Framework are: a framework provides a minimal amount of user-facing functionality (it may provide simple ways to create it) but generally focuses on providing tools that make a developer's life easier.

The third is: "Integration" which for most organizations is a quixotic windmill chase if there ever was one. In my years of working on voter databases, targeting tools, contribution systems and email systems people constantly asked for all these systems to be integrated, but when asked for practical reasons why they often came up short. When you do have those practical reasons-- those integrated queries you want to run on your user data -- your developer can make that happen to you probably better than you can with squeezing your data needs into a CMS.

There's also some gray area here -- a "Third Way" if you will. Sometimes a framework gets extracted out of a content management system. CodeIgniter, for instance, was extracted out of ExpressionEngine, and Sapphire was extracted out of Silverstripe. You may be tempted to say "Hey, this is the best of both worlds!" and it could be, but keep in mind that you're still choosing to adopt a bunch of opinions in your software from people who don't have your organization's priorities in mind. The point is to start with a framework that allows you to build solutions rapidly rather than to buy off on somebody else's solutions. Also, you have content management systems like Ellington and Mephisto that are built on these pre-existing frameworks. Same deal applies-- just because the content management system is built on a framework, even one that you like, doesn't mean that the design of the content management system works for your organization. It is likely better and cheaper to build a solution that works for you out of the framework.

This isn't to say that you need to build every application in your web presence from scratch. At Sunlight, for instance, we use Blue State Digital's[1] mailer and advocacy tools and integrate them seamlessly into our campaigns when they fit the bill. They're a great provider of services that fit around what we need. We're happy to drop in other off the shelf solutions as well-- the Sunlight Foundation blog, being a blog and all, is powered by WordPress. But when it comes to content management and end user experience, we want to control the user experience as much as possible.

Now, this isn't a decision for everyone to make. But if you are sitting there thinking about your content management needs and trying to figure out how to "power" your website and a vendor has given you a bid somewhere close to or over $40,000 for the first year of purely technical work, consider shopping around for a full time Django or Ruby on Rails developer instead. You'll find yourself with the ability to do more, faster.

One last caveat: never hire anybody who is religious about their software. If somebody believes that "Rails is the solution!" or engages you in a debate about why "Drupal creates so much possibility for our movement" and tries to inject some form of zealotry into your thought process, get away from them as quickly as you can. Writing good software is, at the end of the day, not about the framework you use or the content management system you're an expert at, but about being a good developer. A good developer is going to seem nearly agnostic about the tools that they use and instead be able to converse with you and develop the solution that is right for the problem. A language like Python or Ruby or PHP doesn't matter nearly as much as the competency of a developer. A great developer is going to be able to do amazing things in any language or framework.

Update 5:06pm It should be noted here that this isn't a Drupal specific post, though it seems like there's a lot of anger from the Drupal community about this post. To those that think that this is a direct attack on Drupal/Your Favorite CMS, I ask that you take another look through the article and keep a level head. It isn't. Another misunderstanding is that this is specifically geared towards the Open Source community, which it isn't.

Next, there's a new argument I didn't account for that I should have: "doing it all yourself means if your developer gets hit by a bus, you're going to be out of luck!" That's not true exclusively of frameworks vs. content management systems. That's where the competency comes in: if you hire a competent ruby developer to build a Ruby on Rails solution for you and help you maintain it, that code will be maintainable, just as if you hired a competent ExpressionEngine developer to make modifications to EE Core. And if you hire an incompetent Ruby developer their code will not be maintainable, just like when you hire an incompetent EE developer. The point is competency.

[1] it should be noted that I was a founding partner in Blue State Digital. There are plenty of other solutions out there for mass-mailing and advocacy, like Democracy in Action, Convio, and Vertical Response, and Constant Contact.