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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )