[Zope] - Selling Zope to your organization

[Wolf Logan]

that's a lot of questions. in my organization, i came in as a "tool and die"
programmer, writing code that was used by consultants to support consulting
projects. the consultants themselves worked mostly in perl, so there was a
lot of pressure for me to use perl as well. i did a few embedding/extending
projects in support of perl, and after seeing its insides, promptly
developed a lifelong loathing of the language. having limited expereince
with python, i began to explore how it might be used in our organization.

when the current project came up, i realized that it could be implemented in
python in less than half the time it would have taken to code it in C. i
lobbyed for python, and since programming resources were tight, we ended up
going with it. the almost immediate functionality of the code, and the
subsequent ease of maintenance, sold python pretty well.

as part of the python project, we used bobo to code a web user interface
around our toolboxes. the entire process took less than an hour, and the
quality of the result sold bobo. when bobo became zope, other people in the
organization were actually the first to suggest its use in other projects.
the most die-hard perl programmer in the company is now talking about
learning python and zope. i think we're pretty much convinced now.

basically, python sells itself in terms of immediate results *and
maintenence*. it proved to be much easier here for a team of engineers to
use python cooperatively than it did for them to use perl cooperatively. i
don't know if that had to do with the language or the engineers, but it
worked for us. performance has never been raised as an objections, primarily
because for our purposes, python is actually faster than other options.
(example: we have a simple web-proxy doohicky that has to make a few
decisions about the proxy target based on the request. writing it in python
sitting on sam rushing's asyncore, it's faster than almost anything...and it
integrates smoothly with the rest of the system in ways that would be hard
to do otherwise.)

zope sells itself based on ease of implementing complex systems. writing a
simple call-tracking system for a help desk is a one- or two-day project in
zope, and it scales pretty well to lots of complex features. in general,
zope tends to be one of the most convenient ways to access functionality
through the web. find an existing project and web-enable it with zope.
that's usually a convincing demo.

open-sourcedness is less of an issue here, but it does make it very easy to
slip zope into an organization. you don't need a big budget approval to "try
it out"...and if it works, you can move directly into production with just
the branding requirement.

> -----Original Message-----
> From:	Gabe Wachob [SMTP:gwachob@findlaw.com]
> Sent:	Monday, January 18, 1999 5:05 PM
> 
> Hey folks-
>     Has anybody here had to go through the experience of selling Zope
> (and Python) to your own organization over another technology (esp.
> Perl/CGI)? . . .
> 
	. . . Has anyone had any success doing this? Has anyone used
> Zope as a way to get people using Python?
> 
>     What sort of resistance have people experienced in moving from
> Perl/CGI to Zope? Is performance ever cited as an objection? Having to
> learn a new language? The newness of Zope and Python? The relative lack
> of popularity of Python and Zope? Open-sourcedness? Single-sourcedness
> (of Zope), even if open source? Licensing issues (particularily the
> "logo" license requirement)? Apparent complexity?
>