Open Source: The Whole Product

Published on The O'Reilly Network (http://www.oreillynet.com/)

http://www.oreillynet.com/pub/a/onlamp/2003/10/16/whole_product.html

Open Source: The Whole Product

by Bernard Golden

10/16/2003

As the United States pushed across North America in the 18th
and 19th centuries, immigrants arrived in two waves. The
first wave consisted of scouts, trappers, explorers, and
adventurers seeking new territory, looking, in some cases
literally, for El Dorado, the City of Gold. They didn't care
that towns, roads, and stores were nonexistent. The riches
they lusted for could only be found in unstable and
undefined, even lawless circumstances. When civil society
finally occupied a territory, the second wave began to
arrive: farmers, ranchers, and storekeepers. They wanted to
pursue their occupation in peace and needed stability in the
forms of laws, religion, and schools.

In Geoffrey Moore's book on technology strategy, Crossing
the Chasm, he describes a similar process in the life cycle
of technology adoption: a first wave of adventurers and a
later wave of settlers, whom he calls Early Adopters and
Pragmatists. Each type has different product requirements
that they demand when adopting a technology. The Early
Adopter seeks advantage in new technologies. The Pragmatist
seeks stability with established technologies. Moore's book
is a classic technology strategy book but does it make sense
in a world of open source?

In this article, we'll look at the different types of
technology adopters, how they have responded to open source
products, and how Pragmatists can find comfort in using open
source. We'll demonstrate a new way to source technology,
with examples, finishing with a brief overview of how to
create an open source strategy for your organization.

Life Cycle of Technology

Early Adopters

Early Adopters use technology to offer new services, reduce
costs, or cut time to market. They constantly scan
technology developments to find new products to increase
their business competitiveness. Early Adopters are the
channel hoppers of business, constantly looking for novelty
and new sources of advantage.

Because Early Adopters begin using products early in their
life cycles, they live with often-significant shortcomings.
The technology provider is typically a small, untested
company with an uncertain future. The product may not work
very well, requiring lots of work, multiple installs, and
workarounds to get the application up and running. Moreover,
the Early Adopter puts up with poor technical support,
nonexistent documentation, and the lack of reference
customers. The Early Adopter is willing to live with these
shortcomings, believing that the company can gain
competitive advantage by implementing new technologies.
Early Adopter employees tend to be extremely curious,
excited about new products, and achievement junkies.

Pragmatists

Pragmatists approach technology implementation very
differently. Pragmatists will only use technology when it is
well-established and safe. They won't be left behind and
lose their position in the market, but they're unwilling to
take risks with new technologies. Pragmatist employees tend
to seek well-known, easy-to-use products with lots of help
available in terms of documentation, training, and support.

To sell successfully to Pragmatists, a technology provider
has to deliver what Moore terms a "Whole Product". A Whole
Product has easy-to-use characteristics, easily available
technical support and tutorials, and is stable with few
bugs. There are lots of reference customers around, and
several of the Pragmatist's direct competitors have already
implemented the technology, so the Pragmatist knows the
technology will work for its industry. In short, the
Pragmatist organization is the home of the "It's safe
because lots of other companies use it!" type of thinking.

How This Works in the Open Source World

In the open source world, there is no single provider of
software. Open source is developed by cooperative groups of
individuals, each of whom contributes portions of the
product. The product may have minimal documentation. Often
no support organization is available. Consulting may be
non-existent. In sum, since there is no providing
organization, there are no ancillary services available. How
will these different types of customers react to the reality
of this product development and delivery?

Early Adopters have enthusiastically embraced open source
products. Early Adopters have always worked with early stage
providers, which, by definition, are unconventional
organizations. Early Adopters gain competitive advantages
from open source due to its low cost, rapid release cycles,
and quick implementation of forthcoming standards. The easy
availability of source code makes Early Adopters even more
enthusiastic about open source, since they can fix problems
they run into during implementation without waiting for
immature providers to deliver updated products. Early
Adopters and open source are a match made in heaven.

However, Pragmatists face a real dilemma regarding open
source. Enough organizations have implemented open source
solutions so that the market acceptance criteria have been
met; by this measure, the time is ripe for Pragmatists to
begin implementing open source.

