2014 ·English ·48 slides ·6518 views

Why Plone Will Die

This document discusses reasons why the author believes Plone may decline or become a "CMS zombie" unless changes are made. Key points include: Growing developer and integrator frustration due to legacy code, complexities, lack of documentation and APIs. Difficult and unpredictable migrations between major Plone versions that introduce issues and costs. Stagnating community and market as Plone relies on aging technologies like Zope and ZODB. The author argues Plone needs to remove legacy code, simplify architectures, introduce explicit APIs, support new databases and Python 3 to thrive in the future. A potential approach is starting from scratch with Pyramid and new components rather than continuing to build on aging foundations.

Source PDF 4.4 MB Slide text

1/48 arrow keys or swipe · click image for fullscreen

Details

Uploaded: 29 October 2014
Updated: 12 November 2022
Language: English
Slides: 48
Image size: 2048x1536
Views: 6518
SlideShare ID: 40873306
Uploaded format: PDF
Collected: 2026-09-27

The description above is SlideShare's automatically generated summary, not the author's own text.

Source & completeness

Content: original + reconstructed
Validation: passed
Slide text: available (46 slides)
Original files: yes

original.pdf PDF · 4.4 MB · 48 slides

Checksums (SHA-256)

original.pdf: 7f8c289761c3043f4479532db2791f75a0dc7c1ce40680deef6773bfcd2470c2

Slide images come from SlideShare's public renderings (2048x1536 px, WebP). Any file marked as reconstructed is assembled from those images and is not the author's original source file.

Full text of every slide

Text extracted by SlideShare from the slide images — may contain OCR errors. 46 of 48 slides have text.

Why Plone Will Die (or turn into a CMS zombie) Andreas Jung Plone Conference 2014, Bristol

Disclaimer • perhaps tendentious • perhaps provoking • perhaps unbalanced • always my personal opinion • not representing any official Plone position

Integrator

Consultant

Plone coredev

Loudmouth Consultant

Why am I giving this talk? • growing developer pain • growing integrator pain • rising and unpredictable project costs • developer frustration at every corner

2014 - the year of Plone legacy

2014 - the year of Plone legacy • Plone 4.2➝4.3 • 3rd party code • TinyMCE issues • schema tabs no longer working • Javascript issues • JQueryUI incompatibility

2014 - the year of Plone legacy • Plone 4.0➝4.2 • 3rd party garbage code • Migration to Plone 4.3 not easily doable • Migration costs not predictable

2014 - the year of Plone legacy • Plone 4.0➝4.2 • own project • Migration to Plone 4.3 not easily doable • Migration costs not predictable • Problems with fully qualified links in images and links

2014 - the year of Plone legacy • Plone 2.X➝4.3 • customer grown project • AT➝Dexterity • p.a.event pain • p.a.widgets pain • z3c.form fun • much more pain…

2014 - the year of Plone legacy • Plone 4.0➝4.1➝4.2➝4.3 • own project • started in 2010 • every migration upgrade had more or less severe issues and caused significant work and costs

I am not talking about UX with Plone

Let me talk of _my_ (backend) developer experience

>>> reasons[„programming“] • Dexterity programming experience

Dexterity wanted to be pythonic IMySchema (attr1, attr2) MyType obj = plone.api.create(„my.type“, container, id) obj.attr1 = „foo“ obj.attr2 = „bar“

…but it ended like this MyType IMySchema (attr1) IBehavior1 (attr2) IBehavior2 (attr3) obj = plone.api.create(„my.type“, container, id) obj.attr1 = „foo“ IBehavior1(obj).attr2 = „bar“ IBehavior2(obj).attr3 = „hello world“ call_some_subscriber(obj) # plone.app.event Q: Is this pythonic?

>>> reasons[„programming“] • Insufficient parameter checks • Insufficient error handling • Stupid error messages

My personal enemy: z3c.form • no compatibility checks between schema fields and widgets, pdb needed • pointless, unhelpful error messages saying all and nothing • vocabulary issues always require to use pdb (NOVALUESET error with lots of fields and vocabularies)

…and then this madness '/Users/ajung/.buildout/eggs/z3c.form-3.1.1-py2.7.egg', '/Users/ajung/.buildout/eggs/plone.z3cform-0.8.0-py2.7.egg', '/Users/ajung/.buildout/eggs/plone.autoform-1.6-py2.7.egg', '/Users/ajung/.buildout/eggs/plone.app.z3cform-0.7.6-py2.7.egg', '/Users/ajung/.buildout/eggs/plone.formwidget.namedfile-1.0.9-py2.7.egg', '/Users/ajung/.buildout/eggs/collective.z3cform.datetimewidget-1.2.6-py2.7.egg', '/Users/ajung/.buildout/eggs/plone.app.form-2.2.4-py2.7.egg', '/Users/ajung/.buildout/eggs/zope.formlib-4.0.6-py2.7.egg', '/Users/ajung/.buildout/eggs/five.formlib-1.0.4-py2.7.egg', '/Users/ajung/.buildout/eggs/z3c.formwidget.query-0.10-py2.7.egg',

