Subject: Re: Development Shop FSB
From: Tom Lord <lord@regexps.com>
Date: Tue, 12 Mar 2002 11:45:56 -0800 (PST)




	I want to do what I enjoy doing for a living, develop Free
	Software.

You and many others.

      It seems most, if not all, FSBs don't actually make their money
      from their development projects, but rather from providing services
      for these products, or contracting/infrastructure rollout/support
      contracts etc. 

There's a big difference between RH and most pure FSBs, but I happen
to think that RH is one of the more interesting examples there is
(disclaimer: I'm a (very minor) shareholder).  So let's look at how
they make money.

Take a look at RH's most recent 10Q.  They distinguish between
"Subscriptions" and "Services", discussing the role of each in both
their revenues and costs.  It's also interesting to look at the
explanation of R&D costs and relate that to "Subscriptions" -- one
time costs for the subscriptions infrastructure seem to get charged as
R&D.

As I read the report (and this jives with their advertising and PR)
they work hard to implement subscriptions that cost an almost-fixed
annual amount to provide, no matter how many customers there are (not
counting costs such as physical media).  In essence, they implement a
mostly automated infrastructure and then sell access to that with a
windfall margin.  And, indeed, as a percentage of related revenue,
their "subscription costs" are falling; as a percentage of overall
revenue, their "subscription revenue" is increasing.

That subscription infrastructure appears to be, de facto -- not
necessarily in terms of licensing -- a collection of proprietary
software.  You can't download it anywhere.  You can't install it and
populate it with programmers and support staff to set up a competing
subscription service.  Don't take a job working on that infrastructure
if you think your job will be to "develop Free Software" in the
ordinary sense of that phrase.

In my opinion, that subscription model is not a stable solution: those
infrastructures can be commoditized and externalized and nowadays
there are big companies that have a big interest in seeing that
happen.  I just wonder if RH will capitalize on what it's got by being
paid to release that infrastructure, or whether they'll just have its
value yanked out from under them by someone else's Free and public
replacement.

RH also (judging by their press and financials) makes some big
consulting and custom development deals, along with a mysterious
category called "open source services" which is apparently different
from either of those .  Collectively, these are what they define as
"services".  In Sept-Nov 2001, they say they spent about 6.3M on such
services, pulling in about a 40% margin on that cost.  At least in
recent times, that segment is falling as a percentage of overall
revenues and its costs increasing as a percentage of related revenues.

It's impossible for an outsider to accurately measure such things, but
I'm skeptical that RH's contributions to the public corpus of open
source software corresponds to a decent percentage of a $2,520,0000
expenditure.  The point of that observation is simply that, there too,
if your goal is to contribute to Free Software, you might wind up
being disappointed if your job is to provide "Services" in the RH
sense of the word.

So, yeah, I think you have a good point:

	In that case, what is the real difference between working a
	day job and writing software by night, and making good on
	support/service contracts and writing software when you've got
	some free time?


But take heart: If the subscription model isn't a stable solution to
the FSB business model problem, is the RH services model any better?
or can we predict that it will have to change?

I think it's predictable that in the long term, and in the absence of
competing alternative business models, service revenues and their
costs will fluctuate randomly and wildly.

It's the nature of software that the complexity that will be
encountered in the future is fundamentally impossible to predict.  
Sometimes, we suddenly find ourselves with many commercially valuable
results that are just a few short tactical plays away.  During those
times, the custom development contracts work as a business model.
Other times, there isn't a wealth of "easy plays", but there's plenty
to do for the long term.  At times like those, custom development
contracts are less appealing.  To be more concrete, when there's a
flurry of new chip architectures, porting GCC is hot stuff.  When
there isn't, cleaning up GCC makes good sense for everyone involved,
and could easily be done under a retainer model, but good luck trying
to get someone to sign a six month contract for that purpose.

Contracting for services one at a time is inefficient and costly.  As
a business model, it's a bit like wind-farming in a region subject to
extreme climate fluctuations: sometimes the generators spin, sometimes
they don't (for years at a time).  Eventually, I predict (hopefully
sooner rather than later), those big service contracts will be mostly
replaced by steady retainers and those retainers will pay people to
"do what [they] enjoy doing for a living, develop Free Software."
Some of those people will spend a lot of time at customer sites,
analyzing needs, and occasionally ordering in the field engineers.
Only exceptionally will a special contract be needed for a particular
service.  (And just think what fun it will be for the accountants to
keep this under control; good thing the most important retainers will
be at a decent premium :-)


	Add to this, allot of people here are somewhat developers of some
	kind. If you start an FSB, most likely you will spend most of
	your time on the income generator, rather than the open source
	development. 

	The work you put in when you develop *IS* worth something. 

It's worth the most when you instantly commoditize it by integrating
it into the public corpus.  RH brags a lot about the amount of
development they do but I don't see them even trying to integrate that
work into the public sphere except in cases where they can take more
from others than they give back.  Thus, they play in the "classpath"
and "gcc" projects, but hold back in the installation program and
upgrade-over-the-net spaces.  In doing so, they're protecting their
revenues.  With a more retainer-based model, that conflict of interest
would disappear.  Indeed, when they and their customers figure out how
to make "contribute to the public sphere" a contractable service, just
think how nicely they'll be able to allocate an R&D budget.

-t