Almost every corporate site keeps its text inside the HTML, which is why a visual redesign costs as much as rebuilding the site. A content management system exists to break that coupling: content on one side, its visual rendering on the other, and publishing that goes through explicit rules rather than a hand-driven FTP transfer. As of January 2003 the Open Source answer to this problem has stopped being experimental.

Context and problem

Under the “content management system” label fall very different things: the engine behind a news site such as Slashcode, the document-editing tool of a large organisation. The underlying problem, though, does not change. A piece of content has an author, a date, a language, a state (draft, in review, published), and one or more renderings: web page, feed, print. Putting all of that inside .html files means duplicating structure on every page and giving up any way to query the archive by metadata.

The classic proprietary-market answer is a closed product that welds content, database and templates into a single block, often with per-CPU licences and a cost that grows with the number of editors. The Open Source answer I am concerned with here starts from a different place altogether: a general-purpose application server with its own object database, and on top of it a framework dedicated to content management.

Architecture

The most mature case, today, is Zope (Z Object Publishing Environment), an application server written in Python. Its structural feature is object persistence: ZODB (Zope Object Database), the built-in database, saves Python instances as objects in a hierarchical tree, with no mapping step towards relational tables. A document, a folder, an image are objects reached by URL by descending the containment hierarchy — Zope’s publishing model translates a URL path directly into a traversal of the object tree.

On top of Zope runs the Content Management Framework (CMF), a set of tools that brings in the concepts typical of editorial management. The main components are:

  • portal_types: the registry of content types. A type (Document, News Item, Link, Image) is a Python class of a few hundred lines, to be extended or replaced;
  • portal_skins: the presentation layer. Templates (DTML and Zope Page Templates) live in layered folders, and a request resolves a template by traversing the layers from the most specific to the most general. Changing the look of the site means changing a layer, not touching the content;
  • portal_workflow: the state machine that describes the lifecycle. The private state moves to pending through the submit transition, and to published through publish, where the permission on the approval transition belongs to the Reviewer role;
  • portal_catalog: the index. Each content object is catalogued by its metadata and its text, and becomes queryable without the administrator configuring indices by hand.

What counts, on the architectural side, is the separation between these four tools: the type says what a piece of content is, the skin how it looks, the workflow who may change its state, the catalog how to find it again.

The critical point

Metadata is not an administrative detail: without it, an archive cannot be queried and cannot talk to other systems. To each piece of content CMF attaches a set of properties — title, description, author, creation and modification dates, subject — that tracks the fifteen elements of Dublin Core, the resource-description scheme standardised in RFC 2413. It is the same vocabulary that WebDAV (RFC 2518) uses to expose a resource’s properties as XML elements in a namespace.

In practice, content described with standard metadata is not held prisoner by the CMS that produced it. It can be indexed, exported, reused on another channel. A proprietary system that invents its own metadata scheme reaches the same functional result inside the product, but shuts the door to the outside. Here Open Source, beyond the licence on the code, brings a value rarely cited: adherence to public formats and protocols, because whoever writes free software has no interest in building format lock-in.

Implications

As of today the Open Source offering for content management is already broad. Alongside Zope/CMF there is OpenCms, a Java engine in development as a free project since 2000; Midgard, which runs on the LAMP stack — Linux, Apache, MySQL and PHP — with its own object model; and a long list of more vertical engines for portals and news sites. On the CMF branch a presentation layer, Plone, is in development, supplying ready-made skins and an editorial interface on top of the framework.

For anyone weighing up an enterprise solution, the question is not “Open Source or proprietary” in the abstract. It is more concrete: does the system genuinely separate content, presentation and workflow? Does it expose content with standard metadata? Does it let you extend a content type without rewriting the engine? On these three criteria a framework such as CMF holds its own against closed products, and on top of that keeps every line readable and editable — CMF’s content types are Python files of a few hundred lines, not black boxes.

Limits

Some honest constraints remain to be put on the table. Zope’s learning curve is steep: the object model, acquisition, and the security system ask you to think in different terms from the PHP-plus-relational-database pairing many are used to. ZODB persistence is efficient for reads, but it wants care over concurrent write transactions and over the growth of the Data.fs file, which has to be packed from time to time. The CMF layer is still evolving, and the base editorial interface, without a layer such as Plone, is spartan. None of this takes anything away from the architecture; it only serves as a reminder that “mature Open Source” means mature as a project, not free of adoption cost.

Anyone who wants to check for themselves finds the code and documentation in the open, and can stand up a CMF instance on a test machine in an afternoon. That is the best way to tell whether the separation of content from presentation holds for your own use case, rather than trusting a slide.

These same themes are at the centre of the IDC Content Management Seminar, where noze is among the exhibitors; the report is in the insight published by noze: https://www.noze.it/en/insights/idc-content-management/.

https://www.zope.org/ https://www.zope.org/Products/CMF/ https://www.opencms.org/ https://www.midgard-project.org/ https://www.ietf.org/rfc/rfc2413.txt https://www.ietf.org/rfc/rfc2518.txt https://dublincore.org/

Cover image: Enterprise Content Management concept diagram showing the capture, manage, store, deliver and preserve stages of content, with labels… — diagram by ModriDirkac, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:AIIM_ECM_SLO_Scheme.png