Ian Bicking just wrote a Cracker Jack post on the direction he’d prefer for Plone’s development. It and its comment thread are great reading.
Money quotes:
One of the ongoing concerns in the Plone community has been the difficulty of attracting and maintaining developer interest in the community, and generally making Plone easier to work with as a developer. It’s been a very successful community for consulting and integration work, but it has not been as rewarding for developers.
Five didn’t remove any complexity, it only added to it. Even if the new components were superior that doesn’t make themsimple. Plone is aching for more simplicity, not more power.
Zope 2 is a behemoth, and its metaphors are deeply intertwined with existing code. Acquisition in particular is ubiquitous, essential to lots of the machinery, and deeply confusing.
Grok…attempts to make development in that environment more pleasing. It eliminates most ZCML (ZCML is Zope 3’s XML-based language for declaring the relation of various components in a system). Grok uses conventions and introspection to make Zope 3 look more like a traditional web framework, with simple views and models and templates, and less of the wiring you have to set up in typical Zope 3 architectures.
…Plone shouldn’t be so focused on managing the complexity of its stack, but focus on reducing that complexity. And it should reduce that complexity by focusing on content management and moving all the other pieces people have built on Plone out of Plone.
Sure, the customizability is “powerful,” but I don’t hear people clamoring for power. They want simple, predictable, fast, maintainable.
So, I offer this as my suggestion to Plone. I think Plone-the-community has the opportunity to be more than Plone-the-software; I think it must do this to remain viable in the long term. But to get there the community make some choices — you can’t add simplicity.
This is great, informative reading. Check it out.
Seek Nuance 