[Zope2-migration] What I think we should focus on now

[Paul Everitt]

On Thursday, Feb 13, 2003, at 12:42 Europe/Paris, Joachim Werner wrote:

> Hi!
>
> I agree with Paul tha twe should learn from ArsDigita. But there 
> really is no need to be pessimistic.

Correct.  Instead, we need to do an honest analysis of the risks.  We 
don't, IMO, need to label such discussions as "pessimism".

> We don't have a problem with the product, only with naming and selling 
> it.

This is an opinion that is shared by some.  I've tried to articulate 
some of the points that I think are substance, rather than 
naming/selling.  I think the challenges of substance I've outlined can 
be, for the most part, addressed (and are already being addressed with 
Jim's notes).

Simply saying "we don't have a problem" is wrong, IMO.

> Zope 2 is not perfect, and a rewrite makes sense. But still Zope 2 is 
> a very good product. I'd compare it with Apache 1 vs. 2, not with the 
> ACS. This fits better.

Personally, I agree with you.  However, the personality profile of the 
"larger group", the ones that haven't drunk the kool-aid, might see 
things differently.

> We want Zope 3 soon because it will be better than Zope 2, and at the 
> same time we don't want the wrong people to get in contact with Zope 3 
> too early.

Well said.

> So we should focus on the RIGHT people, the people that can help with 
> Zope 3 development, but understand the limitations. As I've pinted out 
> at least twice on this list, I think the key to get those people 
> involved is FORWARD COMPATIBILITY, so they can write add-ons to Zope 2 
> that work with Zope 3 more or less unchanged.

I 100% agree.  I brought this up on #zope3-dev, but let's just say it 
didn't get a rousing response. :^)  (However, Jim wasn't there during 
the discussion).

If this paragraph of yours landed, and if some important pieces of Zope 
3 (e.g. zcml or the new zpt syntax for probing the request) were 
backported, then I'd feel much less nervous about the depth of the step 
function.

> This will, automatically, reduce the problems with Zope 3 having not 
> enough modules to start with etc.

Right.  And it will help address a big worry of mine.  The number of 
quality Zope add-ons is still not as big as it should be.  When we 
split energy across three architectures (Zope 2, CMF, and Zope 3), this 
will worsen.

If a developer can write important parts of his code in a way that is 
more future-proof, then that's a little more realistic demand on the 
world of Zope developers.

> I've also mentioned before that I don't think that there are too many 
> add-ons people really need to be ported. Most of the add-ons can be 
> replaced by something different that does the same job. E.g. nobody 
> really needs Squishdot. People could also live with getting the same 
> features as part of a Plone for Zope 3 package ...

Saying we don't need Squishdot doesn't magically produce it's 
replacement.  Splitting energy across three architectures might lead to 
fewer solutions for the different audiences.  This is a fairly common 
lesson learned from the world of x-platform products.

--Paul