Plone community wisdom: a personal take on the Bristol Plone 2020 open space

...wherein the author provides a personal reflection on an anxiety-causing possible crisis point for the Plone project, which was resolved brilliantly during the Plone 2020 open space


In the lead up to the Bristol Plone Conference, there was much chatter on the attendee mailing list about Andreas Jung's provocatively entitled presentation, "Why Plone is Going to Die".

Another mailing list thread centered around the need to make Plone easier to use for non-developers.

Some email participants were pushing for a complete rewrite of Plone, to address concerns about the complexity of Plone's underpinnings and the rapidly changing nature of web user interfaces going to pure JavaScript.

There was much angst and predictions of doom if we did not make radical changes to Plone-the-software.


Andreas has been part of Plone and Zope for as long as most of us can remember. He has been a huge contributor in many parts of the software we all use and deploy, and he has been ever present in online forums and chat rooms.  Not a person who shies from controversy, he makes it his business to speak forthrightly and say the things that others may think but will not say out loud.

This has gotten him into trouble, but his well deserved reputation as a contributor, organizer, and doer -- not to mention his intentionally provocative presentation title -- led to his much awaited presentation on Day 1 to be standing room only... and it was a big room.

Andreas' slides:

Andreas's talk on video:

Andreas' main points were:

- growing developer pain
 - growing integrator pain
 - rising & unpredictable project costs
 - developer frustration

As he went through his 48 slides, I realized that Andreas had not just raged on with a litany of reflexive complaints (where would I get that idea?), but he had come up with a list of items that, yes, we could work on!  His pain points were a roadmap to improving the quality of the code base that he had run into problems using.

In fact, during the sprints two days later, an entire table of developers tackled some of the migration pain Andreas had described with the next Dexterity based content types.

Other code-centric examples he brought up:

  • z3c.form
  • the Pythonic (or not) nature of Dexterity
  • the proliferation of small plone.* eggs
  • Zope Component Architecture
  • TinyMCE and other JavaScript migration issues
  • Zope 2 and CMF
  • incompatible add-ons
  • plone.api

