Open Source Commentary from Navica's CEO, Bernard Golden
December 2006
In This Issue
-
The Open Source Digital Divide
-
Navica News
The Open Source Digital Divide
Most of the publicity and attention paid to open source focuses
on the “sexy” products, especially those associated
with companies that have received venture backing; MySQL,
Zend, and SugarCRM are examples of this type of product. Naturally,
there are a whole range of products that are widely used but
get less attention since they do not have the finances to
support PR and marketing activities, even though they have
significant financial backing in the form of large companies
that donate engineers to the development team; Apache comes
to mind in this regard.
But there is a third category of product, and it is one that
should concern every user of open source. These products are
ones that are widely used, have many organizations dependent
upon them, and yet have scarce resources to support them.
I got a particularly vivid illustration of this type of product
recently when I had the opportunity to talk with Corey Shields,
the head of the Open Source
Lab at Oregon State University. I was returning from
speaking at the Government Open Source Conference while he
was heading to the Bay Area for a debriefing session regarding
OSL’s participation in Google’s Summer of Code.
We ended up sitting next to one another on the flight to SFO.
The OSL is a tremendous resource for the open source community.
The OSL offers community projects a reliable hosting environment
along with significant networking to support product downloads.
Among the projects it hosts are: Mozilla (Firefox), Drupal,
and OpenOffice. It serves up an enormous amount of traffic
– it has 600 megabits on tap to support its activities.
And it does this at no charge to the hosted products. The
OSL relies upon University funds, although it is now seeking
other sources of funds, including individual and corporate
donations (you can have your name put onto a rack for only
$20; see here
for details).
During our discussion Corey shared with me the circumstances
of how one project ended up at the OSL, which struck me as
an example of the great service OSL provides, but a troubling
example of how bereft of resources some open source projects
are that they literally pose a risk to commercial vendors
that depend upon the product, as well as end users that rely
on its functionality. The project Corey described is BusyBox.
BusyBox is a key piece of technology for nearly every Linux-based
embedded product on the market. For example, every Linksys
router sold carries BusyBox with it. BusyBox is a single executable
that contains compressed versions of the most important Linux
utilities. Since embedded products typically have small amounts
of memory, a small footprint utility product is critical.
Because BusyBox is so memory efficient, it is included in
almost all Linux-based embedded products that require ssh
access and the ability to execute from the command line.
Despite the product’s importance, though, it was on
life support before it came to OSL. It was housed on a single
PIII server located in the maintainer’s bedroom; network
connectivity was a flaky low-bandwidth connection. Because
the machine and the Internet connection went up and down repeatedly,
BusyBox was often unavailable. When the availability reached
a critical state, OSL stepped in and offered to host the product.
So the product now can rely on the University’s commercial-grade
Internet connectivity and data center – but the software
still resides on the same creaky old PIII! That’s right.
This critical building block of the embedded Linux world runs
on a machine that most of us wouldn’t let our children
use to browse the Internet.
How can this be?
First, the product relies on the resources of a single committer.
He works on it part-time, and supports its infrastructure
(including hardware, now excluding power and network connectivity,
thanks to OSL) out of his own pocket. He seems satisfied with
that arrangement. The fact that he only works on it part-time
doesn’t seem to bother him, either. So, in part, the
situation occurs because the maintainer isn’t too concerned
about it.
However, that doesn’t mean that other people and organizations
shouldn’t be concerned. Having a dependence upon BusyBox
is a risk factor, and one would think that the organizations
that ship products with it would be concerned with its support
and enhancements.
That, perhaps, brings us to the second reason the product
has a paucity of resources. The embedded world operates very
differently than the server world. Embedded markets are incredibly
competitive, and costs that work out to less than a penny
per unit are critical. Embedded manufacturers may be focused
on costs to the exclusion of assessing business risk. Put
another way, they’re too cheap to worry about how BusyBox
gets to them and whether it’s viable long-term.
A final reason may be that companies that rely on BusyBox
just don’t know how thin its support structure is. They
may rely on their engineers to select the products that go
into their software stack, and fail to peer too closely at
the components within it. As has been said many times, ignorance
is bliss.
However, it’s hard to think this situation is tenable,
long-term. As open source is used more and more widely, one
would think that pressure would build for truly mature products
that carry significant dependence and thereby risk.
Still, this nonchalance in the face of risk is striking.
It’s a curious state of affairs since venture money
is being shoveled into the open source world at an enormous
rate, so clearly there’s money out there. It’s
especially remarkable because it’s obvious that many
of the companies currently being funded clearly do not have
a viable financial future. As I wrote in a previous newsletter,
users only pay for open source when they’re dependent
upon it, and many of today’s commercial open source
products offer utility but not criticality; in other words,
due to their characteristics, organizations may find them
helpful but the products do not impose dependence.
So we have a paradox. A vital product scrapes along with
barely adequate resources, while other products with little
discernable potential are showered with funds. There’s
a digital divide at work in the open source world. A middle
ground where essential products that lack a compelling “fundable
idea” can still garner adequate resources must come
into being. Otherwise, should a product like BusyBox demonstrate
unreliability, the open source world itself runs the risk
of being dismissed as not being capable of matching up with
commercial software.
Navica News
You can hear me speak at these upcoming events:
December 13, 9:00 a.m.: "A Market Overview of Open Source",
JBoss ISV Event, Hyatt Regency, Santa Clara. Register here.
If you are interested in having me speak at your
organization:
Contact me directly via email.
You might be interested in reading my blog posts
at CIO Magazine:
Five Things You
Should Know About the Microsoft/Novell Deal
Open Source Goes
Mobile
Community Beyond
Open Source
Musings on Vista
|
