[Zope3-dev] visions, brands and roadmaps in the sand

[Martijn Faassen]

Hi there,

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 
this situation.

...

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 
version names.

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 
Zope).

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 
than better.

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.

Regards,

Martijn