[Zope-dev] the Zope Framework project

[Martijn Faassen]

Hi there,

Chris McDonough wrote:
[snip]
> I'm pretty sure a steering group and a rebranding of existing software is not
> going to make us more effective. 

I'm proposing a deconstruction, not a rebranding; a new name is 
introduced as an entity needs to be named, namely the Zope Framework.

What is going to make us more effective is:

* a recognition of current reality, i.e. the Zope Framework is not the 
same as the Zope 3 application server and it serves a far wider audience.

* leadership

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

Who is going to make that decision to encourage this? Allow this? You? 
Me? Who? Right now, *nobody* is making such decisions and nobody can 
properly get away with saying they allow it. Leadership is a way to get 
out of it.

> - discourage the contribution of stop energy (discourage
>   the utterances of "don't", "stop", "this is wrong",
>   "stop talking about this").

+1, though a simple discouraging of utterance can't accomplish it by 
itself. What you need is active leadership that encourages such 
experimentation.

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

Sure, I agree with all this. Does everybody? What if we get 3 times -1 
and 3 times +1 in a discussion on it?

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

Someone's still developing all this software: our community. Someone 
needs to take responsibility for all this software. I'd say that group 
is the Zope project.

Who decides to kill something off? Who decides whether a merge is okay? 
Who decides we should have a documentation website for a widely used 
component.

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

If you don't have a list of "known good" versions you don't know what to 
test together, unless you maintain a separate list for each library, 
which would require a lot of coordination overhead which a single list 
does not.

If you say we shouldn't maintain a known good set, then other systems 
building on top of this will need to maintain their independent lists 
all by themselves, and there's less chance that Zope 2's, Zope 3's and 
Grok's list will agree. I think such an agreement is a good idea.

Just because *you* tend to use a few selective libraries for your own 
efforts doesn't mean everybody else is. I think we should definitely 
support your use case, but not only your use case. A steering group 
would be aware of these use cases and balance them.

Regards,

Martijn