- By Thomas Lord -
Let's suppose 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 polls 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 setup 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, 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, never mind support. That's why free software has an
advantage: The portion of the $7.9 million 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 one a month's 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 we'll have a staff that won't burn
Let's offer live support 16 hours a day, 7 days a week, with an average of 6
engineers online whenever support is live. 16x7x6 divided by a
24hr/workweek uses up 28 of our our 32 support engineers, leaving
4 left over to build releases and handle escalations. Each
support desk 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 manageable, especially if
we tack on a one-time hookup 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
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 disincentives 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.
"Commentary" articles are contributed by Linux.com and NewsForge.com readers. The opinions they contain are strictly those held by their authors, and may not be the same as those held by OSDN management. We welcome "Commentary" contributions from anyone who deals with Linux and Open Source at any level, whether as a corporate officer; as a programmer or sysadmin; or as a home/office desktop user. If you would like to write one, please email firstname.lastname@example.org with "Commentary" in the subject line.