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
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.
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
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce