[Zope-CMF] Plone/Metadata/FUD

[alan runyan]

Quickly to recap what Erik is pissed about.

Many moons ago Plone was under the BSD license.  We were
going to develop it and then at some point release a non-opensource
product based on Plone.  Basically it would have had some client tools,
Visual workflow tools, a really neat user manager, and some
other things.  This was going to be "Enterprise Plone."  In
the same breadth of saying this I told mmmanager people
that no matter what the base Plone would always be opensource
and would be open for community contribution.  But there may be some
extensions that would not be opensourced, such as Enterprise
Plone components.  Opensource consulting companies have
alot of things they dont opensource - sometimes it just doesnt
make sense (it takes a lot of time to opensource components, ask
a ZC developer).  So as far as "telling the Plone developers" - I dont
think they care because anything I do to Plone would not endanger
their use of it. I see Plone as mere plumbing, like CMF/Zope.  It will
always be open, contributions will go back into the pot, and I think
all people who develop Plone respect me and understand that my
interests in Plone will not conflict with their interests.

Does Plone supplant the CMF?  Absolutely not.  As any of
the developers of Plone (most are very long time ZOPE developers)
would tell you Plone only adds to the base roux of CMF.  We
add the rice, sausage and spice trinity to make the Gumbo
known as Plone.  So I believe the energy Erik is expending
is certainly not proportional to the claims that Plone is
'forking' the CMF.  We build *on top* of CMFDefault,
which itself is meant to be a kind of 'simple implementation'
of the API.  It demonstrates the use of CMFCore.  So we are
doing, as I honestly feel - exactly what Zope Corp intended :
providing other implementations of CMF.

Why are we doing this?  we found that for our usability approaches
we need a lot more functionality than out-of-the-box CMF
provides.  We are willing to roll features developed in Plone
back into CMF, which I think is a very nice idea.  One of the
most obvious things I've seen that we have extended is how
we approach Workflow:

  CMFDefault has different pages depending on the workflow
transition.  This obviously will not scale.  If you have 100 transitions
in a large implementation you would need 100 templates.  We
extended the WorkflowTool and creates a mechanism so 1 template
would work for all of the possible tranisitions.  Why doesnt
CMFDefault do that?  because what CMFDefault gives you is
a reference implementation and it is suggested (by everyone at
Zope Corp) that you 're-implement' the skins/functionality to
your liking depending on your requirements.  This is exactly
what we have done.  And if we were "not participating" with
the CMF community we would have not written on top of the
CMF but in our own framework.  Then you may have an arguement.
But we have folded in the portal_calendar tool from Plone to
CMF (thanks to ChrisW and AndyD) and I would hope in the
future we could merge our Workflow changes into the CMFDefault
because I think its useful for all.  Also our implementation is more complex
(obviously... it does *more*) so it may not have a role in the world
of CMFDefault which is the simple-and-easy system to dig through
to wrap your mind around the tooling framework.

So I think I have demonstrated for the first and last time why Plone
is not a 'fork' of the CMF.  That we are working with the CMF developers
(note the changeSkin() method on the PortalObject in CVS) and are
doing things in a way they do not reject.  I am not interested
in pleasing everyone.  I am only interested in creating a fantastic end-user
experience that can be easily extended by Zope/Python programmers and
a install/configuration experience that is so simple - first timers can get
things working effortlessly.  I believe negative feedback is useless
feedback.
It should only be relayed as 'constructive criticism'.  Tell us exactly why
your experiencs were negative and suggest ways for us to help improve
the product.  Flaming is very unpythonic.  I just spent a week with people
who wrote CMS's in many languages and the flames were kept to a minimal.
Co-operation, tolerance, and communication are the only way the open-
source community can progress.

cheers,

~runyaga