
Tres Seaver, father of CMF, gave a talk at the DZUG Conference today entitled “Door Number Three: One Perspective on the Future of Zope”, in which he ruminated on the history of Zope and made predictions on the future of Zope. Here are his slides, more or less verbatim (although I missed one about buildout):
Zope’s identity crisis
Is Zope…
- an application?
- a platform?
- a set of libraries?
Different audiences
- Python developers
- Content managers
- Site managers
- Casual developers
- Zope2 identity
Mixed
- application (ZMI, “active” content)
- platform (Products
- not library (dependencies)
Audience mixed
- Content managers
- “Scripters”
- Application developers
Zope 3 identity
- Audience: experienced developers
- Eventually evolve Z3 to replace Z2
- “forward-compatibility” goal
- Zope 2, like Marxist state, “withers away”
Zope3 is now “old” tech
- Initial ZC sprint, November 2001
- Initial community sprint, January 2002
- Zope3X released Nov. 2004
- Five 1.0, ZopeX3 integrated into Zope 2.8, Apr. 2005
Two visions
- Jim’s list post, Feb. 2006
- Vision 1: “gradualism”
- Vision 2: “Zope 5″
- App server configured to support either Z2 or Z3-style apps
- “Zope3 explodes”
Competing alternatives
- Ruby on Rails
- Other Python frameworks
- Django
- TurboGears
- Pylons
- Twisted
- WSGI
- Paste
Lessons from Competition
- Lower barriers to entry – RoR has attracted frustrated Java developers
- Interoperability matters
- Slick marketing pays off
Disruptive Technologies
- Component architecture
- Egg-based distribution
- Buildout-driven deployment
- Grok
Component architecture
- Replaceable components
- Good for reuse of software
- Problematic for identity
- Configuration
- Risk: brand dilution / displacement – fuzzy about what Zope really is
Egg-Based Distribution
- Eggs as analogs to Java’s .jar files or Ruby .gem files
- Explicit dependency management
- Entry points
- Easy installation – easy_install (similar to Perl’s CPAN)
- Controlled environments
- workingenv
- virtual_python
- Risk: increased release management burden
- Risk: complex dependency relationships
- Need a mechanism for specifying “known-good” assemblies / configurations
Buildout-driven Deployment
- Scripted creation of an application instance / stack
- Specific versions / branches for components
- Repeatable, cross-platform
- Technology agnostic
- eggs
- checkouts
- tarball + CMMI
Grok
- Tackles “barrier to entry” problem for Zope3 application development
- Avoids ZMI
- Applications can be served outside Zope
- See Phillip’s Nudge talk
Decision, decisions, decisions!
- Monty asks: (see the Monty Hall problem game theory)
- Do you want what’s in the Box, or what’s behind the Curtain?
- What about what’s behind Door #3
- Let’s make a deal!
Behind door #3
- Drop the “application” part of the Zope brand
- Plone largely owns it
- Emphasize “platform” role for “Zope”
- Provide “known good” assembly of packaged components
- “Library” is main role for current Zope 3 code
- Satellite projects are where the real work gets
- “Pluggable app” stays Zope2′s role
- support Plone, Silva, etc.
Why trade?
- Improved branding story
- Focused audiences
- Improved intake models for community
- Grok for developers
- Paste / WSGI as evangelism
- Content managers / scripts not swamped with details
Prognostications
- In two years, Zope3 will no longer be installable as an application
- Zope2 / Plone will still be the dominant “application”, in terms of production deployments
- WSGI / Paste will bring Z3 components much wider use outside Zope
Technorati Tags: conference, dzug, natea, plone, sprint, zope, zope3

