On 2/6/06, Martin Aspeli <[EMAIL PROTECTED]> wrote:
> Guys ... from my reading of the z3-user discussion, there were two subtly
> different things that came out:
>   - Have funky release codenames. Okay, good - makes it easier to talk
> about Zope 3.2 vs. 3.3. However, I think this is secondary (by far) to ...

I think it's terrible. I say again, I think 3.2 and 3.3 are easy to
talk about. "Well, the current version is 3.2. 3.3 is coming out this
spring and is likely to include foo.baz. We're hoping to get foo.bill
in for 3.4 later this year, but it depends on the usage patterns we
notice from some of the 3.1 deprecations"

"Well, the current version is Sarengeti. Olympus is coming out this
spring and is likely to include foo.bz. We're hoping to get foo.bill
in for Mushroom later this year, but it depends on the usage patterns
we notice from the Dustmop deprecations"

I don't think the second message is any clearer.

>   - Have a *brand*. That means one name, a name that doesn't change. It
> could just be "Zope 3" with a capital 3, or it could be a more distinctive
> name, e.g. Zope 3 Zomething (where Zomething is something to be decided)
> to have an even more distinctive brand; a logo that has some punch, a
> colour scheme, a web site with proper advocacy and some start-here
> documentation and some quick tutorials.

A good brand name is good. Maybe to be proper with the Web 2.0
phenomenon, it should be 3Zopes.

Beyond that, I think that 'Zope 3' is a good looking set of characters
and can be a strong brand in and of itself. Just always, always,
always refer to it as Zope 3. It doesn't need to be Zope on Zydeco or
something like that. 'Zope 3' has a lot of strong brand potential.
It's crisp, it's clear, it builds on something established yet can
differentiate itself from it.

> The secondary brand name (the Zomething in my example above) was the
> original example - and I personally think this is a good idea, just to
> give the clear message that this is distinct but building on Zope 2.

Zope 2 is seldom referred to as Zope 2. Zope 2.x maybe, but I seldom
notice it referred to as Zope 2, except now that Zope  3 is on the
scene. By just adding emphasis to the 3, and it doesn't even need to
be a strong emphasis, I think we can capture a lot.

A fancy name isn't going to give the message that this is distinct,
especially if the experience of finding out what Zope 3 is and how to
use it starts bringing back painful memories of prior Zopes, or starts
to mirror the stories people have heard about Zope - "yeah, it's great
if you can figure it out... good luck figuring it out..."

(alright, I'm a little cranky after losing a fight with trying to a do
what I thought was a simple multi-adapter registered with just an
'adapter factory=...' directive call in ZCML... damn thing wouldn't
use my publishTraverse and all I could do was scream and cry and
re-architect my solution because those browser directives did their
magic blessings of publishTraverse, call, and everything else and I
couldn't figure out how to do that on my own easily... augh..)

> Seriously, look at http://www.djangoproject.com or http://rubyonrails.com.
> This is about getting people to *understand* what Zope is about, to
> understand that we *care* that they understand and that we made an
> *effort* to make it easy for them to get into it. It's about lowering the
> barrier to entry and the risk that they'll spend time learning something
> that'll turn out to be a dead end. It's about showing off that Zope can be
> sexy and knock the socks off the competition. It's about generating some
> excitement, not just a dreary list of technical blather.

Yes! Exactly! You know, for all of the "Django is wonderfully
Pythonic..." "it's for perfectionists..." talk, I see a lot in its
core documentation that I think Zope 3 does better. Django does some
very impressive things, but glancing over documents like their Model


I see a lot of things that remind me of things that didn't scale well
conceptually in Principia/Zope - tuples and tuples of tuples
(including permissions, in the style of (('can_order_pizza', 'Can
Order Pizza'),) )! Those of us who remember building aggressively
large __ac_permissions__ structures also remember, if their
experiences are like mine, the difficulty of maintaining such lists -
is id or title the first element? Oops, I made a typo and did
'cant_order_pizza' and nothing caught it!, and so on.

zope.formlib and zope.schema really blow all of these other systems
away, I think. I think it's ridiculous that people are saying "well, I
don't want to write an Interface" but are fine with writing
``first_name = meta.CharField(maxlength=30)``. But in Zope 3.2, you
can't even get a list of zope.schema.* fields in apidoc easily! To
make up for it, there's *great* documentation about formlib, but it's
in the source.

Anyways, I'm sure this is all stuff that we can agree on.

I think the code-naming thing is silly. Names drive me crazy after a
point because I just don't find the worth in keeping my internal
translations up to date.

If the next release is going to be sexy, I still think that there
should be good articles written as the release approaches. From "New
in 3.2: zope.formlib, why it's better than zope.app.form, how to start
using it" to "Deprecated in 3.2: i18nmessageid versus i18nmessage and
how it affects you (especially if you don't know anything about

It's like the difference between this, which we have:

and this, which I absolutely love:

I know that even I would care a lot less about new Python releases if
it weren't for Andrew's terrific documents. And while they're not
comprehensive, they're great for quickly getting that "oh, so that's
what that new thing is!" enlightenment.

But with 3.2, some of the new big features seemed to be surprise to
even some core developers: "Viewlets made it? Whoa..". So if Viewlets
are in Zope 3.2 Xing Hua and no one knows about them, does the fancy
branding make a sound?

This is an important discussion and I don't think I'm saying anything
new here, at least not new for me. I just want to say that 'brand' is
very important, and not to be taken lightly. But also there are far
more important things than coming up with fancy names. There's been a
lot of discussion about packaging and releases - very important, I
think. I had to write my own little semi-packaging system because I
was pulling in so many disparate and useful third party tools and had
our own stack and getting it all out of the various subversions and
CVS repositories and into something usable and something I knew would
work with the released version of Zope (or released version we're
using for a particular suite of apps). 'zpkg' was way too hard to
figure out. Eggs... Hell if I understand them anyways. So while it's
great there are so many useful tools and libraries people have made
available, who thinks they could write a page for the mythical Zope 3
web site that says "You've just downloaded Zope 3.2 - Now what are
some other things you can use with it? [list of packages, easily
downloadable and installable]" Again, knowing I have Zope 3 Clemens is
of no concern if I have to spend another hour arguing with subversion
and CVS and then finding out what I checked out worked with the
upcoming Zope Big Muddy but not Clemens.

So I say - let's focus on the points you and others have brought up
about good informational resources, and just make 'Zope 3' a strong
brand by making it a strong brand. Otherwise, it's like those episodes
of The Wire where Stringer Bell, basically in charge of half the drug
trade in Baltimore, was trying to figure out how to keep people coming
to his corners when their product was inferior to the dope the east
side boys were slingin'. In a business class he learned that changing
the name was an option, and soon the corner boys were calling out
different names every other day for the same sorry product. Without a
change in quality, it doesn't help.

> This is the proposal that considers the most serious consideration in my
> opinion. The original discussion showed that a lot of people found Zope's
> lack of branding a problem. Now it's time to find a solution to that
> problem.

Something that I admire about Ruby on Rails, Django, MochiKit, and
TurboGears all is that they're opinionated, proud of it, clear in
their message, and all seem to have a similar degree of respect for
simplicity and communication. I hope that's the message that people
are getting. You're right in what you say earlier - you can visit
these sites and instantly get a grip on what's going on. (On the other
hand, 'eggs' and 'paste' and all of these other things, I still don't

Alright, I've stayed up way too late on this.
Jeff Shell
Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to