[ZWeb] NZO pre-alpha Announcement and Call for volunteers

[Jeffrey P Shell]

On Sunday, February 16, 2003, at 01:57  AM, Erik Lange wrote:
>> But CMF == Zope.org.  :)  That's what it is.  If it weren't for the 
>> current Zope.org, the PTK venture wouldn't have been launched, which 
>> became CMF.  It all stemmed from a "Zope.org in a box" concept.
>>
>> Plone is CMF.
>
> Hmm... everytime it comes up, that Plone does it's stuff different 
> than CMF Default, people are  screaming "CMF Default != CMF". CMF 
> Default is an implementation of the CMF, and so is Plone.
>
> It looks like you're now saying, that Plone = CMF ? Well, then CMF 
> Default must also = CMF ?

It's as much CMF as anything else built with the CMF.  But you're 
right, in a sense, it's not the framework but an implementation based 
on that framework.  Personally, I don't care much for CMFDefault at all 
- it gets in my way more than it helps me.  I think this is because 
most of my content management jobs have different requirements than 
CMFDefault OR Plone provide.

> But will the CMF Default be discontinued ?

Why should it be?  I think it should only be discontinued *if* no 
default is provided at all.  However, Plone uses CMFDefault - Plone 
doesn't provide any new content objects, it augments the functionality 
of CMFDefault by providing better skins than CMFDefault provides (and 
some replacement and new Tools - but it doesn't deliver an outstanding 
issue tracker, or compound documents, or a shockingly different 
workflow).

>> ZopeZen is CMF.  bridgerlandliteracy.org is CMF (and doesn't look 
>> like it at ALL, I'm proud to say.  Now if only it had some 
>> content...).  More than that - they're all Zope.
>
> I'm _not_ talking about the look :-)
>
> I'm talking about the underlaying machinery... I find the Plone-look 
> very nice, and we're using it for our sites - but we have stripped it 
> for all underlaying Plone-functionallity.
>
>> What would have been odd is if NZO had been implemented with 
>> SkunkWeb, Webware, or even more bizarre - PostNuke.
>
> Now, that would have been very, very bizarre... but that's also not 
> what I'm talking about ;-)
>
>> So I don't understand how you can say that Plone has chosen a 
>> different path for implementing CMF.
>
> Andy McKay just wrote that the other day...
>
>> It manages content, right?  It uses CMFCore and CMFDefault (for 
>> better or worse), right?  It's *exactly* the CMF.
>
> Hmm.. I'm more for the way Robert Rottermann says it:
>
> "I consider CMF to be a toolset one can build a CMS from.
> Plone IS a CMS"

That's right.  It's all on how one sees it.  I've always seen 
CMFDefault as part of the CMF (again again - for better or for worse 
;), it's all part of the same mudpile to me.  Most of the time when 
people talk about CMF, they seem to be talking about CMFDefault more 
than CMFCore - which is understandable, because CMFDefault is what you 
see "fresh out of the box".  By my own twisted logic, Plone just makes 
the mudpile bigger.  So, different perspectives here.

> Personally I believe there a many tools that could be great to have on 
> NZO - CMFPortlets for one - and believe that it would be more flexible 
> to build NZO from a selection of tools from the community, rather than 
> replacing the toolbox with an alternative one.

We also need to get this thing done.  We were joking about how long NZO 
was taking before I left Zope Corporation - and that was summer of 
2001.  It's now a year and a half later.  Personally, I'd be happy if 
Zope.org were to stay as it is now.  It would make my current job 
requirements more clear - "clean it up, keep making it better" instead 
of "clean it up, make it bearable until the new solution kicks in".  
But the software is living beyond its maintainability point.

>> The experiences gained by implementing and managing such a site 
>> ultimately became the CMF suite - the core framework, which can be 
>> used (with a fair bit of effort, but it's worth it) to build many 
>> different types of sites; a basic default implementation of a site 
>> using that framework; other useful basic products.  It had always 
>> been hoped that the community would come up with and share new 
>> products and skins for the CMF, and that's exactly what Plone is.
>
> Well, Plone is much more :-)
>
> Plone alteres the "toolbox" and the tools you have in it.
>
> Plone does a good job!
>
> But I agree with Aussum, when he says it's too early to start throwing 
> out tools of the toolbox:
>
> "But, is the whole community (or ZC ) willing to endorse a software 
> that -in
> Robert's words- "(is not) only a bunch of skins you can take or  
> leave" but
> rather something that "does alter the way how things are done rather
> profoundly", thus forcing to take the decision to "build a site (using)
> plone only or not use it at all"?.  I'm one who says "I don't think 
> so".
> Experience has taught that any enterprise will need to custom-develop 
> the
> sooner than it would've wanted or expected, so there's no reason to let
> people believe that Zope and CMF is all about an
> eight-apartment-four-stories building that you can convert to four 
> duplexes
> by just removing some floors. We should be crystal clear at stating to
> people "you can build your duplexes from scratch, using the best of 
> breed
> of our smart machinery and framework. We did that with our own portal".
>
> My personal and humble belief is that as a community oriented to 
> content
> management, there's a lot of work to be done (in the CMS framework
> territory) before we can say "this is the way to go" regarding an 
> end-user
> experience."

