Open Source Commentary from Navica's CEO,
Bernard Golden
September 2007
In This Issue
-
Achilles and the Tortoise: Open Source
and Hardware
Achilles and the Tortoise: Open Source and Hardware
If you recall your Greek history, you may remember Zeno’s
Paradox of Achilles and the Tortoise -- posed, apparently,
to respond to someone else’s insult to the philosophy
teacher Parmenides, showing that ideological battles among
academics have a rich history. Achilles was, of course, a
magnificent athlete. The paradox was that in a race between
Achilles and a tortoise, if Achilles gave a sporting head
start to the tortoise, Achilles could never catch up! If he
allowed the tortoise a 100 foot head start, once both started
running (surely running is the wrong word for the waddling
that a tortoise performs during ambulation), Achilles would
shortly have run the 100 feet that was the tortoise’s
head start – but the tortoise would have moved on during
the time Achilles was covering the 100 feet. Achilles would
continue running and shortly come to where the tortoise had
moved to during the initial period of time – but the
tortoise would have moved yet further on. The paradox is,
as I’m sure you can see, is that Achilles could never
catch up with the tortoise, no matter how fast a runner he
was.
I originally heard this formulated another way: if you stand
some distance away from a wall, and then walk half the distance
toward it, and then walk half the remaining distance, and
then again walk half the distance still remaining, no matter
how many times you walk half the distance, you will still
never reach the wall.
How does this relate to open source?
Moore’s Law is perhaps the most famous theory in all
of high-tech. First propounded in a modest trade rag in 1965,
Moore’s Law posits that the performance of chips (actually,
not the performance, but the density of transistors on a given
piece of silicon, which translates directly into performance)
doubles every 18 months or so. What really makes this doubling
exciting is that is accomplished at a constant price; in other
words, every 18 months, for the same price, you get twice
as much performance. Moore noted this phenomenon; later commentators
dubbed it Moore’s Law. I must say that to characterize
Moore’s Law as a phenomenon seems barely adequate; it
is clearly the most dramatic technical progression in human
history.
Just as important is the inverse of Moore’s Law: the
fact that, for a given level of processing power, the price
is cut in half every 18 months. It’s this facet of the
Law that has led to every teenager in Western Civilization
having an iPod hanging out of his or her ears. The ever-cheapening
price of processing power has revolutionized the use of computer
technology, moving it from a costly possession reserved for
only the most important uses to a cut-price commodity applied
everywhere.
Moore, a modest man (he didn’t even refer to the phenomenon
as Moore’s Law for a good decade after everyone else
used the term) identified the central reality of the information
age, and his name will forever be lionized in his eponymous
Law. It has become used by commentators as a shorthand phrase
to capture the headlong march of information technology; in
fact, it has been transformed into something like a meme –
universally used to impressionistically characterize our times
in a way that precludes the need for detailed argument. In
short, Moore’s Law has ascended to bromide, trotted
out for every occasion.
By contrast, open source remains much less well-known within
the general society. If you ask most people about open source,
they’ll respond along the lines of “Uh, like Linux?”
This, of course, ignores the other 150,000 opens source products
(give or take a few thousand) available throughout the world.
Which is pretty interesting, because, if you look at it,
open source is the tortoise, Moore’s Law Achilles, forever
unable to catch up.
Why do I say this?
Moore’s Law proclaims a price drop of 50% every 18
months, while open source provides a price drop of 100% --
immediately. By moving to open source, IT organizations immediately
save the entire cost of whatever proprietary software that
is their alternative choice. No matter how long Moore’s
Law marches on – it’s been going strong for 40
years now – it will, according to Zeno’s Paradox,
never catch up with open source.
Okay, okay, Zeno’s paradox is actually a logical fallacy,
and Moore’s Law, even if it can’t reach zero cost,
can get so close as to be indistinguishable. Understanding
this process is made all the more difficult by the staggering
progression of performance that is part of Moore’s Law.
Nevertheless, open source outraces Moore’s Law by dropping
pricing to zero immdicately.
Why is it, then, that everyone in the industry wholeheartedly
clasps the truth of Moore’s Law to their bosoms, while
many people remain skeptical about open source? The question
remains, how can we communicate the potential of how open
source makes hardware-style economics available in the software
world?
If you listen to open source skeptics, you’ll typically
hear them say “yeah, I save money on the licenses, but
I’ve got to spend so much on technical talent that I
don’t net any savings (you’ll also hear people
complain about not having “one throat to choke,”
but, at bottom, that’s an argument about how expensive
they feel open source is to manage, technically speaking).
It’s true that open source does, generally speaking,
require more technical ability to successfully implement.
Many potential users feel that the savings available through
lack of open source license fees are overshadowed by the technical
investment that is necessary with open source. To be fair,
if you look at any one transaction – one system –
one project – open source may have a tough time making
a business case. Changing the technical skill level of an
organization requires a change to all of its practices and
processes; comparing the cost of that effort to the amount
of proprietary license fees that would be saved on any one
project, and it’s pretty clear that the marginal cost
of the license fees would be less than the total cost of uparmoring
your IT organization, skill-wise.
But is analyzing the tradeoff based on a single project the
right metric to make the open source decision? In other words,
should you compare the total cost of getting your personnel
more technically savvy against the license fees for just one
system?
Many people would object to that equation, citing the need
to amortize the personnel skill investment across a number
of projects so that no one project’s economics are overloaded
by needing to carry all the personnel costs. In this view,
doing something like cost accounting to spread the money spent
on skill improvement over enough projects would make the numbers
come out in open source’s favor.
In my view, though the cost accounting approach may make
the financial analysis friendlier toward open source, it doesn’t
really move the discussion to a plane where open source economics
destroy proprietary licensing cost structures.
This is because the open source vs. licensing fees for an
individual project limits the analysis to projects typical
of today – which are not reflective of tomorrow projects.
Tomorrow’s projects will be vastly different because
they will be architected with different assumptions, operated
at far different load patterns, and managed by much different
operations staffs. Simply put, if you assume that you will
still build the same kinds of systems when you no longer have
license fees, you fundamentally misunderstand what systems
will become when they’re based on free software.
The way forward for tomorrow’s systems are the current
crop of Web 2.0 companies – not in their functionality,
the relevance of which to most everyday business concerns
is, to say the least, unproven – but in their architecture
and design assumptions.
The Web 2.0 companies all assume:
Large and rapidly growing user populations
Huge and exploding data requirements
Intensive processing requirements
Extensive use of free open source software
In short, Web 2.0 companies assume scale and build the capability
to deal with scale into their architecture. And if you assume
scale, you don’t lock yourself into designs that are
economically crippling as you build out.
If you strip away the glitz factor and fawning media attention
to Web 2.0 companies, one can discern that their arrival is
the confluence of several factors:
- Cheap hardware (have you priced a computer lately? They’re
practically giving them away)
- Affordable broadband (I get 6 Mb for $46/month from Comcast;
it’s a scandal that the US doesn’t have even
higher bandwidth available, but these kinds of speeds make
interesting new applications possible)
- The willingness of people to share information in order
to reap value from others
The applications of tomorrow for businesses will need to
be designed with the same principles – because the same
forces that have created Web 2.0 companies will surely become
the norm for mainstream businesses.
Many people have commented on the social factors that businesses
need to adopt in order to participate in a Web 2.0 world:
transparency, responsiveness, moving from brand-building to
individual interaction, and so on. I am not interested in
addressing those things here, important though they are.
I am interested in looking at the technical implications
of this migration of Web 2.0 functionality into mainstream
businesses.
Here are the lessons businesses need to apply:
You must design for scale: Your architecture
must be flexible and extensible. In particular, you must not
imagine an X-sized system without thinking through what you
will do if it becomes a 10X- or 100X-sized system. Too many
companies design a system that they can afford (in terms of
licensing fees) if it is of limited size, but could not afford
if it suddenly needed to be five times as large.
You must waste software: Old-style systems
assumed that software is a precious commodity, expensive and
inflexible, so system functionality must be constrained and
the vision of what the system might deliver is deliberately
limited. In the new world, systems needed to be designed to
scale horizontally so that you can handle huge volumes. Google
throws software (and hardware, of course) at the challenge
of managing the world’s information. Instead of constraining
your system, design it to use as much software as you could
possibly need.
You must use open source: It’s obvious.
If you assume the last two items, it’s clear that building
a system based on proprietary software will soon eat you out
of house and home as the license fees incrementally grow every
time you add a new machine to the application infrastructure.
With these lessons in mind, the criticism of open source
software as being labor-intensive comes into better focus.
The economics of open source essentially trade off personnel
costs against capital costs. Personnel costs are the incremental
costs of using open source rather than proprietary software;
this is based on the putatively higher costs of open source
because it is less “finished” than proprietary
(to my view, this is debatable, and much more product-specific
than a blanket statement about open source). Keep in mind,
the open source cost is the marginal extra cost of labor associated
with using open source: both open source and proprietary have
certain labor costs in common, since all software requires
some technical talent be applied to it to get it to work.
What we need to understand is the incremental extra cost of
using open source rather than proprietary, which as I noted
in my parenthetical statement, I’m not really convinced
of. The capital costs that must be examined are the license
fees associated with proprietary software.
In a high labor cost economy like ours, the general rule
is to use capital in place of labor wherever possible. That
general rule is a good one, but in the “Web 2.0”
world of tomorrow’s business applications, it’s
not applicable – because the measuring stick of assessing
the labor versus capital issue is far different than it is
for today’s applications,. Simply put, the incremental
cost of labor necessary to build an open source-based highly-scalable
(dare I say it, Web 2.0) application is far less than the
license fees necessary to build the same application based
on proprietary software. For one machine, the labor cost of
using open source is perhaps higher than the license savings
achieved through using it; for one hundred machines, the labor
cost is amortized across them, while the license fees mount
up with each additional machine. You don’t need very
many machines in order to reach the crossing point where the
additional license fees outweigh the labor costs.
If you believe, as I do, that the next wave of corporate
applications will look more like Facebook and less like PeopleSoft,
what should you do?
- Start building the right skill base in your personnel:
open source skills and, perhaps more important, a favoring
of open source as a fundamental part of the corporate infrastructure
- Start designing systems that are extensible and that make
economic sense when extended to 10X or 100X scale
- Stop listening to proprietary vendors when they tell you
how to analyze your objectives and problems. Their solutions
will inevitably be focused on using their products; worse,
their solutions will inherently be bounded by a vision that
the resulting application will make financial sense when
it includes their product; in other words, they will put
blinders on you when in order that you narrow your vision
of the way to solve your business challenges. They sell
hammers, so their characterization of the problem will always
look like nails.
Stop thinking of IT as that group: IT is everything in today’s
economies. When something is ubiquitous, it has to be everyone’s
problem and it has to be cheap enough for everyone to use.
That means open source.
Navica News
You can hear me speak at these upcoming events:
October 16, 1:30 p.m., GOSCON Government Open Source Conference,
Portland, OR:"Creating an Open Source Policy for Your
Organization" workshop. More information here.
December 11, 3rd DoD Open Conference, Tysons Corner, VA:"Creating
an Open Source Policy for Your Organization" session.
More information here.
If you are interested in having me speak at your
organization:
Contact me directly via email.
|
