[Zope-CMF] Plone/Metadata/FUD

[Erik Lange]

At 05:11 AM 10/2/02, Paul Everitt wrote:

>On mercredi, oct 2, 2002, at 03:09 Europe/Paris, hazmat wrote:
>
>[snip]
>>these aren't forks they are progressively layerd systems that build
>>functionality that users and developers can avail themselves of. ie
>>Zope->CMFCore->CMFDefault->Plone.
>
>This point about layering is very important.

Very, very important...


>>also i'd like to note that this conversation has been mostly civil (with one
>>noteable exception), of which i'm glad, please lets keep it that way.
>
>Well said, Kapil, the voice of moderation! :^)

:-)


>Here's my two eurocents on the Plone/CMF discussion.
>
>a. Zope is a framework for web applications and CMF is a framework for 
>content management.  Neither claim nor aim to be end-user products.
>Plone does, and should thus have its own identity.  This is even more 
>important for Zope 3.

Yes :-)

So people shouldn't be given the impression that they can use standard 
CMF-products in Plone... just as some CMF1.3 products probably won't work 
with Zope 3 - and as CMF 1.2 have to be re-written to work in CMF1-3...

If People want to use other CMF-products, they shouldn't build on top of 
Plone, but on CMF... or wait for the CMF-products are being re-implemented 
in Plone.

This is where people get's stucked; Plone gives the impression that itworks 
out-of-the-box with any CMF-products, so people installe Plone and then 
they installs the extra products they want - and then when it doesn't work, 
Plone's answaer is "we're working on re-implementing that product to work 
with Plone - or maybe we'll port Plone back to CMF, so the developers of 
that product should change it themselves to make it work in Plone..."

The result is that the user is stuck in the middle...

Hmm... it strikes me now - Plone at it's present state is much like women; 
you can't live with them, and can't live without them ;-)

>b. IMO, Plone is as much a fork of CMF as CMF is a fork of Zope.
>Stated differently, Plone is as incompatible with the CMF as the CMF is 
>incompatible with Zope.

Right :-)

As many Zope-products must be re-written to work in the CMF - many 
CMF-products must be re-written to work "correctly" in Plone.

And according to Chris' experience with the calendar, Plone-products have 
to be re-written, to work with CMF... and that's not the right way to do 
it, IMHO.

>c. I've spent a lot of time with Alex and Alan (in person, on the phone, 
>in IRC, email, etc.) and I don't think they are misleading anyone.  Others 
>might have better evidence or different interpretations, so understand I'm 
>just giving a personal opinion.

I'm not saying it's intentionally - I'm just saying that many new users 
_feels_ mislead, as Plone is promoted as a standard CMF-product and not as 
an alternative CMF implementation - which it is according to both me and 
Alan's ealier posts on this.

It's a brilliant alternative CMF-implementation - but that's beside the 
point ;-)

>Plone is an actively developed end-user product built on the CMF.  This is 
>a good thing.  It's also free, as in beer and speech.

Haha - is a beer free ? I usually pays for my beers, and have no problem 
with that ;-)

I will have no problem with having to pay for Plone, as I wouldn't need it, 
but I would have a problem paying for CMF... or "CMF-add ons", that are 
really Plone add-ons.

>Also a good thing.  There is already one for-fee packaging of Plone, and 
>hopefully more to follow.  More good things.

I agree :-)

But  good things shouldn't change other good things - just because they are 
good for some... good is a concept that could be used for many things, 
unless we narrows down our definition of "good" to equal Plone ;-)

>A recently-recommended book says "[m]ost conflicts are based in differing 
>interpretations of the facts."  We should step back from heavy artillery 
>and find out how the situation can be improved for all our viewpoints.

I agree :-)

Regards,
Erik