Re: Zope3 name

Jim Fulton wrote:
> seb bacon wrote:
>> First (and what got me thinking about it again): was it appropriate to 
>> call the pre-New-Year-release  an 'alpha'?  On the one hand, I know 
>> Jim is keen to keep up the momentum among developers.  On the other, 
>> it suggests (to me) a level of maturity which the product has not yet 
>> reached, which could damage perceptions from the outside.
> 
> I'm puzzled and wondering what you thing "alpha" means. The term
> "alpha" in connection with a software release doesn't imply maturity
> or stabilities. The purpose of alphas is to give people early looks at
> where a product is going so that they can provide feedback in time to
> affect the product development.

To me, "alpha" is the first stab at a release.  It does not imply 
stability but it does imply a level of maturity.  To me, it is the end 
of the majority of development, and the beginning of testing. [1]

In truth, "alpha" is whatever you want it to mean.  Therefore, I contend 
that it is a dangerous label to use, because it will add to the 
confusion that many people clearly already have.

> The alpha was *very* clearly marked as early and not for production
> use.

True.  However, many people (read: anyone not already hacking on Zope 3) 
will simply note that there is an "alpha" release (without looking at 
it), and will assume a "beta" release and a "final" release are just 
round the corner.

>>  - It is entirely unclear that Zope3.0 will be ready before such a time
>>    that Zope 2.x runs out of minor version numbers and perhaps
>>    undergoes some major changes itself (what about the proposed
>>    back-ports of new Z3 functionality?)
> 
> I tried to make it clear that Zope 2 releases will continue beyond the
> advent of Zope 3.0.

You did make it clear.  I was just worrying about version numbers.  You 
state in another mail that we can use 2.10.x, etc, which I had 
overlooked.  (Though 1.10 always looks inferior to 1.9 to me, probably 
from years of conditioning of seeing numbers sorted alphanumerically in 
various listing contexts).

>>  - Zope3 will be so different for developers from 2.7, it seems
>>    confusing to make it sound like a major point change when it's
>>    actually a complete rewrite. 
> 
> Major point changes often are rewrites. The reason for selecting a major
> point change is to let people know that this is a really major revision.

See Paul's mail.  Zope 3 is a **major** rewrite.  People need 
convenient, meaningful labels to help them understand the implications 
of large changes.  A name change indicates a larger change than a major 
point change.  I believe that, for example, Mac OS9 -> OSX was intended 
to convey something like this.  It is a psychological (marketing?) trick 
to make people clearly understand that they are getting something new 
and better.

>>    People will go out and buy the "Zope
>>    Book" and find it completely irrelevant.  I would prefer Zope 3000 or
>>    Zope Component Server, for example.

> I'm sorry, but I don't see how gaving it a slightly different name is going
> to make any difference here.  I doubt that the Zope 2 books will be 
> completely
> irrelevent. We'll only know that when we get further along.  There will be
> Zope 3 books to replace the Zope 2 books. In any case, Zope 2 will be with
> us for some time and, thus, the Zope 2 books will remain relevent.

I am imagining someone in a shop in front of a bookshelf.  They know 
they have Zope 3 downloaded on their computer, but there are more books 
about Zope 2.  They hope that the Z2 books are relevant to Zope 3, so 
they buy them.  However, the Zope 2 books are not relevant to Zope 3.

How would a different name help?  Only marginally, admittedly.  Actually 
reading the introductions would make more difference.  But the fact that 
these two products are in many ways very different is underscored by the 
different names.  These small details help people feel comfortable.

Incidentally, we don't know that the crossover between 2 and 3 will be 
large or small, but I doubt that it will go beyond compatibility layers 
and a few backported features... or do you think otherwise?  I imagine 
that the 'Zen' of the two products will always remain very different.

>>    Having 3.0 suggests a replacement of
>>    2.7 to nervous users.  Why not have a name which does not apparently
>>    preclude parallel development?
> 
> I name doesn't preclude development.  A name has nothing to do with
> the level of development.

I think you are being too literal - you are thinking too much like a 
developer (unsurprisingly ;-), and not enough like a 'suit'.

*We* all know that the name has nothing to do with the development or 
quality of a product (hence my use of the word 'apparently.')  But if 
everyone thought like that, there would be no need for the advertising 
industry at all.  And everyone would buy the cheapest toothbrush, the 
one without the triple bend handle and the multi-angled, hand-finished 
bristles.

My propositions:

  - there is some confusion about Zope 3, despite your best efforts to
    clear things up
  - some of this confusion might be solved with some simple rebranding

If it were demonstrated that the majority of the Zope public (or even, 
just your customers) felt more comfortable with the next generation of 
Zope being called "Zope Component Server 1.0" (for *whatever* reason), 
would you still oppose such a move?

If not, there is a simple way of moving this issue forward.

If so, could you elucidate your reasons?

seb




[1] Googling for some other definitions of 'alpha stage', I think this
interpretation is fairly widely held. Here are the first two I found:

http://www.t3y.com/tangledwebs/tw0204.html
Once all the software's features had been implemented, the project moved 
into the alpha stage. This was the debugging stage, and only after all 
known severe bugs had been found and fixed would the project move onto 
beta testing. Yes, known bugs were fixed before the beta was released.

http://whatis.techtarget.com/definition/0,,sid9_gci211654,00.html
Originally, the term alpha test meant the first phase of testing in a 
software development process. The first phase includes unit testing, 
component testing, and system testing.