This is what the future looks like
If you haven't been paying attention, pay attention to Repoze. I'm pretty sure this is the future. Repoze lets us set up Zope so that it runs directly in Apache (using mod_wsgi), no separate process to manage. It lets us create pipelines with things like Deliverance in them. Virtual hosting, retry (on ConflictError) and transaction management is all middleware, enabled or disabled as desired with a dead-simple configuration file and re-usable in other contexts. The Repoze website runs four or five different pieces of software, all themed up using the same Deliverance theme. Issue tracking with roundup, blogging with pyxblossom. This is cool stuff. :-)
For example, collective.lead uses the Zope transaction machinery and ties it into SQLAlchemy's transaction management. Although I haven't tried it, I'm pretty sure you could use this here to run an application that needed integrated SQL-ZODB-whatever transactions without Zope at all.
The whole thing is just a collection of eggs, and a .ini file for Paste. It feels very controllable and non-magical. The examples from Repoze use virtualenv, but I made it work in buildout (which I prefer, though virtualenv is well suited to something as egg-based as this too) in a few minutes (though we may want a simple Paste Script template for the basic layout, the products directory and so on). This model of development and deployment is basicaly the same that Pylons and TurboGears uses (and probably other frameworks too), and it makes interoperation with such frameworks much more likely.
Right now, Repoze is still a proof-of-concept, but a damned good one. I say that, because to make it work slickly, Tres, Chris and Paul had to re-package bits of Zope to be eggs. Right now, those eggs contain copies of Zope 2.10, CMF 1.5 and Plone 3.0.2 code. I don't think they had to change anything else, although they refactored some code (like virtual hosting) out into new packages and didn't use the old packages.
There are some things we can do to make Repoze a viable, stable and community-owned alternative to the traditional instance-based mode of Zope deployment. First of all, we should break Zope 2 up into eggs. The Repoze guys did so in a quick-and-dirty way, creating a few über-packes like zopelibs and ploneproducts. That should be pretty trivial - we can make packages out of all the standard Zope 2, CMF and Plone products easily (since Products.* is now a namespace package). We can also make eggs out of the other things in $SOFTWARE_HOME), such as ExtensionClass, Acquisition and so on. Maybe we make some more coarsely-grained eggs that incorporate a few of those packages. We also need to see the completion of the long Zope 3 eggification process, use those eggs as proper dependencies, and be a bit better about declaring dependencies for Plone 3's eggs in the plone.* and plone.app.* namespaces.
Note that it's completely all backwards compatible. We can continue to roll a Zope 2 tarball that builds old-fashioned instances, using a bit of svn:externals magic. However, if we did do this, and we kept the eggs released and up to date, then people could choose to use them the Repoze-way - as eggs, in a WSGI pipeline. I know I would (once it reached a stable version, at least).
Secondly, we need to promote and experiment with this stuff. Paul has already done a couple of great screencasts, but we need people to push the boundaries of what this type of set-up can do and then share that with the rest of us.
I think if we did this, we'd actually have come pretty far, and we'd have "normalized" Zope a whole lot more. We could (and would) still continue to support other deployment methods, since in the end it's all the same code. However, we'd probably start seeing some different kind of innovation, with WSGI middleware to do all kinds of fun stuff - single sign-on, interactive debugging, reporting, tramline-like file management... just off the top of my head. We'd also present developers with a simpler and more unified deployment, packaging and configuration story. A Repoze virtualenv or buildout feels very light and consistent - all the code lives in eggs, there are a few top-level packages like var/ (for Data.fs) and etc/ (for zope.conf and zope2.ini), and of course Products/, where non-eggified old-style products continue to work.
If you haven't checked it out yet, look at Paul's screencasts, or just download it and give it a go. I think you may be pretty excited.