For years, I've been working with one or another CMS, I've built several of my own CMSs (even sold a few), and now have this iCite net project which could suggest a bright post-CMS utopia on the right rainy day if you were in the right rained-on mood. But, I think I've just now come up with a really good one-liner about why CMSs essentially don't work.

First of all, Jeffrey Veen's Why Content Management Fails and Making a Better CMS (which I originally mentioned here and here, respectively) make a number of excellent points, and can probably be regarded as some of the most succinct and accurate critiques of CMSs to date. So, I recommend you read those if you're interested in content management.

But, I think there is a more succinct, simple, and blunt explanation than Jeffrey's. And note: I've been using the word "contents" instead of "content" to talk about the contents that get managed.

So, here it is:

There is no such thing as "content"! And, as a corollary: Because there is no such thing as content, content can't be managed, and content management fails!

Now, as I hope I've already made clear, I do think there are contents. This website has contents; or this blog post is part of the contents of this website, etc.

But, trying to manage content is like trying to manage retail. In other words, content is a generic category, not an actual thing. In actual practice, there are specific contents that are managed—and, importantly, there is often significantly little in common between different sets of contents (e.g., from one website to another).

(For my programmer friends out there, let me state it this way: content is like an abstract class or an interface, most of whose fields and methods are merely placeholders unless they're overridden in specific concrete contents classes.)

So, CMS tend to represent a set of generic functionality. And, there may be nothing wrong with that functionality (though there often is, as Jeffrey describes so well), but folks have wrongly assumed that this generic functionality can manage the specifics of their contents. It can't.

As an analogy, imagine I had a retail management system that was purported to meet the needs of all kinds-of retailers: grocery stores, clothing stores, newspaper stands, etc.

Folks from both a grocery store and a clothing store both might be able to think in terms of retail, but the process of how their stores are managed is very significantly different than each other. And, it's not surprising that those folks would choose distinct clothing store management systems and grocery store management systems over generic retail management systems.

Obviously, given a simple enough set of features, a CMS will work across different sets of contents. But, if that's it, what that means is that even the best CMS is, at most, only going to consistently meet lowest common denominator needs.

I realize that many CMS have, for example, weblog modules. And, weblogs are then like a genre of specific contents managed on top of the CMS. But, in my experience, these types of modules nevertheless address only pretty-low common denominator contents needs (i.e., they're good if you want a weblog, but anything almost exactly, but not, a weblog doesn't work so well).

(As an historical note, the last big CMS I developed was actually an engine around which many different kinds of very specific contents management systems could be built. I experimented with a number of the ideas of the iCite net in that system.)