In our efforts to find ways to lower project costs, we came across something called open source software. Given my background in large IT shops, global consulting firms, and enterprise software companies, I was pretty skeptical about a product that promised something for nothing. The whole ethos of volunteers delivering high-quality software seemed counterintuitive to me. Furthermore, I wondered how we could obtain support and training for the product. In short, I couldn’t understand how open source worked. However, I felt we had to try open source as part of our effort to do the best possible job for our clients.
Our experience with open source amazed us. Far from our nightmare vision of poor quality code distributed by a flaky group of unqualified idealists, we found that robust products were available that performed more than adequately—we were able to succeed with open source. I knew we were onto something when our clients began to ask, "What other open source software can we use in our system?"
This presented us with another problem. Many of our clients accepted without question our open source recommendations; after all, the role of a professional services firm is to serve as a trusted advisor, and these clients expected us to fulfill that role. Others, however, although not mistrusting us, would inquire how we chose the proposed product. If the project plan called for turning the system over to them after implementation, they would ask about training options and quality, where they could turn for support, and so on. Even though we had seen good results with the products we recommended, we really had no formal criteria or documentation we could point to as the basis for our recommendation. The problem was compounded if our clients needed to get approval for the project from higher-ups in the organization. The higher you go in an organization, the more formal the paperwork needs to be. It wasn’t nearly enough to present a slide that, under selection criteria, stated "a guy from the system integrator heard this was a good open source product." Clearly, our clients needed something more concrete for their project approval and budget process.
Even if our clients would have accepted an informal method of selecting open source products for their projects, I was uncomfortable with it. A career spent creating and implementing mission-critical software has made me acutely aware of the importance of assessing software in all its dimensions: functionality, support, training, and documentation, among others. If we were going to recommend open source products as a key piece of our client’s software infrastructure, I felt we needed a more formal methodology that would assess a product along all of those dimensions before we put it into production.
Out of that came our development of the Open Source Maturity Model (OSMM). This model assesses open source products for their maturity—essentially, their production-readiness. The OSMM enables one or two people to evaluate an open source product with less than a week’s work. By doing so, the model quickly identifies which products are worth a more in-depth pilot-project evaluation. Using the model has made us more comfortable with our recommendations, made our clients’ project-approval process flow much more easily, and significantly reduced our clients’ project risk.
As we’ve created open source-based systems for our clients, I’ve concluded that all IT users share their motivations. Open source is going to be widely used throughout the industry. Its cost structure is compelling. I believe the move to open source is consistent with the cost-reduction trend in all industries via customer self-service and self-reliance. As an example, look at the airline industry. In the beginning, it delivered high-cost, full-service transportation, complete with elegant meals and personal attention. Today, airplanes get you there just as fast, but elegance is but a distant memory. Passengers book their own tickets on the Internet (Remember travel agents? Another victim of self service. . .), bring their own meals, and pay extra for a movie, all in the name of low fares. You’ll occasionally hear someone nostalgically recalling the long-gone days of elegant airline travel, usually a passenger about to step onto a Southwest Airlines jet—the Greyhound bus of the sky. The obvious IT analogy is the hardware transformation driven by Dell. You get a rock-bottom price but are expected to install and configure the system yourself. I believe software is going to tread that same path: low prices (free in the case of open source) accompanied by more do-it-yourself work.
Because of this belief, I decided to share our experiences with open source. As it becomes more widely used, a formalized method of selecting and assessing open source software and all of its elements will be extremely useful. You can take advantage of the system we use and shorten your learning curve with open source products. There is no turning back: You will need to be more self-reliant in the future as you choose and implement software. I hope you find the material in this book useful. If you do (or, for that matter, if you don’t), I would be delighted to hear from you; I can be reached at bgolden@navicasoft.com.Please visit the site to view the latest information.
