I've been a Zope developer since 1999. I'm pretty honored to be part of the community that helped create such a resilient piece of software. Not many open source projects last this long. But Zope obviously is nowhere near perfect. We've seen lots of gnashing of teeth over the years. When you mention the word Zope in the presence of members of the "in crowd" in the Python web development community, some tend to look at you as if you had just farted. Much of this contempt is deserved, because Zope has tended to be an island in the Python development world where only the very committed were welcome, and the terms of that committment have become less attractive over time. I won't offer any specific defenses against this claim, although there are many.

In 2005, I gave a keynote presentation at a DZUG conference . I don't even think I have the presentation itself around anymore, but I can pretty much sum it up as glum. I claimed that Zope was waning in popularity (not without cause) and thus people should really start to take a good look at other web frameworks as development platforms. This was not well-received, but I believe it was true, and still is. I had charts even. Don't make me show them to you.

At the time, the ability to use Zope software in concert with software from the burgeoning other-Python-web-framework-world without brutal cut-n-rape coding seemed a distant and daunting goal. A scripter story existed which encouraged people to store code in an object database, and edit it through the web. While this mode of working garnered many fans, it also proved to be a dead end for all but the simplest of customization work because the code couldn't be manipulated and introspected with any existing toolchain. Some more responsible and farsighted folks realized that TTW programming was a dead end. So they developed Zope 2 "Products". Zope 2 has a concept of plugins (Products), which are essentially Python packages. But these have just enough majyk foo in them to put purists off and a sloppy enough implementation to drive even the fairer away. Work started in 2001 on Zope 3, which was meant to be a "cleaner Zope", a rewrite from scratch. Zope 3 is now essentially a set of libraries which can be used mostly independent of any particular web framework. Of course, nobody really knows this, because we didn't do a good job of marketing or documenting this, so right now "pure" Zope 3 deployments are limited, very few other web frameworks use Zope components, and most Zope 3 deployments (at least by number if not importance) are actually Zope 2 deployments which use the Zope 3 bits as straight libraries.

Paraphrasing somebody, no matter how smart your community is, the rest of the world has more smart people than are numbered in your community. So while Jim and Stephan and a host of other folks toiled away on Zope 3 components, and while the Zope 2 folks polished the bumpers, the rest of the Python web development community consolidated around (relative to Zope, anyway) smaller frameworks like TurboGears, Pylons, and Django. Because they were newer, they didn't need to carry around all the backwards compatibility baggage imposed by six or seven years of hot-n-heavy development. And because they were smaller, they were easier to understand in toto. So Zope 3's "next big thing" thunder was largely stolen by a host of smaller frameworks, which attracted many developers. The Zope 2 developers, committed to their island, stayed on it, occasionally dipping their toes into the water of other frameworks and as a result, temporarily disappearing .

While all this was happening, Phillip Eby was diligently working up specifications and software that he hoped would eventually allow Python web frameworks to share some implementation bits. What resulted was WSGI , a sort of lingua franca that can be shared by servers and Python web applications. He also created a specification and implementation for Python eggs , a packaging format for Python software, and setuptools , which is a collection of software which helps packagers create distributable releases of software, and which helps end users install same.

In the mean-mean-time, in mid-2006, Tres Seaver, Paul Everitt and I formed a company named Agendaless Consulting . We'd each already been Zope developers for years, so it was natural to continue to do Zope consulting. Personally, even as I branched out into doing more pure-Python projects like supervisor and buildit , my main bread-and-butter was and still is Zope consulting. But frankly, in 2005, I was beginning to not like it very much. It seemed pointless to keep developing software on a platform that was so obviously on-the-wane. Eight years is a long time to have such a niche development specialty, and I was worried that I'd be irrelevant in three or four years. But people kept paying me to do it, so I did. I'm glad I did.

There really are some brilliant concepts in Zope. Completely declarative, role-based security. A transaction manager which can coordinate commits and rollbacks of multiple otherwise-unlrelated database managers. Query-string arguments mapped to function arguments automagically. A very workable HTML/XML templating system (ZPT). XML-RPC APIs "for free" everywhere. If you're willing to pay the price of admission, which is some committment, Zope is still a great platform on which to base an application, and though it may treat you badly some days, on most of them, it will be a very reliable friend.

Here we are in 2007, and I'm happy to say that the future of Zope is looking much brighter to me than it did in 2005. That statement is not entirely accurate, though. I still believe Zope, as a brand, is losing developer mindshare. In my opinion, the only thing that has been keeping it at even its current level of relevance is Plone. Which is a shame, because you can really make some nice software with Zope without Plone anywhere in sight. But the Zope brand itself doesn't carry as much value as it used to, despite the quality of the software which bears its name.

Which leads me to repoze . Repoze, broadly, is an attempt to carry the benefits of the Zope platform along into a future where the delineation between Python web frameworks isn't so stark. Its aim is twofold:

• Allow folks to more easily use Zope technologies without using Zope-the-application-server.
• Allow Zopish folks to use technologies from other web frameworks more easily without "giving up their Zope".

I won't go into Repoze much here, you can look at the web page if you're interested. But I will say that it has given me new enthusiasm about creating web applications using Python. I'm looking forward to creating lots of new software in a world where I'm no longer in a (largely self-imposed) Zope "ghetto" and I can share stuff with a larger crowd of people via WSGI components while still retaining the ability to earn money using my specialties.

It's my opinion that four or five years from now, Python web developers won't be arbitrarily classifying themselves as "Zope developers" or "Django developers", etc. Instead, they will be (to at least some extent) "plain-old-Python-web-developers". Ian Bicking's Paste in concert with Phillip's WSGI and eggs makes mixing and matching web framework technologies vastly easier than the job used to be in the past.