Subject: how to create 21,780 new free software jobs (2,530 in R&D)
From: Tom Lord <>
Date: Mon, 4 Nov 2002 13:50:37 -0800 (PST)

Let's suppose that my computers run a distributed file system client
that's capable of detached operation.  I give my ISP about $11/month
to get my kernel, all my binaries and upgrades from there, pretty much
automatically.  I report bugs to my ISP, and call their help desk when
I have problems.  My ISP poles me about new feature requests.  I can
store my files remotely, giving me backups for free.  I can get at my
files from any machine on the net.  This is an excellent way to
provide "software by subscription" and "ubiquitous, personalized
computing".  And, remember, it costs:


for the software and support components (i.e., that doesn't count
remote storage or bandwidth costs).

Several universities have operated with such a set-up for ~15 years.
They've gotten good results, and universities are notorious

My ISP can lump me into a user community of 60,000 users -- roughly
2-4x times the size of a university campus community.  I picked that
size because university computing systems work pretty well and are
easy to think about and engineer for, while businesses can pay a
little more and become more efficient.  For all the users in my
community of 60,000, there's a budget of:

	$11/month x 60,000 == $660,000/month == $7,920,000/year

to produce the OS and apps I use and to provide me with support.

At first glance, that's a pretty small budget to provide a complete OS
and apps, nevermind support.  That's why free software has an
advantage: the portion of the $7.9M that goes to strategic and
tactical development of my OS and apps can be pooled with the amounts
from other groups of 60K users without the need for a monopolist
producing the platform.

Will I get good support?  Sure.  Presume that for every 1714 users, my
ISP pays a $190,000 salary to a skilled support engineer, plus a
$10,000 facility cost.  Thus, my group of 60,000 gets the equivalent
of about 35 support engineers. Giving each a one month vacation, we're
really talking about the equivalent of 32 engineers.  So, remember,
we're planning on:

	32 support engineers : 60,000 users

In addition to a one month vacation, let's give each support engineer
a light work week (24 hours).  That way there will be some slack to
pick up the inevitable spikes in demand and a staff that won't burn

Let's offer live support 16 hours a day, 7 days a week, with avg 6
engineers on-line whenever support is live.  16x7x6 divided by a
24hr/work-week uses up 28 of our our 32 support engineers, leaving
4 left over to build releases and handle escalations.  Each
desk-support engineer gets about 2,143 users -- each user gets a
little over 1/2 hour of individual support per year at maximum
utilization.  We can see from these numbers that the quality of the
software and of the release engineering process are going to be
critical -- but these ratios certainly look managable, especially if
we tack on a one-time hook-up fee for new users.  With such handsomely
paid and slackful support jobs, hopefully the people doing those jobs
can do quality work and be amply qualified.

How much of our budget just got burned up by support?

	35 x $200,000 = $7,000,000

that leaves $920,000 / 60K users to do the strategic and tactical
engineering that produce the OS and apps.  Not much, really -- but
don't forget that that budget is pooled across all the user

At the beginning of 2002, AOL had 33M subscribers.  Let's say an
AOL-scale operation worked this way.  That'd be 33M / 60,000 = 550
user communities.

	550 x $920,000 = $506,000,000

to produce the OS and apps.  At our standard pay scale and facilities
cost, that'd float a staff of 

	$506,000,000 / $200,000 = 2,530 engineers

which is starting to look like a pretty healthy amount.

This plan doesn't touch existing free software markets.  We might even
be able to fund it entirely from falling bandwidth costs.  From 33M
users, we'd create:

	2,530 new free software R&D jobs
	19,250 new free software support jobs

all based on $190,000 salaries and 24 hour work weeks and 11-month
work-years.  And that's with only 33M users -- there are probably 5x
that many to be had.

The conclusion?  We need free software R&D spending to bootstrap this
business model.  The industry needs to look towards Athena and Andrew
and similar projects that roughly fit this paradigm.

In my own little niche of the world, I've most recently worked on
source management and release engineering tools that are well suited
for this paradigm of distributed development and support -- remember
we talked about 4 support engineers for each 60,000 users doing
release builds and handling support escalations?  That's 550 source
trees to keep in quasi-sync, just for this purpose alone.  We should
plan on the need to feed those trees from decentralized and competing
R&D suppliers, with code and bug-fixes flowing in both directions, and
ongoing-disincentive to keep all 550 trees in perfect lock-step (i.e.,
lots of non-fragmenting forks).

Piece of cake.  Probably only take a week or two.