Subject: Re: FSBs and client-server
From: Ian Lance Taylor <>
Date: 25 May 2000 09:38:38 -0700

   Date: Tue, 23 May 2000 23:25:51 -0700 (PDT)
   From: Brian Behlendorf <>

   > Naturally we should all keep encouraging these centralized providers
   > to open their systems.  It might happen.  Arguing for it costs little.

   So, this is an interesting point.  How many people buy into Linux because
   it's Linux, and how many because it's Red Hat or Corel's distribution?  
   By the same token, how many people choose USInternetworking because of who
   they are, versus the tools (Peoplesoft, etc) they provide?  My point being
   this - the customers of ASPs are in a good position to drive those ASPs to
   use common architectures and code, as a way to make sure they don't get
   locked into a vendor who could disappear overnight.  Many ASPs have code
   escrow agreements with customers, but most customers realize how useless
   that code would be if the company dies and the developers leave.  So my
   basic question is, are end-customers sufficiently motivated towards
   intangibles like standards compliance and common code to be able to
   compell ASPs towards open source (or otherwise common) solutions?  *Can*
   they be educated on this, the same way the world has been educated on the
   value of open source end-user software?

It's interesting, though not surprising, that you are focusing on the
code.  My first concern with using an ASP is my data.  If the ASP goes
under, what happens to my personal data?

If I can get my data back in a usable form, I have a fighting chance
at doing something else.  It would be good if there were some other
ASP offering the same service who could take my data.  But it would
also be acceptable if I could feed the data into a traditional

The pain of either type of switch would be large.  Even if there is
another ASP providing exactly the same services, I can't imagine that
it would be seamless.  This type of switch between service providers
happens in the physical world from time to time; for example, when you
switch payroll companies or insurance vendors.  It's always a royal
pain.  Moreover, the more personal data of yours that they have, the
worse the switch is.  It's comparatively simple to switch cleaning

In other words, to really hammer the point home, what I as a customer
want from an ASP is not necessarily an open source solution.  What I
want is a common data format.

In particular, the main advantage I get from a libre program--the
ability to tweak it to do what I want--has much less application to an
ASP.  My tweaking their program makes no difference at all unless they
agree to run the tweak.  That's the nature of a centralized service.

So from a customer perspective, perhaps we need to push ASPs not to
open source or common solutions, but to well defined APIs to which we
can write our own interfaces.  You said something similar later in
your message.

Opening the source helps the ecosystem as a whole, but it doesn't help
either the customers or the vendors nearly as much as libre
applications do.  It doesn't give the customers the right sort of
freedom, and it doesn't give the vendors similar levels of potential

On a different note, when you say that ``the world has been educated
on the value of open source end-user software,'' I think you are
engaging in a bit of forward thinking.  That education has only
reached a tiny percentage of the world so far.