Some more ideas to consider

After all the awesome blog posts and mailing list posts about Plone's future, I don't have much left to say. I do agree with lots of the points mentioned and try not to reproduce those here.

I'd like to bring up some more minor ideas nonetheless.

1. Make add-ons first class citizens

The number of features that everyone wants to see in Plone is growing and even at this point I think Plone does more than we can guarantee to deliver good quality for.

In my opinion the only way out of the current 'everything should be in the core' meme is to embrace add-ons more and make them first class citizens of the Plone ecosystem. Alex Limi already posted some ideas on how to improve the installation and update story and I wholeheartedly agree with him. We need to provide the entrypoints and metadata for add-ons to integrate seamlessly with a Plone installation. I have some specific ideas on how to do this and plan to rework the add-ons control panel of Plone in the near future.

Obviously this goes hand in hand with all the planned efforts for turning the products section of plone.org into something more usable. The PyPi-like interface goes a long way of making it simpler for developers to upload their packages to plone.org and ratings and reviews give you another metric for judging a packages quality.

2. Plone should be lighter

In my opinion a default Plone installation at this point does too much and it is too hard to turn off some of the unneeded features for a particular site. What I would like to see is for Plone to come with two different flavors of default configuration. One that resembles what we have right now and which is created by default by the installers. I'd call this the 'evaluation version'. The other one I would like to see is the 'minimal version', which configures a Plone site with just the options you need to have for a working system. No content added, no portlet assignments, one simple one-state-workflow, no content rules, staging, versioning, openid or what not.

What I would like to do is to group all the configuration needed for one particular feature into an extension profile and present this as a feature control panel. So you can get versioning with a single click in the control panel or you can add it as a GenericSetup dependency in your policy package for your site and have the same effect.

This allows integrators to reuse the new base profile called minimal version as the base for their policy packages without hopefully having to delete anything from the created site. The minimal version obviously becomes the GenericSetup base profile. As a nice side effect we can get faster test runs by running most of the integration tests that require a full Plone site against the minimal version.

3. More fine grained configuration upgrade procedure

Closely related to the above mentioned, I think we need a better upgrade story for the configuration of both Plone itself as well as add-ons. We have the underlying technology with GenericSetup upgrade profiles available. What remains is to expose this in the user interface, so you know if an installed add-on needs an upgrade.

For Plone itself we need to distinguish between essential upgrade steps and non-essential ones and give the user the choice to apply the non-essential ones according to their needs. For example creating the site mananger in the Plone 3 migration is essential, reordering the CSS files in the registry is something that should be left to the user to decide with a small description of what will happen and why we do it.

4. Optional code

In the same way I'd like to see the Plone configuration to become lighter, we could think about using the same principle for code. Everyone who has ever used a Windows installer for a more complex product, knows their ability to choose from a variety of options during install time. So you can either install only the base product or install some options with it. Later you can go back to the installer and add or remove more of these options. I think this should be doable with a set of more independent packages which we are getting better at and an installer based on buildout.

Why should we think about this at all? Less code is less code to run, to eat your memory and CPU cycles, to contain bugs and security holes and to look at when trying to figure out how to extend the system.

However this has a big risk of resulting in more non-reproducible bugs and more integration errors between different parts, so it needs to be considered carefully. Plone the product as downloaded by the casual user should still come with all the bells and whistles.

5. Unicode!

This is a personal pet peeve of mine. We are already in a good starting position to master the move from a system using encoded strings to a fully Unicode aware application. There are some major next steps we need to take to get there eventually, so one day we can theoretically run on Python 3. Obviously this is not something we need to do in the next year but Python 3 lingers on the horizon and one of the certain things about it, is that we won't be able to use it unless we fix our Unicode story.

For Plone 4.0 I would like to do some changes to Archetypes and PortalTransforms to get better Unicode support. Still on the todo list are external data sources like LDAP, SQL and quite some configuration stored in the ZODB like old Zope2 properties. Maybe more for 5.0 we will need to think about using a Unicode aware publisher, which goes nicely with ditching the Zope2 publisher and going for a repoze based setup. There is more work here and a fine balance to keep between introducing backwards incompatible changes and moving forward.

Personal note: I'm on the move...

There are some big changes coming up in my personal and professional life which I wanted to share with you.

For a few days I'm officially homeless now. I handed over my apartment to my landlord last week early in the morning. In February I'm staying with friends and hijack some couches. Thanks a lot to my brother for hosting me in the first week!

While I still have to work for one more week in late February for my old employer - a small hospital in the eastern part of Hamburg - I'm already looking forward to my new job opportunity.

But first I'll attend the Plone Strategic Planning summit in San Francisco to help shape the future of my favorite Open Source CMS. I think this is going to be a great opportunity for Plone and hopefully we will see lots of interesting stuff happening on and especially after the Summit.

Finally end of February I will move to a beautiful little sea-side town at the Fjord of Oslo in cold Norway. Amongst other things this little town is world famous for one of the coolest Plone companies called Jarn, home to many dedicated and extremely skilled Plone addicts. It is with great pleasure that I'll have the opportunity to join them starting in March.

So prepare yourself what happens, when I don't only work on this project in my spare hours but can share my experience on a daily basis with lots of other amazing long term core contributers. It is truly an amazing time for me and Plone these days :)