[Zope-dev] the Zope Framework project

[Martin Aspeli]

Chris McDonough wrote:

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

First of all, I'm not sure what Martijn is saying is necessarily in 
dichotomy with what you're saying, so we may be going off-topic here.

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

<snip>


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

As a consumer of various bits of the Zope Framework, I'd be pretty 
troubled if no-one were to care about backward compatibility or testing 
a known-good set (what we now call a "release") of things that are known 
to work together. To have to do that myself (or ourselves, in the Plone 
project) would be a substantial overhead; if we were concerned that 
backwards compatibility would be ignored, we would have serious concerns 
about adopting any piece of software coming out of the project.

Realistically, there's a release and management overhead that leads to 
some kind of economy of scale. zope.* is a big namespace. Managing at 
least some chunks of that namespace as a single unit will likely be 
beneficial, in terms of getting consensus around evolution, instilling 
some energy in people and setting goals to get things done, in terms of 
making releases and managing expectations, and so on.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book