[Zope-dev] the Zope Framework project

[Chris McDonough]

Martin Aspeli wrote:
>> IMO, we should just try to solve problems we actually have under whatever brand
>> the problem seems to fit under best that *doesn't* have the baggage of the Zope
>> name.  We have a good number of brands now (grok, repoze, plone).  These brands
>> *do* have leadership and structure and forward momentum.  Let's use it.
> 
> I don't think the confusion around Zope 3, the Zope framework and the 
> consumers that happen to use zope.* packages is going to go away just 
> because we ignore it. I totally agree with your pragmatic approach, but 
> that's something quite different.
> 
> Zope *is* a project. There's enough activity on this list and enough 
> people who commit to svn.zope.org that you can't argue otherwise. 

I agree that by historical accident, we all use some set of software related to
the name "Zope".  However, at this point, this is a *problem*.  The Zope brand
is too diluted to have any meaning whatsoever.  There is no consensus for change
direction because no one knows what anybody else is talking about whenever the
word is mentioned.

Martijn's proposal suggests creating a term the "Zope Framework" which
essentially means all software that currently makes up Zope 3 plus related bits.
 While its meaning is smaller than the word "Zope", IMO it is just too large and
undirected too.  There's no set of people smaller than the entire community that
can pretend to understand all the software.  Additionally, no one person cares
about *all* of the software.  Most of us care deeply about only small parts of
it.  I'd be unable to serve on a steering group dedicated to "the Zope
Framework" because I just don't care about 95% of the software; my steering
capability for that 95% would be quite poor.  OTOH, I think I'd be pretty good
at steering the other 5% if I could not have to worry about the 95%.

Trying to bind all of these bits of software together into some unified whole
controlled by some central entity is exactly what needs to *not* happen.
Instead, the individual packages need to be blown up and set free.  The smaller
parts need to be managed and morphed as standalone projects, which will live or
die on their own merit, managed by people who care about them.

It's my belief that trying to do this under the "Zope" brand is not going to
work in part because it presumes that everything with "Zope" in the name is of
equal importance to everything else with "Zope" in the name; this just isn't
true.  The most reusable and important bits of Zope (the component architecture,
the interfaces stuff, ZODB, the catalog stuff) are orders of magnitude more
important than other stuff in SVN or in any Zope release.

- C