Subject: Re: FSBs and client-server
From: Brian Behlendorf <>
Date: Wed, 24 May 2000 01:31:44 -0700 (PDT)

On Wed, 24 May 2000, Stephen J. Turnbull wrote:
> >>>>> "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.

OK, sure.

>     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 ... 

Of course not, what they provide is a commodity, searching.  They
still do it better than anyone else, but it's far far different than
enterprise software with lots of complex interactions between specialized 

> Also, I can't really see AOL saying that about their internal email
> system.  

The "customer" for AOL's services doesn't care a hoot about standards so
long as you don't keep them from their IM's, but they're a much different
kind of customer than I am considering.

> 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).

Laziness/contentment.  Sometimes there is such a thing as "good
enough", which people forget way too frequently.

>     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?  

More that it provides a solution for customers we will probably not be
interested in: hands-off support (where the support staff can't touch the
machine) is much much more difficult to perform, and difficult to scale,
than hands-on support (where the support staff owns the machine, as in an
ASP). Yet some companies will pay for such a service.