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