Matthew Buckland wrote an interesting article giving a good overview of the importance of the decision “which CMS technology should we use for our web app?” and catagorizes the possible solutions into three basic categories, namely 1. open source, 2. proprietary and 3. built from scratch.

At WWW, we have been delivering Content Management System (CMS) solutions for over 5 years now. We have had an interesting journey in this regard and have come to some strong (and hopefully useful to others) conclusions.

In the beginning, our approach was to build our own CMS for use by our clients. We sold it as a proprietary product, licensed on a Software as a Service (SaaS) model.

We quickly realised however that:

1. Everyone and his dog was/is doing this – well at least every small company with the word “web” in their company profile…
2. It is impossible to keep up with the feature-set available in popular and rapidly growing open source CMSes. Any feature additions are expensive – either to the client or to you as the owner of the code base (neither outcome is favourable)
3. For a client, it is scary to be tied into a proprietary CMS only supported and managed by one (usually small) company

We concluded that we should seek out the best CMS for each typical requirement and become experts at implimenting that solution instead.

So we did loads of research and testing and had some vigourous internal and public debate.

It’s been a while since I blogged about this (last was 2006), so here is where we currently stand…

1. We have found that Joomla! can meet 95% of requirements for CMS sites. As the world’s most active open source project, about 15 modules are added by users weekly. Our Joomla implimentation service is very popular.
2. Some other niche requirements are best met using Drupal. Our Drupal consulting service is also fairly popular. 
3. For very small or blog focussed web sites, we impliment WordPress.

Some web sites have requirements that can not be well met using the above CMS platforms. This is because, even though they are built to be flexible and scalable, they still have limitations.

Common reasons why these solutions will not work include:

1. Mulit-site requirement: A brand with a ”parent” head office and then multiple offices which share some, but not all of the data of the parent brand. In order to maintain a “single-point-of-data-entry-and-management,” these sites need to have complex rights and permissions and multiple URLs and look and feel designs running off one centralized database. An example of this is our work for RE/MAX Internationally. See www.remax.com.au as an example.
2. Multi-lingual translation on the fly: A site that has to display in multiple languages and any page on the site needs to be translated from the default language into the other languages per page, component etc. on the fly through the back end. An example of this is our work for Schwarzkopf International. See www.ask-schwarzkopf.com as an example.
3. Multiple “Instances“: This refers to web applications that enable users to sign-up for their own blank version of the web application. The site has to create a unique sub-domain and provide the new sign-up access to their version of the system, ring-fenced from all other users. An example of this is our work for PersonL. See www.personlplace.com for a brief rundown.

The above-mentioned examples we tackle using strong and proven coding frameworks. After some more reasearch and vigorous debate on this topic, we settled on the following MVC frameworks that we use:

• Ruby on Rails –  our usual default recommendation
• CakePHP – when the client would like PHP (because of hosting or other reasons)
• .NET – when our client would like to standardize on Microsoft (not MVC, but we impliment .NET using an MVP philosophy. We eagerly await the stable .NET MVC release).

We have also centralised our Ruby on Rails components into our own PlatformCMS, which meets many of the requirements that Joomla can not.