Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.18/text0027.txt

Internet Message Format | 1990-03-18 | 7.8 KB

From: Donn Terry <[e-mail]>

In an earlier posting, I noted that I believed that standards encourage
innovation.  John (our illustrious moderator) challenged me to flesh out
the original bare-bones statement.  Here I go.

First of all, let me suggest that you read "Bugs" by Christopher Anvil
in Analog, Vol CVI, No.  6, June, 1986.  It's an interesting piece of
fiction which is basically a fever-dream about why standards are
important to end users, and the consequences of their lack.  It supports
my position by showing that energy is often wasted when standards are
not present.

I believe that standards encourage innovation.  Clearly there are others
who don't, and I'd like to suggest that they think about it again.

Standards are written for areas where there is a clear consensus that
there is a "right way" to do something, or at least there is a reasonable
hope of agreeing on a "right way".   Where there is no consensus like
this, standards are premature.  (See below on premature standards.)

When a consensus is reached concerning a standard, the number of possible
ways of doing something (at least within a given context) is reduced
(ideally to one, but compromise may require that there be a small number).
The key issue here is that the way(s) that remain are believed to be
nearly optimal and are clearly adequate to do the currently known jobs.
(If a new aspect comes out it's (supposed to be) because the context didn't
originally include that aspect.)

Because the standard specifies a particular way of doing something, it is
fairly mechanical to do it that way, and it need only be done once
(per implementation).  Once it is done, it is done, as well.  No further
energy need be wasted keeping up with the Jonses on that specific issue.

I assert that the amount of energy available to invest in what feels
like innovation is approximately constant, and will be expended
somewhere in that amount.  I also assert that this is distinct from the
energy needed to do the mechanical implementation.  Thus, if the energy
of innovation is not expended in one place, it will be expended in
another.

However, for many individuals it is also a lot more comfortable to stay
in an area they are familiar with than to go into something new and a
bit harder or riskier.  This is the classical path of least resistance.

So, where does this lead?

A given amount of energy will be spent on what feels like innovation.
If it can be spent in a "comfortable" area, it will often be spent
there.  If not, it will be "forced" to other, less comfortable areas.
"Innovation" in a comfortable area isn't innovation, it's
hyper-refinement, and in general doesn't make things much better
overall, although it might locally optimize something.  (A further
refinement in the classical debate on how many angels can dance on the
head of a pin doesn't do computer end-users much good, even if the
answer is ten times more accurate than it was before!)

If "innovation" becomes impossible in an area because of a standard, it will
be forced into another area.  Given that all the "old, comfortable" problems
are now walled off from innovation, that energy will go into new areas, where
it will make noticable advances.  Even in areas where it initially looks
like there is a standard, there may be a place for innovation and improvement,
but it is bounded by the standard.

For example, the read() system call certainly shouldn't change at this
point in terms of its interface, although if the de-facto standards were
weaker (as they were when UN*X was invented) you could argue long and
hard about the type of the buffer argument, whether it should be a
function or a procedure, or whether the count is signed or not.  Even
argument order might be an issue.  Further effort in that area might
make it slightly better, but not very much.  However, if someone really
wants to work on read(), I bet that it could be made smaller and faster
without changing the interface.  That would be useful.  Tweaking
the interface wouldn't be nearly as useful (although it is easier and
lots more visible.)  (OK, maybe by now read() implementations are optimal,
but you get the point.)

However, because there little or no opportunity to play with read(),
someone could go off and start prototyping something really useful, like
new tools.  In fact, because of the de-facto standardization of UN*X and
MS-DOS, that's exactly what I claim happened:  there was no further room
for innovation in the "old" stuff, so it happened in the areas not yet
explored.  The pethora of tools on UN*X systems is an example.  However,
I think we are just about saturated with shells, greps, and similar
tools and it's time to move on.  (This is not to say that V6 sh, Bourne
sh, csh, ksh, ad nausium weren't valuable.  They were because they
explored the space of classical shells, and now we appear to know how to
make a pretty good one for experts.  Its clear we don't have the "novice
shell" problem licked yet, and rather that making another expert shell,
it would be more useful to explore the novice shell space (by
innovation).  Standardizing the shell (and thus forcing away innovation)
will move those energies into (I personally hope) novice shells.  It will
also move innovation into things like the ksh history mechanism, which
built tightly upon the existing de-facto standards of vi, emacs, and
Bourne shell.)

(Note that I didn't say that innovation ONLY occurs when standards
force it, just that standards tend to keep it in areas that need it.)

Note that there still are debates about angels and pins, but they are
usually confined to the standards process when the time for a standard
is right.  And, once done, they are done; there's little reason to
re-open them again.

If you don't believe my point about the energy available for innovation
being constant, Anvil presents a case that the feuding and keeping up
with the Jonses that is inevitable when a standard is not present (or
when a de-facto standard changes rapidly) will sap the energy for
innovation (that is, for making things better.)

On premature standards:

All of this is not to say that premature standards never occur.  They clearly
do.  In computer systems (particularly busses (I realize the risk I take
in saying that)) this is not all that uncommon.  There are a couple of reasons
for that, and I don't attempt to assert that all of these have necessarily
actually occured.  I'm simply saying it reasonably could.

    1) Personal: Ego gratification.  It's nice to have your name on a
       standard, particularly if you're looking for a job.  You like
       doing standards, relevant or not.  It counts as a "publication".

    2) User pressure:  end-users see that standards save them grief
       and then reverse the direction of the implication arrow.
       They want to get rid of grief so they infer standards will of
       course do that.  (This might be true, or might not, depending
       on the circumstances; when it's not, the standard is
       premature.)

    3) Vendor pressure: having something proprietary declared as
       "standard" is a big competitive advantage, particularly if
       you make a lot of money licensing technology or patents.
       (Again, this doesn't imply that the standard is premature,
       but simply is a force that can cause premature standards.)

Usually, this "outs" itself in two ways: the standard is never finished
(there are legion), or the standard is crammed through a (typically small)
committee and then roundly ignored by the users.

The standards process is designed to avoid premature standards, but if
it was 100% effective in avoiding them, it would also elimiate some good
and useful standards.  If one slips through it is usually ignored at a
small cost.

(I would note that "premature" is often used to mean "not in my interests".
Here I mean *really* premature.)

Donn Terry
HP Ft. Collins

In this I speak only for myself, and in no way represent either my
employer or the IEEE.

Volume-Number: Volume 18, Number 28