Martijn Faassen wrote:
> The Zope Framework project
> :Author: Martijn Faassen
> :Date: 2009-03-02
> This document offers suggestions to reorganize our community so we can
> act more effectively. It does this by trying to clarify what our
> community is about. The document tries to innovate minimally in
> concepts and naming in order to provide a relatively small
> evolutionary step forward that can still make us all work together
> better. Even though this is an evolutionary step, it will still have a
> big impact if implemented, so please read on.
> This document should be relevant to *all* the parts of our community
> that build web applications, whether they use Zope 2, Zope 3, Grok,
> Repoze, or applications built on top of these such as Plone or
> Silva. While it talks a lot about Zope 3 this is because the Zope
> technology within Zope 3 is used within all these projects. The
> document wants to recognize this officially.
> The main innovations in concepts are the name "Zope Framework" to
> distinguish it from the Zope 3 application server and the
> "core"/"extra" concept. These are all hopefully descriptions of what
> are current practices, simply making them more explicit.
> The biggest innovation is the introduction of a Zope Framework
> Steering Group as a new entity that will be the steward for the
> development of this framework. The steering group's primary aim is to
> facilitate developers in the community so that they can continue to
> maintain and develop the framework so that it is useful to all of us.
I'm pretty sure a steering group and a rebranding of existing software is not
going to make us more effective. Here's what I believe would make us more
- encouraging radical change for experimentation purposes, releasing folks from
various constraints (backwards compatibility, style policing, historical
- discourage the contribution of stop energy (discourage
the utterances of "don't", "stop", "this is wrong",
"stop talking about this").
- focusing on externalizing software; each egg should stand on its own as
something that a non-Zope person would be able to understand and use
in isolation. This means documentation for each thing, as well as
a sane dependency graph. This is *less* about giving this collection
of software a group name ("the zope framework") and more about
making people *forget* that it is a part of some larger thing. When
a piece of software does not have a purpose in isolation but still
lives in its own egg, kill it off and merge it back into whatever
thing its most closely related to.
- Stop trying to version control and treat all this software in some
overall release. Let each piece of software have its own life. Likewise
if a piece of software does not have its own life, kill it.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -