Plone roadmap

More info about PLOG 2012: http://www.abstract.it/abstract-en/initiative/plone-open-garden-2012/

See the Plone roadmap document on Google docs.

This is a draft document about the future state of Plone. There is not currently a single consensus about what direction Plone is heading in. This document contains for short and long term what the current thinking is about where Plone is headed.

We have the framework team who decides what really goes into a new version of Plone, via PLone Improvement Proposals (PLIP). This is near team. We now have a roadmap team who can have a longer range view, based also on what customers want and what would need to happen for this to work well. This gives a good idea to for example IT departments so they know if a feature is worth waiting a few months for or if it will take a few years for it to land in core Plone.

Plone is not for everybody. What is the ideal size? We used to say it is fine for a single user website and for a multi billion dollar world wide company. That may not be the best message. Plone is typically best suited for medium to large sites. Some metrics from the document:

• Complexity: Plone is usually best suited for sites with multiple content authors working on a single site. For single-author sites, Plone is often considered too complex. Multi-site CMS installations, where content is shared between several distinct websites, can be built with Plone, but is not supported out of the box.
• Duration: Plone projects typically require some ramp-up and initial planning. This means the duration of Plone projects is usually measured in weeks and months, not days. Anecdotal evidence suggests a typical project is 2-6 months long.
• Cost: Costs vary greatly across geographies and organisations, but it is fair to say that most Plone projects involve a meaningful investment of resources (money, staff, time).

Plone has a few differentiators, like these:

• Plone is entirely built by a community, which is fairly unique for CMS platforms that Plone is usually compared with.
• Good security track record. It is easier for us at Netsight to patch one hundred Plone sites than one Wordpress site; and you need to patch Wordpress a lot more often.
• With Plone 4.2 easier theming will come into the core with Diazo.

We used to say at some point that Plone 4 was going to be evolutionary and Plone 5 revolutionary. But people have been wanting to try the new technologies earlier. Still, Plone 5 might break some backwards compatibility. Trickling some of the Plone 5 technologies into Plone 4 already, may make the upgrade easier.

We are using more outside technologies. For example, instead of Kupu (which was maintained by Plone) we now use TinyMCE (which is maintained outside of Plone).

In the medium term, Plone will separate the user interface from the editing interface, using plone.app.cmsui. Plone will use Chameleon as template engine; there might be incompatibility with some add-ons, but core Plone already works fine with it, using its normal zope pagetemplates. Add five.pt to your eggs now and check if your add-ons keep working; fix them when they do not work.

In the long term we will probably get rid of the Zope Management Interface. Plone is the only major user of Zope 2, so let's make Zope 2 (or Zope 4, or whatever it will be called) what we want it to be. We have several own versions of control panels in the Site Setup already of course.

Have a look at the Plone roadmap document yourself: http://bit.ly/roadmapplone. Note that this is still a draft. Add comments! Get your thoughts in sooner, rather than later.