[Zope-dev] Re: The bleak Future of Zope?!

[Max M]

Martin Kretschmar wrote:

> Shortly said, the whole set of stupidities in
> connection with Zope3. It is a pretty bad state
> for a project, if it looms for years as the
> followup project on the horizon but in reality
> isn't one! 

It looks like the classical strategic mistake:

http://www.joelonsoftware.com/articles/fog0000000069.html

Funny thing though is that Joel uses Netscape/Mozilla as an example on 
how not to do it. I think that the jury is still out as to who won the 
browser war.

So it ain't ower until the fat lady sings.


> I can't believe the fairy tales with
> the possible migration from Zope2 to Zope3.

Me neither. The best we can hope is that it will be like copying a Z2 
product to a folder, and then move stuff out into configuration files 
instead. Perhaps it can be somewhat automated, but I see a lot of 
subtleties that can only be handled manually.

On the possitive side, a lot of the Z3 technologies are allready 
back-ported to to Z2. So Z3 will not be completely alien.

But if Z3 succeds in picking up more developers, as Z3 development gets 
a lot easier and more Pythonic, it can very well be better in the long run.


> All the people which have dwelled more or less
> deeply into the Zope2 world, thereby having had
> an enormous learning curve and now running
> applications, will not be able to participate
> easily on the academic Zope3 train. The technic
> freaks who modell Zope3 are usually not application
> developers, which have to build and run working
> applications for real human users. The artifical
> not-yet-product Zope3 will sooner or later be
> distracting development efforts from Zope2 because
> Zope3 is "almost finished." That doesn't look not
> nice ...

It is the single biggest concern about Zopes future. That is correct. 
And not one to be taken lightly.

But the biggest problem with Z2 has allways been the steep learning curve.

Relatively few developers has been able to work on it. The time lost for 
Z2 developers transfering to Z3 could quickly be offset by new 
developers due to an easier development model.

Also, Python is flexible. We will probably see a transition phase, where 
products are developed for Z2/Z3 compatibility. That way we *can* get a 
smooth transition.


> Further I see the problem that Zope probably has
> no real target group as an application server.

Zope has allways had that problem. But actually it fits very nicely into 
the cms market. Especially with Plone as the base.

Many companies has their own home rolled cms system. They will be 
replaced by open solutions due to scale of economics. It is simply to 
costly to compete against something like Plone.

Zope/Plone has a sweet spot that actually fits most customers out there. 
You can make solutions for a fraction of the cost of what a typical Java 
bases system costs.

Many Java based cms solutions are too costly timewise to implement 
solutions in for many customers.


> The enterprise world is dominated by .Net and
> J2EE. Zope in its current form without a sensible
> documentation in conjunction with the drama about
> the english zope book doesn't help changing this.
> Scripting has arrived in the Java world by Groovy,
> so this isn't a reason for using Zope anymore.

Scripting was never the reason for Zope. The absolutely brilliant object 
publishing model was.

Well that and Python.

It might be Groovy, but Python it ain't!

The things you can do in Zope you simply cannot do as well in other 
systems. The solution fits the problem space *very* well.


> In
> the world of small and medium applications PHP is
> likely to stay, because it leads much faster to
> results. Zope is to complicated for this.

The world of small/medium applications will dissapear! The bigger 
systems like Plone can do anything out of the box that the small 
hand-built systems needs to have hand coded.

Why on earth should somebody set up a PHP server and do a lot of hand 
coding, when they can set up a Plone server that does it all for them?

PHP based systems tends to be monolithic blocks. Something like PHPBoard 
is a good example. Setting it up is rather complicated. And using 
several on the same site is also difficult.

I Zope you can have a discussion board in each end every folder, just by 
adding it through a web based interface.

Furthermore smaller systems will grow larger. Then they will get growing 
problems too. Developers allready using bigger systems will find the 
future simpler.


> For the CMS stuff we have Plone, but this is rather
> suited for handling some simplistic documents for the
> intranet rather then a nice internet representation.
> This is because customizing Plone isn't trivial at
> all and nobody want's to run web pages with standard
> underwear blue. OK, the colours can be changed easily,
> other features via CSS, etc. ...

That is hard for any CMS system. What system does it better? It isn't a 
simple task to create a skinning system that flexible.

Actually I find Plone to be very well factored for a system of that 
complexity.

There isn't much in Plone that you cannot change to your liking. But 
it's a complex beast for flexible solutions. (That is why it is good for 
us consultants ;-) )


> Maybe I'm simply sick of moving along within web
> browsers and the file system without a sensible IDE
> and documentation.

That might be it ;-)


regards Max M