[Zope] To Zope or Not To Zope?

[Howard Clinton Shaw III]

On Wed, 26 May 1999, Alexander Staubo wrote:
> Paul Everitt wrote:
> [snip]
[snip]
> [snip]
[snip]
> > It's likely that the part that stores data in the relational database
> > might start out commercial, as well as the client-server version of
> the
> > object database.
> 
> This statement piques me, for several reasons. I don't mind that Digital
> Creations publish products that are commercial and cost $, but I'd
> object to any Microsoft-ish pricing (eg., if you'd sold Confera for
> $1000 I'd definitely balk). So please be lenient, huh? But more than
> that I'd like to ask you what happens when you demote a commercial
> product to a free one. Isn't this unfair to all those people who might
> have bought it?

Digital Creations have made their standpoint on this clear several times, and personally
I have to agree with them. If they make a product available for a price, then in paying that
you are paying to get it NOW. With most products, including your example of Windows, you
pay just to get your hands on it. If the documentation is not yet complete, or certain areas
of procedure have yet to solidify, then to release it would generate a wave of requests for
assistance, which DC cannot afford to supply. Therefore, those products whose current
state is one which can be expected to generate a more than reasonable amount of 'need'
in terms of support and care, then they restrict its distribution by making it available only 
to those who need it enough to pay for it, thereby limiting its spread (and the resulting
calls for help) and providing sufficient remuneration that DC can afford to answer those
queries which do appear. Witness ZTables, which has been available for some time, and
in use in several places, as a commercial, i.e. remuneration-required, product. When it
reaches a state of easy usability and sufficient documentation, it will become available to
those who do not have a strong enough 'need' to pay for it upfront.

They don't demote a commercial product to a free one. They promote it to an open one! Their
opening of the code has benefits even for those who initially purchased it, in terms of a wider
body of knowledgable developers who can answer questions regarding it, etc. 

Think of it in reverse. What is really happening, is that they are developing a free/open product,
but can't afford to release it until they can handle the volume of traffic that it will generate. You
are paying them to release it early to you.

I know that personally, with respect to their stated goal of maintaining an arm's length, the picture
of a stratified community, with some relegated to the 'free' club and others given special treatment
in the 'gold' club seems likely to generate strain betwixt and between that is not necessarily present
in the other view. Basically, we are all on a level playing field... the information and tools are available
to all, if you wait long enough, and for those who can't wait, a bit of money will grease the wheels.
Let's not divide the community.

Paul, DC, let me just say once again, that in all the reading of articles and discussions and responses, 
never have I seen a negative image of Zope or DC go by. You guys are on target in maintaining
the proper relationship with the community you have fostered and built around Zope. Keep up the
excellent work.


> 
> Maybe you should consider stratifying your product line into "free" and
> "subscription". If I join the Zope Gold Club for $500/year, I get all
> your heavy-duty client/server stuff for free. Sort of a "fixed rate"
> thing.
> 
> > > 	3) Zope is not "standard" enough that should I get run over by a
> > > truck development could proceed without me.  Finding consultants and
> > > programmers other than myself to work on this project could
> > > be difficult.
> >
> > I completely realize that going with Zope is still a risky decision.
> > However, the question of risk due to being non-standard is
> > mostly offset
> > by the risk of going with a closed-source vendor.  Do you
> > _really_ trust
> > Apple et al. to be responsive to all of your issues?  IMO, customers
> > should demand control.
> 
> The risk from my own point of view is really that Zope's design suddenly
> one day might prove inefficient. For example, what if Zope doesn't scale
> beyond 1000 objects? That's my fear, because such a break in scalability
> may be deep in its design. I doubt that Zope doesn't handle 1000
> objects, because obviously you've done some testing beyond that limit
> (you have, haven't you? Right? RIGHT? :), but since I've not looked
> through all the sources I can never be sure that at some point I'll say
> "I'd like to do..." and somebody will tell me "You can't, because
> internally Zopes this and that as...". That's how Windows tends to work.
> :-)
> 
> Alexander Staubo
> mailto:alex@mop.no
> http://www.mop.no/~alex/
> 
> 
> _______________________________________________
> Zope maillist  -  Zope@zope.org
> http://www.zope.org/mailman/listinfo/zope
> 
> (For developer-specific issues, use the companion list,
> zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )
--
Howard Clinton Shaw III - Grum
St. Thomas High School
#include "disclaimer.h"