snow sprint 2006: the end of the world as you know it
It's the law of critically organizing phenomena. Everyday is the end of the world as you know it. Simply put, some days it is more apparent than others.
Last night stephan richter created an area in the Plone svn repository for the the plone namespace package for zope3.
Why is this important?
To my knowledge, this is the first time that Plone the brand has decoupled from CMFPlone the Zope 2 `Product` for anything other than t-shirts and the occasional conference topic. My perspective is the plone communities vice of platform monotheism as having isolated us from sharing our virtues.
Most of what makes Plone valuable is not architectural. The knowledge about user experience and usability, the solutions to a myriad of use cases, the practical experience informing the product is broadly applicable to a larger space.
This is not to say parts of the Plone stack are envelope-pushing examples of what can be done with Zope 2 and Zope's Content Management Framework.
Dually, Plone has been a shining example for the need for Zope 3, at once a demonstration of the power and business potential of Zope 2 and CMF, and a tremendous example of the issues of Zope 2 and CMF that propogated and educated the Zope 3 rewrite.
Zope 3 is a ground up rewrite of Zope 2 embodying these lessons learned by the Zope, web development, and python community over the last five or so years in the creation of systems like the current Plone CMS. Ruthless refactoring has led to a raw, powerful and developer friendly system for solving problems in the webspace. It is conveniently focussed on making life more fun and productive for those who have paid their dues in Zope2 working with systems like CMFPlone.
If we look at Plone, we see a majority of issues that are pain points for the Plone community of integrators, solution providers, service providers and development community stem from issues with maintainablility, orthogonality, migration, dependency and quality management that Zope 3 has rigorously improved on over Zope2 both in process and in code.
On the other hand, the emphasis on design, usability, and user experience that make Plone so compelling is lacking in Zope3. Though Zope3 has all the necessary tool to develop a full blown CMS (see TIKS), Plone is still considered to be a preferable alternative if what you need is a CMS, in spite of the maintenance costs and learning curve inherent with deploying Zope 2 systems.
Complementary interests and strengths? absolutely. Is plone on zope3 a fork of CMFPlone?
absolutely not.
Zope3's biggest contribution to python at large is it's component architecture. zope.interface has found it's way into a number major projects such as Twisted and rdflib and zope.component will undoubtably find it's way into many more. A road tested and ruthless refactored system, it is currently finding it's way back into Zope 2 as a powerful tool for extending old Zope 2 applications and building new ones.
What does this mean? CMFPlone can use Zope3 components today, and Zope3 can use components written for CMFPlone. This means that beyond adaptation needed for compatibility, the rest of the python written is interchangeable and reusable.
No forking is necessary to `rewrite` plone or CMFPlone. All that is necessary is for Plone developers to refactor old behavior as components and develop new behavior as components. Bite-sized, simple, easily testable, sensible components. On the zope3 side, a basic scaffolding can be built with existing components.
Plone can return to being a skin rather than a framework. Zope3 can benefit from the availability of a new set of components informed by Plone experience in the CMS space.
Having a unified architecture for componentization allows this. Now we have a plone namespace where plone developer can start developing....free of the cruft of Zope2 et. al. Like a clean lab to work in, Zope3 will allow better quality control, faster development cycles, better feedback, and better productivity.
Don't get me wrong.
It's not a silver bullet. It doesn't remove the complexity of a fullblown CMS with 4 + years of rapid development. It requires a little extra conscious effort and some hard thought about what Plone is doing right and wrong. It require some scrutiny to how components should be licensed to encourage reuse and proliferation.
It requires alot of active engagement by the plone community. It requires changes in the way we do things and some work to make the flow of components from Zope3 to CMFPlone and back as efficient as possible.
But....
it makes me excited to write code for plone and for zope[3] again. and I haven't felt that way in a while. This community has always had a tremendous spark; it classicaly has attracted interesting smart enthusiastic people doing interesting things.
hopefully, this will help keep that tradition by making it easier to quickly manifest those ideas.
Because, singularity or not, that is what it's all about......
Last night stephan richter created an area in the Plone svn repository for the the plone namespace package for zope3.
Why is this important?
To my knowledge, this is the first time that Plone the brand has decoupled from CMFPlone the Zope 2 `Product` for anything other than t-shirts and the occasional conference topic. My perspective is the plone communities vice of platform monotheism as having isolated us from sharing our virtues.
Most of what makes Plone valuable is not architectural. The knowledge about user experience and usability, the solutions to a myriad of use cases, the practical experience informing the product is broadly applicable to a larger space.
This is not to say parts of the Plone stack are envelope-pushing examples of what can be done with Zope 2 and Zope's Content Management Framework.
Dually, Plone has been a shining example for the need for Zope 3, at once a demonstration of the power and business potential of Zope 2 and CMF, and a tremendous example of the issues of Zope 2 and CMF that propogated and educated the Zope 3 rewrite.
Zope 3 is a ground up rewrite of Zope 2 embodying these lessons learned by the Zope, web development, and python community over the last five or so years in the creation of systems like the current Plone CMS. Ruthless refactoring has led to a raw, powerful and developer friendly system for solving problems in the webspace. It is conveniently focussed on making life more fun and productive for those who have paid their dues in Zope2 working with systems like CMFPlone.
If we look at Plone, we see a majority of issues that are pain points for the Plone community of integrators, solution providers, service providers and development community stem from issues with maintainablility, orthogonality, migration, dependency and quality management that Zope 3 has rigorously improved on over Zope2 both in process and in code.
On the other hand, the emphasis on design, usability, and user experience that make Plone so compelling is lacking in Zope3. Though Zope3 has all the necessary tool to develop a full blown CMS (see TIKS), Plone is still considered to be a preferable alternative if what you need is a CMS, in spite of the maintenance costs and learning curve inherent with deploying Zope 2 systems.
Complementary interests and strengths? absolutely. Is plone on zope3 a fork of CMFPlone?
absolutely not.
Zope3's biggest contribution to python at large is it's component architecture. zope.interface has found it's way into a number major projects such as Twisted and rdflib and zope.component will undoubtably find it's way into many more. A road tested and ruthless refactored system, it is currently finding it's way back into Zope 2 as a powerful tool for extending old Zope 2 applications and building new ones.
What does this mean? CMFPlone can use Zope3 components today, and Zope3 can use components written for CMFPlone. This means that beyond adaptation needed for compatibility, the rest of the python written is interchangeable and reusable.
No forking is necessary to `rewrite` plone or CMFPlone. All that is necessary is for Plone developers to refactor old behavior as components and develop new behavior as components. Bite-sized, simple, easily testable, sensible components. On the zope3 side, a basic scaffolding can be built with existing components.
Plone can return to being a skin rather than a framework. Zope3 can benefit from the availability of a new set of components informed by Plone experience in the CMS space.
Having a unified architecture for componentization allows this. Now we have a plone namespace where plone developer can start developing....free of the cruft of Zope2 et. al. Like a clean lab to work in, Zope3 will allow better quality control, faster development cycles, better feedback, and better productivity.
Don't get me wrong.
It's not a silver bullet. It doesn't remove the complexity of a fullblown CMS with 4 + years of rapid development. It requires a little extra conscious effort and some hard thought about what Plone is doing right and wrong. It require some scrutiny to how components should be licensed to encourage reuse and proliferation.
It requires alot of active engagement by the plone community. It requires changes in the way we do things and some work to make the flow of components from Zope3 to CMFPlone and back as efficient as possible.
But....
it makes me excited to write code for plone and for zope[3] again. and I haven't felt that way in a while. This community has always had a tremendous spark; it classicaly has attracted interesting smart enthusiastic people doing interesting things.
hopefully, this will help keep that tradition by making it easier to quickly manifest those ideas.
Because, singularity or not, that is what it's all about......
posted by whit at 1:32 AM
0 comments
