Mar 11, 2012

CMS vs DMS

I've spent a lot of evenings over the past 5 years or so jotting down notes for my one-day to-be CMS, or so I thought. This morning I came across this post, which makes me think I've actually been designing (or perhaps rather, dreaming of) a DMS.

Reading this post made me think of something I recently added to my CMS/DMS notes:

Why do all CMS come with predefined concepts like "categories" and "tags"?

Wouldn't it be much better if you had a data-facility that let you define schema for any data-structure? You could then use this to define your own "category" and "tag" data-types.

Okay, so CMS like Drupal already have this - in Drupal it's called the CCK. It's the culmination of an inevitable conclusion that all CMS developers seem to have a few years too late:

In order to satisfy everyone's needs, you need a general data-management facility.

The problem is, by the time most CMS developers reach this conclusion, their CMS is littered with built-in, pre-defined, set-in-stone concepts - plus loads more add-on concepts from third-party contributors, and for that matter, typically, at least 10 different developers built their own versions of the same concepts.

By the time you start building the general-purposes data-management facility, the already existing built-in concepts will need to be integrated with the general-purpose data-management facility, and many third-party developers will integrate their add-ons with the data-management facility, too - which is a recipe for bloat, duplication, inconsistency and confusion... which add-on should I pick? do I need an add-on, or should I just define a custom data-type? etc.

If your CMS/DMS had the data-management facility at birth, you wouldn't need lots of add-ons for concepts - add-ons developers could instead focus on delivering useful UI-features, providing integration with third-party components and services, and other really useful things.