CMS Product comparison

Sample Only – Full Version available to

subscribers at http://www.e-
consultancy.com/publications/open-source-
cms-evaluations/

Author: Matthew Evans, Ben Rometsch

Friday, 01 August 2003
Version 1.4
Version History

Author(s) Version Date Change Details

Matthew 1.0 28/07/2003 Initial framework
Evans
Ben Rometsch 1.1 30/07/2003 Technology Additions
Matthew 1.2 31/07/2003 Requirements analysis per CMS
Evans
Ben Rometsch 1.3 01/08/2003 Technical Updates
Matthew 1.4 01/08/2003 Updates to requirements, exec summary
Evans and excel summary
Table of Contents
1. Executive Summary.....................................................................................4
2. Introduction..................................................................................................5
3. Content Delivery Approaches – Baking or Frying.........................................5
3.1. Baking....................................................................................................5
3.2. Frying....................................................................................................5
3.3. Choices...................................................................................................5
4. Products.......................................................................................................6
1. Executive Summary
There are two content management systems that are being considered for
use, Infoglue and OpenCMS.
Infoglue – the good.
Infoglue has been recently designed to take advantage of all the latest
features and technologies available in the Java language. It implements an
MVC pattern and a three tier architecture, separating the content from
structure from management. It uses best practice coding and has an
interface that is easy to understand even for non-technical users.
Infoglue – the bad.
The project has only been running as an open source project since Feb 2003.
Activity on the project is high for the author, but the public have yet to catch
on and start implementing modules. Some of the features in the user
interface are stubs for functionality that is waiting to be written. Worst of all,
there is an almost complete lack of documentation making any development
reliant on communicating with the original author.
OpenCMS – the good
Based on open standards and a good technology platform, the software will
be stable and scalable. The project is mature and has a high activity level
from both original authors and public users. There are a host of features
included in the CMS and it has a modular design to allow other developers to
add new functionality. There are many companies worldwide that have
implemented more than 50 reference sites, so future resource would not be
an issue. There is plenty of documentation and support from the project
website.
OpenCMS – the bad
OpenCMS is now version 5 and may be suffering from feature overload. The
interface is clunky and not designed for the average business user. The
templates engine uses a number of technologies and can be confusing,
especially for rendering dynamic content.
The recommendation
OpenCMS has been used to make over 50 reference sites and probably a
number of others that we don’t know about. It has a high level of
documentation and support. As these are the pressing issues at this time, it
makes more sense to use the more mature and highly supported product.
2. Introduction
Client specific content removed

3. Content Delivery Approaches – Baking or Frying

Before continuing, it is important to introduce a central concept that
differentiates practically every content management system available now or
in the future. Although a lot of focus is given to the way content is added and
managed within a CMS, one of the most important aspects to consider is how
the content is actually deployed and presented to the user. There are two
schools of thought in this respect that are at opposite ends of the spectrum.
They are often referred to as the “baking or frying” question.

3.1. Baking
CMS’s that employ the “Baking” philosophy do most of their work before the
user enters into the equation. When the site is published by a CMS user, the
CMS engine crawls through the website (much in the same way as a search
engine robot crawls through a site) and makes a static copy of the site. That
is, a snapshot of the site is taken at that particular moment in time by the
CMS engine. This static site is generally stored as a collection of HTML pages,
images and documents and uploaded to the live web server or servers once
the CMS has finished crawling the site.

3.2. Frying
CMS’s that rely on the “frying” method employ a completely different method
of content delivery. The CMS and its related data are deployed along with the
live site. When a user requests a page, the CMS engine (which is present on
the live site) intercepts the request from the user. The engine knows which
pieces of content are current for that requested page. It prepares the page
and sends it to the user.
In this instance, when the CMS user hits publish, very little happens. The CMS
will store the information describing which versions of content are currently
“live” and nothing more. Any subsequent page requests from users will be
served using this live version.

3.3. Choices
Naturally with such radical differences in philosophy, the choice of whether to
“bake” or “fry” the website is a critical one. Most CMS’s employ either one
approach or the other; rarely both together. The three fundamental issues to
take into account are those of performance, timeliness and flexibility. The
“Baked” delivery approach stresses the web server as the site is being
deployed but normal website requests from users can be serviced very
efficiently; the processing will already have been performed and so the
system does not need to do it again. “Frying” systems on the other hand do
not stress the server when the CMS user decides to publish the site, but the
system encounters a small overhead whenever a normal page is requested
from the user. Caching (remembering) pages after they have been processed
once can dramatically improve the performance.
In terms of timeliness, baked systems will always lose out. If a single word is
spelt incorrectly within the website, the system must process (bake) the
entire website and deploy it to the live web servers. A frying system, on the
other hand, can apply the change immediately.
On the whole, frying systems are more flexible. Since each page request is
processed by the web server it is often a lot easier to apply dynamic features
such as personalization or form processing. Baked systems, by their nature,
tend to be less flexible.
The general tenet adopted within the industry is to use a baking system only
when the volume of requests to the site makes it financially unfeasible to
deploy a “frying” system. If the number of page requests for a site is not very
high (anything below around 500,000 page requests a day) the increased
flexibility and timeliness of a frying system makes it the better choice.

4. Products
After searching the open-source content management landscape for systems
that appear to fit the requirements, the candidates have been reduced to the
following four systems.
• Apache Lenya - http://cocoon.apache.org/lenya/
• RedHat CMS - http://www.redhat.com/software/rhea/cms/
• OpenCMS - http://www.opencms.org/
• InfoGlue - http://www.infoglue.org/

Sample Only – Full Version available to

subscribers at http://www.e-
consultancy.com/publications/open-source-
cms-evaluations/