However, the other characteristics of a Whole Product are
missing. Since Pragmatists are reluctant to move forward
with a technology without supporting services, where can
they find the Whole Product? To solve that problem, they
need to look within their own organization and create the
Whole Product themselves. The task may seem daunting, but
the payoff is that with open source a better quality Whole
Product can be created than was ever possible in the
single-source world.

Creating the Whole Product in an Open Source World

How can a Pragmatist create a Whole Product by itself? How
can it find all the resources it requires to feel
comfortable using open source? In a world without Whole
Product providers, the Pragmatist organization must take a
pragmatic approach to the problem, rolling up its sleeves
and doing it itself. It must develop a coalition of
providers who specialize in different aspects of the open
source technology and use them to create the necessary Whole
Product. Pragmatists must use a new model regarding
technology adoption, thinking of themselves more like movie
producers rather than retail buyers.

Movie producers create a final, complete product by drawing
on several specialists: actors, set designers, costumers,
and so forth. The producer takes the responsibility of
selecting them and managing them in order to create the
finished product. Each specialist cooperates with the others
while operating independently.

Pragmatists must take a similar approach to create the
necessary open source Whole Product by drawing together
training, documentation, and support. While this may seem
like a significant effort, there is a corresponding
advantage: by using specialists in each of these areas, a
better Whole Product can be created than is possible by
relying on a single provider.

It may seem dangerous not having a single provider
responsible for the Whole Product, but it may actually be
safer. After all, the flip side of "one throat to choke" is
"single point of failure". It actually may be riskier
placing all the responsibility for the Whole Product in the
hands of a single provider, and risk is something
Pragmatists want to avoid.

Creating the Whole Product: Two Examples

Examples of a concept always make the concept more vivid, so
let me describe two examples of creating a Whole Product.
The first example is a brief overview of how to bring a new
technology into an organization and create a Whole Product
coalition around that technology. The second is a
description of a real-world project that my firm recently
completed, which demonstrates our technology choices and how
we addressed the necessary Whole Product requirements.

Bringing a New Open Source Technology Into an Organization

Imagine that you are responsible for bringing an open source
product into your organization. You have been asked to find
ways to reduce costs in new system development, particularly
in the data storage layer of your systems. At the heart of
many software systems is a relational database. There are
several open source relational database alternatives,
including MySQL. Using MySQL will reduce the cost of a
system from $5,000 to $100,000 or more obviously a
significant savings. The software itself is freely available
for download at no charge. But where can you turn for
documentation, training, and support?

Code Fragments only

There are several superb books on MySQL, both tutorials and
reference, which serve as documentation for the product.
Multiple organizations provide training on MySQL and can
teach the members of your organization how to use the
product. Finally, there are many professional services firms
who offer support for the product (and, for that matter, can
provide specialized consulting if needed). Another excellent
resource for support in the open source world is to draw on
the accumulated experience of other users. This can easily
be done by posting questions to the MySQL mailing list,
which many very experienced MySQL users monitor and offer
help to question posters. This is an outstanding support
mechanism available at no charge.

In this example, the services of several providers are
brought together to create a relational database Whole
Product. Each of the necessary pieces of the Whole Product
is delivered by a specialist and it is undoubtedly better
than a comparable product delivered by a generalist
organization.

Using a Whole Product Coalition to Implement a Project

To illustrate further this new method of creating a Whole
Product, let me describe our experience on a recent project.
We were asked to integrate a web site and a central CRM
system for a large foundation so that user information input
in web forms could be inserted into the CRM database. After
considering several different architectures and products, we
proposed this architecture: a web service for the
integration mechanism delivering an XML file payload
containing the user data. We decided to implement the
integration mechanism in Perl, since commercial alternatives
would have added at least 30% to the overall cost of the
project, which would have caused it to overrun budget. Our
development environment was Windows XP with an Apache Web
Server using MySQL as the underlying database. The
production environment would be Windows 2000, IIS Web
Server, and MS SQL Server as the database.

We used many Perl modules during the course of the project:
several XML-oriented modules for the XML payload, SOAP::Lite
for the Web Services integration piece, and some helper
modules for utility functions. Our favorite helper module
was Win32::Guidgen, as the CRM system uses 32 character
randomly-generated identifiers as table keys. This module
saved us a ton of work writing a routine ourselves.

