As of a few days ago there is an association in Italy for people who use the Zope application server and the products that sit on top of it, Plone first of all. The news itself is organisational, but the reason a national coordination is needed is technical, and I would rather set it down.
Context
Zope is an application server written in Python, released in 1998 by Digital Creations (now Zope Corporation). It keeps objects in its own transactional database, the Zope Object Database (ZODB), written by Jim Fulton: rather than mapping Python classes onto relational tables, it persists the objects as they are, with per-transaction commit and rollback. The Content Management Framework (CMF) runs on top of Zope, and Plone runs on top of the CMF; its 2.0 series shipped in March 2004.
It is a coherent and not widely adopted stack. Coherent because a single idea — persistent objects, a hierarchy of containers, templates — runs through every layer. Not widely adopted because that idea resembles almost nothing else on the web of 2005, where LAMP and the frameworks that start from the relational database hold sway. Anyone who picks Zope in Italy is thus left with powerful tools and few peers on the ground to ask for help. That is exactly the gap a users’ association can fill.
The programming model that needs explaining
Three Zope mechanisms together account for its productivity and its steep learning curve, and they are the points where a local community decides whether someone reaches adoption or gives up.
The first is acquisition. An object inside a folder can inherit attributes and methods from its containers by walking up the hierarchy: a SQL query or a template fragment written once near the top is visible to every object below, without redeclaring it. It is the mechanism that centralises shared resources, and also the one that produces baffling behaviour when name resolution climbs a level you did not expect. It does not exist in the other stacks developers come from, and it has to be taught.
The second is Zope Page Templates (ZPT) with the Template Attribute Language (TAL). A ZPT template is valid HTML in which the logic lives in tal: attributes on the existing tags, so the document stays openable and viewable as a static page even before rendering. It is a deliberate design choice — the template remains a file a designer can edit — far from the textual interpolation of string-printing systems.
The third is through-the-web (TTW) development: you build much of the application from the browser interface, writing code and templates that end up in the ZODB alongside the data. Convenient to get started, awkward for version control, because the code lives in the database and not in files you can run cvs or svn over. Here team practices are not obvious and are passed on by direct experience more than by documentation.
Critical point: persistence is not the relational database
The knot that most often sends people astray when they arrive from MySQL or PostgreSQL is that the ZODB is not a relational system and you do not query it with SQL. You navigate the object hierarchy, and write concurrency on a single storage has to be managed by hand.
Zope’s architectural answer is ZEO (Zope Enterprise Objects), from 2001: a client-server model in which a ZEO server process keeps the shared storage — usually a FileStorage — and several Zope clients connect to it through a pluggable storage, with client-side caching. This way you scale the application processes horizontally over a single database, but you shift the complexity onto conflict handling (ConflictError) when two transactions touch the same object. Resolving them well means writing _p_resolveConflict methods on the persistent objects, and that is knowledge which circulates on mailing lists and at conferences, not in the introductory manuals.
I will add one element that weighs heavily in 2005: the split between the development lines. Zope X3 3.0.0, the first production release of the component-based rewrite, shipped on 6 November 2004 and is not compatible with Zope 2 — Zope 2 applications, and therefore Plone, do not run on that line. Anyone planning a project today has to choose knowingly which line to invest in, and to find your way through this transition a community that has already been through it counts for more than any white paper.
What changes for developers here
A national users’ association affects three concrete things. It puts in touch the few firms and few developers who, on the same territory, run into the same problems of acquisition, ZEO conflicts and migration, cutting the time spent reinventing solutions that are already known. It produces and translates documentation: most Zope and Plone material is in English, and a localisation done well lowers the barrier for public administrations and small outfits. And it gives a collective voice towards the international community, which for a European-born stack like Plone counts for a good deal.
The formal side of the association does not interest me here. What interests me is that there should be a place where a name-resolution problem through acquisition, or a conflict-resolution strategy on ZEO, can be discussed among people reachable in the same language and the same time zone. For a niche stack, that is what separates sustainable adoption from technical isolation. Among those who chose to be there from the founding is noze, which builds its own web and content management work on Zope/Python: https://www.noze.it/en/insights/azi-founding/.
Limits
It remains to be seen whether the coordination will keep pace with the Zope 2 / Zope 3 split, which over the coming years will force choices that are anything but trivial. And a users’ association does not replace upstream code contribution: the value of a local community is measured also by how many patches and reports it sends back to the international development lines, not only by how much it consumes. On that, a judgement can be passed a few meetings from now.
Cover image: Logo of Plone, the open source content management system built on Zope — logo by The Plone Foundation, public domain — https://commons.wikimedia.org/wiki/File:Plone-logo.svg