Choosing A Content Management System

I’ve shied away from tech blogging.  Even though its how I make ends meet, it isn’t really my passion in life.  Nor is it something I’ve considered terribly relevant to the purpose of this blog.  This post by Pam Spaulding finally convinced me to post this.

I think that an understanding of how corporations work (and ought to work) is fundamentally a political issue.  A corporation is a vastly less accountable form of government (which more than a few small government types unfortunately miss).  So I think their study can be a fruitful pursuit.  With that in mind, I have some insights that might be helpful for organizations choosing a new CMS, and will discuss the implications of those choices.

As a brief primer, a Content Management System can be thought of as a way to help people in creative and technical roles work well together.  A good CMS is easy for writers to use to get their ideas out onto the website, and easy for developers to tweak to give the website new features, and it look and perform better.  WordPress is a content management system.  WordPress.com developers and designers have crafted an impressive site, and bloggers such as myself form the creative team behind the content.

There are a few scales on which to evaluate CMS software (non exhaustive):

• Open Source – Closed Source
• Free – Expensive
• Liberal – Restricted
• Popular – Rarely Used
• User Friendly – Predatory Interface
• Stable – Experimental
• Fast and Scalable – You’ll be needing lot’s of hardware
• Well Architected – Well at least it runs

In general one wants to lean towards a fast and stable platform.  The tricky thing is most CMS’s I’ve dealt with may claim to be stable, but rarely ever are.  (One notable exception is Django, which I’ll be discussing further).  Marketing hype can and does frequently slink in front of many systems out there.  So immediately the issue of trust comes to the fore.  We’ll get back to that in short order.

The choice one most often runs up against are purely Free and Open Source systems, and fully proprietary ones.  Hybrids are rarely used.  The problem with choosing an unpopular CMS is that finding knowledgeable developers and working example sites can be quite difficult.  One can minimize the pain by sticking to a familiar language, but a new system is a new system, even if everything in the world were written in Basic (thankfully it ain’t).

We come back to trust when looking at a popular CMS.  If its widely used, there are examples to look at (and people to contact.  Never blindly trust a list of sites where the CMS you are evaluating is used.  Talk to them.  Was it easy to use, or a pain?  How long did it take?  Do people there understand it, or are they reliant on outside contractors to do the most basic tasks?).  If its open source and popular, then there is a world wide community of programmers who can and will vet the code for you.  The more transparency involved, the more you can be sure you’re dealing with something that lives up to its hype.  The “many eyes” approach open source programming makes famous is only true of larger projects.  Small projects are often driven by only a few core developers (sometimes even just one).

So a popular system is best, and open source software has an advantage in terms of code transparency (and often code reliability).  This brings stability in most cases (if you stay off experimental branches).  Speed varies significantly across systems.

Which leads us to the remaining points.  There are Content Management Systems out there with user interfaces that actually eat users (these are largely proprietary).  Such a thing is to be avoided.  Talk to people who have used a CMS, and love it.  Next there is how much room the license leaves you to maneuver.  Some systems are proprietary.  If you want to make changes, well, you can’t.  You just have to improvise and rig something to work around the system, rather than through it.  Then there’s restricted licenses that let you see and modify the source.  But doing so requires you to make all of your code public.  The most palatable solution is either GPL 2 or a BSD like license.  With GPL Version 2 (not the AGPL or GPL 3), you can be sure that your code remains your own.  With a BSD license, you are free to do whatever you want, even repackage the system and sell it as your own!  (Highly recommend against this.  Entering the CMS market is largely like a small university entering big league college football: a huge financial sinkhole.)

In essence the ideal Content Management System is free, open source, popular (and supported by an active developer community), fast, stable, easy to use, and free of restrictions.

Django hits almost all of these points which is quite impressive for a Web Framework.  It isn’t a full fledged Content Management System.  Developers will need to build in much of the desired functionality.  But when approaching this from a business perspective, that’s a huge plus.  No CMS is going to come packaged to fit your business’s unique needs perfectly.  Most companies either make due or struggle and fight the system they just bought for several hundred thousand dollars (while paying consultants vast sums to install a system no one in house will be able to work with 5, 10 years down the line).  The one area where Django could use some help is would be a very lightweight CMS built on top of it, governed by the same license.  This would improve the user interface, which is the only area where Django lags behind the competition.  For your company, a good dev team can remedy that right quick.

What does a good CMS, vs a bad CMS mean?  It goes back to the point of a good CMS being a facilitator of sorts between roles within your organization.  With a good CMS as defined above new features are a straightfoward process.  You’ll be far less likely to run into problems like “the CMS doesn’t support this” (which is a certainty with the less flexible approach a poor CMS affords).  It means new developers will come on board ready to rock and roll, because they’ll be able to draw on a large knowledge-base of users and developers, and many will already be familiar with the system.  A good CMS removes frustrations and makes creating new content simple for your writers.

Using a truly free and open source project is in itself a political act.  So if you do pick an open system, publicize it and share that with the world.  Good software also powers effective campaigns and political efforts.  Drupal was behind Howard Dean‘s impressive efforts in 2004.  And for a new beta project, the New York Times used Django to implement a system to help New Yorkers see what is going on in the news with their elected officials.  The very same arguments that make for an effective corporate team apply to nonprofits and political campaigns.