Open Source Commentary from Navica's CEO,
Bernard Golden
February 2007
In This Issue
-
The "Flip Test": What if Open
Source Came First?
-
Navica News
The "Flip Test": What if Open Source
Came First?
I saw a pretty interesting blog
posting on techdirt recently about the relationship
between books and ebooks. The writer noted that if you flipped
the order in which these two technologies were available,
it would give you pause about the true benefits of ebooks.
If ebooks were all that was available, and then someone invented
the paper-based book, users would note that paper-based books:
- Are dirt cheap
- Never run out of power (I once saw someone from MIT’s
Media Lab speak on this topic; he opened the book and exclaimed
“Look! It’s on!” to much delighted laughter)
- Don’t require special hardware to access content
(and have no DRM, to boot!)
- Have essentially unlimited usable lives
Given that, wrote the blogger, wouldn’t you expect
paper-based books to supersede ebooks?
If you follow the link
within the blog posting, it leads to a discussion
about the “flip test,” in which the chronological
order of two related technologies are flipped to show how
the earlier really is better in many ways that the later entrant
– books and ebooks as a case in point.
I started mulling this over and, naturally enough, decided
to apply it to open source software. However, I decided to
perform a bit of an inversion of the flip test; rather than
use it to convince myself that open source is better than
proprietary software, I thought I would look at the shortcomings
of open source that are always being pointed out, and assess
how proprietary software addresses those shortcomings. In
addition, I wanted to think about other ways those shortcomings
might be addressed – if you performed the flip test
and imagined that open source was the established player and
proprietary software the interloper.
So, what are the common things proclaimed as open source
drawbacks? Here is my list, along with a description of how
proprietary software addresses the issue, and an imagining
of another solution that would integrate with an open source
installed base.
Fuzzy intellectual property
One issue often brought up about open source is the fact
that its decentralized development methodology and informal
project management processes can make it difficult to know
for certain that a downstream organization does not expose
itself to IP infringement issues.
How does proprietary software solve this problem? Proprietary
companies insist on developing every line of code themselves,
thereby allowing them to assure their customers that there
is no risk of infringement. There’s only one drawback:
it’s frighteningly expensive to take on that development
burden, and the industry is rife with numerous implementations
of similar functionality. In other words, this is an overly-centralized,
over-expensive approach to this problem.
How might it be solved in our open source-already-exists-so-how-do-we-fix-it
world? Well, to begin with, one might expect that every project
would routinely include an avowal of intellectual property
ownership (much like what is in place with Linux today) as
part of the code check-in process. In fact, SourceForge might
integrate a check box avowal into its source code control
system. A measure like this would address 98% of all concerns
about infringement; after all, isn’t an avowal more
or less what we receive today from proprietary vendors –
we take them at their word, and never go check for ourselves.
But what about those customers that wanted more than avowal?
What if they wanted impartial assurance? Perhaps something
like the Underwriters’ Laboratory would come into being,
to provide third party testing using a tool from a company
like Black Duck or Palamida. For those customers for whom
no form of assurance would be sufficient without legal shielding
via indemnification, we might expect to see an insurance-like
entity step forward and provide indemnification. Rather than
the individual product indemnification typical of today (i.e.,
pretty much every open source company like MySQL offers indemnification
for its customers), a blanket approach would be more likely
– remember, we’re living in the already-existing
cheap open source world, the proposed solution would need
to adhere to the low cost ethos of that world, and group insurance
is always cheaper than individual.
Open source takes too much work to get installed
and configured
One thing you always hear about open source is that it’s
only semi-finished – that it’s too much like a
tool and too little like an application. Put differently,
this complaint says that it requires too much work to get
it working properly – and too many IT shops are short-handed
and unable to devote the resources to do the necessary work
to successfully use open source. This criticism is often framed
in this way – open source is only 80% complete, and
getting it to 100% makes it less attractive than proprietary
software.
Frankly, I’m not particularly convinced about this
criticism. It seems to me that plenty of the rest of the software
world delivers hard-to-use products. But, if you accept this
criticism of open source, what would we see as the ways the
problem could be addressed?
The proprietary world currently solves the “last 20%”
problem by charging high license fees for the entire 100%
of its delivered product and devoting a portion of those fees
to improving product integration, making training resources
available, and creating a services arm that can be brought
in to get their product working properly (this last, by the
way, reminds me of the way Detroit used to build cars pre-Deming
religion – fixing the problem post-assembly).
So, if open source were everywhere, but was difficult to
install, how would that problem be solved?
Well, for one thing, we might expect that established service
providers would step forward and offer implementation services.
In a sense, we would see system integrators act in a role
equivalent to proprietary vendors’ services arms.
It’s odd, but we haven’t really seen any of the
large “name” SIs (e.g.., Accenture) create open
source practices. I recently talked to one colleague at a
well-established commercial open source company and asked
about this, and he observed that most large SIs today have
one partner who is their “open source guy” and
he is trotted into customers to discuss open source –
when they demand a conversation about it. However, there is
little evidence that the major SIs are making any concerted
move into open source, which, on the face of it, is curious,
since one would expect them to respond to demand. It’s
likely that they are suffering cultural conflict regarding
open source; beholden to their proprietary partners, they
are unwilling to jump off the gravy train.
However, in a world of primarily open source, those cultural
conflicts wouldn’t exist, and SIs would actively seek
out implementation projects and compete on open source expertise.
Of course, one might observe that paying SIs repeatedly for
one-off implementation projects is repetitive and wasteful
(good for the SI, but bad for customers 2 – N, who are
paying repeatedly for work already performed once; the same
situation exists today, but nobody on the supply side has
an incentive to change it, since both software vendor and
SI benefit financially from repetitive sales), so why not
work to extend the open source product so that it is better
suited for simple installation and less customization is necessary?
In an open source-assumptive world, one would expect to see
end users demand that their service providers donate the extensions
they’ve created on behalf of their customers back to
the open source product community; after all, by donating
those extensions the customer loses little (they’ve
already paid, so it’s a sunk cost), and the mutual donation
of code extensions benefits the overall open source ecosystem.
Gradually, one would see an accretion of code donations improve
individual open source products, with new SI work focused
on business-differentiating additions (likely to be kept proprietary
by the funding customer) or new, non-differentiating functionality
(to be donated as the latest accretive addition to the open
source pearl).
Open source is OK for infrastructure, but where are
the apps?
Open source is great for infrastructure products, but, thus
far, we haven’t seen many open source business applications.
And besides, even if open source applications do become widely
available, they’re not likely to be able to handle the
scale demands of the largest customers. So goes the shibboleth
proclaimed by proprietary software vendors and their apologists:
analyst firms, too-lazy-to-do-anything-but-print-press-releases
technology press outlets, and, worst of all, Stockholm Syndrome-suffering
end users who insist they love being held captive by their
vendors.
It’s true that the open source world has not, to date,
delivered widely-used line-of-business applications. It seems
that the “scratch one’s own itch” approach
that has worked so well for infrastructure has not transferred
to well to applications that require domain expertise in addition
to pure engineering talent. Most of the significant initiatives
in this area are via venture-funded startups that seem to
be Mini-Me copies of the incumbent proprietary vendors; it
remains to be seen how well they’ll fare once realistic
business expectations for commercial open source companies
are confronted, as I wrote about last month.
As noted above, the current solution from the proprietary
world is to charge all users, even those with modest application
needs, expensive fees that, in part, fund creation of the
highly scalable products required by a minority of users.
The proprietary vendors justify this by maintaining that,
absent the investment enabled by everyone paying high license
fees, no large user could afford to self-fund the scalability
work it requires. Does this make sense? It’s something
like Toyota insisting everyone pay Ferrari prices so that
the few drivers that want to take corners at 120 mph have
a suitable car available. Worse, the current application world
also imposes the need to drive and maintain a Ferrari, even
if one’s own needs run more to the fetching-the-dry-cleaning
mode of use.
But, what if the world was dominated by open source software,
yet was suffering because the dominant open source world wasn’t
delivering scalable business applications? How would that
problem be solved?
Rather than proprietary vendors attempting to self-develop
these Ferrari-like capabilities in their software (and taking
forever to do it, as well, as pointed out in this blog posting
by Chris Koch), one might expect that the most performance-demanding
and vertical functionality-requiring customers would band
together with highly capable vendors with deep industry expertise
– companies like HP and IBM – to extend existing
open source applications to meet those requirements. In other
words, the problem would be solved by the application of expense
dollars to create shared solutions rather than by the creation
of capital-eating, intellectual property-hoarding entities
selling proprietary solutions.
What the “Flip Test” tells us
Applying the flip test to understand the world of open source
is enormously instructive. It enables us to see which aspects
of the current controversy regarding open source are inherent
to open source, and which are merely misplaced criticisms
based on unexamined assumptions transferred from the currently
dominant world of proprietary software.
It’s relatively easy to see that the advantages of
proprietary software (which is really what all the criticisms
of open source come down to – it’s lacking some
aspects of what proprietary software delivers) can be addressed
in open source by means other than creating a top-heavy, inflexible,
vendor-centric industry. It just takes imagination to recognize
that there’s more than one way to skin a cat, and more
than one way to marry end user needs with satisfactory software.
Navica News
You can hear me speak at these upcoming events:
February 8, 8:00 a.m.: "Virtualization: The Other Half
of the IT Economic Revolution", Motorola Open Source
Organization
March 2, 9:00 a.m.: "Open Source and Education",
San Jose Education Foundation, San Jose, CA
March 13, 10:00 a.m.: "Open Source ROI: The Real Story",
HP Linux Advisory Council, Philadelphia, PA
March 15, 9:00 a.m.: "Open Source and Programmer Productivity",
Bureau of Economic Analysis, Department of Commerce, Washington,
D.C.
March 20, 1:00 p.m.: "Building an Open Source Business",
SDWest, Santa Clara, CA, joint presentation with Bill Weinberg
May 10, 10:00 a.m.: "Open Source Virtualization: Creating
an Action Plan", Red Hat Summit, San Diego, CA
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:
Where "The
Long Tail" Falls Short
What CIOs Don't
Get About Open Source
By the way, the blog posting I did about "Why CIOs Don't
Care About Open Source" got a lot of traffic and many
comments that were pretty interesting (and a few that were
pretty uncomplimentary -- one person called me an a*********!).
If you didn't get a chance to read the blog or the comments,
I recommend you take a look:
Why CIOs Don't
Care About Open Source
|
