Content Management Systems Reconsidered
There’s an interesting post at Sunlight Labs that takes a good hard look at the advent of communnity-in-a-box content management systems, and whether they’re worth the trouble when compared to more flexible “frameworks” like Django and Ruby on Rails that provide more primitive but customizable components. Actually, the title of the post is more forceful than that: “Content Management Systems just don’t work.”
He observes that CMS’es often have “opinions” that are an artifact of the original intentions of the creators, which often stand in the way of it becoming an effective tool:
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.
He talks about Recovery.gov and its use of Drupal. I’ve used the latter on small sites, and it got me up to running speed faster than I could have done myself. I’ve also used Joomla with a crew of 20 collaborative journalists. But I get where he’s coming from, because in the end, the training and the coercing of the CMS to do what I wanted was rather painful. If I had to run something larger, like Recovery.org, his advice would be to hire someone fulltime, and use a framework. Given how many sites Clay Johnson has overseen, and how many different systems he’s used, it’s a valid concern.
March 2nd, 2009 06:40
I think seeing Drupal as a CMS is inaccurate. Drupal is more like a framework that bundles CMS modules you can use, ignore, or often disable completely. The vast majority of Drupal’s code is there to support a modular framework for supporting inversion of control (the menu system), templating (the theme layer), database abstraction, user management/authentication, input security (filter out XSS, etc.), permissions, logging, and the decorator pattern (hooks) for altering/extending current functionality.
The CMS components (node, block, etc.) are lightweight modules running on top of that framework. When you ignore or disable them, Drupal becomes a PHP framework that can run head-to-head against other frameworks.
March 2nd, 2009 06:48
Oh, and I responded on the linked blog about the “a CMS cannot be a framework” argument:
http://sunlightlabs.com/blog/comments/posted/?c=364
March 3rd, 2009 15:52
I agree that Drupal is a strange hybrid beast, that cannot be fully described as a CMS. But I would say that it has an “opinion” as described in the article. The nomenclature and taxonomy structure definitely enforces a viewpoint on how things should be organized that most implementers comply with. A true framework is generic like a Lego set, and I think Drupal is something slightly higher level than that. Not sure we even have a term for that.