Re: What I think we should focus on now

I completely agree with your comments. Mainly the part about fragmenting 
the community ... -- I'd just like to focus on actually getting things 
done rather than only discussing the problems. If the core developers 
around Jim get communicated that forward compatibility tools are what 
we'd like to see, they can focus on that.

I understand the mission of this list as to define what migration tools 
(and concepts) we need, so that the developers can work on them.

Joachim

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


-- 

iuveno AG

Joachim Werner

_________________

Wittelsbacherstr. 23b
90475 Nürnberg

[email protected]
www.iuveno.de

Tel.: +49 (0) 911/ 9 88 39 84