[Zope-dev] the Zope Framework project

[Chris McDonough]

Martijn Faassen wrote:
> The Zope Framework project
> ==========================
> 
> :Author: Martijn Faassen
> :Date: 2009-03-02
> 
> Introduction
> ------------
> 
> 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
effective:

- encouraging radical change for experimentation purposes, releasing folks from
  various constraints (backwards compatibility, style policing, historical
  ownership)

- 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.

- C