Subject: Re: Successful FSBs
From: "Stephen J. Turnbull" <>
Date: Sun, 27 Oct 2002 16:08:03 +0900

>>>>> "Tim" == Tim O'Reilly <> writes:

    Tim> I *did* say that any definition of FSB that ipso facto
    Tim> excluded exploration of google, yahoo!, amazon, and host of
    Tim> ISPs as FSBs was prejudicing the very question that the
    Tim> thread was purporting to ask: what can would be entrepreneurs
    Tim> learn from "successful FSBs."

They're welcome to stop patenting and concealing the software they
develop; I think most FSBers would welcome that with open minds.  I
don't think they're going to stop, and that is why I exclude them.

    Tim> The tragedy, I've argued, is that amazon, google, et al don't
    Tim> consider themselves FSBs and act accordingly.  And for me,
    Tim> "accordingly" is explicitly and judiciously engaging with
    Tim> open source projects they depend on, NOT making everything
    Tim> they do open.

So what do you have to say that Shapiro and Varian didn't already say?
They're quite clear on the point that sometimes you should protect
your intellectual assets with vicious legal devices, and sometimes you
should give it away.  That sounds to me like exactly what you said,
except you gave it a new-age spin, and they put it in terms that will
go down easily at the top ten B-schools.

    Tim> If FS advocates had been thinking more about software as
    Tim> service, we would have avoided the whole ICANN fiasco,

Are you serious?  The ICANN fiasco is not about Verisign's monopoly;
it's about trade names and the support for anti-squatting regulation
at the grass roots (until they realized that it would just allow large
squatters an even bigger advantage, by which time it was too late).

    >> But Amazon is basically an ASP, and they want to keep the
    >> software concerning their core competences private.  To the
    >> extent that that integrates with OSS they've pulled in, they
    >> are _not_ going to contribute back to the community, and in
    >> fact they probably don't want their developers to participate
    >> in the community.

    Tim> That's actually not true.  The developers there are very open
    Tim> to working with outsiders.  I've been working that angle for
    Tim> some time, and making connections for them.

I stand corrected.  More power to you, and to them.

    Tim> But I won't argue your basic point.

Then I will, or at least question it.  What do you think is going on
there?  Is this the developers wanting to hang out with their natural
colleagues, more or less against the better judgement of management?
Or does management "get" it?

    Tim> But there should be a definition that understands more nuance
    Tim> than has been shown in this discussion.

Why?  If you tell Amazon or UUNet that they should be, or even "are",
an FSB, what good does that do?  "Ask what your business can do for
free software."  But do such businesses need to be called FSBs?
Aren't we grown up enough to do business with everybody from Peter
Deutsch to IBM's webserver and virtual Linux divisions to Microsoft
employees who use and want to support XEmacs, even if they're not
called "FSB"?

It seems to me that rather than trying to include everybody who can
pronounce "free software business," we should be looking at how FSBs,
pure or otherwise, can grow their free software businesses.  On the
other hand, we should be looking at FS NPOs, such as LUGs and
projects, and trying to get them to interface with businesses on
business-like terms.  The XEmacs Project does _not_ want to _be_ a
business, but it bothers me that our relationships with business users
is almost entirely on a individual basis, although I know that at
least one large firm has a fairly large internally-developed app based
on XEmacs.

    Tim> That's my real agenda.  I'm convinced that free and open
    Tim> source software have built an amazing open computing platform
    Tim> (i.e. the internet) but that many free and open source
    Tim> advocates haven't thought through where that platform goes
    Tim> next, and the consequences of failing to get people who are
    Tim> building components of that platform to think about their
    Tim> indebtedness to the free/open source software ecology.

Debt is a contract.  But the free software contract is quite clearly
not a debt contract.

Institute of Policy and Planning Sciences
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
 My nostalgia for Icon makes me forget about any of the bad things.  I don't
have much nostalgia for Perl, so its faults I remember.  Scott Gilbert