[Zope-dev] The bleak Future of Zope?

[Stephan Richter]

On Wednesday 21 April 2004 03:58, Martin Kretschmar wrote:
> Maik Jablonski of the german speaking Zope Users Group
> DZUG issued a pretty bleak outlook for the future of
> Zope. What are your oppinions?

I think Chris is right to say that Maik had a bad day. If not, and if he is 
serious about his uninformed opinions as stated in this E-mail, then I feel 
the necessity to reply to his points.

> Here comes the translation of his oppoion:
> > Maik, what makes you look full of scepticism for
> > the future of Zope?
>
> 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!

The reason it took so long is that there are a lot of people that take, but do 
not give back. While the Zope community has thousand's of developers, the 
Zope 3 community never exceeded a core team of 10 people at any given time. 
That is very sad!!!

People use Zope 2 and rest on it. Many do not realize that if you want to stay 
in the technology business, you have to innovate and Zope 3 is just that, 
Zope 2 would eventually fall apart due to bloating and inflexibility. Zope 3 
anticipates this and tries to fix the deficiencies. 

BTW, the TODO list for Zope X3.0 is less than 80 lines long at this point.

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

Well, if you have not studied the proposed solutions, what can you expect? I 
personally never believed in a compatibility layer for Zope 2 in Zope 3, 
which was thought possible early on and I made no secret out of it. However, 
the current approach is very simple and therefore realistic. Starting with 
Zope 2.8 or 2.9, you will be able to start developing applications that will 
run in Zope 2 and 3. This will provide a migration path to many. BTW, if you 
think that we do not address your needs correctly, don't waste time 
complaining, but use it to create **constructive** criticism on Zope3-Dev and 
participate.

> 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.

"academic", huh? To talk about myself, just because I am a Ph.D. student does 
not mean I am academic (in the sense you mean it here). I often consider 
myself as an engineer in science. Furthermore, I have developed many apps for 
end-users before starting to work on Zope 3. Many of the large contributions 
I made were motivated by my application development experiences. The current 
I18n and L10n support, for example, would not be what it is without my 
real-world doings. 

> The technic 
> freaks who modell Zope3 are usually not application
> developers, which have to build and run working
> applications for real human users.

First off, freak has an extremely negative connotation in English, other than 
in German. The German "freak" is translated as "geek" to English.

Now to some of the other developers:

Jim (Fulton) -- Over the last years I have been several times in F12g and had 
the chance to get to know him better. Jim has wealth of experience that is 
hard to match. If he cannot think about a good solution or thinks about his 
approach as too "abstract", he always talks to other ZC developers (who do 
work on applications all the time) for advise and values it highly. He is a 
true engineer!

Steve -- He has built the first commercial application for Zope 3. In fact, a 
lot of his contributions came from a time were he readied Zope 3 for this 
application.

Marius, Albertas, Bjorn, Victorija -- They develop for Zope 3 because they do 
projects with it. Enough said!

Gary (Poster) -- He uses Zope 3 already in Zope 2 (FrankenZope) for a customer 
project.

Python Labs (Fred, Barry, Guido, Tim and Jeremy) -- Clearly they have all had 
a lot of application development experience. 

Shane, Tres and other ZC developers -- Most of the ZC developers these days 
work on customer projects, so they have plenty of real-world, end-user 
experience.

Martijn Faassen -- All I say is Silva.

Phillipp (von Weitershausen) -- He also builds applications and his 
contributions were often very practical ones.

Sidnei -- Well, he built the second Zope 3 app that actually makes use of the 
strengths of Zope 3 in a way that is not possible in Zope 2.

So I see no reason to believe that we are a too abstract- or academic-thinking 
set of developers. 

**However**, we all need to be academic, because otherwise we would not be 
able to build a stable and well-performing framework for other people to work 
with and build on! Abstract thinking and development is a pre-requisite for a 
good, solid foundation.

> 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 ...

That will happen, of course, as people migrate to Zope 3 and this is a good 
thing. 

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

Really, I see a lot of opportunity; maybe not with Zope 2, but I think we 
innovated a lot in Zope 3, which will give it a great competitive advantage.

> The enterprise world is dominated by .Net and
> J2EE.

I think these technologies are all much stronger in the US than they are in 
Europe or other contintents. Of course they are bigger, since they have huge 
company backing, but most of their solutions are also very expensive. 

> Zope in its current form without a sensible 
> documentation in conjunction with the drama about
> the english zope book doesn't help changing this.

Well, stop complaining and do something. It is always so easy to complain, 
isn't it? (I do not mean you directly here, it's a general comment.)

And now my favorite subject, documentation. As for Zope 3, I have done 
everything I could to create a lot of valuable, quality documentation. We 
have:

- A tutorial with slides (with comments) and working code for a trivial 
example Zope 3 content component.

- A Zope 3 Developers book (currently about 430 pages that needs some updating 
-- coming soon) that explains solutions to some of the most common day-to-day 
tasks for an application developer.

- An API reference comes with Zope itself. Since Zope 3 is so configurable, it 
is not worth making a static API reference. The tool, accessable via 
http://localhost:8080/++apidoc++, provides an extremly interlinked 
documentation as I have seen it for no other technology yet.

- The online Zope 3 Wiki is also pretty rich of information, but you have to 
work a little harder.

- Philipp also works on a Zope 3 book.

> Scripting has arrived in the Java world by Groovy,
> so this isn't a reason for using Zope anymore. 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.

This changes with Zope 3. PHP is for script-kiddies, not for experienced 
developers. Zope was always more than just scripting. It was an application 
framework that supported scripting. That made it so attractive.

> 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. ...

Aehm, I think Plone's success speaks for itself. It found a niche. It does not 
have to perform outside of it.

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

Well, join the Zope 3 community. Good documentation and Emacs is the answer.

So far to my direct response.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training