Re: Yearly Fees for Support of Compiler

[dlindsle@afit.af.mil (David T. Lindsley)]

I have been following this thread with some interest, and couldn't
resist contributing my $100 (inflation, you know :-) )

Support is indeed an expensive activity for a compiler vendor.  At
the same time, bug fixes probably should be provided for free.

I think part of the problem may be this.  With some vendors, when one
purchases a compiler, the support fee is built in to the purchase
price.  Other vendors separate the price of purchase and the price of
support.  Both approaches have their benefits, and their place.  For
example, if one is running a proprietary OS, and buys a compiler, the
price will likely have support fees built in, since you're running
the machine on their software (and hardware), anyway.  For third-party
vendors, it may make more sense to charge separately for support.

The vendors with the "package" deal will likely tout the fact that
you do, in fact, get a comprehensive package.  The vendors who
charge separately for product and support will likely tout their
prices, which will probably be lower.  Both are correct; neither
misrepresents its product, or engages in equivocal advertising.

These products also have slightly different audiences IMHO. (1) the
part-time tinkerer.  Perhaps a student with not much money to spare, or
someone who moonlights on the side (as a consultant, shareware author,
whatever).   If it doesn't work, post to comp.lang.* or look for patches
available via ftp. (2) the "big shop".  Production facilities, places
where a lot of work hours are riding on the reliability of a product.
If it doesn't work, we need somebody here *now* to fix it; it's cheaper
to pay the annual support fee than to have two dozen programmers sitting
idle for a week at $40+/hour apiece.

These distinctions are, of course, not absolute.  In particular, a
university might be closer to (1) or (2), depending, e.g., on its size.

The moral, of the story, of course, is "look before you leap (buy)".
Read the fine print.  (What support, frills, utilities, compatibility
does the product offer?)  Decide whether you need and can pay for a
fully- "powered" and supported tool.  Understand your needs and the
capabilities of the tool in question.  (The "reasonable-use" issue.)
Is this tool the most efficient for the job?  (Don't start writing tens
of thousands of lines of application code when dBASE or 1-2-3 would do
just fine.)

I'm sorry to be so long-winded, but I don't think this is a small issue.
Software authors/publishers have been lucky so far; we disclaim a lot,
and get away with it.  This is not unreasonable, precisely because of
the reasonable-use issue.  (It's easy to see that GM is not liable if
somebody gets run over with a Chevy; it's a lot harder for a compiler
vendor to prove misuse on the part of the programmer, particularly to
a judge/jury which may not be computer-literate.)  But software authors
and publishers also get away with selling buggy software because of this.
My fear is that someone is going to try to make programmers liable for
their bugs, and unwittingly make them liable for misuse as well.

BTW, I understand there are some strings attached to FSF software.  (I
could be half- or all-misinformed on that ii if I am, could somebody
clear me up?)

Questions, comments, discussion, constructive critcism are welcome.

-- 
Dave Lindsley	#24601#					   OPINIONS. MINE. 
dlindsle@blackbird.afit.af.mil		(The words don't come no smaller.)
	"If you don't succeed at first -- transform your data!" (me)