Since 1 June 2007 three European e-government projects built on Plone — CommunesPlone (Belgium and France), UdalPlone (Basque Country) and PloneGov.ch (Switzerland) — have converged under the name PloneGov, and over these weeks the model is reaching Italy: the first public body to join is the Ferrara Chamber of Commerce. What is of interest here is the rule the content management system brings with it: an application that solves a shared need is written once and reused, instead of being re-purchased body by body.

Context

It all starts in 2005 in Sambreville, a municipality in Wallonia, where Joel Lambillotte, then the IT manager, needed to set up an intranet for documents and procedures and chose to build it on Plone rather than buy it. From there the group organised itself as a free-software community among local authorities: each municipality puts in development, the others reuse it. The estimates circulating in the community speak of an investment on the order of a few hundred thousand euro a year since 2005, largely the time of developers employed by the administrations themselves. The OSOR document reports that the per-portal cost dropped from roughly 10,000 to roughly 1,000 euro once the base application is written and only needs customising — an order of magnitude below the figures typical of a proprietary intranet. These are indicative numbers, stated by the project’s own members rather than by independent accounting.

International co-ordination is in the hands of ZEA Partners, a non-profit network of small and medium enterprises working on Plone. ZEA handles cross-border operations, shared documentation and communication; development stays with the bodies and their suppliers. In Italy the technical supplier for the launch is noze, and the initial group of adopters includes — beyond the Ferrara Chamber of Commerce — the University and Province of Ferrara, the municipalities of Modena and Arezzo, the Unione Reno Galliera and ARPA Veneto. noze’s notes on the Italian launch event, hosted by the Ferrara Chamber of Commerce, are collected in a dedicated insight: https://www.noze.it/en/insights/plonegov-launch-europe-italy/.

Architecture

Plone is a CMS written in Python that runs on the Zope application server. Version 3, released on 21 August 2007, brought integrated version control over content, inline editing, the Kupu 1.4 visual editor and a finer permission model over users and groups. For the PloneGov case, two things from that release matter most.

The first is GenericSetup: a mechanism for describing a site’s configuration — content types, workflows, roles, permission profiles — in version-controllable XML files, kept separate from the content database. A body that has modelled an administrative procedure can hand its profile over inside an installable package, and another body applies it to its own site without rebuilding it by hand.

The second is the shift to packaging via Python eggs and zc.buildout. Here an add-on is a Python library with its dependencies declared; a buildout.cfg file lists the eggs to download and the sources to develop locally. So a PloneGov extension — a content type for council resolutions, a workflow for incoming-mail registration — becomes a reproducible artefact, installed on another instance from the same build recipe. On this technical basis reuse stops being a good intention and becomes a practice: without a package format and a declarative configuration, sharing would come down to copying code by hand between installations that, at that point, drift apart.

The module sources sit on svn.communesplone.org under the GNU GPL, with the logic of any FLOSS (Free/Libre and Open Source Software) community: a public repository, commits from the various bodies, applications a municipality writes for itself that the others can install.

The critical point

The model holds as long as configuration stays expressible as versionable data and packages stay composable across instances. It is a fragile balance. Plone allows deep code-level customisation — overriding templates, views, adapters — and any customisation made outside the GenericSetup profile is a slice of state that does not travel with the package and has to be reconciled by hand when the shared add-on is updated. The real risk, in a network of bodies with differing local needs, is the silent fork: each one starts from the same base, accumulates unpackaged changes on top, and after a few cycles the installations diverge to the point where the “common” thing to reuse no longer exists.

The discipline PloneGov demands is therefore organisational before it is technical: keep the shared base generic, isolate local specifics in separate packages, push fixes back upstream rather than keeping them in-house. The project’s public notes describe exactly this — spotting problems together, documenting solutions, never writing the same software twice — but it is a practice that depends on whoever applies it, not a guarantee from the tool.

Implications

For an Italian body the sum can be checked, not taken on trust. The question is not whether Plone is the best CMS in absolute terms, but whether a given procedure — a public notice board, document management, a registration intranet — has already been modelled by another body in the network and is available as an installable package. When the answer is yes, the cost moves from buying a closed solution to customising an existing one, with inspectable sources and no lock-in to a single supplier.

There is also a less obvious consequence for the supplier market. Under proprietary licensing the supplier resells the same product to several bodies; with code held in common it sells development time on something that belongs to everyone. ZEA Partners tries to keep a market of small firms standing on this premise. For Italian suppliers joining now, the value lies not in owning the code but in being able to model it and keep it aligned with the shared base.

Limits

Plone 3 carries an operational entry cost you cannot ignore: the Zope/Python stack asks for specific skills to deploy and maintain, and a body adopting the model must be able to rely on staff or suppliers who handle buildout, eggs and GenericSetup. The savings reported by CommunesPlone members hold for those who stay inside the reuse discipline; anyone treating the installation as a closed product to customise at will loses most of it and ends up with a complex system without the network that justifies it.

The Italian field test remains to be made: the European network has a few years of practice behind it, the Italian one starts now. How many packages are genuinely shared and reinstalled between bodies, and how many remain local forks, can only be read a few development cycles from now.

Cover image: Group photo of dozens of members of the Plone open source community gathered at the Plone Conference 2009 in Budapest — photo by Christian Scholz, CC BY 2.0 — https://commons.wikimedia.org/wiki/File:Plone_Conference_2009_Group_Photo_-_Flickr_-_MrTopf.jpg