I don't even think there is a single "way to go" regarding an end user 
experience.  All I know is that this project's delays have been a joke 
for far too long now.

>> So if it's open source, built on Zope, and built on the CMF, and as a 
>> result offers all of the community features required by a site like 
>> Zope.org (which of course it gets because Zope.org started the whole 
>> thing in the first place), why would it not be good enough to use?
>
> It's fine !
>
> That's not it - but is it the only way to build CMF portals in the 
> future?
>
> I don't understand why people gets so angry, everytime I mention that 
> it's not the only way you can implement the CMF and build portals.

I'm not saying that it is the only way.  But I am saying that a way has 
to be chosen.  "Whatever you do it's evil for somebody".  At some 
point, a choice has to be made and stuck with by those who ultimately 
have to develop, support, and maintain the project.

If we use Plone, people get mad.  If we don't use it, people get mad.

> Am I a bad person, because I don't use Plone?

I don't use it either.  We started using it for an intranet project, 
but it was too slow.  It lingers as a place to hold documents and such, 
but the heavy project work has moved on to Roundup.

> Why all this hostillity against not-Plone-users?

Why this hostility towards them?

The fear, as I understand it (because I feel it too) is that Plone may 
replace the CMF/CMFDefault package and make things harder for all of us 
who don't want to use it.  I've whined many times about how hard it is 
to make the CMF do non-CMFDefault behavior.  It's almost too much work 
for very small shops and teams.  I would not like to see an even more 
complete and focused product be what I have to start from.

But at the same time, Plone's goals are aligned with NZO's goals more 
than any other product/toolset out there for Zope, and it's more 
complete as far as immediate usability goes.

>> These are my own (slightly hungover) opinions.  And I should state 
>> that I'm not a Plone advocate per se - I doubt it will be used in any 
>> of my consulting contracts in the near future, as it doesn't fit the 
>> bill of what most of my customers need.
>
> We agree here :-)
>
>> But if it works for this situation, and works well, then why not use 
>> it?
>
> As Aussum said:
>
> "...unfortunately nzo's
> technology adoptions will be a reference point of what Zope and its 
> Content
> Management Framework is, and therefore will act as an endorsement of 
> the
> whole community (or at least ZC's on behalf of it) to the design 
> decisions
> of its developers."
>
> So NZO has another role to play, besiddes just being a cool site - it 
> also has to be the visible reference-implementation of CMF. Plone is 
> not such a reference, as Plone has chosen to do a lot af things 
> different than the Default implementation - unless ofcourse, the CMF 
> Default is beeing discontinued in favor for Plone.
>
> On the other hand, CMF Default wouldn't do the job alone, but with a 
> nice skin (could be a Plone-look-a-like) and CMF Portlets, I think one 
> could make a very decent site, using the rules of CMF Core and > Default.
>
> By not chosing to do so, it sends a signal that Plone is _the_ way to 
> go, for everybody who's building a CMF based portal - and as you have 
> experienced yourself, it's not always like that...



>>> Has the Plone-community voluntered to support NZO in the future, or 
>>> has Zope corporation also chosen Plone as a new standard for CMF 
>>> implementations ?
>>
>> Why does this matter?  It's open source.  Has Zope Corporation or the 
>> Zope community personally volunteered to support all of the web sites 
>> that my company deploys on Zope?  There is intrinsic support supplied 
>> by the open source community, that should be good enough.
>
> Guido said:
>
> "The reason why Zope Corp is not super-keen on having the site run on
> Plone is one of support.  Once Sidnei has delivered the site and is
> retired, when the site dies at 3am, whose beeper goes off?  Not mine,
> but that of some poor schmuck of a Zope Corp sysadmin, who will
> attempt to fix the problem.  When there's a problem with the Zope
> software that he can't solve on his own, who gets called at 4am?  Not
> me, but someone else at Zope Corp who knows a lot about Zope.  This
> guy doesn't know anything about Plone, but he knows CMF.  If (God
> forbid) the problem is caused by something that Plone does differently
> than CMF, he's stuck.

Since the CMF is so open ended as far as implementation possibilities, 
and so much more complex than Zope anyways, I think any solution found 
would run into these same problems.  I dare anybody at Zope Corp (or 
contracted by them) to raise their hands and say they understand the 
current Zope.org implementation.  Most of the primary developers of the 
site have moved on to other jobs now.  So whether its an in-house 
solution, or Plone, or whatnot, this is a known risk.  So all I'm 
saying here is that with or without Plone, this situation is likely to 
occur no matter what.

[SNIP]

(Snipped because almost everything entered up to here was a day ago, 
and I have too much else to do today ;).