Why we use Content Management Systems

An organization wants to work on content in a WYSIWYG way, do approvals workflows on changes outside of a traditional go-live cycle, and in a place that is not actually live. The organization also wants to promote changes to live (or from live) safely.

At least, that’s a relatively short version of what I identify as the root cause of CMS decisions. The strongest argument in favor of CMSs perhaps.

Breaking that down

• Content is prose and pics (shouldn’t really be code)
• Non-technical users want to edit content comfortably
• Approvers want to do approver stuff at various levels of granularity
• Audit of changes is important too, both historically, and for “what is pending?”
• There could be more than one “branch” of potential content changes in progress
• A set of content changes could go live in one go, or one by one
• Quite often users want to see pending changes in production, or perhaps a non-live domain that is otherwise the same as live
• Promoting sets of content changes should concisely warn about divergent changes in the “destination” that the “source” is about to overwrite

CMS features not directly related to the initial statement

I’m generally far less interested in other built-in or plugged-in functions of a CMS. That includes document/media ingestion, commerce features, social media enhancements, trackers, search, discussion forums, data entry, etc. These features may be great, but I’m left feeling cold if one other thing is not on the feature list (read on).

Why the vast majority of CMSs suck.

They don’t use source-control as their backing store, and can’t possibly allow round-trip editing of content. As such technical perfectionists have been divorced and the TCO has gone ridiculously high because of lock-in, Conway’s Law, and concerted efforts to price their apps as cure-alls. I’m not interested in CMS applications, platforms, frameworks, or libraries that use a relational schema for storage of canonical content.

“Round-trip” in this context is where content can be accessed via a source-control checkout (power techies) as well as via the polished web interface. Both of those should coexist equally. The power techies would use a command line to perform a checkout of a repo/branch, edit using conventional editing tools, and commit atomically when they are finished. Were someone to F5-refresh a browser view of the same content in the CMS app, they’d see the same change.

Another “free” feature of source-control backed CMSs is the clarity of diffs in an attempt to promote sets of content changes (merge). Where branches are used to mirror environments. the three-way merge possibilities of source-control systems are highly relevant too. That’s true for cherry-picks as well as “merge all” scenarios. Built-in history and the possibility of reverts are also relevant to a CMS workflow.

You see source-control is a perfect fit for content management systems.

With a first class honoring of content under source-control, you’re also much less locked-in to any CMS vendor’s technology.

Which CMSs can store content under source-control?

There’s a site cmsmatrix.org that has a rudimentary comparison feature. It’s difficult to tell whether the drop-down choices include “source-control” or related synonyms and acronyms, let alone named technologies in that space. One CMS is Alfresco has “Other” listed for database which is as clear as mud. CMS Matrix lists 1200 different CMS tools, and doesn’t appear to have a search facility. They could throw a rudimentary search capability together in less than a day in AngularJS, but it might be a little slow.

Tools that do use source-control as the canonical store, in order of apparent life

Nesta CMS, Apache’s CMS, Git-CMS, Hardwired, Caloris, and Regulate

I’ve not used any of those. Some are not perfect round-trip capable, and may never be. All can store canonical content under source control, but I’m not sure if the do the commit/push too from the web editor.

I’ve mentioned before that Github do something that’s pretty compelling as a CMS, albeit a little feature limited.

Lastly, my employer ThoughtWorks has also made a CMS that is using source-control as a backend, that’s solid enough for us to bet the corporate website on, but it’s not yet using branches for staging. Read Part-1 and part-2 of their very detailed blog series. I’m looking forward to part-3 as I’ve mentioned to the team :)