home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / graphics / 13598 < prev    next >
Encoding:
Internet Message Format  |  1993-01-09  |  3.4 KB
  1. Path: sparky!uunet!cs.utexas.edu!swrinde!emory!ogicse!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!crabapple.srv.cs.cmu.edu!andrew.cmu.edu!pa0q+
  2. From: pa0q+@andrew.cmu.edu (Phil Andrews)
  3. Newsgroups: comp.graphics
  4. Subject: Re: SDSC Image Tools source
  5. Message-ID: <kfHQTts000009CQ0UC@andrew.cmu.edu>
  6. Date: 8 Jan 93 08:29:13 GMT
  7. Article-I.D.: andrew.kfHQTts000009CQ0UC
  8. References: <1ifpmsINN33k@network.ucsd.edu>
  9. Distribution: world
  10. Organization: Pittsburgh Supercomputing Center, Carnegie Mellon, Pittsburgh, PA
  11. Lines: 58
  12. In-Reply-To: <1ifpmsINN33k@network.ucsd.edu>
  13.  
  14.  
  15. In response to the SDSC Image Tools release posting, Alaxander-James Annala
  16. wrote:
  17.  
  18.     >I don't know what experience with other supercomputer centers may
  19.     >be -- however, the gnu people don't have trouble with supporting
  20.     >'modified' copies of their software.  From a user's perspective,
  21.     >these binary only distributions can create problems -- for example
  22.  
  23. As the graphics coordinator of the Pittsburgh Supercomputing Center I can
  24. add our ten cents worth. Many people seem to think that writing a useful 
  25. utility is the tricky part. This is just not true. Almost by definition
  26. the effort
  27. involved in any successfull system will be dominated by support, and efforts to
  28. reduce the support requirements of a freely available system are the most 
  29. important part of its development. 
  30.  
  31. Once you decide to try for some reasonable amount of bug fixing the most
  32. difficult scenario to deal with is the unauthorized user who makes changes to
  33. the source code which (perhaps unkown to him) introduces new bugs. Trying
  34. to deal with these, knowingly or unknowingly, is a frustrating experience 
  35. guarranteed to pursuade most people never to release anything on the net
  36. ever again. SDSC deals with this, perfectly reasonably, by not releasing
  37. source.
  38. This is cannot be all peaches and cream for them however, because it means 
  39. they must maintain a very large number of binaries and the
  40. machines/environments
  41. to produce them.
  42.  
  43. In our case the PSC has been distributing several packages for over five years
  44. now, our biggest "seller" being the CGM interpreter GPLOT, via anonymous FTP
  45. (don't send me mail, it's on ftp.psc.edu). We worried about this problem
  46. from the
  47. start and decided to approach it by making the source freely available but
  48. copyrighting it to explicitly prevent the redistribution of changed
  49. sources/binaries.
  50. And yes, we still have had people do this, and I have sent them nasty messages
  51. telling them to stop. We also provide as many binaries as possible.
  52.  
  53. Other centers have other approaches; the software tools group at NCSA
  54. explicitly
  55. places their code in the public domain (please correct me if anyone wants to),
  56. and it is still not clear to me whether there even is a "best" approach.
  57. In defense
  58. of SDSC, we have noticed a clear trend towards more of our users taking
  59. binaries
  60. directly rather than wishing to deal with the sources and I expect this
  61. trend to
  62. continue as compilers, etc., become unbundled. However, I can believe that
  63. the availability of source gives even these users a warm fuzzy feeling, simliar
  64. to a decent warranty on a piece of electronics.
  65.  
  66. One thing that is definitely true, if you worry too much about 100% of users
  67. being able deal with your source, you are locked into arcane and unproductive
  68. programming practices and out of advances such as ANSI C and C++, let alone
  69. more aggressive approaches such as SmallTalk and Common LISP.
  70.  
  71. -Phil Andrews
  72.