What should Plone be?

When plone grows up. It should *know* what it is. Unlike ZOPE which suffers from multiple personalities. Plone should learn from this and not become feature laden. It should focus on one area and do that area *really* well. What should that area be?

I was writing up a snap-in proposal for plone. then I started thinking, is Plone going to be a Portal or is it going to be a Content Management System (proper). Post-nuke and slashdot *are not* content managment systems.

If anyone can install Bricolage - please tell me. I would be interested to see their approaches to Content Management Systems. Ultimately if Plone is going to succeed we need to help ZOPE with its Versioning Management and create a deployment tool. NOTE: here is the Version Control Proposal at dev.zope.org. I think I like the ideas and most certainly need to work off this Proposal.

Version management is the ability to diff between 2 sets of *text* data (give up on diffing objects). I would say the 2 sets of *text* data would be the 'rendered content'.
Also the ability to be able to 'go back in time' and restore a previous copy. Ideally you do this for a 'structure of content' not just a content item. as it makes sense usually to 'version' an entire branch i.e. Marketing sub-section of your website.

For Plone/ZOPE to pentrate and be flexible. It should not be relied on to do content delivery. Therefore a deployment tool that can deploy versions (structures of rendered content) into a 3rd party system (via FTP/XMLRPC/WEBDAV etc) should also be looked at.

I read somewhere CMF1.3 will have a composite document concept. I think 1.3 with the above features would be extremely helpful. What do you think? Do these features make sense? Should plone be a portal? or should it be a Content Managment System?

~runyaga