PyCon 2009: Zope 3 is dead! Long live Zope 3!
This is my subjective account of the discussions about Zope that happened under PyCon 2009. I make no claim that this represents any sort of truth except my own.
Update: There was some interest in keeping Zope 3 around and alive, and as a result it was renamed BlueBream.
On thing that really made med excited about PyCon 2009 was the amount of Zope gurus that was going. Primarily the fact that we got several of the main drivers behind the innovation in Zope web frameworks lately into the same room was cause enough for celebration. The Zope community have a history of “violent agreement”, and I always suspected that it would be fruitful to have these discussions in real life, where misunderstandings are more easily and quickly fixed. My hope was that the result would be a renewed sense of consensus on where Zope was heading, and I think that was pretty much exactly what happened.
No decisions was taken, and I think that is good. When a community decides something it’s important that the people who take the decisions also have the ability to make it happen. For Zope, there is no central group that have the ability to create Zopes future by themselves, and therefore it’s important that no central group takes decisions. The future must grow out organically from what is actually done and created.
The discussions started with an open space on Sunday morning, with a “Hate Zope/Plone” BoF. About ten people showed up and sat around a table complaining. Perhaps not very constructive, but fun and possibly cathartic. At 4pm there was a Repoze Open Space, and at 5pm there was the “Zope: Status + Future” Open Space I announced earlier. This Open Space dragged out and spilled over into the bar. The major revelation for me was that nobody seemed interested in the application server known as “Zope 3″. Of course, opinions on what exactly made up this application server differed. Was the “Application Server” if you included the Zope Management Interface, the ZMI? Or was it zope.app.publisher that was the “Application Server”? It was clear that few, if any, used Zope 3 as a monolithic whole any more. Most Zope 3 users picked and chose the libraries out of Zope 3 that they wanted, and those who didn’t, wanted to. Nobody seemed interested in a big fat Zope 3 Application Server any longer. The wish of the day is to have a lean, mean webserver that doens’t have everything included, but instead uses a dependency tree to include those parts, and only those parts, that your application needs. And this of course was the whole purpose of the eggification of Zope 3, which therefore can be declared to be a resounding sucess.
The discussions continued during the Zope sprint that followed. And one thing that most people seemed to absolutely not want was zope.app.publisher, the central part of Zope 3. It’s too big, too complex and does too much. Chris McDonogh of course wants to use repoze.bfgs minimalistic publisher. Gary Poster from Canonical wanted something more flexible than repoze.bfg, but less complex than z.a.p. Jim Fulton wanted Bobo back, the much simpler publisher that was the center of the early versions of what became Zope 2. Also, nobody was interested in using the ZMI. As these seems to have been the main contenders for being Zope 3 The Application Server, the conclusion is inevitable: The application server known as Zope 3 is dead.
And this is a Good Thing. Not because Zope 3 was crap. It wasn’t. It’s bloody fantastic. But there is a lot of confusion about what Zope is. There is Zope 2, an application server called Zope 3 and a vast library of web application modules also known as Zope 3, so the fact that nobody any longer want the application server help clear this up. We can forget about it. We are then left with a big framework of libraries, which are set to get a release in the not too distant future as the Zope Framework (probably 1.0), and an application server called Zope 2 which includes the framework (and other bits). It’s still not perfect, but it’s way less confusing.