[Zope-dev] Defining Zope 3.

[Jens W. Klein]

I'am an almost passive reader of this list and typical 'user', or lets 
say, software I write is a consumer of all this useful Zope-SOMETHING.

I observed your discussion and read all the threads and I wasnt sure all 
the time if its the right direction. Writing code is better than 
discussing names and declaring things dead or alive. I think Gary boiled 
it down a bit. 

Am Thu, 16 Apr 2009 00:06:41 -0400 schrieb Gary Poster:
[...]
> This message seems like a reasonable start to me:  "Zope 3 has become
> focused on supporting frameworks and applications, rather than trying to
> be one itself.  It is now called the Zope Toolkit.  Parts of it are used
> by Zope 2, Plone, Grok, Repoze.bfg, and by many other different
> applications and frameworks."

I.e we're using parts of the Zope Toolkit for the next generation code-
generator (agx, successor of archgenxml), which is really out of web 
application scope. Why not point out zope is a powerful architectural 
choice? 

Using Zope Toolkits core parts is a way to write code in Python (ZCA et 
al as a core-architecure). Other parts are offering a bunch of 
interfaces: solutions to common use-cases and convinience. All the code 
inside the toolkit fits together, which is in my opinion the major 
advantage and elevates programmers productivity a lot (even if its a 
challenge for beginners to get started with the puzzle).
 
[...]
> Second, the "Zope Toolkit" is about supporting other frameworks.  That
> means that it is reasonable to expect that the packages and the parts of
> packages that were about the ZMI will quite possibly die a typical open
> source death of not enough people caring anymore.
>
> I don't think trying to guess which parts or packages will die is a
> particularly useful exercise.  The community will support what the
> community supports...as usual.  This is open source.  You're gambling
> that enough other people will be there with you to make it worthwhile,
> and you may be required to step up with money or talent  or energy to
> make that happen.

I agree completly. In my opinion declaring things dead in a free software 
eco-system is not the usal way. Things are supported if they are used and 
those users care about the code. A low barrier to new contributors helps 
a lot. 

I.e. in Plone we have a tiny set of core components covered by the Plone-
Foundation. Becoming contributor is easy (compared to zope), but also 
needs a ontributor agreement. 

But most of the code resides outside the plone-subversion. It lives in 
the swamp named collective (also provided by the Plone Foundation). 
Everybody can get access within minutes and may modify anything in there, 
real anarchy. From a programmers POV the collective is like normal 
Wikipedia articles where everybody can edit. But also Wikipedia has more 
closed articles, which compares to the more protected plone-subversion. 
This works very well. In collective are many dead-projects. But sometimes 
one get just picked up. 

I would divide the Zope Toolkit in two parts: 
(1) The real core which has to be mature. I doubt its all current 50-70 
packages (dont ask me which parts this are, most of the active authors 
here are knowing it better) 
(2) The more loose ends where more agility is needed. Plus outside-
toolkit stuff like ZMI, application-server-installers etc. whatever the 
community-members are willed to support. 

Part two should have a real low barrier for new supporters, without 
contributor agreement, w/o need of ZPL.

just my 0.02 Eur.
-- 
Jens W. Klein - Klein & Partner KEG - BlueDynamics Alliance