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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )