Subject: Re: FSBs and client-server
From: Brian Behlendorf <>
Date: Tue, 23 May 2000 23:25:51 -0700 (PDT)

On 23 May 2000, Ian Lance Taylor wrote:
> When Tim suggests that providers of centralized systems should make
> their software libre, he is going against the grain.  They want to
> retain control of their software.  Tim is suggesting that they should
> free it up, which leads to a loss of control as other people start
> providing similar services.  Why should they do this?  

Here's a justification we're using at Collab.Net for an ASP-style service
we are providing yet also provide all the underlying software for,

ASPs providing commodity services, like email-outsourcing, have no problem
(relatively speaking) in getting customers, because usually the switching
costs are extremely low; unless a customer has started using some
proprietary Outlook enhancements like scheduling (continuing the email
example), the interfaces to the service are very standard: SMTP, POP,
IMAP, etc.  They can reassure customers that, should they fail to deliver
on their SLA, the customers have reasonable options at their disposal,
either choosing a competitor or using their own software.  There are
other strong incentives beyond the potential cost savings (compared to
in-house hosting) I won't go into, but the basic idea is that customers
have that reassurance.

This is also true for those ASPs like USinternetworking, who provide
commercial apps like Peoplesoft or Baan on a per-user basis.  If they do a
lousy job, there are others providing the same software as an ASP, and
those companies could also pull it down themselves (at much greater cost,
but probably less than starting from scratch).

But when you get into greater degrees of complexity, with a service suite
that is relatively quite different from others out there, customers will
have far more concern about their ability to recover from a "what happens
if the service company disappears" situation.  This may not be much
different from "what happens if my desktop software provider goes out of
business and can't give me support", except for the big difference in time
- an ASP outage is a complete outage, whereas the desktop software will
keep working, usually.

So the primary business justification for releasing our code as open
source software is to provide a very efficient level of insurance to our
customers - if we screw up, you can do this yourselves, or get one of our
competitors to do it.  That's a harsh way of spinning it though - the one
that's usually more successful is, "we want 1000 companies using this
software, even if they don't pay us a dime, because make it easier to sell
to new customers if we can point to an established userbase, who've
adopted this as a standard." And of course, it might lead to code
contributions, makes our engineers much happier/helps with recruiting,
yadda yadda yadda.

I'll concede this is not a universal "Duh!", though, and may be particular
to our application, which is software development groupware.  It makes our
life harder, gives our competitors a significant advantage over us, and
gives us more opportunities to fail.  However, I think it also places us
well ahead of any commercial closed-source competitors, who even if they
also provide the software under a standard per-seat licensing model,
still will have to battle a zero-cost alternative.  And in fact we would
welcome a company that wished to provide commercial-grade support services
on internal installations of our software, since we're uninterested in
being in that business ourselves (currently).

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

> What's interesting to me right now is to speculate about the wave of
> decentralization which should follow the current wave of
> centralization.  What will it look like?
> Perhaps as more web services arise, they will start to commoditize.
> They will then become services which are simply available on the net.
> Rather than going to a particular web site, you will tap into a
> particular service.  Today we can see this in a few services such as
> DHCP and NTP.  Perhaps other services will commoditize, such as
> e-mail, chat, credit card authorization (leading to general net
> services for purchase of generic items), newswires, stock trading,
> other things I'm not thinking of.

Erm, that's the big idea behind using XML as the back-end data interchange
format.  Semi-standard DTDs and schemas per industry.  Things like SOAP
and DCOM are a stopgap; things like e-speak and Jini could be longer-term
infrastructural plays.  What's important is to make sure that the
interfaces are open, so that anyone can plug into an electronic  
marketplace and start providing services next to the big boys - that's
exactly equivalent to the opening of the OS that happened with Linux.

Once you get past HP's "e-services" marketspeak, the idea of companies
providing programmatic interfaces to their business offerings is pretty
powerful.  But it needs to go quite a bit beyond just XML over HTTP; a
framework for service discovery, certificate-based authentication, and
negotiability (so that someone looking for a size 7 tennis shoe can settle
for a 7 1/2 if it's on sale at 70% off) is pretty interesting.  That's
what e-speak is struggling to answer.  Oh, and e-speak's core is L/GPL,