Toward a 2017 Plone Roadmap

This is a living document outlining a continually evolving roadmap for the future of Plone.

This is a DRAFT: incomplete or much more verbose than needed.
Help to improve!
Please join the discussion in our forum

The Plone roadmap is created through community discussion, not set in stone. A broad discussion on the roadmap will continue to occur at a number of places, starting with Plone Open Garden (PLOG) in Sorrento, Italy, April 18-22, 2017.

The original Plone 2020 discussion started in 2013 at the Brasilia Plone conference.

By late 2016, with Plone 5 already a year old, and considering the latest elements highlighted during the Boston conference, it was time to record the current state of discussion in an actual roadmap.

As of the beginning of 2017, we think Plone has multiple possible roads leading to different markets.

  • the existing Plone platform
  • products based on the Plone platform (“distributions”)
  • the headless CMS (Plone + REST API)
  • plone.server

The existing Plone platform

Shining

The existing Plone platform is very secure, flexible and extensible. It offers a good user experience and focuses on accessibility.

It allows you to build a wide range of sites for very different audiences, from very simple sites managed by a small team or a single person with no technical background, to large sites supporting complex business processes and involving a lot of custom features.

Plone offers specific features (security, complex workflows, sophisticated permissions, high pluggability) which make it a better solution compared to its competitors in many cases.

Challenges

This platform targets the regular CMS market, where we can also find other well-known actors like WordPress or Drupal.

Plone is not as successful as these, for many reasons, including:

  • At the time CMSs started to appear, Python was not mainstream as it is today, and PHP-based CMSs continue to benefit from that.
  • A majority of Python developers consider the Plone stack to be very complex, so the Python community does not participate much in promoting Plone.
  • Deploying Plone is not as easy as deploying competing products, which are offered as ‘one-click’ solutions.
  • Customization via add-ons is similarly a ‘one-click’ solution on competing CMSes, whereas in Plone it requires file-system access through the shell, at a minimum

There is nothing to indicate that CMS market shares will change dramatically, but the CMS market is huge and is likely to stay this way for the foreseeable future. Even very small shifts in the market can have big effects.

Tasks

The Plone platform is relevant and the current efforts to improve its codebase or its features must be continued. Very important efforts under way include:

  1. Removing unused components, clean up the code base, moving to Python 3, and making Plone WSGI compliant. With the recent spike in development on Plone’s backend, there is a good chance that Plone will be on Python 3 by 2018.
  2. Adding Mosaic to Plone core and continuing to improve the through-the-web experience. With the recent focus on Mosaic and its ecosystem there is a good chance to get it into the core ecosystem in 2017.

Deployment: With the rise of virtual servers, containers and cloud hosting, this becomes less of an issue. These offer a simpler way to test, develop, and deploy Plone. This will only work if we devote more resources into documenting, testing, maintaining and marketing these solutions, which include Docker, Ansible, Snaps, and single-click deployments on cloud platforms.

One vital area in which we need to invest is packaging and deployment. In the past, we suffered a lot from the fact that standard web-hosting offers come with PHP pre-installed, whereas Plone needs a more involved setup.

In short: deploying and installing (including documentation, and promotion of those solutions) should be treated as a strategic marketing effort.

Plone, the platform

Some recent initiatives in the Plone community have aimed to build specialized distributions of Plone, such as Quaive, OneGov GEVER or CastleCMS.

While based on the Plone platform, these distributions may give up some of Plone’s versatility and generality in order to focus on a specific target market or specialized application.

Plone distributions aim to compete with open-source or non-open-source solutions like Microsoft Sharepoint, Jive, or OpenText and other large scale CMSs.

These distributions are also important innovation drivers for UI and features. Their code is open source and some features will be PLIP'd for inclusion into Plone.

Other distributions include:

Roadmap

Python 3

Plone still runs using Python 2.7. Because this version will be supported only until 2020 all code need to be ported to run on Python 3.

This includes all dependencies, like Zope2 or the ZODB. With the codename Zope4 this ongoing process is started, Plone needs to follow up, be part of this community and build on this work.

Codebase and code-quality

Test coverage, quality of code and tests and style guidelines are already defined. In order to lower the barrier for new Plonistas to understand the code-base, reformatting and review of our old code are needed. This is already enforced on some packages by automatic checking via continuous integration (CI). The ongoing efforts need to be completed

In order to do not break existing code, we collected a bunch of packages over time, resulting in moe than one way to do things.

We need to get rid of the old code. This includes dead/ orphaned code, not needed in Plone but is left over from Zope2 or CMF. It also included code that is still used, but where we now have a new, often more flexible or faster way to do the same. Examples are DTML, the skins folder or Archetypes.

