Erico Andrei: Unlocking the Power of plone.distribution

I have created https://github.com/plone/plone.distribution which will end up in Plone 6.1.

With this you can create your own Plone CMS, or:how integrators use 20 years of collective work as the secret weapon to control a market / segment.

I talked about Plone distributions before. Maurits blogged about my talk. I talked about a distribution of Plone specifically meant for Brasil. And after a while I saw that some organisations were actually using it.

The idea is not new. You have Drupal distributions, Joomla templates, Typo3 distributions. For example CiviCRM is a distribution of Plone.

Plone was never very friendly for distributions. Newer Plone versions would come out that made it hard to upgrade the distribution.

The logic to create a new Plone site is currently distributed:

• browser view in CMFPlone
• content in plone.volto, plone.app.contenttypes
• translations in plone.app.locales

So there is no clear contract. How do you create a new site from Python code? No idea, I would copy some codes There is no RESTAPI service. Without such a service, how would you provide a SAAS for Plone?

Still, there are many examples of "distributions" in our family, for example: Quaive, SENAITE, Bika, Portal Modelo, Vindula, Volto, CastleCMS, io-Comune, Classic UI. Reality check: maybe we are not really selling Plone CMS. Plone CMS should not be targeted at the end user, but at integrators.

We need to define what a Plone Distribution is. It is a contract to create a new instance of a Plone Site. It follows conventions about how to create initial content. It provides a Python API and a RESTAPI. Use cases: starting point for a ne CMS project (website, intranet, headless backend, ...), basis for SAAS offering.

plone.distribution is the package that is the basis for this, the factory. Distributions should be first-class citizens in the Plone world. Convert the initial content from plone.volto and plone.app.contenttypes. Cleanup the codebase. It will sit above Products.CMFPlone, so we can use plone.api in the code to make things easier.

You can use it now as an add-on in Plone 6.0.  In 6.1 it will be a core package.

We are not yet another framework, Plone is a CMS. It is good to concentrate, be specific. But I can say: "Plone is a platform, not a CMS." We have solid foundations: permissions, workflow, basis for content types.

Marketing for Plone: focus on a market and segment, not on the common denominator. For some Plone companies Drupal is a competitor, for others Typo3. Plone marketing should target integrators.

By default you will see two distributions when you start the Plone instance: default (Volto) and ClassicUI. You can add your own, and optionally hide the default ones.

Example distributions:

• collective.ploneintranet
• We have portalbrasil.edu/leg/gov/jus as base for public websites in Brazil.
• kitconcept.voltolighttheme. Allows developers to showcase new blocks.
• A to-be-named distribution for personal site / blog. It is scratching my own itch, for ericof.com, and as additional target Maurits, who is blogging right now.

A distribution is not a "policy package". You do not need to have a GenericSetup profile. You can have complex forms, like with collective.plone.intranet.

Next steps.  How to create a front-page in 45 languages? We should think about that. Should we add features in a distribution package? We need to improve content export/import. It works, but I have questions.

We ship this with 6.1. With 6.2 I want to ship with 6 or 7 distributions. It is a seed we plant for integrators to think about.