[Zope2-migration] New mailing list

[Paul Everitt]

On samedi, fév 1, 2003, at 21:43 Europe/Paris, Steve Alexander wrote:

> I'm going to play devil's advocate in this email. Don't take my 
> questions to imply my real opinions and needs wrt zope2 migration.

I'm not sure what to make of this.  If these aren't your opinions, and 
if they aren't the opinions of others, then there's not much to discuss?

>> But there is still a co-dependency between the two groups:
>
>> Zope 3 implementors desperately need people to write applications for
>> Zope 3, particularly in advance of the Zope 3 launch.  (Launching
>> with zero usable products will be pretty bad.)
>
> Why should that bother someone who is developing Zope 3 and intends
> using it for their own in-house purposes?

Because they want "Zope in general" to succeed?

If the core group is only scratching their own itches, we should put 
out the word to deployers: "Plan to stick with Zope 2 for a while until 
Zope 3 can scratch your itches."

The worst thing to do, IMO, is provide blanket statements of comfort 
that leave companies and developers in bad shape later on.  If certain 
things aren't likely to happen (and we should know, we're five months 
or so from feature freeze), then say so.

As an example: "If you are writing a CMF application today, when will 
you be able to do that on Zope 3?"

>> Zope 3 implementors also need more people participating in
>> implementing, so they need companies to support the effort and
>> contribute staff time.
>
> True. There are more ways to contribute than writing code.

>> Zope 3 deployers need an architecture that will last at least 3
>> years, and they need it to arrive pretty quickly.
>
> There won't be any Zope 3 deployers until Zope 3 arrives. I don't see
> how they need it to arrive quickly.

Because this "in-between" period is what hurts mature projects.  Zope 3 
was first publicly presented as something that might happen by Michel 
Pelletier at the Long Beach IPC 9 in Mar 2001:

   http://www.pault.com/X/983148775/984150194/984153960/984240636
   http://www.zope.org/Members/michel/Components.txt

Let's be generous and say that, although that was when the developer 
community realized a new architecture was coming, it wasn't the time 
that Zope 3 started.  Let's also say that the Beehive BBQ presentation 
doesn't count.  Instead, let's declare Zope 3 as publicly starting 
during during December of 2001, when Jim put out the first public call 
for a sprint.

The beta will arrive 1.5 years later.  I'll concede the point that 
there's no use in moaning, as it's just the way it is with volunteer 
efforts.  However, I hope others concede the point that long 
"in-between" periods place a disturbance in the force.  And IMO we need 
to understand the reality, communicate the reality, and seriously 
consider alternative approaches.  I.e. risk management.

For your needs, it is a problem that can be managed.  However, Zope 2 
is a mature project that is beginning to appeal to people in the 
mainstream.  I think a poor transition could have a negative effect in 
this part of Zopeland.

>> I'm not sure how this symbiotic practice works in practice, though.
>>  Obviously zope3-dev and #zope3-dev aren't ideal for discussions 
>> attractive to deployers.  I don't have any good suggestions on how 
>> deployers can influence implementation, unless they become
>> implementors.
>
> Deployers can start writing a non-critical application.
>
> * For the deployer, this increases their knowledge of zope 3.
>
> * For the implementors, this motivates work and design choices that
>   are informed by the needs of deployers.
>
> And, if the non-critical application is made openly available
>
> * Others can learn from the application, and build on it.

Right, this is indeed a good course of action.  But how realistic is 
it?  It's a course in which, in order for developers and deployers to 
communicate, the deployers must become Zope 3developers and meet the 
Zope 3 developers on their terms.

Maybe we could do something really crazy, like *ask* people what they 
need from Zope 3?  For instance, imagine a survey question:

   "List the top 5 factors in Zope that help you sell it.  List the top 
5 that make it hard."

The challenge, though, is what happens if we find out:

   Top 5 Needs of Deployers != Top 5 Interests of CA Developers

We might end up in a spot where, all things considered, deployers will 
stick with Zope 2 until Zope 3.3, when it catches up with and passes 
the maturity level of Zope 2 + CMF.  Some people won't change just for 
a new CA, if it doesn't do something they deem important.

Which would mean that the land of Zope will have a multi-year period 
(2001 -> 2004+) in which there are three architectures for developers 
to choose from: Zope 2, CMF, and Zope 3.

Like you, I'll caveat all this with a disclaimer: things aren't this 
gloomy, this is a hard problem and I also don't have silver bullets, 
etc.  However, this doesn't excuse us from the responsibility of 
managing this transition and the risks involved.  There's more to the 
transition than writing new code letting the chips fall where they may.

--Paul