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: http://www.colorado.edu/conflict/peace/example/fish7513.htm 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. Geoff