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

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

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.

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to