'386 Unix Wars

Geoffrey Leach geoff at Veritas.COM
Tue Jan 1 08:36:25 AEST 1991


>From article <1990Dec30.193929.16181 at kithrup.COM>, by sef at kithrup.COM (Sean Eric Fagan):
> In article <1990Dec30.170614.22573 at ddsw1.MCS.COM> karl at ddsw1.MCS.COM (Karl Denninger) writes:

>>SCO has done the same kind of thing.  BOTH companies seem to feel that you
>>have no right of expectation to a bug-free product, or one which conforms to
>>the appropriate documentation and standards in the industry -- unless you
>>buy a nice expensive support contract.  
> 
> Well... look at it another way.  Support personel are expensive.
> Development people are expensive (as are all the people to back them up:
> production, documentation, sales, managers, internal support, hardware
> maintainance, etc.).  So... would you rather have to pay $8000 for a single
> license, and get the support you want, or pay $1000, and get somewhat
> limited support?

In essence, Sean says that the Karl (as an SCO customer) has no right to expect 
that their product should work "as advertised", given their price point which
Sean describes as, "somewhat as a loss leader."  If SCO (or any oem!) had a 
disclaimer on their shrink wrap packages that read something like this, I'd
be inclined to agree.

	Notice to Purchaser.  SCO makes no warranty, express or implied that
	this product functions according to the documentation which SCO
	furnishes as part of the package.  The purchasor has no rights
	whatsoever. The purchasor must purchase a support contract before
	SCO will even speak to him concerning the use, functioning or 
	operation of this product.

Its been some time since I opened any SCO products, but I think I would 
remember seeing it if it was there.  I expect ISC is no better.  To say
nothing of ATT!  Their shrink wrap 386 SVR3 comes with free support for
something like three months.  But try to collect.  If you don't have a
piece of their hardware, their service organization won't talk to you.
(That's my experience as of almost two years ago.  Perhaps they've changed.)

Rather than having a discussion of what <your oem> has done to you lately,
perhaps we could shift the discussion to what are reasonable expectations
for product labeling and performance.  Keep in mind, that we are talking
about low-end product here.  Stuff that competes with OS2.  Many -- perhaps
the majority -- of potential purchasors are upgrading.  They have no knowledge
of UNIX and have never heard of UseNet.  Do the oems have any responsibilities,
or is it buyer beware?

My response to this question is radical.  I believe that it is in the economic
self-interest (albeit long term) of the oem to provide full support as part of
the cost of the package.  In other words, "fre" support.  The model I have
in mind is that used by Word Perfect, who (as of a year ago, at least) had
an 800 number that would talk to you about any aspect of the product whatsoever.They didn't even attempt to eliminate bootleg copies.  As I see it, the 
basic advantage to the vendor of such a policy is that it builds good customer
relations.  Would the vendor perfer to have a customer that loves him and his
product -- and will, as a result, be willing to put up with a lot of hassle
should a bad release ever get out -- or one that is looking for any way at
all to replace the vendor's product with a new one?  Perhaps less obvious,
but still a real advantage, is that the vendor is forced to face up to the
necessity of producing a quality product.  Bugs become a cost to the
organization rather than a profit center.

Unfortunately, the computer industry is run, for the most part, by bean 
ounters.  Anything that reduces the cost of the product is OK by them.
Well, I disagree.  If we don't know that a buggy product is not a product
at all, then we are making a fatal mistake.
If we don't learn that if we ship products (hardware or software)
that do not live up to the customers' expectations for quality, then our
industry will go the way of the American automobile industry.

Geoff Leach



More information about the Comp.unix.sysv386 mailing list