Path: utzoo!attcan!uunet!usenix!jsq
From: vyw@stc06.ctd.ornl.gov (WHITE V L)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, NIST Shell-and-Tools FIPS Workshop
Message-ID: <567@usenix.ORG>
Date: 1 Oct 90 15:50:25 GMT
Sender: jsq@usenix.ORG
Lines: 79
Approved: jsq@usenix.org (Moderator, John Quarterman)
Subject-References: <558@usenix.ORG> <560@usenix.ORG>
X-Submissions: std-unix@uunet.uu.net

Submitted-by: vyw@stc06.ctd.ornl.gov (WHITE V L)

Doug Gwyn writes: 

    >In article <558@usenix.ORG> std-unix@uunet.uu.net writes:
    >>Standards let the government avoid vendor-specific requirements like
    >>UNIX or SVID.  ...
    >>The Government has a burning need for a standard, they find it
    >>politically unacceptable to use UNIX System V as that standard, ...
    >
    >I have to challenge this often-heard (from DEC, for example, who don't
    >want truly open systems in the first place) rationale.  In fact there
    >have been more than one major (in the billion-dollar range) federal
    >acquisition where SVID conformance was specified, and that specification
    >was successfully upheld in appeals.  Thus the government's official
    >position would appear to be that SVID is an acceptable standard.

Yes and no.  This is hard to explain to someone who hasn't lived through it.
Yes, the 3.5 billion dollar AFCAC case upheld the legality of the use of
the SVID in procurements.  No, SVID is not proprietary and any vendor
who wished could make his system conform to it.  Yes, the SVID is a perfectly
good standard and we could be using it to fill in the gaps in our
procurement specs until the IEEE has time to produce a reasonable and
mature set of Posix standards.

So why aren't we? 

One reason is that we don't want to lock out systems that are primarily
Berkeley based.  However, we could still pull out enough definitions from 
the SVID for utilities which don't differ any or much from their BSD 
equivalents, write out exceptions to allow for the BSD differences,
and have a decent spec which would get us a Unix (not a proprietary) system.

The bigger reason is that "SVID" is a four letter word to the federal 
supervisors who are pressured by vendors hinting darkly at protests. 
The AFCAC precedent doesn't stop these threats, and it doesn't matter whether 
the vendor could actually win one of these protests.  
Any protest, whether it is eventually upheld or not, adds an incredible
burden of time, money, and headaches to the already baroque procurement
process.  It can stop your buy for months.  The problem is
the vendors who have had a free reign in the government for so many years and
aren't willing to give up their hold now that
they are being forced to play by the rules of competitive procurement.  
I suppose the problem is also the system that lets them clog the works with 
unjustified protests, but I don't know how to prevent that without being 
unfair to the vendors who have justified protests.

I've been told this is no excuse to pressure the longsuffering Roger Martin
to hurry through an immature FIPS and that I should just write a better spec,
good grief. Just say what I want.  That's my job, after all.
Well, I have done that, because I had to, and I ask you, how am I
to define what shell or editor or grep I want without reference to
SVID or the BSD manual or X/OPEN or some draft of 1003.2 (to which I am
reminded on every page not to require conformance)?  Somebody has a complaint 
about all of them, and I've wasted a lot of time bending words to satisfy
nervous bosses when I'd rather be programming.  

Yes, we should make the standards process reasonable and not rush it.
Yes, we'll have to make some sacrifices in lost productivity in the meantime
in order to accomplish that goal.  It would help a lot if the vendors
meant what they said about their standards support instead of standing
in the way.  And you know, I've used the products of those vendors who
are making the most noise, and they're GOOD.  Don't they believe that
themselves?  Don't they think their products can stand on their own merits?
Why are they so afraid of the big bad SVID?

I'm sorry this is a nontechnical contribution, and a long one at that,
but unfortunately the
nontechnical problems sometimes have a greater impact on our work and
are more difficult to overcome than the technical ones.

These opinions are wholely mine and do not represent an official position
of my employers or of the federal government.

Vicky White
Oak Ridge National Laboratory
vyw@ornl.gov

Volume-Number: Volume 21, Number 159