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
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
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
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -