A few months ago, I posted about the newsinitiative site I had spent most of the summer working on*, and mentioned that we had decided to build our own content management system for it from scratch. Promised to say more about the CMS “build vs. buy**” decision process we went through, but never got around to it. After installing Search Meter for WordPress a month ago, discovered that people have actually been searching this site for more info on that decision.
CMSs are a funny category of software. When you go to choose a word processor, you’ve got three or four serious options to consider (but it generally comes down to Word). Image editor? Maybe a dozen (but it generally comes down to Photoshop). There are usually more options for server-side web application software. Survey package? Maybe a dozen. Blogging platform? Again, maybe a dozen (but it generally comes down to Movable Type and WordPress). But the game changes immensely when you start looking at content management systems.
OpenSourceCMS lets you try out demo installations of around 50 free CMSs. cmsmatrix.org lets you create feature comparison tables on, wait for it, 643 different content management systems, ranging in price from $0 to $200k (at the higher end, you’re paying for a team of guys in jumpsuits to come to your organization and live under the desks).
On the university web development mailing lists I’m on, “Which CMS is right for us?” is the single-most frequent topic of discussion, by a wide margin. Everyone needs one (or thinks they need one — I think they’re often deployed unnecessarily), but no one knows which way to jump. There is probably no harder software choice you can make, for several reasons:
1) Unlike, say, email clients or HTML editors, you can’t switch CMSs on a dime. Once you buy into a CMS, it’s very hard to switch to another one. You have both data lock-in and systems lock-in (this alone is a very good reason to think hard about whether you really need a CMS or just think you need one).
2) Actual needs can be very difficult to quantify correctly in advance, and difficult to correlate with product descriptions.
3) It takes a lot of time to evaluate the options – you really need to install a CMS and work with it for a good while before you know whether it’s going to work for you. But these things are not plug and play — it’s not like installing a piece of desktop software and being able to figure it out by studying the menu options. Bringing a new CMS up to the point where you can even duplicate your normal workflow could take days or weeks of research and experimentation.
4) There are simply too many to choose from. If you have to go through step #3 for each of half a dozen finalists, you’re talking about a major expenditure of resources, just to make the decision.
CMSs are complicated beasts. Once you’ve made your decision, the real development work begins, which generally involves understanding that system’s internal workflow, node hierarchy, templating and conditional languages, plugin options, data structures, etc.
So why are there so many CMSs on the market? Two factors contribute to the reason. One, because choosing from among existing systems is so damn hard, and so time-consuming. And two, because organizations’ needs differ so radically. For a CMS to encompass everything anyone might want to do, it has to emerge “out of the box” as a very generalized, rarefied system. There’s no such thing as a CMS that works the way you want it to work as soon as it’s installed. Making a CMS sit up and do the tricks you need it to do is going to require development time, period. Faced with these options, many organizations with in-house programming talent just throw up their hands and say screw it, let’s just build something. How hard can it be?
In a sense, they’re right. A basic CMS is a pretty trivial programming task. Create, update, and display content in a database. But the devil is in the details. You probably need a user management system, with authority roles. You need a workflow system to move content through draft, review, and published states. You need a system to manage incoming non-text media. You might need the ability to run surveys and polls, or to handle other kinds of form data. If your content takes public comments, you need to be able to manage those comments on the back end (and deal with comment spam as it arrives). You need it to be able to generate email to authors and editors when content states change. You might want built-in blogging, and everything that comes along with that. You want RSS feeds coming out of its ears. You need to deal with all those nasty curly quotes and other special characters being pasted out of MS Word into your forms. You need author bio pages. You need to accommodate static content sections, like “About This Site” and “Contact Us” (again, with spambot protection). You need form field validation to make sure authors are putting the right kind of data in the right places. You might need to accommodate multiple-author bylines. You need pagination for longer pieces of content. You need both a back-end and a public display system. You need “E-mail this page to a friend” and “Print this page” functionality. You need to think about security at every step of the way. You need to be able to preview content before publishing. You need context-sensitive usage documentation for all of the authors and editors. You need the ability to modify timestamps and story slugs. You need to come up with a way to create clean URLs. You might need multi-level search (site-wide and project-wide). If you’ve got multiple developers, you need a code checkin/checkout system (CVS or SVN). The list goes on, and every little piece piece needs to be built by you — hopefully with enough forethought that it scales outwards nicely as you add features.
So once a group has put in all of the time required to get the results they want, they decide they may as well release it into the wild, either as open source or commercial software. And “walla,” we now have 643 systems to choose from.
Our case called for a multiple team layout (the four participating universities), each with its own project. Some projects would have custom Flash interfaces, others would not. We needed projects attached both to schools and to semesters, so we could refresh the whole thing next time. We needed to handle multimedia content from many sources, in an elegant manner that didn’t require users to mess with paths or HTML. We needed the ability to have user-selectable layout templates nested within master templates. We need the ability to embed custom HTML blobs, to alter story order, to embed custom database applications with story bodies. And so on.
Given enough time, we probably could have found an existing CMS that could have been hammered into shape. But the clock was ticking, and our experiments with existing CMSs were showing that the research and discovery process was going to take too long. If we built it ourselves, we reasoned, we’d grok every square millimeter of the project, and be able to tweak anything without having to study docs or hang out in forums.
After several weeks, we drew a line in the sand and said “We can build this.” Almost immediately, we started getting feedback from people who had been in the same boat, and either vehemently agreed or disagreed that we had taken the right approach. Arguments in favor were pretty much in line with our own reasoning. Arguments against included things we already knew, such as the fact that we wouldn’t benefit from free security and feature enhancements and would not be able to take advantage of existing plugins and modules that could save us a lot of time. All true, but in the end, we have no regrets. We even got accused of having a bad case of Not Invented Here syndrome (which simply wasn’t true – we were just trying to do the right thing for the organization and for ourselves, and would have gone with an existing solution if we had thought it would be easier).
Ultimately, I think the two-month timeframe it took to construct our CMS from scratch was about what it would have taken to choose and implement an existing CMS, so it was probably a wash, time-wise.
The fact that major news organizations have already inquired about adopting our CMS makes us proud. Ironically, in the end, I’m still not convinced that the site we produced warranted a CMS at all. We spent months developing our system. Formatting 100 or so pages manually inside a simple templating system would have taken a fraction of that. The number of pages you ultimately have to manage, the frequency of updates etc. needs to be considered very carefully when deciding whether you need a CMS at all (don’t adopt a CMS just because everyone else is doing it, or because you think it will ipso facto make your life easier – ye olde permissions-based filesystem, favorite HTML editor, and templating system remain a great way to manage large amounts of content in many contexts — that’s what we did for the new J-School site, and we couldn’t be happier).
One thing is clear: Anyone who could really master the whole CMS minefield could make a great living as a CMS consultant. Organizations need good, educated advice from people who have been in lots of trenches. And they need it bad.
I’ve left a whole other category/approache out of this discussion: Frameworks (Ruby on Rails, Cake, Symfony, Code Igniter, Django). We did spend time talking about frameworks vs. CMSs, and in retrospect, I kind of wish we had used one rather than build completely from scratch. But like CMSs, frameworks require quite a bit of exposure developer/experience before you can really be productive, so the same time constraints we faced pretty much kept frameworks off the table. We went with plain old PHP, which is what we know best. We’re now developing some in-house Django talent, which will probably guide our next big project.
Has your organization been through the build vs. buy CMS decision? Which way did you go? Any regrets?
* No, we weren’t responsible for the visual design, just the CMS.
** When I say “buy” I’m being colloquial – if we had not done it ourselves we would have used an open source CMS such as Drupal.