Geir Bækholt of Jarn just delivered a keynote talk at the European Plone Symposium 2009 in which he outlined the roadmap for the next two major releases of Plone. You can skim through the slides here, but it’s worthwhile to click through to the full version so you can click on the “Notes” tab and read Geir’s notes to accompany the slides.
Jon Stahl's Journal
Politics, the environment, technology, activism. And stuff.
I’m sure I’m being silly, but where exactly is this ‘notes’ tab you speak of? I did click through as you suggested, but don’t see that anywhere.
I can’t seem to find the promised “full version” in this never-ending hoolahoop of web 2.0 gadgets, widget, and social twitter slidesharing google ads
Doesn’t it have a url?
@John — there are two links in the above post, both of which take you to the slideshare.net page for the presentation.
@Scott — the tab is labeled “Notes on Slide 1″ and it is below the slide deck next to the comments.
This is great — really clear and helpful.
I think you guys will make everyone run far away from Plone even before it have an “ideal” usable version! Sorry! I just can’t maintain my Plone sites since Plone is change radically on each new version. I’ll quit out!
Sorry you feel that way, Jean. Plone hasn’t made a major release in two years, so it’s hard to see how anyone can justifiably complain that we’re “changing things too fast.”
Plone 4 will not have any “radical” changes from Plone 3, as Geir’s talk clearly shows. Plone 5 will have some larger changes, but you’ll have plenty of time to prepare. And thanks, to Plone’s excellent security track record, nobody’s forcing you to update sites that are working great with the current version.
I agree with Jean. It may be 2 years since the last release (Plone 3), but people such as myself who are not full time Plone developers struugle to update either their own or other 3rd party applications to new releases of Plone as there is often NO backward compatibility with earlier versions of Plone, as there is no consistent API to Plone to buffer against internal changes to the product.
The Plone development community really need to listen to these comments, rather than brush them off as they always seem to do.
I have spent a lot of time struggling to update a site I have developed using archgenxml and some 3rd party applications with Plone 2.5. Some of the 3rd party applications have not been upgraded for Plone 3, and I do not have the time to learn enough python and the depths of Plone to attempt to fix them for Plone 3 myself. The poor state of documentation does not help either.
I had originally hoped to give my application (for on-line history projects) back to the Plone community, but because of these issues it will probably not happen.
The site I developed can be found here: http://www.franktraynors.au.com
Regards,
Don,
I’m sorry you’re having a bad experience updating your Plone 2.5 site.
Unfortunately, the core Plone developers can’t compel add-on product authors to update or maintain their products. This is a problem that affects all open-source communities with vibrant add-on product ecosystems. Plone has actually done a much better job of making it easy for product authors to keep products updated than many others, but I agree that there is still room for improvement.
The process for updating products is well documented, but unfortunately, it does require some experience with Plone development. That is unavoidable.
It sounds like you are in a situation where a few hours of consulting from an experienced Plone consultant would make a big difference.
Hi John,
I appreciate your reply. However, I think you may have missed the point of what I am trying to say.
It is one thing to add new features to a product, but if in doing so you break work that others who have limited time and resources, and do so consistently, then I think people just give up.
I suspect the add-on product authors you refer to initially put a lot of time and effort into understanding how a particular version of Plone works to initially develop a particular add-on product, but just give up on keeping it updated when they realise that every new release of Plone is likely to break products developed for the previous version. They simply do not have the time or resources, and have developed the add-on to provide needed functionality for a particular project.
My point is that if the core architecture of Plone was implemented appropriately, additional functionality could be added without breaking add-ons developed over earlier versions.
This sort of capability is well developed in proprietary applications.
Many people, including myself, are not in the position to pay for specialist IT consultants for what are essentially private interest or community projects.
I hope this makes some sense.
Regards
Don-
I totally hear what you are saying. And I agree with you, it would be really really nice if what you’re describing were possible; it would save a lot of people a lot of pain. But from what I’ve seen out there in the world, it’s pretty much an impossible goal to never break an API. Or, more accurately, it would come at the cost of being unable to make major improvements in our code. There aren’t any open-source CMS projects that have the developer resources necessary to never break add-on products at least a little when they do major upgrades.
Generally speaking, the changes required in most well-written add-on products from Plone 2.5 to Plone 3 or Plone 4 aren’t more than a couple of lines worth. It can depend a lot on the add-on product, and in an ecosystem with over a thousand add-on products, many are quite frankly not up to the high coding standards of Plone itself. So they may need more work, or may have never really been suitable for “serious” projects in the first place.
Plone has a pretty good track record here compared to most of the other products with which I’m familiar. I’m sorry to hear that we haven’t been successful enough for you. If there are specific add-on products you’ve had trouble with, you should visit plone-users or the product-developers lists; the community may have helpful suggestions or alternatives.