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
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
