On 6 July 2011 15:27, Sascha Welter <zopel...@betabug.ch> wrote: > I'm sorry, I don't really understand the current line of discussion yet. > > I see a lot of discussion which part is going to be cut out and dropped, > or replaced. I haven't yet understood what's the end target for the > project. > > So, are you guys expecting to get Zope into a shape where it will > attract new users and be a viable player again? Or, isn't the line > currently that "nobody uses Zope for new projects anyway"? > > In case that we believe that no new users are attracted to Zope, > wouldn't that mean that resources should go to make Zope into a shape > that helps existing applications run on Zope and survive? Modernize the > code, but break as little as possible in the process. As someone said, > what's the use for a company that has invested a lot of money in a Zope > Product, if there is something called "Zope" around, but they can't use > it without a major rewrite? > > > In case all these changes are made to make Zope again into a shiny new > framework that will attract new users, what's the use? Wouldn't people > go to pyramid anyway? There they have all that stuff already - but right > *now*. > > Looking at the descriptions here, in that line of thought and in the > long run we'll end up with something like pyramid in a few years, only > with a lot more disgruntled former users and much more confusion about > the name. When you change the name in the end, you've come full circle > anyway.
Zope in it's current form is not maintainable in the long run. There are too many alternative ways of achieving the same thing. Over the next few years we will need to start moving to Python 3, and the only way to make that port possible is by reducing the size of the codebase. As a Plone developer, my interest is in how we make Zope into something that enables Plone to continue evolving and developing, to port to Python 3 and increasingly use more standard WSGI components. Rewriting in Pyramid is not an option for us, large rewrites generally fail (even if they do produce excellent new technology along the way...) Of course if people who have legacy applications want to continue maintaining a 'Classic' Zope 2 in it's current form then they are free to do so, but it won't happen without investment on their part. I expect they will have similar concerns to the Plone developers, and may find the same reduction and evolution approach to Zope useful. Laurence _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )