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. There are some
straightforward and incredibly effective techniques for helping to ensure
that the kinds of discussions we have been having are more productive. 
The book _Getting To Yes_ ( http://www.amazon.com/gp/product/0140157352 )
does a great job of describing them -- it's required reading in lots of
university classes, particularly in MBA programs.  The book is nominally
about negotiations, but the ideas apply to a huge range of interactions. 
Here's a summary:

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.

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:

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.

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.

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.

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.

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

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.


Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to