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:

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.

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

Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - )

Reply via email to