Building CMS after CMS
In my life as a web developer/programmer I've built quite a lot of different CMS systems. Never have I used one of the commonly available CMS solutions, neither closed nor open source. "Why not?" is probably the question that comes up first when reading these lines. The reasons are rather simple: they don't quite fit the needs of the client, to put things mildly.
So many people, so many wishes
People are strange creatures. Clients never quite want the same thing in their search for a good web site/application. In fact I've yet to find two clients to whom I could offer the same solution. It just isn't going to happen. Of course there are generic parts that many people want to have on their website. Many companies wish to offer company news, downloads, event calendars, articles and other well known 'standard components'. Of course these are quite well covered by many existing CMS solutions. Needless to say, these features are never causing any problem if one would try to fit in an existing CMS system. The problems rise when the client comes up with desired features that aren't covered by existing systems or only partially.
Fighting the giant
The worst imagineable scenario occurs when a client has already chosen for a CMS system even before they contract your company to build their website/application. In most real world companies people who don't have the proper knowledge about technical implications are the ones who decide to purchase a CMS system. It's them who are sensitive for marketing/sales talk from third parties who offer 'complete solutions' to manage their corporate websites. In the ideal world those who are the decision makers incorporate the knowledge of their technical staff when choosing a CMS solution but more than often this isn't the case. Those who have to create or maintain the website find themselves stuck with a system they would never choose themselves. If only someone would have asked their opinion! Maintaining the website is one thing, building it is even worse. Developers find themselves fighting the often rigid structure of the existing CMS solution in a desperate attempt to make the impossible happen. Management is convinced of the power of the system they purchased and therefore they expect everything they want to be implemented in a glitch. That's what they were told by those who sold them the system so it's only logical that this is what they expect. In reality things aren't as smooth as they seem. Development exceeds deadines, costs rise and the management ends up with a way too expensive website, delivered way past the desired deadline. And very often the end result isn't quite what they wanted but at one point everyone silently accepts the situation because things have already ran out of hand enough.
So... we'll build it ourselves then?
The alternative for choosing existing CMS solutions is building one from scratch. This approach has several tempting advantages but of course it comes with a price tag. When developing a CMS from scratch, developers aren't 'crippled' by having to build everything within a tight prescribed frame. Another advantage is the fact that (technical) creativity can flow quite freely. If the development team is both skilled and creative enough almost everything is possible. It seems like the right formula for success. Now for the bad news: This approach can cause serious problems in terms of costs and maintenance, the last being the most serious hazard. In terms of costs it's difficult to say whether the balance shifts towards the stock-CMS solution or the custom made solution. As we have seen, both approaches have advantages and disadvantage. Personally I believe these will even out against eachother quite well if we consider licensing costs and/or training with an existing CMS and extreme coding challenges when trying to do something the existing CMS doesn't support on one hand and extra development overhead on the other hand when creating a completely custom CMS. Maintenance however is a different story. Custom made systems are often built by people with very little writing talent. Therefore documentation is often non-existent or very scarse at it's best. The pressure of upcoming deadlines also causes documentation activities to be skipped or performed very badly. This causes a serious risk for the client. It renders the client completely dependent on the one(s) who created the system. I leave it to the reader to realize why this is a very bad thing. It seems we're quite stuck now. We cannot use a a pre-built CMS because of it's limitations, rigidity and sometimes price and we cannot build it ourselves because it's too expensive and because it poses a maintainability threat.
Introducing the Meta CMS
The above described status quo calls for a different approach, which I'll dub the 'Meta CMS'. A Meta CMS would be a framework enabling developers to build a CMS fast and without posing limitations on what the CMS and the site presentation engine can have in terms of features. Efficiency could be achieved by offering stock data access components, form components, page rendering components through XML->XSL transformations for both frontend and CMS backend. Most traditional CMS approaches are 'feature centered'. We find a news component, a calendar component, a links-section and many more commonly used matters. If we want a more exotic combination of features or components that just aren't available in the CMS we're stuck. Therefore, away with feature-centered plugins! The core of any dynamic website, in my humble opinion, shouldn't consist of blocks that enable predefined feature sets to be implemented but of... CONTENT! Texts, images, URL's, flash movies, video's, documents etc. etc. form the building blocks of any site on the web. The meta CMS should have these as it's fundamental building blocks instead of predefined combinations of these presented in chunks. Another cornerstone of any website is the page entity. A website consists of pages. Pages are interrelated by internal or external links. Pages contain texts, images and other basic blocks of content.
The ideal Meta CMS
My ideal CMS, or meta-CMS would be a better description would have the following:
- Open Source or at least with a well documented programming API
- If licensed, have a fixed price to deploy the CMS for one client no matter how many users
- Platform independent
- Based on open standards both in terms of W3C standards as well as code (JAVA, php, etc.)
- Content centered (versus feature centered)
- XML based (XML being the core output format both internally and externally
- Use XSLT for final presentation format in order to be flexible in terms of multiple client types
- And last but not least: it should SAVE development time instead of making things more complex. It should be a better alternative compared to the do-it-yourself approach as described in my essay.
Concluding thoughts
Frameworks like MMBase or Zope seem to have adopted this philosophy quite well which means at least I'm not the only one who 'has a dream'. However after studying these frameworks I believe they are on the right way but not quite the meta CMS yet. It seems there's work to do. Let's build the XML driven Meta CMS that really saves developers and clients time and money in terms of efficiency, without loosing any flexibility in terms of being able to satify the wishes of the customer. The road ahead is long but who knows we might get there eventually...
