From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: *
X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_20,INVALID_DATE,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!dog.ee.lbl.gov!nosc!cod!sampson
From: sampson@cod.NOSC.MIL (Charles H. Sampson)
Newsgroups: comp.lang.ada
Subject: Re: Yearly Fees for Support of Compiler
Message-ID: <3050@cod.NOSC.MIL>
Date: 8 May 91 19:57:22 GMT
References: <2222@ac17.cs.nps.navy.mil>
Organization: Computer Sciences Corporation
List-Id: <comp.lang.ada>

In article <2222@ac17.cs.nps.navy.mil> nash@ac17.cs.nps.navy.mil (david nash) writes:
>                                      ...  In my mind, reputable companies
>that market software make an implicit promise of correctness to would-be
>buyers.  The gentleman to whom Mr. Taft responded was suggesting that they
>provide bug fixes without payment, not enhanced features.

     Actually, computer software is one of the few places where no promises
of correctness are made, at least explicitly, as many people have noted.
("This software is not warrantied at all.  If it causes your house to burn
down, don't blame us.")

     I just looked up the original article and as I read it the primary
issue is not bug fixes, it is support; the poster wanted the compiler
writers to look into a suspected bug.  Now, as a group, the compiler
vendors have a mixed record on bug fixes, probably a little worse than
for personal computer software in general.  I don't know why this is so.
Maybe it's because of the complexity.  (An Ada compiler is a lot more
complex than even a desktop publishing program.)  The issue of support
is quite different from that of fixing bugs, however.

     For over 10 years I was in charge of a compiler that had unlimited
free user support.  (Paid for with your tax dollars.  It was for one of
those strange DoD languages.)  A tremendous amount of time was spent try-
ing to discern exactly what the user had done.  Most users, trying to be
helpful, partially analyzed the problem themselves and filtered out "un-
important" information.  They were almost always wrong about what the
problem was ("array references don't work") and what was unimportant
(after 30 minutes of probing, "Oh, is that important?  Yes, I did insert
a line like that upstream.").  Furthermore, often the problem turned out
to be the user's, not a compiler bug.  I hope this doesn't sound like I'm
flaming my erstwhile users.  They were trying to be helpful and this situ-
ation just goes with the territory.  It was only a minor irritation to me,
occasionally worth a laugh around the coffee pot, but if I had been working
for a company trying to make a profit solely on the sales of that compiler,
I would have been substantially less sanguine about it.

     What is the solution?  I don't know.  Any good company has to have
some way of getting feedback from its customers.  An approach that is
initally appealing is to charge for support when the problem turns out
to be the user's, but make it free if he is reporting an actual bug.  My
guess is that this approach could end in some ugly finger pointing from
time to time, and probably generate some customer ill-will, exactly what
the vendors don't want or need.

                              Charlie