home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.21 / text0160.txt < prev    next >
Encoding:
Text File  |  1990-10-26  |  4.1 KB  |  81 lines
  1. Submitted-by: vyw@stc06.ctd.ornl.gov (WHITE V L)
  2.  
  3. Doug Gwyn writes: 
  4.  
  5.     >In article <558@usenix.ORG> std-unix@uunet.uu.net writes:
  6.     >>Standards let the government avoid vendor-specific requirements like
  7.     >>UNIX or SVID.  ...
  8.     >>The Government has a burning need for a standard, they find it
  9.     >>politically unacceptable to use UNIX System V as that standard, ...
  10.     >
  11.     >I have to challenge this often-heard (from DEC, for example, who don't
  12.     >want truly open systems in the first place) rationale.  In fact there
  13.     >have been more than one major (in the billion-dollar range) federal
  14.     >acquisition where SVID conformance was specified, and that specification
  15.     >was successfully upheld in appeals.  Thus the government's official
  16.     >position would appear to be that SVID is an acceptable standard.
  17.  
  18. Yes and no.  This is hard to explain to someone who hasn't lived through it.
  19. Yes, the 3.5 billion dollar AFCAC case upheld the legality of the use of
  20. the SVID in procurements.  No, SVID is not proprietary and any vendor
  21. who wished could make his system conform to it.  Yes, the SVID is a perfectly
  22. good standard and we could be using it to fill in the gaps in our
  23. procurement specs until the IEEE has time to produce a reasonable and
  24. mature set of Posix standards.
  25.  
  26. So why aren't we? 
  27.  
  28. One reason is that we don't want to lock out systems that are primarily
  29. Berkeley based.  However, we could still pull out enough definitions from 
  30. the SVID for utilities which don't differ any or much from their BSD 
  31. equivalents, write out exceptions to allow for the BSD differences,
  32. and have a decent spec which would get us a Unix (not a proprietary) system.
  33.  
  34. The bigger reason is that "SVID" is a four letter word to the federal 
  35. supervisors who are pressured by vendors hinting darkly at protests. 
  36. The AFCAC precedent doesn't stop these threats, and it doesn't matter whether 
  37. the vendor could actually win one of these protests.  
  38. Any protest, whether it is eventually upheld or not, adds an incredible
  39. burden of time, money, and headaches to the already baroque procurement
  40. process.  It can stop your buy for months.  The problem is
  41. the vendors who have had a free reign in the government for so many years and
  42. aren't willing to give up their hold now that
  43. they are being forced to play by the rules of competitive procurement.  
  44. I suppose the problem is also the system that lets them clog the works with 
  45. unjustified protests, but I don't know how to prevent that without being 
  46. unfair to the vendors who have justified protests.
  47.  
  48. I've been told this is no excuse to pressure the longsuffering Roger Martin
  49. to hurry through an immature FIPS and that I should just write a better spec,
  50. good grief. Just say what I want.  That's my job, after all.
  51. Well, I have done that, because I had to, and I ask you, how am I
  52. to define what shell or editor or grep I want without reference to
  53. SVID or the BSD manual or X/OPEN or some draft of 1003.2 (to which I am
  54. reminded on every page not to require conformance)?  Somebody has a complaint 
  55. about all of them, and I've wasted a lot of time bending words to satisfy
  56. nervous bosses when I'd rather be programming.  
  57.  
  58. Yes, we should make the standards process reasonable and not rush it.
  59. Yes, we'll have to make some sacrifices in lost productivity in the meantime
  60. in order to accomplish that goal.  It would help a lot if the vendors
  61. meant what they said about their standards support instead of standing
  62. in the way.  And you know, I've used the products of those vendors who
  63. are making the most noise, and they're GOOD.  Don't they believe that
  64. themselves?  Don't they think their products can stand on their own merits?
  65. Why are they so afraid of the big bad SVID?
  66.  
  67. I'm sorry this is a nontechnical contribution, and a long one at that,
  68. but unfortunately the
  69. nontechnical problems sometimes have a greater impact on our work and
  70. are more difficult to overcome than the technical ones.
  71.  
  72. These opinions are wholely mine and do not represent an official position
  73. of my employers or of the federal government.
  74.  
  75. Vicky White
  76. Oak Ridge National Laboratory
  77. vyw@ornl.gov
  78.  
  79. Volume-Number: Volume 21, Number 159
  80.  
  81.