[Zope] To Zope or Not To Zope?

alex@mop.no alex@mop.no
Wed, 26 May 1999 23:44:39 +0200


Sorry if you misunderstood my intensions -- I was just asking a
question, that's all. I did not mean to rag on DC in any way. I have not
read about their standpoint regarding commercial/free products, so for
me that question was logical.

I'm _all_ for what you say. Kudos to DC for making this discussion
largely irrelevant. :-)

The Windows example was about design, not openness, and the reference to
Microsoft (a pox on them all!) was about price level.

From what I'm seen so far of their corporate (or non-corporate,
depending on your point of view) thinking, DC does have my stamp of
approval.

--
Alexander Staubo             http://www.mop.no/~alex/
"In the end, we all assume room temperature." --John Maynard Keynes

>-----Original Message-----
>From: Howard Clinton Shaw III [mailto:shawh@sths.org]
>Sent: 26. mai 1999 23:14
>To: Alexander Staubo; Zope@Zope. Org
>Subject: RE: [Zope] To Zope or Not To Zope?
>
>
>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"
>