Re: New mailing list

>> 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?

Although I agree with the assertions you made, I couldn't see what you 
added up to make the assertions. I asked the questions to expose the 
reasoning that links what we know or expect about people's motivations 
to the assertions.


>>> 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?

This reminds me of discussion about Linux. People developing linux for 
embedded applications don't much care about Linux on the desktop.

However, if there is more use of Linux in general, that's good for all 
users and developers of Linux.

So, you can perhaps persuade an 'embedded linux' developer that linux on 
the desktop is of some importance to them.

Is there any similarity to the Zope 2 / CMF / Zope 3 situation here?


> 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."

No-one should choose Zope 3 over Zope 2 until the risk to them of doing 
so is outweighed by the benefits to them of doing so.

A few examples of how I'd look at such decisions.

* A small application made to familiarise oneself with Zope 3 that is
   not for a client or on a particular deadline.
   On Zope 3: No risk, some benefit in learning.
   On Zope 2: impossible.
   Use Zope 3.

* A content management application of medium complexity, to be completed
   for a client within 3 months.
   On Zope 3: Very high risk. Perhaps some benefit in cleaner code.
   On Zope 2: Known medium risk.
   Use Zope 2.

* An application that needs to take advantage of customisation of
   individual instances on the same server, that is not suited to the
   CMF, to be delivered in 6-9 months.
   On Zope 3: Medium risk. Great benefit. This is the kind of stuff
              zope 3 is designed for. It will be ready for this in time.
   On Zope 2: Medium risk. You have to roll your own customisation
              facilities, but do so inside the constraints of Zope 2's
              less flexible framework.
   Seriously consider using Zope 3.

* A new novel capability for web applications, to be delivered in 6
   months. For example, web services support, to support applications
   not CMF style content management.
   On Zope 3: High risk. Great benefit. The architecture is designed to
              plug in different protocols.
   On Zope 2: Very high risk. You might end up with something that
              patches Zope 2 very heavily, but is not accepted into the
              core distribution.
   Or, if you don't need other parts of Zope, consider using Twisted.


Imagine a wiki page with a list of a few kinds of application, and an 
estimate (that's updated every month or two) of when the risk of 
undertaking such an application with Zope 3 should be approximately the 
same as undertaking it with Zope 2.


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

That sounds reasonable.


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

That's a good question. To answer it, I'd need to know a lot more about 
what kinds of requirement a 'CMF application' can meet out of the box.

I don't know a whole lot about the CMF.


[On awkward in-between periods]
> 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.

Ok.


[On my suggestion of deployers building their own example application]

> Right, this is indeed a good course of action.  But how realistic is 
> it?

It isn't risky. It is somewhat costly in terms of time taken to do it.
It is the course where a deployer starts taking responsibility for their 
own decision of what technology to use.


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

People learn best by doing :-)


> 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."

I'm a bit confused here. Is a deployer selling Zope or is a deployer 
selling their solution to their client's problem?

Nevertheless, I'd be interested to hear answers to the question you 
suggest. Expecially if the answers aren't just the reasons, but explain 
why the reasons are so.


> The challenge, though, is what happens if we find out:
> 
>   Top 5 Needs of Deployers != Top 5 Interests of CA Developers

I can think of two remedies to such a situation. Neither of them may be 
attractive to deployers, though.

1: Deployers become developers, and take their needs as deployers across 
as interests as developers.

2: Deployers fund developers to develop the things that they need.


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

That would be entirely appropriate.


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

That's stretching it. No-one is suggesting that a deployer use Zope 3 
right now. So, that's 2003-2004+. A Zope3 beta is planned several months 
from now, so that becomes 2003+ - 2004+.


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

As individuals with our desires of particular outcomes and benefits, the 
market seems cruel. Everyone is scratching their own itch, acting for 
their own benefit, and the net result has unexpected consequenses.

--
Steve Alexander