Tags: Posted in web development 7 Comments

I often listen to the Boagworld podcast by Paul Boag of Headscape; the current episode has a feature, which is essentially an extract from his forthcoming book in which he talks about content management systems and how there are too many of them.  His post has a lot of really good points about what to look for in a system and the issues that come along with them, such as support; his post on Vitamin shows the costs of a CMS, most of which aren’t strictly financial.

All really useful stuff but I’d like to expand upon that a little more.

There are too many content management systems

You only need to go so far as CMS matrix or Open Source CMS to get a sense of how many community project content management systems there are out there.�  This is alongside all of the off-the-shelf or hosted solutions you can splash out on.

As Paul says, there are a lot of problems with this huge array of choices.  Not all CMS are created equal.

There can never be too many!

That may be overstating it slightly but I have my reasons!  I actually think that creating a CMS of some kind is a great thing for a developer to be involved in; whether it’s by themselves or part of a team.  There are so many related issues it’s possible to plough through that many valuable lesson can be learnt.  The big difference is in the longevity of the project, support and of course the end-user/client.

It’s fair to say that there’s no need to keep reinventing the wheel but when it comes to CMS, it’s a case of creating the right kind of wheel for your project.  Sticking with the analogy; someone didn’t invent a wheel and leave it at that, it’s been refined constantly for every vehicle; each vehicle having different needs from their wheels.

There are a core of tasks the CMS needs to be able to do such as having users to privately manage the system, creating, modifying and deleting content; other than that every CMS can either meet the needs of the developer to speed up their daily workload or the needs of the client to give them control.

Projects like Drupal have a great following behind them and a product now at version 6 has become quite mature and can be extended to make a niche, targeted system.  Why should we as developers keep making new ones when projects like this are durable and usable?

Off the top of my head, here’s a quick list of the topics I’ve learnt about through working on a developing our in-house system:

  • Permissions
  • Dynamically generating standards compliant mark-up
  • Localisation and the issues surrounding multi-language systems
  • User experience
  • Problem solving
  • Working with other people’s code
  • Version control or the problems of not having it
  • SEO
  • How to store and manage Images/media

Our system is now 3 generations along and serves many clients well and while we know how it can improve, we’re learning from our clients all the time.

So yes there are too many but I think it’s valuable to the development community as a whole.  So many projects or systems to learn from and try and compete with (in some cases).  The issue isn’t the number of them per se but that it’s difficult for (possibly less experienced) developers or clients to know what is good or bad; which does what they want it to, or where the real costs are in using various systems.

Be Sociable, Share!
28th August, 2008