Plone And Zope 3
For a little while now Plone development has been moving towards Zope 3 development styles, conventions, and techniques via the Five product on Zope 2. There is much documentation available on the internet today for following this path (at least from the perspective of Zope 3). One of the largest benefits of this is being able to use the Zope 3 Component Architecture (CA) which promises to provide us with more manageable and reusable components.
The repercussions of such a system is that developers have a more robust framework for developing applications and when components are developed by one developer, there is a higher chance that this component can be reused by another developer in another project (and of course by the same developer in other projects).
Business Impact
Benefits
Of course further development, refactoring, and refining the base architecture generally provides a more robust solution to such an extent that businesses have to spend less time and effort managing and supporting deployed solutions. Having reusable components means less time spent developing new components and more time spent plugging in existing components which proves to take less time and thus less expense.
Risks
Migration of existing sites can get quite complicated. Also having to deal with switching frameworks such as making it difficult to maintain backwards compatibility with third-party products. Of course this gets easier as more and more third-party products adopt the same Zope 3 develop techniques which means education of this process moving forward is vitally important.
Random Non-Plone Impacts
From the perspective of a traditional Zope 2 developer deciding whether a new project should be developed and deployed on Zope 2 VS Zope 3 there are two different types of people:
- Zope 2 developer who is accustomed and familiar with Zope 2 development techniques with no interest to move outside of the Zope 2 development model.
- Zope 2 developer who is interested in Zope 3 development techniques but due to missing functionality (Zope 2 has obviously been around a lot longer than Zope 3) in Zope 3 has to develop and deploy on Zope 2.
Obviously the move to Zope 3 development techniques for #1 Zope developer doesn’t make any sense. But developer #2 would be very interested in getting equivalent (in capability) functionality from Zope 2 into Zope 3. And once enough of the required Zope 2 functionality has found a capable equivalent in Zope 3, #2 developers will have a path to fully migrate to developing and deploying on Zope 3.
In order for a full set of Plone components to deploy and run on Zope 3 a lot of this traditional Zope 2 functionality will have to have equivalents on Zope 3. So in the process of providing this functionality for Plone on Zope 3, Zope 2 developers will have much of their wanted/needed functionality migrated as well. This means non-Plone Zope 2 developers will have a higher likelihood of being able to deploy on Zope 3.
Conclusion
It is the recommendation of this author that moving to Zope 3 development techniques is a required manner of evolution for Plone and the Plone software stack (which is in agreement with the Goldegg effort of course). And related to this, the development process and attitude should be to build Zope 3 components on Zope 3 and build them so they (for the some finite time period) can be deployed on Zope 2 until the convergence of Zope 2 and Zope 3 is complete.