[Zope-dev] The bleak Future of Zope?

Joachim Werner joe at iuveno.de
Wed Apr 21 15:24:53 EDT 2004


Hi!

I am not too active on the Zope mailing lists any more because there is 
not too much time left for it. But this thread asks for a comment. So 
here it is:

First of all, I am not sure if the release policy of Zope 3, and the 
whole concept of doing a complete rewrite was right or wrong, but at 
least I don't see a much better alternative. Zope 2 really is getting 
ugly with its age, so just fixing it wouldn't really be too much fun.

What I've been missing in Zope 3 fro years now is a clear focus on a 
single target. Maybe that is the target of Zope 3: not solve a specific 
problem like web content management but be a general toolkit for 
building applications.

But I think it would have been a bit easier and much more efficient to 
start with a rather focussed project, let's say a web groupware system 
or a CMS, then make sure that things don't get too specific. That way 
there would have been a list of deliverables to test all the neat new 
features and concepts against, not just conceptual ideas.

As things are now, me and lots of other commercial Zope users never had 
the resources to really actively participate in Zope 3 because we have 
to earn our living, and that means applications for the end user if we 
don't want to charge for the toolkit (which is obviously no option).

Well, it's not too late for this. The world still doesn't have the 
perfect groupware or CMS application, and maybe Zope 3 can be a starting 
point for it.

The problem of Zope 2 is - don't kill me for saying that - Plone. Plone 
and its foundations in CMF have created a large momentum around a 
terribly horrible code base. Believe me or not, almost everything gets 
more complicated with CMF/Plone than with plain Zope. Building a 
framework on top of a broken framework on top of an ageing framework 
that is hardly documented isn't a very good idea after all. The 
shortcomings in Zope 2 itself should have been addressed and fixed, 
rather than reinventing most of its good parts poorly and keeping the 
bad parts. Send me a private mail for an extensive list of issues I see ;-)

There are quite a few Zope-based CMS solutions out there, and most of 
them are better than their commercial counterparts in many respects. But 
if we had managed to start a joint CMS effort (other than CMF, which is 
a failure by design) two or three years ago things would look even 
better now.

I am currently working on a prototype for a project management solution 
that is going to be used at SUSE LINUX AG. For that I am using plain 
Zope. No Archetypes, no Plone, no nothing. Why? Because while Zope 2 is 
ugly in many respects it still is the most beautiful solution in the 
Zope (2) community. The original Zope concept is great (having a 
filesystem-like structure of objects and a web-based frontend to work 
with it). What I expect from Zope 3 (at least as one part of the 
project) is a better replacement for Zope 2.

The few problems I have always had with Zope 2 haven't been addressed in 
Plone. They probably have been addressed in Zope 3. I'll have to find 
out. What I am looking for is a real rapid development tool for 
web-based (or at least distributed) applications. If Zope 3 doesn't 
deliver that then other solutions will "win the war".**

Rapid development can only work if there is an easy-to-understand 
concept or basic paradigm in a system. Zope 2 is such a system. A lot of 
things just got ugly because too much bloat was added later. One of the 
best ideas with the worst implementation was ZClasses. ZClasses would be 
extremely useful if they really worked as expected. In the web frontend 
all we'd have needed is a separation between configuration stuff and 
data (e.g. using two or three tabs instead of one mixing everything). 
Zope 3 has addressed this issue quite well I guess.

What we should work on in the future is development tools for Zope. If I 
get the stuff I know about Zope 3 right it should be relatively easy to 
write IDEs (or plugins for existing IDEs) that add wizards, 
code-completion and lots of introspection, so that I don't have to learn 
all the API but can explore it while developing.

Add an UML-based or UML-inspired graphical frontend to do the 
application architecture.

Finally we need industry-strength performance. The last point is one of 
the most important ones. Zope 2 has lots of very nice features (like the 
ZODB, WebDAV access, etc.). Basically everything is there to replace a 
lot of the most recent Microsoft products (including their planned WinFS 
DB-like filesystem). We are just lacking the performance (mostly thanks 
to Python being a beautiful, but not really fast language).

That's from my part.

Cheers

Joachim

** A final question that is mainly aimed at the ZC people: What is the 
competition you are positioning Zope 3 against? I've never seen an 
answer to that quite important question ...


-- 
iuveno AG
Joachim Werner

Wittelsbacherstr. 23b
90475 Nürnberg

Tel.: +49 (0) 911 9883 984

E-Mail: joachim.werner at iuveno.de
WWW: http://www.iuveno.de




More information about the Zope-Dev mailing list