>>> reasons[„programming“] • complexity • growing complexity • wrapper modules…

250 modules (4.3 install) Up to 400 modules (custom install) Q: Who understands this? (completely)? http://www.wired.com/wp-content/uploads/images_blogs/wiredscience/2011/08/iceberg-towing-illustration-dassault-systemes.jpg

>>> reasons[„programming“] • Zope Component Architecture - A framework is not an API

Zope Component Architecture ZCA • ZCA is the foundation of the Plone core (not of Zope2 itself) • ZCA has good parts and bad parts • brain***k features like multi-adapters neither lead to better code nor better readability • ZCA is a reasonable implementation framework • ZCA based code can be complex and complicated • ZCA often misused as public API in lack of an API at all • _I_ do not want to see much ZCA stuff on the public API level (except schemas, interfaces)

>>> reasons[„programming“] • Lack of explicit and documented APIs

Documented APIs are essential • APIs define an entry-point to a particular functionality • APIs encapsulate and hide complexity • APIs define a well-defined behavior • APIs can validate and enforce constraints on incoming and outgoing data • plone.api • „Facade“ design pattern • covers only the most elementary functionality of Plone • APIs must be humane (Kenneth Reitz: https://speakerdeck.com/kennethreitz/python-for-humans)

>>> reasons[„programming“] • Migration pain

Migration pain • Plone portal_migration usually works but • often TinyMCE issues • often Javascript issues • incompatible add-ons • (subtle) behavioral changes • Not a single smooth Plone 4.3 migration this year • Migration costs • often no longer predictable • higher risks & higher costs with every Plone major release

>>> reasons[„programming“] • Legacy all around us

The pain of dealing with legacy • e.g.Zope 2, CMF • new rewritten functionality added without removing all old culprit • more radical cuts are needed in order to get rid of old garbage before adding hopefully better code

>>> reasons[„others“] • Stagnation!? • Shrinking community!? • Shrinking adaptation!?

Stagnation Source: Plone Developer Survey 2014

Geographical stagnation? Source: Plone Developer Survey 2014

>>> reasons[„others“] • Shrinking CMS market? • More legacy Plone projects than new Plone projects?

Shrinking CMS market? Source: Plone Developer Survey 2014

#WhatMakesPloneAnOptionFor_ME_Today • Enterprise CMS • fine-grained security model • outstanding security record over the last 12 years • flexible workflows • ZODB was great but time to move on…

#WhatMakesPloneAnOptionFor_ME_Tomorrow • As a developer • getting rid of old code cruft • getting rid of over-designed and over-engineered code cruft (e.g. portlets, z3c.form) • explicit and consistent APIs everywhere • explicit type checking • much more explicit error messages

#WhatMakesPloneAnOptionFor_ME_Tomorrow • As a consultant/integrator for „enterprise“ projects: • better search-engine (e.g. ElasticSearch) • better scalable database backend • Python 3.x • a coherent and consistent architecture

How can this be achieved? • Define what Plone currently is • Define what Plone should be in the future • Define the scope of Plone • Know your market segment • Be realistic about the goals that can be achieved with the given resources

How can this be achieved? • Zope 2 development is dead • ➝ Forget Zope 2 • CMF development is more than dead • ➝ Forget CMF • ZCA…well… • Take the good parts and forget the rest • ZODB • It was nice with you but we need and we do have better options…no more pickle graves please.

How can this be achieved? • Throw everything away and start from scratch • Pyramid • Python 3 • a new persistence API • a new pluggable persistence layer • evaluate the database market for the best database option with respect to scalability, ease-of-use etc. • see how existing functionality like Dexterity fits into a new architecture The time of the monster application servers is over! Take the best components on the market and build it yourself.

And there’s one more thing… • Don’t call it Plone! • Develop it under the umbrella of the brand Plone • But give it a different name (similar case with Typo 3 and its reincarnation NEOS)

Plone Developer Survey (103 answers) • 103 answers • most interesting: a lot of interesting comments about the pros and cons of Plone • http://goo.gl/pBK3DM

Questions? Source: Monty Python