Subject: Re: FSBs and client-server
From: "Stephen J. Turnbull" <>
Date: Wed, 24 May 2000 16:32:15 +0900 (JST)

>>>>> "Brian" == Brian Behlendorf <> writes:

    Brian> But when you get into greater degrees of complexity,

It strikes me that maybe it's not complexity, per se, but the fact
that complexity has two downsides:  the service becomes less reliable,
and the cost of switching vendors becomes higher.

    Brian> the one that's usually more successful is, "we want 1000
    Brian> companies using this software, even if they don't pay us a
    Brian> dime, because make it easier to sell to new customers if we
    Brian> can point to an established userbase, who've adopted this
    Brian> as a standard."

But can you imagine Google saying that?  I think not ... so you also
need a situation where the service is not merely complex, but where
complexity really does increase switching costs and thus creates
incentive for a long term relationship.  (Some of the business school
guys are calling this idea "multiplexity", but I don't know a standard
definition.  Their application is to producer alliances, rather than
producer-client relations.)

Also, I can't really see AOL saying that about their internal email
system.  I'm not sure how to parametrize that, though, but it is a
case where a long-term relationship is present (in fact, in general
that will be true with email examples).  Or could you argue that
AOL-style email is not a very complex ("multiplex") service?  Ie, that
the stickiness of the relationship is something else (hanging onto an
address, say).

    Brian> And in fact we would welcome a company that wished to
    Brian> provide commercial-grade support services on internal
    Brian> installations of our software, since we're uninterested in
    Brian> being in that business ourselves (currently).

On the theory that this increases "your" market share (both in number
and scope to a slightly different application), and also provides an
obvious candidate for the "soft" landing for your customers if you go
away?  (Not to mention an obvious path for expansion by merger, which
I don't think is what you had in mind.)

    Brian> So my basic question is, are end-customers sufficiently
    Brian> motivated towards intangibles like standards compliance and
    Brian> common code to be able to compell ASPs towards open source
    Brian> (or otherwise common) solutions?  *Can* they be educated on
    Brian> this, the same way the world has been educated on the value
    Brian> of open source end-user software?

I think so.  On the education side, the battle is half-won.  Eg, I
would guess that the Economist, which is not a technology-oriented
journal by any means, does articles on standards battles once a month
or more (although not always focused on the standards issue, standards
coverage is always slanted toward "standards are a good thing,
compliance is a minimum, `ownership' is a large competitive
advantage").  They're becoming more aware of the issue of openness as
time goes on, too, although I can't quantify that.  I think the
Economist is a pretty good barometer of "informed general business

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 straight lines for?  "XEmacs rules."