[Zope] Zope needs this (and Dynamo has it)

[Richard Moon]

At 14:47 07/03/00 -0600, you wrote:
>Alexander Staubo <alex@mop.no> writes:
>
>[snipped]
>
> > Zope doesn't have the flashy packaging and sexiness of a product line
> > Dynamo -- which, actually, I strongly urge you (and everybody else in
> > this forum) to experience yourself, before you snap back at my again --
> > and this affects management decisions. Dynamo is exceedingly sexy, and
> > it boasts the kind of bullshit magic that have management and tech
> > people alike drooling.
>
>OK, but see you're trying to make Linux something it is not.  Linux is
>not about marketing.  It is not about world domination.  We
>specifically do not care about this :-)


I would say that I specifically do care about this. As a freelance 
developer I want there to be good recognition of Zope in the market place. 
It is all about recognition. I was extolling the virtues of Zope to the IT 
Director at a client and he said 'So why haven't I heard of Zope ?'. My 
answer, that it was all very new and on the verge of success probably did 
not convince him. (Of course it is all very new and it is on the verge of 
success ).

If I say Linux, Perl or C then management are usually quite happy. These 
are recognised names - but nobody owns them. SO it is possible for free 
software to be successful in the sense that they are as well recognised as 
commercial products (which have huge budgets behind them).

Some management (perhaps most) will prefer to buy a "fully supported" 
product from a major player. We don't need to take on that kind of 
marketing head on. Rather we can present Zope and Python as tools to do a 
job, not strategic decisions to be made by management. However it is 
reasonable for management to ask "Will Zope be around in three years" - 
"can we de-Zope if we have to" - "Who owns Zope" "Who uses Zope". Managers 
are not likely to take a "risk" on a product. At the moment they usually 
feel happy that Linux, C and Perl are going to be around in three years time.

If Zope is to succeed it will be because of its capabilities as a product - 
because it installs out of the box in six minutes, while the Microsoft 
equivalent takes 5 hours. Because 60 minutes after downloading it you can 
be running a web page which interrogates your legacy databases (which is 
what happened to me).

We know about the documentation issue, which is hopefully being sorted.

I feel there is also an issue with the product itself. Zope seems to work 
on two levels - you have a very high-level part - I'm thinking of the 
security model, the SQL methods and the Z Search interface, the drop-in 
products like SquishDot etc. These set Zope apart from other technologies 
which people might use (PHP/ASP etc).

You also have a low-level  part (External methods etc). Because Zope has 
the high level part it encourages the thought that there is not much 
'programming' needed to develop a Zope site. But sooner or later you are 
going to hit a wall - for example questions you see asked on this list such 
as "how do I assign a value to a variable". Well the answer is ...

<dtml-call expr="REQUEST.set('abc_search', strip_abc(abc_text))">

... a string of gobbledygook. (So what does the dtml-let tag do is the 
obvious question that springs to mind.)

It is great that Zope has the low level stuff but I feel that work needs to 
be done

1) To analyse actual usage of Zope to see what features are being used and 
which areas of usage cause concern/difficulty
2) To Implement high level dtml tags to implement them.

I've stuck my neck out here - feel free to chop it off.



Richard Moon
richard@dcs.co.uk