Subject: Re: Successful FSBs
From: Adam Turoff <>
Date: Fri, 20 Sep 2002 10:31:51 -0400

On Fri, Sep 20, 2002 at 07:19:01PM +0900, Stephen J. Turnbull wrote:
> >>>>> "Lynn" == Lynn Winebarger <> writes:
>     Lynn>     If anything, why not orient towards how you convince
>     Lynn> large businesses to deal with small-scale operations (like
>     Lynn> Russell's government contract problem a while back)?  I
>     Lynn> mean, if we were going get exclusionary of certain types of
>     Lynn> FSBs.
> The antagonistic reply is "big clients are like big investors: they
> want their clients to grow with their needs."
> The supportive reply is "hmm ... you've got something there: it may be
> a small piece of software (# KLOC) but if it integrates well into the
> client's operations, it's as big as the client is (# workstations)".

I don't know if the antagonistic reply addresses what's going on
in software today.  I don't understand your supportive reply.

A big comapany like GM is going to be wary to deal with Joe's Garage
ERM, and is certainly more comfortable dealing with SAP.  On the
other hand, large companies are already using packages like Perl,
CVS, Linux and RT.  If one of those open source packages isn't
quite working right, there's a clear path to getting support, paying
for features or training (absent an O'Reilly title or a healthy
training industry for that product).

The "you can read the source and modify it yourself" argument
doesn't really wash in these circumstances; the real issue is that
the software "just works" in the simple case, and it can be easily
modified by many people (and you don't get ignored like you would
with Microsoft or Oracle).

Perhaps this is the reality behind free software and the boutique
FSBs that support them.   I'd also buy the argument that there's
some tie between the complexity of the product and the ability to
build an FSB around it.  Projects like CUPS, Ghostscript, Snort
and RT seem to be doing a good job to be supporting their authors
through lifestyle FSBs, while projects like Perl and Linux are too
big to support a single lifestyle FSB (although many lifestyle FSBs
are built around them).

Just to add another monkey wrench into the mix, it seems like
Perl-based content management systems are released at the rate of
2 per month, yet never seem capable of supporting even a small
one-person FSB.  Perhaps content management is "too complex" to
support a lifestyle FSB around a single product; Zope Corp fits
the model of a VC-funded FSB and seems to be doing well.