[Zope-dev] the Zope Framework project

[Hermann Himmelbauer]

Am Montag 02 März 2009 18:11:59 schrieb 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)

No, I really disagree with that. In my opinion. To my mind, the problems of 
Zope 3 do not come from too few "radical ideas" but from the fact, that many 
components are simply not yet finished and documented.

Building something new is for sure interesting, experimenting can and will be 
enlightening, but what we need is a very stable base.

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

People like me, who build long-term projects, need to rely on a continuous 
development process. What I really don't want, is to overwork my whole code 
every half year in order to be able to upgrade to the current Zope 3 release.

I very much appreciate some sandbox-idea, where people can branch and 
experiment. But I think we miss so often the point, that Zope 3 technology is 
hard for newcomers (maybe different with Grok): The newbie (or, let's say the 
PHP-Junkie) is confronted with entirely new concepts:

- buildout (KGS)
- component architecture
- object database

... and much more. And there is no clear entry point to learn all that, so the 
user is really overwhelmed. And later on he may realize that various features 
are still absent in Zope 3 (e.g. session management via URLs etc.), or, what 
also happens quite often - he just does not find what he needs as some 
functionality is in some unknown lovely/z3c/zc/other package.

I think a key elelement in a project that decides over success/failure is the 
growth of its user base. So my suggestion is to really look closely what can 
be done in this area instead on focussing on radical architecture changes. 

Martijn's document, which tries to clear things up, is a good start in this 
area, I think.

Best Regards,
Hermann

-- 
hermann at qwer.tk
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7