I've been thinking a lot about the various things said in the vision
discussion. Lots of people said things I agree with, but other things
were said that make me worry a lot (losing brand-identity and useful
names), and so on. Here I sketch out some of my thoughts.
Reading back through it, it is long. I hope not everybody is tired by
now and someone will read it. It's more like a summary of the thinking,
and I don't propose anything really new. So it may leave you
disappointed reading to the end. I hope it's useful to someone, still,
in at least providing some tools, useful concepts, to think with about
Imagine a world where Zope 3 had never been called Zope 3. Imagine it
was called 'foobar'. Otherwise everything is exactly the same. Let's
think through this alternate reality for a while:
By not having called it Zope 3 we would not hade made the implicit
promise that foobar is there to replace Zope 2. foobar doesn't need to
ever have the same featureset Zope 2 does, or the same audience. foobar
can be used together with Zope 2, or bits of it can be used independently.
Zope 2.10 could then be called Zope 3 instead. It contains a heavy dose
of foobar technology, and we have a roadmap to foobarize Zope even more.
Eventually you could run foobar apps in Zope that do not use the older
Zope 2 technology at all.
Unfortunately we do not live in this alternate universe. We have named
it Zope 3 instead, not foobar. We've been implying, saying, that Zope 3
is to succeed Zope 2, for years.
In the last few years we've seen a realization in the Zope community
that we cannot really leave Zope 2 behind us just like that. It has too
much value. We have started efforts to include Zope 3 technology in Zope
2. We've become more confident that Zope 2 *can* evolve forward, guided
by Zope 3. Still, that 3 is in the way of continued evolution of Zope 2.
It confuses newcomers, and blocks a smooth progression of version
numbers. It gives people the impression that Zope 2 is a dead end, and
2005 was a year of rennaissance for Zope 2.
At the same time, Zope 3 *is* an application server platform, and large
applications have been developed on it successfully. Let's not forget
that Zope 3 has now fulfilled its promise of being a better successor to
Zope 2 for a large class of application domains that we've been using
Zope 2 for.
Let's also not forget the commonalities Zope 3 and Zope 2 have, which
are much more than you'd think at first sight.
Learning Zope 3 is far easier than learning Zope 2 *and* CMF *and* Zope
3 technology *and* the quirks and limitations of Five. Five is a shorter
climb for those who know Zope 2 already, but it's a far higher mountain
than Zope 3 is.
We've gone towards both visions. We have a Zope 3 platform and a Zope 2
platform that is evolving forward helped by Zope 3 technology. Dropping
either vision will break promises we've made.
Zope 2 has a through the web development model that was a major
contributor to the early success of Zope 2. Zope 3 has no equivalent. I
believe Zope 3 has a better model for large scale software, but it's
definitely not as good at marketing and blocks certain people from
getting the job done.
The Zope 2 through the web development model also has serious drawbacks.
It's hurt the evolution of Zope 2 by focusing people's attention on
through the web development where it wasn't actually contributing
anything and could've been done more effectively within a product. It
cost people's time and frustration.
We need to consider whether through the web programming is worth is as
much as it was back when Zope was first released.
Jim has indicated he wants to put more focus on the ZMI development
model and build on what's there in Zope 2. Do we have developers to work
on it? We should be careful about implying promises there.
We have two visions, two related things called Zope. We have confusing
So people have been thinking about a way out, a way to clarify the
message. The problem is how to navigate our way out without doing more
damage than what we'd fix. The only way to solve that problem is by
being very careful.
The proposal was made to work towards a successor of both Zope 2 and
Zope 3 called Zope 5. In effect Zope 5 would be the "Zope 3" of my
alternate foobar universe, or at least an evolved version of such that
can run clean foobar-based applications as well.
The proposal was made to change the name of the Zope 3 component
collection to "Zed". In the foobar universe, this would mean separating
out the foobar library from the foobar application server (and then
looking whether the foobar application server can be made to work with
I worry about losing brands we've worked on hard to establish. While
many people do not understand the difference between Zope 2 and Zope 3,
many others have heard about Zope 3 and they know it is not Zope 2.
I worry about announcing a Zope 5 before we're ready. Do we have the
development resources to make Zope 5 a reality? Breaking a promise we
can't fully keep (Zope 3 succeeds Zope 2) by replacing it with another
promise we may not be able to fullfill any time soon (Zope 5 will be
backwards compatible with Zope 2 and Zope 3) sounds dangerous.
Naming it Zope 5 and listing the featureset it would have won't make it
exist without a lot of hard work.
I worry about losing names, concepts, that are useful handles on things.
In a Zope 5 universe, we'd still need names to name the old Zope 2 parts
and the Zope 3 parts. Stephan would want to work on what is now Zope 3,
not the Zope 2 parts. Five would be for those bridging the two efforts.
And new developments should happen in Zope 3, not Five - only after that
they should come back to Five. Right now we have good conceptual handles
to talk about these things - Zope 2, Five, and Zope 3 mean things to
people. Calling it all Zope 5 might muddle things up and leave it open
to new interpretations and confusions, which wouldn't be good.
What to do? Since this is open source, I think it depends on what people
*will* do. Roadmaps are hard to make if no vehicles arrive to travel on
these roads. All we can do is trace out a few lines in the sand and hope
they will be followed, but we know from history that things don't always
turn out as we expected. Nobody expected the current situation, after all.
Will people start evolving the ZMI in Zope 2?
Will people develop an appserver that can run both Zope 2 as well as
Zope 3 applications?
Zope 3 is exploding into component pieces. How far will we go with it?
How to separate the appserver bits from the components?
I would suggest stability in our message for now. I believe the current
situation is not ideal, but workable. Let's not rename things just when
we've finally, in 2005, reached a situation when at least core
developers on Zope 2 and Zope 3 know approximately what is happening and
where we're going. Let's rename things when we are ready.
I would suggest that for now, we name only new things: the bit that can
run both Zope 2 and Zope 3 apps, a new ZMI for Zope 2 perhaps, and leave
the old names alone for now.
Let's not call the new things Zope, for now. Their own identity is good,
and won't confuse anyone. We can always fold them into Zope later, when
they're ready - we did that with Five. Then in a year's time, let's talk
again. Perhaps then we are ready to fiddle with the names and version
numbers of what we already have.
I do think that time will come, but I think that time is not now, and I
think that announcing changes to names now will make matters more worse
Let's instead draw some lines in the sand and talk about where they
might be going. I'm very excited about the work that's being done.
Zope3-dev mailing list