home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / mach / 1105 < prev    next >
Encoding:
Internet Message Format  |  1992-08-31  |  3.5 KB
  1. Path: sparky!uunet!sun-barr!olivea!decwrl!pa.dec.com!weir.pa.dec.com!ed
  2. From: ed@weir.pa.dec.com (Ed Gould)
  3. Newsgroups: comp.os.mach
  4. Subject: Re: Mach 3.0 on 386/486
  5. Message-ID: <1992Aug31.163850.26515@PA.dec.com>
  6. Date: 31 Aug 92 16:38:50 GMT
  7. References: <1992Aug31.134336.5202@nic.funet.fi> <Bts7q1.1I5@percy.rain.com> <1992Aug31.000622.10414@nntp.csl.sony.co.jp>
  8. Sender: news@PA.dec.com (News)
  9. Reply-To: ed@pa.dec.com
  10. Organization: DEC Network Systems Lab, Palo Alto
  11. Lines: 58
  12.  
  13. > It is true that mtXinu has their good NNTPSERVER which offers you good hints
  14. > and discussion about Mach386, but you still cannot get updates mentioned in
  15. > mach386.updates WITHOUT buying the expensive AutoSupport.
  16. > 
  17. > That is only thing I have to complain about mtXinu, I think that when you
  18. > buy product, you should have the best possible product. If it isn't as good
  19. > as it should be (it has bugs) then you should get fixes to make it good.
  20. > I mean, there is no buglist in advertisements so you should get a bug-free
  21. > product too. Add-in packages are different, of course you have to pay
  22. > for them, but you should get bug fixes for free.
  23.  
  24. There Ain't No Such Thing As A Free Lunch.
  25.  
  26. No software product ever sold has been free of bugs.  Anyone who thinks
  27. otherwise is fooling themselves.  Fixing bugs costs money.  It costs
  28. staff salaries, it costs overhead for the office space, supplies, and
  29. machines those staff use to find and fix the bugs, it costs additional
  30. staff salaries, and the associated overhead, to collect the bugs and
  31. distribute the fixes to customers, it takes staff to manage the
  32. systems used by the folks doing the bug fixing and distribution, and
  33. so on for a lot longer than many people have taken the time or effort
  34. to understand.  They just want their "simple" bug fix for free.
  35.  
  36. Product pricing is a tradeoff.  To get "free" bug fixes, the initial
  37. price of the product must have the costs of providing those fixes
  38. built into it.  When we set the initial prices for Mach386 (yes, this
  39. is not an unbiased comment from a third party - I left mt Xinu shortly
  40. after the Mach386 product was first released), we decided that the
  41. customers as a group would be best served by the pricing structure
  42. that kept the initial price low, but had available as an option
  43. additional services at additional cost.  We knew full well that there
  44. would be individuals who would prefer things differently, but it is
  45. not possible to accommodate everyone at all times.  We made the
  46. decision then (and, I presume they have continued to do so in
  47. reconsidering the prices as time has gone on), that we thought was
  48. best over all.
  49.  
  50. Staff resources are limited as well.  Which is more important to a
  51. small support staff, fixing the bug that keeps the whole system from
  52. booting for one customer, or fixing the bug that keeps "uncompress *"
  53. from working, after a workaround has been offered?  We always thought
  54. it was the former.  "Hire more staff," you say?  Pay more money for
  55. the product.
  56.  
  57. If what you want is the absolute lowest-price thing you can get your
  58. hands on, it's there for you to get from CMU.  It's not supported,
  59. it's not complete, and it changes every week or so.  That's not what
  60. most people want from their software.  Most people want stability, and
  61. they want to know that when a serious problem arises, someone will pay
  62. attention to it.  That's worth money.
  63.  
  64. Like I said before, and others have, too, TANSTAAFL.
  65.  
  66. --
  67. Ed Gould      ed@pa.dec.com        Digital Equipment Corporation
  68. +1 415 688 1309      Network Systems Lab    505 Hamilton Ave, Palo Alto, CA  94301
  69.  
  70. "Unison is only one form of harmony." -- LW
  71.