[ZWeb] Zope.org and New zope.org status

[Paul Everitt]

On Thursday, Jan 9, 2003, at 16:19 Europe/Paris, Guido van Rossum wrote:

> [Paul E]
>> Are both Jeffrey and Sidnei going to work on the migration throughout
>> 2003?  I expect the launch date to be just the beginning of a bunch of
>> content-related and software-related work.
>>
>> Stated differently, how many dedicated manhours are there after the
>> launch date?
>
> Jeffrey is hired indefinitely.  Sidnei is working on a fixed budget
> with a fixed horizon (the sixth milestone alluded to in his report).
> Beyond that, we'll have to play it by ear.  I promise I'll be all ears
> (but I tend not to hear whining :-).

Don't worry, I won't whine without counterproposals *and* volunteering. 
  So, on to the whining. :^)

Last year I expressed the following concern: if the current situation 
is bad, a half-baked migration is worse.  IMO, there will be lots of 
urgent and semi-urgent work after Day One.  Significant resources will 
be needed.

It sounds like the amount to count on is 5-10 hours per week.  Not a 
lot.  We're doing a lot of content mangling in the migration (e.g. DTML 
isn't allowed anymore, new content types, etc.), so I expect there will 
be over 10 hours per week needed *just on content migration*.

I suggest that the "skin" discussed in your status note will be a lot 
of work in the weeks/months after launch.

So, to shift from whining to *proposing*.

I think it's critical to look for ways to lessen the commitment and tap 
into extra manpower.  Thus, I propose that nzo use Plone, for the 
following reasons:

1) They've already done a lot of cross-browser work.  IMO, anybody that 
says cross-browser UI styling is someone not responsible for actually 
doing it. :^)

2) The Plone community will continue doing such work going forward.  
How much improvement will go into NZO after the launch?

3) If you compare the size of the Plone community to the nzo 
community... :^)

4) Plone is built on CMF already, as is nzo.

5) Geez, they're a great Zope success story for Zope, it makes sense to 
collaborate with them and show confidence in what they're doing.  If 
not, NIH rears it's head.

6) Plone can accomodate different looks and styles, so we could keep 
the nzo look (which, ironically, came from Plone).

As an example, Andy recently migrated ZopeZen from his own Zope 
software to Plone, and it doesn't look anything like plone.org.  
ZopeZen is arguably the second most important site in the community.  
If Andy can migrate to Plone, I think zope.org can seriously consider 
it.

7) We could take the content objects for nzo and put them in the 
Collective, so they won't (hopefully) languish.

7) With Plone, a better nzo can arrive sooner (obviously a subjective 
statement).

Downsides:

1) We introduce a dependency on non-core software.  (BTW, will nzo will 
use anything from the community?)

2) Some people don't like Plone.  Like with CMF, it's hard to pin down 
the reasons.

3) People claim Plone has a performance penalty.  Not as much as the 
claimed penalty of CMF (which is being used for nzo), but a claimed 
penalty nonetheless.  I don't think there are numbers, unfortunately.  
Maybe we could ask Andy.

In summary, given constrained resources, I think the path of least 
effort and most ROI runs through Plone.  And such a choice will 
demonstrate that zope.org is open to working with the Zope community.

On to the volunteering...A call-to-arms in the Plone community might 
turn nzo from its current status into something we're proud of.  I'm 
personally willing to participate and contribute hours.  We were making 
pretty good progress working together last spring, it could happen 
again.

What do other folks think?

--Paul