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"