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.
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 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.
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.
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.
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.
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?
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.
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.
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:
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.
Return to ONLamp.com.
Copyright © 2009 O'Reilly Media, Inc.