Open Source: The Whole Productby Bernard Golden
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 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.
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?
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.
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.