At some point, people thought it's a good idea to divide a feature into several packages, like a base package and a Plone-specific one. While in some cases this enables reusability for the good, this resulted in a nightmarish number of packages, at least from a release managers point of view. It also increased the probability of cyclic dependencies in Python or at the configuration levels. Where possible we should merge packages.

Headless CMS

Nowadays, some people do not want to use a CMS anymore; they consider it unnecessarily complex, old-fashioned, underperforming, and difficult to integrate with modern web development based on front end technologies.

Instead of using an existing CMS, they prefer to use a REST API compliant storage backend and build their website or application using their favorite front end tools and frameworks.

Unfortunately (for these people), CMS features are, most of the time, absolutely necessary to run a website. These include creating content, performing searches, and managing a validation workflow. But even smaller elements like breadcrumbs, navigation, sitemap or a contact form are very important and are actually very difficult to develop from scratch.

This audience might adopt a backend which exposes all its features through a REST API. This is basically a CMS without a UI: a headless CMS.

This is a new market and it has already been identified by companies like Contentful and other vendors. Most of the major players in the CMS market are actively pursuing this same strategy, e.g. Drupal, WordPress, Typo3, Django REST framework.

In this market, we think Plone has a good chance to stand out.

Plone has a superior set of features and, unlike other CMSs which also try to implement a REST API, Plone comes with a very clean and robust concept of content management, based on our deep experience and our high standards of quality.

Most REST API solutions tend to focus on providing CRUD (create, read, update, delete) operations, which are obviously important but not sufficient (as already mentioned: sites need breadcrumbs, navigation, actions, commenting etc.). And as most REST API solutions are based on SQL, they also tend to produce table-oriented APIs, which make little sense when managing a website tree.

The good news is that Plone already provides such CMS-as-a-service features, thanks to plone.restapi. The quality of the API is outstanding and, while it is not yet feature-complete, it is already widely used in production.

The Angular 2 Plone client, started at the Barcelona Sprint 2016, could become a reference implementation for a valid UI working with this API. Additionally, we could have many more reference implementations based on different JavaScript frameworks. The ability to have multiple front end clients using the same common storage backend is precisely the point of a headless CMS.

In many projects you might not need the full set of features provided by Plone; instead, you may wish to create simpler or just different UIs for your application.

Some might prefer another technology, such as React, mobile native solutions, or something which does not exist today; the advantage of having such an API-compliant headless CMSis it is future-friendly.

The headless CMS is a great opportunity for Plone, because it opens new markets: any application or frontend developer who needs something more powerful than just a simple storage backend. When compared to the “microservice approach”*, any nicely integrated built-in features would be compelling (would you want to implement a breadcrumb microservice?). This should also be the underlying message of our marketing efforts in this sector. (“A secure permissions and workflow model is hard to implement. Like, real hard. And roll-your-own security is not something you should do. Rely instead on a proven, mature, and time-tested solution that already provides this.”)

“Microservice approach”: you have available different services to produce any given page of your website (such as a commenting service, an authentication service, and a content storage service). Those services are often not very integrated together and they do not cover all the needs of your page (e.g., do you have a breadcrumb service?). A headless CMS would be a unique service providing a comprehensive set of services.

Moreover, in this context, the technical stack and complexity of Plone will not be a barrier: as long as application and front end developers are satisfied with what the API offers, they do not care if it is implemented on top of Express/CouchDB or Python/ZODB. Some of the APIs we use today might event be implemented in COBOL, yet we have no idea, and it doesn’t affect their usefulness.

plone.server

Also started during the Barcelona Sprint 2016, plone.server is a high performance, asynchronous I/O backend for multinode deployments. Compared to our current stack, plone.server provides much more scalability, asynchronous features (like long polling, websockets), and a very modern technical stack. It is far from being feature-equivalent to CMFPlone but offers a lightning-fast alternative backend for projects that do not need the complete set of Plone features.

plone.server proposes a deep evolution of the Plone architecture:

  • It only exposes a REST API, and does not provide any server-side rendering. This REST API will be compliant with the Plone REST API developed on Plone 5, so any client built on top of Plone 5 REST API will work with plone.server.
  • It keeps the most modern and relevant packages of Plone (like Dexterity and ZTK) but removes all the old ones (like Zope2). It is based on Asyncio, ZODB, and Python 3.5+.
  • It delegates all its subtasks to best-of-breed components (like ElasticSearch for indexing instead of ZCatalog).

Summary

The main point about these paths for Plone is that they are by no means separate and exclusive, but instead complement each other, drive innovation in each other, and offer exciting options for Plone's future.

Please join the discussion about the Plone roadmap in our forum at https://community.plone.org/c/development/roadmap