An industrial research project on a content management system often prototypes on one stack and ships the definitive platform on another. The two phases can diverge a great deal, and when they do it is worth pinning down what actually crosses the boundary. Hardly ever is it the prototype’s code; it is the decisions that drove it — which content types the domain needs, how the stages of a workflow are separated, where the line runs between what is reusable and what is specific to the client.

Context

In Italy the MIUR (Ministry of Education, Universities and Research) programmes for industrial research — the Integrated Aid Packages, among the instruments supporting innovation — finance consortia between firms and universities over multi-year horizons. The final accounting asks for a deliverable that is installable and measurable: for a CMS project, usually a deployable platform and its documentation. The choice of stack is not a compliance step; it is a technical decision with technical consequences, and over the thirty months of a project it can change mid-course.

The Open Source prototype

On the CMS side, in these years, anyone working in Python has as reference Zope with the Content Management Framework (CMF), and Plone on top of it. Zope ships under the Zope Public License; CMF and Plone are Open Source and publicly available (Plone 1.0 is from February 2003, Plone 2.0 from March 2004, plone.org). It is ground on which prototyping runs fast, because the experience gained on a CMS already in production — asynchronous workflows, extensible content types, exports to interoperable formats — translates quickly into a working system.

It is worth pinning down what the stack offers. Zope rests on ZODB (Zope Object Database), the transactional object database in which every piece of content is a persistent Python object. acquisition — the mechanism by which an object inherits behaviours and variables from its container, walking up the tree — is the trait that most characterises the model. CMF adds the services that turn a site into a portal: portal_types for content types, portal_workflow for states and transitions, portal_catalog for indexing and search, portal_skins to keep logic separate from presentation (zope.org, CMF documentation). Non-trivial types are defined in code with Archetypes, the active-schema framework that generates forms, validation, and persistence from the schema (1.3.0 RC2 is from September 2004). The choice of this base is not a given: it is the result of a comparative analysis among the Open Source CMSs of the time, from eZ publish to Typo3 to Midgard.

Critical point

A working prototype does not guarantee the definitive platform. The transition depends on factors that have little to do with the prototype’s code. For its part, the Zope/CMF stack is going through an internal break: Zope 3, released in November 2004 (Wikipedia, Zope), brings interfaces and components as its base model and rewrites much of the framework, keeping from the previous stack little more than ZODB; code tied too tightly to acquisition and to Zope 2 conventions ages fast. But the decisive push is contextual: a platform bound for an industrial client is weighed for the maturity of its application servers, the skills available on the market, and adoption among the partners. By that measure the definitive stack shifts toward Java Enterprise (J2EE), more widespread in enterprise settings than Zope was in Italy in the mid-2000s.

A stack migration is a legitimate, common choice, and it has a consequence worth stating in full: the prototype’s code does not flow into the final platform, still less “upstream” into Plone. What crosses the boundary between the two phases is the decisions — the content types designed for the domain, the separation of an editorial workflow’s stages, the line between reusable and specific.

Implications

The consequence concerns attribution. When the prototype is Open Source but the definitive platform is not, the temptation is to tell the first as if it had merged into the second, or into the ecosystem it came from. It is a simplification that does not survive verification. Mature Open Source platforms — Plone among them — arise from the convergence of many actors over years, and the temporal coincidence between a project and a version founds no paternity. Saying that an industrial project “gave rise to” Plone is almost always a stretch; when the final platform has migrated to another stack, it is entirely so. Zope and CMF are, if anything, the common base from which Plone grew on its own: a fact of the ecosystem, not a bequest of the single project.

What remains to ask is what a project like this actually leaves behind. The verifiable part is the documents: the comparative analysis that motivates the choice of base, the design of the modular split, the specifications of the workflow, security, XML indexing, and taxonomy modules. It is a more modest legacy than a widespread platform, and it is the only one you can show in writing.

Limits

This reading holds for a research consortium with an industrial client and for the Italian MIUR programmes of these years; it does not transfer automatically to other contexts. Where the client and the deliverable are themselves Open Source, the prototype’s code can really survive; where the definitive platform moves to an enterprise stack, what remains lives in the documents and the skills, not in the repositories.

There remains, too, the fact that the choice of stack is not only technical: internal skills, maintenance contracts, and what the partners already know how to run all weigh in. An elegant prototype on a niche technology regularly loses out to a less refined platform the organisation knows how to maintain. It is a real tension, decided case by case.

The path of the CMOS project — prototyping on Zope/CMF and migration to Java Enterprise as the definitive architecture — is recounted both in the insight and in the project page published by noze: https://www.noze.it/en/insights/cmos-conclusion/ and https://www.noze.it/en/projects/cmos/.

Cover image: the CMOS project logo with the marks of the consortium partners, Bassilichi and noze.