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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!uunet!tut.cis.ohio-state.edu!udecc.engr.udayton.edu!blackbird.afit.af.mil!dlindsle From: dlindsle@afit.af.mil (David T. Lindsley) Newsgroups: comp.lang.ada Subject: Re: Yearly Fees for Support of Compiler Message-ID: <1991May16.145218.2170@afit.af.mil> Date: 16 May 91 14:52:18 GMT References: <1991May3> <20600104@inmet> <1991May9.072802.4925@netcom.COM> Organization: Air Force Institute of Technology; WPAFB, OH List-Id: 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)