At least one audience member pointed out that it's maybe not always necessary to upgrade a site, especially since upgrading major releases is, by definition, significant, to which Andreas admitted that he doesn't always automatically upgrade sites (a position that many of us have taken, given that unless the client has a strong need to go to a major new version, there may not be a compelling reason to, especially given Plone's stability and security).

Andreas also presented the results of a survey he circulated prior to the conference, attempting to look at the demographics of Plone developers: age (mostly in their 30s, followed by 40s), gender (95% male), geographical distribution (72% Euro-centric, 12% North American).  He also addressed a question we all have been wondering: is the CMS market shrinking? Is the Plone market shrinking? Are there more legacy Plone projects than new ones?  The numbers don't show a drastic change in Plone's presence.

Someone suggested that interest in CMS development has dropped in recent years, true of perhaps all CMSs except maybe Wordpress.  I see that since 2001 or the heyday of Plone in the mid 2000s there is a lot more interest in mobile applications and other (non-CMS) web sites and services that would draw new, young developers, rather than to the large, established projects for complex CMSs such as Plone and Drupal.  We have all encountered youth who are eager to write their own CMS because Plone seems too complicated to learn... true enough, but after your first quick wins with your DIY CMS and you are asked to implement security and maybe rudimentary workflow, that's when you go "um, ok" and if you have enough self-confidence you allow yourself to wonder if perhaps it would have been ok to spend a little bit of time to learn to use Plone instead of reinventing it...

Andreas then had a wonderful slide (#39) in which he listed all the reason why Plone is still really good:

  • enterprise CMS
  • fine-grained security model
  • outstanding security record
  • flexible workflows
  • ZODB is great (but time to move on...)

and then he gave us his roadmap for making Plone great for tomorrow:

  • get rid of old code
  • do not overengineer code (e.g. portlets and his punching bag, z3c.form)
  • consistent APIs everywhere
  • consistent type checking
  • better / mo' explicit error messages
  • better search engine
  • more scalable database back end
  • coherent/consistent architecture

The key takeaway here is that these are all things we can and DO agree with.

Somewhat more debatable were his prescriptions to:

  • kill Zope 2
  • kill CMF
  • kill ZCA
  • orphan ZODB
  • use Pyramid
  • use Python 3
  • use a new (pluggable?) persistence API or layer
  • evaluate the market for a better database back end
  • don't call the new Plone "Plone"

but, unbeknownst to all of us, those were to be addressed in the Plone 2020 open space two days later...


As Days 1 and 2 of the conference unfolded, the open spaces (Day 3) signup charts filled up quickly, with the morning booked for both the Plone 2020 and the "Growing Plone" topics.

(Sally Kleinfeldt's notes from that combined open space are here: )

It was standing room only, and Martin Aspeli was kind enough (perhaps he was volunteered?) to moderate.  He started off by asking us to write down on post-it notes what it is that each of us loves about Plone.  We passed our notes up to the front of the room, where the notes were clustered by a handful of helpers.

After a few minutes, Martin reported that the #1 "most valuable thing" about Plone was Community, followed by Features, Security, Technology, and Making a Living.  He asked us to keep those important things in mind for the rest of the morning, and whatever we proposed or decided to do should protect and not threaten those most valuable aspects of Plone.

This was a brilliant opening, because it focused our thinking on constructive ways to improve Plone.

Martin then asked us "What are the top one or two items that need to be improved?" and had us pass our post-it notes up to the front again. After a few minutes' wait, the results came back:

  • APIs, hide complexity
  • Integrator usability (TTW, deployments, training)
  • End user usability
  • Code improvements (simplifying code base)
  • Strategy (roadmap, communications, marketing, funding, growth)

The discussion then centred around three issues: improving the front end of Plone, reimplementing the back end of Plone, and reducing the learning hurdles for new Plone developers.

On the front end, it seemed that the proposal that got the most traction was to go with a pure JavaScript user interface, that would render entirely within the browser, and would give us the flexibility to reimagine how to create a beautiful and modern user experience. This would require that the Plone back end serve, essentially, just JSON data.

On the back end, there was much discussion about throwing out Zope 2 and CMF and replacing it with something like Pyramid or Subtance D. Attendees went back and forth on the pros and cons, given the stability of the existing stack, and trying to gauge how much work it would take to rebuild functionality we take for granted using one of these newer frameworks.

On the topic of new Plone developers, keeping in mind that all complex enterprise software requires a significant amount of learning on the part of new developers, we agreed that plone.api was good and that by continuing to add to it and improve it we would ensure that new developers had one canonical way of interacting with Plone.  Adding a JSON layer on top of plone.api would make it possible for Plone to serve JSON data to a pure JavaScript front end. (Whenever someone says "JavaScript" I keep expecting Rok to appear).


Having a feature-complete plone.api in the middle of our stack solves three problems (maybe more) in one fell swoop:

  • those pushing for a rewrite of the back end could do so without affecting add-on developers, integrators, and front end developers

  • those pushing for a rewrite of the front end could do so without affecting add-on developers, integrators, or back end developers

  • new developers (as well as, ahem, existing ones) would have a much easier time working with the Plone code base

But that wasn't the truly mindblowing thing... it was that we had gathered in Bristol, in that particular open space, worried about potentially radical things that were being proposed or that might be proposed to address strategic issues facing Plone, but at that critical juncture we instead found that this broad representation of the Plone community had come together and found a solution, a way forward, that all present in that room agreed with, that didn't rule out potentially big changes in the code base and in the user experience.  By proceeding first with a major push to flesh out plone.api, we would make it possible for the ambitious among us (some might say "crazy") to revamp the back end, or the front end, or both, while keeping all other developers, integrators, and end users along for the ride.  For the proverbial truck barreling down the highway, it would be possible to swap out the tires, wheels, engine, and cabin without slowing it down.


Although I mentioned a few people by name (Andreas, Martin, Sally, Rok), there is one person in particular who has worked very hard at raising awareness of these strategic issues and at leading discussions about them: Philip "That's Konferenz with a K" Bauer.  For that, among the many other things he has done for Plone, we salute him!

Everyone who was in these discussions (whether at Brasilia, Sorrento, Oshkosh, Cologne, Munich, or in the room in Bristol) deserves all our thanks for your committed, constructive participation.  Plone would not be here if it weren't for you.


I would be remiss if I didn't mention Eric Bréhault's rebuttal and Bristol lighting talk in which he explained why the issues we have been seeing within the Plone community are, in fact, common to all CMSs:

Eric's blog post:

Eric's lightning talk (starts 15 minutes in):


Kim - thanks for writing this excellent resume so those of us who were not there can share in the optimism.

1 Like

great introduction for the Plone Strategic Summit!