[Zope-dev] Principles

[Martijn Faassen]

Hi there,

Geoff Davis wrote:
> I am very glad to see that Jim's efforts to better articulate a vision for
> Zope have generated so much interest.  I am not so sure that the
> discussion has been an entirely productive one.  
> 
> I think that we as a community would benefit by working on our social
> engineering as much as our software engineering.

Heh. Yeah. :)

[snip]
> One of the things that GTY recommends is to establish a set of agreed upon
> principles for evaluating proposals.  I think that having such a set of
> principles would help us better focus our current discussion.

Agreed.

> Let's take a step back from the particulars of the various proposals
> floating around and see if we can nail down some principles.  Here is a
> very rough, very incomplete start:

One thing about these principles is weight. Even if we all agree, some 
may think one principle is more important than another. Should one 
principle be able to trump another one?

> 1. Zope should have a clear message about where we are going.
> 
> I'm sure we all agree on this, but this is so broad that it is not very
> useful.  Here's a stab at refining it:
> 
> 1.1 We should have a clear message about where Zope 2 is going. The
> message should give existing and prospective Zope 2 users an idea of how
> long their code will continue to work on releases in the Zope 2 path and
> what kind of upgrade process they will face as the Zope 2 line evolves.
> 
> 1.2 Ditto for Zope 3.

+1

> 2. Zope should try to expand its developer base.
> 
> Again, I am sure we all agree, but this is too broad to be useful.

> 2.1  Zope should leverage the work of others by moving toward an
> architecture that allows one to easily use code from outside Zope.

+1

> This effectively increases the developer base by letting us leverage the
> work of others outside the immediate Zope community.  I assume that this
> (and integration) are the primary motivations driving the CA.

I don't think that's the only motivation driving the CA. A very 
important motivation of the CA in my book is extensibility and 
evolution. Using the CA makes it easier to evolve existing codebases by 
extending them in all kinds of ways.

> 2.2  Zope should be useful for developers not using the full application
> server stack.

 > Again, this serves to increase our developer base by drawing in people
 > outside our traditional core audience.

+1

I'll add a few related principles that have a different perspective:

* Zope should aim not to reinvent the wheel. Instead we should leverage 
code outside of Zope in Zope itself.

* Zope should play friendly with the Python community

   * We want to engage the Python community and use Python community 
code, engaging in non-zope communities.

   * We want the Python community to use more code spun off Zope, and 
have them engage into our community.

And one more that came up a lot:

* We want to cater better to a set of developers left in the cold by Zope 3.

> We probably need some principles about the Zope brand, and so on, but I
> think this should serve as a useful starting point.

* We want the strengthen the brand of our software.

   * of the software we call Zope 2

   * of the software we call Zope 3

   * of the components that Zope 3 is composed of

* We want to strengthen the brand named Zope.

   * the Zope 2 brand.

   * the Zope 3 brand.

   * the Zope without 2 or 3 brand.

* We want to use the strengths of the Zope brand in our communication.

   * We want to capitalize on technical strengths.

   * We want to capitalize experience and maturity.

   * Extended CMS features.

* We want to counter the weaknesses of the Zope brand.

   * We want to counter the crufty, overly complex reputation that Zope 
has in the Python community.

   * We want to counter the reputation in the Python community that Zope 
is off on its own.

* We want to avoid the weaknesses of the Zope brand.

   * In particular, the cruftly, overly complex reputation that Zope has 
in the Python community.

* We don't want to weaken the Zope brand.

   * We don't want to give the impression we promise features that we end
     up not delivering.

   * We don't want to give the impression we promise features soon that
     we end up delivering only very much later.

Note that these principles can all lead to quite different conclusions, 
but it's indeed good to articulate them.

> Let's see if we can expand and refine these principles before going down
> the "vision" road.  I think that we will find that once we have
> articulated a set of core principles, defining a vision that adheres to
> them will be much easier.

Very good initiative! I'll leave it up to you Geoff to see whether you 
want to adopt some of the principles I listed in a larger document and 
give them a canonical number.

Regards,

Martijn