Subject: keeping protocols open (was: Returns to ...)
From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
Date: Wed, 7 Jul 1999 16:09:35 +0900 (JST)

>>>>> "g" == D V Henkel-Wallace <gumby@zembu.com> writes:

    g>     Date: Wed, 7 Jul 1999 10:47:17 +0900 (JST)
    g>     From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>

		      Of course it is very profitable _if_ you can set
    the standard, enough so that it's often worth betting the firm on
    that strategy.  MSFT has done quite well with that strategy.

    g> And yes, exactly.  Milk it as long as you can and then use it
    g> as a stepping stone to the next level.  Why not?

Because Microsoft isn't in a position to use it as a stepping stone to 
the next level.  MSFT can use it to step laterally into another
market.

        I simply do not believe they can get away with it
    indefinitely on that basis alone.

    g> Straw man.  MS is an excellent example of how to do this right.

It is _not_ a straw man.  I am responding to Crispin, who thinks that
"extended" protocols are crucial.  I do not, and pointing out that
they are insufficient by themselves is important evidence in support
of my position.

Yes, MS does this right.  I think it's an issue of "not missing a
trick," not the core strategy.  Are you arguing that it is the core of
their strategy?  If so, why do you think so?

    g> So to get back to specific FSB issues:

    g>   - Will FSBs use similar "standards FUD" to gain strength?  Is
    g> it in fact mandatory in this phase of the market lifecycle?
    g> Red Hat tries to do it.  Cygnus tries to do it.  It ticks me
    g> off when RH tries, but I think it's OK when Cygnus does...OK,
    g> so I'm human!

Warning: the following discussion contains words that could be
interpreted as spreading FUD; that is not my intention.  ;-)  These
are just examples that have personal validity, but not necessarily
validity for others.

FUD is part of the human condition.  It is simply not true that
everyone has time to verify all the software that they use.  In fact,
a small fraction of users have time and skill to verify a small
fraction of the software they use.  Thus you must go on reputation
most of the time.  When Russ Nelson stands up and says "qmail has no
bugs", I don't believe him, but it does make me think seriously about
taking another look at qmail.  But that doesn't create any new FUD
about sendmail, smail, or exim, at least for me.

Now, when Cygnus or Debian publishes their bug database and honest
statements about standards compliance, even self-imposed standards,
that creates strong FUD about any rival who doesn't.  There's nothing
wrong with that, I assume.

As for "standards FUD," what are Cygnus and Red Hat doing to create it
about others?  Trumpeting the fact that they follow standards,
participate in their creation, and develop high-quality software that
meets the standards to some high degree?  I don't see anything wrong
with that, as long as it's true, and it's probably not very effective
in the long term if false.

Nor do I think it's particularly effective to claim better standards
compliance than others, or that you are the standard in an open
standards environment.  My experience with Red Hat, and traffic on the
Linux lists I participate in, suggests that they themselves are
subject to self-created standards FUD because they (used to?) mess
around with libraries and critical infrastructure apps (X11) a lot.
My own woeful tale was for SparcLinux 4.1, but people who follow
kernels and libc and XFree86 a lot closer than I do told me that that
was par for the course for Red Hat at that time.  Rightly or wrongly,
I still don't trust Red Hat distributions.

And since my experience with Debian has been perfectly satisfactory, I
don't intend to spend time checking out Red Hat's presumable
improvement.  I see nothing wrong with that, as long as I don't try to
claim that my opinion has firmer ground than a bad experience long
long ago in a galaxy far far away.  That kind of FUD is not going to
go away; in the long run, a firm's reputation should be correlated
(although imperfectly) with its past performance.

But note that what MSFT (and before that, IBM) do to create FUD is
quite different from anything RH or Cygnus can do.  When MSFT doesn't
comply with its own published interface, it says, "Sorry: that was a
draft, an RFC; the implementation is correct."  That ability means
that it can create FUD about others simply by saying "well, we haven't
decided what `improvements' we'll make in the next version of the
protocol yet."  RH, on the other hand, says "Oh, that's a bug and it
will be fixed in the next version."  Or, at worst they can say, "well,
we disagree with that interpretation of the standard and are arguing
it with the relevent body.  We will be compliant with the published
standard."  But that creates more FUD about RH than about anybody else!

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for?  "Free software rules."