We relied on excellent documentation available for the main
modules from commercial publishers. Having worked at
commercial software companies, whose product documentation
is typically very poor, it was a real pleasure to find
excellently-written tutorials and reference manuals
available. When it came time for migrating from the
development environment to the production environment, the
book Programming the Perl DBI was a real help in identifying
the migration issues presented by a move from MySQL to SQL
Server.

Even with good documentation, problems crop up during a
project that require further help. We ran into issues that
were not described in the available books; we needed
technical support. Again, we were very fortunate with our
choice of Perl as the integration mechanism. We found superb
technical support available through several different
mailing lists. We got help from around the world from people
who are experts in the areas we had questions about.
Furthermore, many of our questions were answered by the
actual authors of the modules themselves.

The contrast between this model of technical support and the
commercial software world was made glaringly obvious when
other members of the project ran into a problem with the CRM
software. It took them many days of interacting with the
vendors technical support organization to even get someone
to pay attention to their problem; even then, the responses
weren't on target. They finally figured out how to solve the
problems themselves but had wasted several days of valuable
project time.

Overall, we had a great experience creating the integration
piece of the project. The typical problems that crop up when
using new software were easily addressed by our Whole
Product coalition. Documentation was available to learn the
new software. When we had problems getting something to
work, technical support was readily available, sometimes
from the best possible source: the author of the software.
All of this was achieved by creating a Whole Product based
on an open source coalition, which allowed our client to
benefit from a cost-effective solution.

An Open Source Strategy

How does an organization develop an open source strategy?
How can it move from the single-source model to the
multiple-source coalition model as it begins to implement
open source-based projects? How can it become more like a
movie producer?

We recommend the following steps:

* Recognize that several partners and sources of information
will be required. Understand that in the open source world,
you need to seek out multiple elements to create the whole
product. Put an explicit process in place to identify each
of the elements you will need and to select a provider who
can deliver that element.

* Choose a pilot project as a beginning step to using open
source. It's easier to get started and to draw lessons from
a small project that can then be applied to larger projects
and other groups in the organization. Choose self-starters
for the pilot, as they will be doing things for the first
time and will need to be willing to experiment and live with
ambiguity as they help develop a successful whole product
for your organization. In other words, treat your pilot team
as an Early Adopter customer and find people who feel
comfortable in that situation.

* Recognize that most of your personnel are Pragmatists who
want well-established products. Open source is no different
than regular software in terms of what members of your
organization will require for success. Documentation and
training are a must. Let them know about the availability of
support via professional services organizations and mailing
lists. The providers of these services, that is, your
coalition partners, should have been identified during your
pilot project. Make them known to the wider audience as
resources that may be drawn upon for help. Without these
resources, open source products will be no more successful
than poorly supported commercial products.

* Assess the performance of the members of your whole
product coalition over time. Are they capable and
consistent? Do they respond in the timeframes required? Can
you continue to depend upon them? They form a critical part
of your whole product, and if they don't continue to measure
up, they should be replaced with a better provider.

* Continue to track developments in the open source products
you use. As new versions are released, assess whether they
should be installed. See if new documentation is available
for use with the new version. Determine if your coalition
partners are ready to support the new version. If the entire
coalition is not ready, assess whether to replace coalition
members or delay migration to the new version.

Conclusion

While the provider side of Moore's life cycle of technology
adoption has changed dramatically with the advent of open
source, the customer side has changed very little. Some
organizations throw themselves into new technologies in the
expectation of reaping competitive advantage while others
until the business benefits are obvious and the technology
is available with all the desired ancillary services.

Open source is an easy choice for the Early Adopter
customer: low cost, time to market, and extensibility offer
significant business advantage. It's not such an easy choice
for Pragmatists, however, as a single provider will never
deliver the Whole Product. For Pragmatists to reap the
benefits of open source, they will need to use a new model
of technology procurement, and develop a coalition of
providers who together can deliver the technology as a Whole
Product. With that new procurement process in place,
Pragmatists can realize the benefits and business ROI that
open source can deliver.

Bernard Golden is CEO of Navica, a Silicon Valley system
integrator specializing in open source solutions.

To facilitate co-ordination regarding the introduction of OSS SW in Vietnam

Subscribe to OSS:

Subscribe | Unsubscribe