Zope Documentation (was RE: Python Popularity: Questions and Comments)

[djmitchell]

Bill Tate wrote:

> I understand the "zen" thing, but it's not something that business
> people are going to care about when they making a decision about
> whether to use it or not.

Yep, exactly.  

My last boss was a "who cares what it is?  If it's open source and you 
techos recommend it, we'll give it a try" kind of guy.  If we could present 
a justification in terms of risk/benefit that looked good, he gave us his 
blessing.  I switched him from thinking development=C++/Java to Perl and 
Python, we replaced Solaris and AIX boxes with Linux, and we saved our 
employers enormous quantities of money.  When I tried to talk him into 
looking at Zope, I found there was no frame of reference I could use - no 
comparisons with J2EE or n-tier COM, which are probably about the closest 
alternatives in terms of development approach  If he was to let me take on 
some work using Zope, his problems were:
- trying to convince his superiors that this unheard-of Zope thing was 
better in some vaguely-defined way than J2EE and large COM solutions
- how to estimate the design/dev times using Zope.  At least with J2EE and 
COM there's some body of evidence out there as to how long projects take 
from conception to production.  We'd proven that Python compared to C++ 
gave something around 10:1 reduction in dev times, but Zope isn't Python
- how was Zope going to perform on hardware from vendor X.  We already had 
reasonable expectations as to how J2EE performed on specific hardware, and 
could budget our hardware purchases with some degree of confidence.  The 
Zope web site suggests "it runs fast", but there's no data at all that I 
could find to back it up

I knew I was on a loser even as I was saying something like "it's a better 
Java than Java" as I was describing Zope's platform independence.  When I 
had to resort to crap platitudes like this, even though I believe it, I 
knew nobody holding development purse strings was going to let me finish 
the spiel.

Zope seems to have an "it's better than the rest; just take our word for 
it" mentality attached to it, and solid comparisons with other tools or 
performance data just doesn't appear to be out there.  Sun took this tack 
with Java in the early days, and MS did with COM/MTS a few years ago, and 
large corporates had a belief that Sun and MS wouldn't let their customers 
down (else they'd lose market share and shareholders would get upset).  
With Zope not having a major corporation behind it, and the NASDAQ collapse 
in 2000, there's that much less blind faith available for Zope.  Even a 
small pilot or proof-of-concept implementation costs serious dollars, and 
that type of money just isn't around any more.

I'd LOVE to use Zope for something grander than my personal site holding my 
resume and pictures of my kids, but if I couldn't convince one of the most 
receptive managers I've ever had, it seems like an impossible task.  It's 
sort of like the conceptual leap that was required to embrace OO 
development several years ago; there was a large body of evidence as to how 
non-OO development worked in "best practice" scenarios, lots of project 
managers skilled in non-OO development and a general feeling of comfort 
that the old ways worked.  Why change to OO, and take on all the unknown 
development risks?

Based on the available documentation, Zope seems to need this sort of 
"death or glory" approach, and hardly anyone seems willing to take these 
risks at present.  Although I'd love to see the next Yahoo! or Amazon 
startup use Zope, there's just no way the men holding the chequebooks would 
allow it.

If anyone's got any suggestions as to how Zope can be made into less of a 
perceived business risk, I'd love to help make it happen, but it seems 
beyond me at present.