Section 5.1. Crafting a Strategy for Open Source Adoption
5.1. Crafting a Strategy for Open Source AdoptionBefore considering any serious use of open source, an IT department should check that it is willing to adopt two fundamental assumptions: a belief in skill building, and the slightest inclination to increase responsibility and control over its IT infrastructure. Even the simplest uses of open source require that some skills be brought into the organization, and unless an IT department wants to have a key-person problem, it must try to capture those skills. The second aspect is an ambition to take charge of more of the IT infrastructure. Open source provides greater control and comes with greater responsibility. If this is not of value to an IT department, open source will seem like a lot of work. Many smart people and successful companies have neither of these attributes. General Motors, for example, has a policy of outsourcing all its IT to EDS. GM is not interested in control and responsibility. At GM, paying someone else to deliver is the fastest, most certain way to get value from IT. Will your business benefit from having a more skilled IT department? For many companies, where IT costs are not large and the use of IT is not a differentiator, perhaps the answer is no. Increasingly it is also possible to use open source by paying a consulting firm to install and maintain a program. This is not really using open source as much as it is using a service based on open source. While it might be a good idea for a company, it is not what we mean when we talk about open source adoption. So, if an IT department is willing to adopt these two fundamental assumptions, the next question is, does it have the skills? In Chapter 3, we described several different layers of skills. If an IT department has these skills already, using open source will be less time consuming than if it is starting from scratch. Different skills are required to run open source as a computing platform as opposed to running open source applications. If an IT department uses Unix systems heavily, it is likely to have most of the skills required to run Linux, the foundation of the open source computing platform. If a department is able to run only Microsoft .NET or Windows, running Linux requires a greater leap. It might make sense to run only open source applications that function well on Microsoft operating systems. It is a mistake to think that using Microsoft-friendly open source applications reduces the scope of the opportunity significantly. A huge amount of open source runs perfectly well on the Microsoft platform. The next question is, which open source projects offer an IT department the most value? Answering this question requires developing the skill of evaluating open source that we described in Chapter 2, and just networking and looking for open source projects that might be useful. We hope an important part of this process for many people will be reading Appendices A through F, which provide a survey of the most promising open source projects for various areas of concern for IT departments. Of course, the decision to go with open source always involves risk, but performing the sort of ROI analysis we described in Chapter 4 can give an IT departmentas well as company managementa reasonable degree of certainty concerning how much it stands to gain by implementing open source. Now, our analysis will turn to the subject of finding the right path to open source adoption. 5.1.1. Steps to Low-Risk Open Source AdoptionThe approach we recommend is a sober one. You will gain nothing by waving the open source flag and applying it everywhere possible, without forethought and planning. This is impractical and rarely makes sense. Even the most highly skilled companies that are enthusiastic users of open source also use plenty of commercial products. Our method for addressing the right approach to using open source consists of the following:
By following these steps, you will discover whether open source is a natural fit for your IT department. If the initial burst of enthusiasm is followed by a sense of dread at doing the work involved, perhaps open source is the right choice in only a small number of situations where open source projects are as productized and mature as commercial software. However, if the spark of excitement at doing it yourself with open source becomes a morale-boosting project that restores enthusiasm and creativity to a department, expanding the use of open source probably makes sense. The following narrative describes how skills might develop at an IT department that is starting from scratch and does not have existing skills in Unix or Linux system administration. 5.1.2. Starting from ScratchThe extreme case of starting from scratch occurs when an IT department that knows very little about open source is interested in finding out if open source can help it achieve its goals. When an IT department starts from scratch, it should begin by asking all the questions we outlined in the previous chapters. Is there any open source that can help? How mature is it? Do we have the skills to handle it? What are the fully loaded costs? Frankly, answering these questions through analysis alone will not produce high-quality results. To answer these key questions, an IT department has to install some open source and start using it in an experimental fashion. Fortunately, highly productized open source products that are aimed at end users and can be used right away are available. The OpenOffice.org products provide a full suite of desktop productivity applications, including spreadsheets and word processors. The Mozilla.org products provide a first-rate email client. Other, more challenging products include SpamBayes, an extension to MS Outlook for filtering spam. Depending on the environment, just using this category of open source can provide many major benefits. If classes of users use PCs for minimal word processing, web browsing, and email, the savings in licensing fees could be substantial. However, this makes sense only if a department is ready to learn how to provide support or create a relationship with a consultant or service provider to do so. In performing experiments using such software, an IT department can gain a much better understanding of whether the risks and responsibilities of open source feel right. Such use of open source represents only a small fraction of the potential value open source can offer most IT departments. Rather, most IT departments will benefit by finding open source projects that either replace existing systems or extend the infrastructure in beneficial ways. In Appendices A through F, we suggest many open source projects that do both. Assuming the IT department starting from scratch is Microsoft oriented, the next step is to look for mature open source applications that are Microsoft friendly. Such users will likely benefit more from open source projects focused on applications or useful tools such as Wikis, content management systems, or applications for specific job functions or tasks. Getting these sorts of programs running, and supporting them for experimental use, is not difficult. However, just gaining the ability to solve the problems in getting mature open source to work is a significant step forward. In addition, unlike with open source projects for end users, this involves skill in understanding how the components that lurk underneath open source programs work together. Most of the types of programs we have mentioned use a database, a web server, and, sometimes, other utilities. If an IT department can easily make standard open source components work together, a huge world of open source applications opens up. When you are starting from scratch with open source software, you should stop at the experimental stage until you are confident your organization has the skills we described in Chapter 3 to support the use of open source in production. At this level, it is important to be skeptical of self-assessments of skills from the IT department. Instead, skills can be gauged by keeping track of how much time is being spent on open source projects to determine the actual costs incurred. One cautionary note: an IT department starting from scratch might find that the experimental systems quickly become operational if the functionality provided becomes popular. This frequently happens with programs such as Wikis, which gain favor with end users and project managers, because they are easy to use and enable free-form communication. If an IT department is not careful, a support burden that it is ill prepared to handle or uninterested in assuming can be thrust on it by popular demand. In summary, starting from scratch involves:
5.1.3. Becoming a BeginnerAt the end of the starting-from-scratch period, an IT department has begun to understand the components of a mature open source application. Getting the parts working together experimentally is not difficult, but it is hard to determine in advance what sort of problems will be encountered. The real challenge at the beginner level is to figure out when you have mastered the components of an application to an extent that you can support them as part of your IT infrastructure. For example, with a content management system such as Drupal, which is based on PHP, an IT department must be able to provide the same support that any professionally managed system requires. This includes scripts for start-up, shut-down, back-up, and operational monitoring of the open source software, as well as a playbook for diagnosing what is going on with the database, application, web server, and any other components. When something goes wrong, the solution should be to run a process, not to find a person. If an IT department has established operational procedures, supporting open source means finding out how to run those processes against open source applications. IT departments get nervous as they approach the launch of an open source application, because if something goes wrong, there is no support hotline to call. The only remedy for such nervousness is experience. Open source projects should be run experimentally with a lower service level until an IT department can develop and institutionalize the skills needed to support it. Then when a problem occurs, an IT department will feel more comfortable and be better able to resolve it. The first applications IT departments should focus on at the beginner level are those that are mature and provide a specific function, without requiring a lot of configuration. Open source applications for bug tracking, Wikis, source code management, or weblogs fall into this category. The goal is to introduce complexity gradually. The productized end-user applications mentioned as a first step are the simplest and most familiar to use and support. The next step is to deploy the mature applications that do not require lots of configuration and customization. Then the challenge is to learn how to support these applications in a reliable and professional manner. This level of expertise, which is not hard to attain or institutionalize, opens up a vast world of applications to an IT department. Supporting open source at the beginner level also builds confidence for taking the next steps. Additional challenges at the beginner level include carefully containing the rate of open source expansion. Enthusiasm from users and from within an IT department can easily result in products being pushed into production before proper support procedures have been designed and implemented. At the later stages of the beginner level, an IT department should start two sorts of experiments. The first is to use more complicated open source applications that require more configuration, but only at an experimental level. Content management systems, application servers or development environments, and open source versions of large-scale enterprise applications for ERP or CRM fall into this category. Gaining experience with more complicated open source will force most IT departments to decide how far along the open source path they intend to travel. Just as with commercial software, it is important to reduce the number of different skills that you need to learn and to leverage the skills that you already have. Maintaining an institutional skill level in any one open source language or component is not easy. The more components you choose to support, the greater the costs will be. Working with more complicated open source usually means understanding how to write code, or understanding the complicated workings of templating mechanisms or other complicated abstractions for controlling software behavior. At this point, an IT department becomes a Perl, Python, PHP, or Java shop, out of necessity. The second sort of experiment at the beginner level is to install and use Linux. We consider starting with Linux a mistake, especially if an IT department does not already have Unix skills. The trip from no Unix skills to minimal Unix skills is much longer than the trip from one flavor of Unix to another. Learning Unix-style system administration is much less beneficial than simply using the sorts of open source applications that can be run on Microsoft operating systems. While this does put some open source out of reach, almost all of the more mature and most of the valuable open source runs well on Microsoft, including MySQL, Apache, Perl, Python, PHP, and many other major projects that are based on these technologies. The more mission critical the system is, the higher the level of Linux skills that will be required. Developing these new skills as an institution can take time. Support services of the sort we mention in Chapter 6 can help, but to use any platform in production, you must have a significant skill base, regardless of how much support is provided. Despite the learning curve for supporting Linux, it is worth pursuing, because it provides a stable platform that allows the widest possible scope of open source to be used. Companies such as Amazon and Yahoo! have used Linux and other open source operating systems to build high-performance systems using the cheapest possible hardware. To summarize, the beginner level involves:
5.1.4. Moving to the Intermediate LevelThe intermediate level of open source expertise is all most IT departments require to get the full benefit from open source. At the intermediate level, an IT department understands how to find, evaluate, install, configure, and support open source applications. These applications can be running on Linux or Windows. The difference between the beginner and intermediate level is how well the open source applications are understood. Beginners understand open source projects well enough to run them in a stable and reliable manner. For more mature open source software, beginners still understand the software as a relatively simplistic black box. For intermediate-level users, software configuration, customization, and integration are the key skills, and their ability to understand how the applications work is far more sophisticated. Here is where configuration of templates, or the complicated abstractions that control an application, starts to cross the boundary into software development. The task of integrating applications with one another and with commercial software usually also requires development, as does extending applications by adding new features. At the intermediate level, a department becomes comfortable performing simple development projects, and then testing, installing, and supporting them. All of this requires a staff that has an increased skill level. One benefit of the increased confidence that is gained at the intermediate level is that support of mission-critical applications becomes possible, because the department now has a much more complete understanding of the software it is using, as well as how to support that software. At the beginner level, departments understand applications only as relatively large black boxes, which is not sufficient for mission-critical support. However, as the skill level rises, so does the amount of work required for institutionalization. It is impossible for even a large IT department to be skilled in even a small fraction of the open source available today. Intermediate-level users must make important decisions concerning which open source components, languages, and projects the department will focus on. Once the department has chosen a focus, perhaps by concentrating on PHP, it becomes confined, in a way, to that type of open source. It becomes easier to use projects that are based on the chosen technology, because the institutional skill level is higher. Of course, this is a long way from vendor lock-in, but it is lock-in nonetheless. Another source of lock-in at the intermediate level is the integration between open source components and the investment in application configuration, both of which represent an outlay that is not easy to replace. It is at the intermediate level that the few who are masters of IT really can show their mettle. The decisions made at the intermediate level are vitally important because they essentially lock an IT department into certain components and skills in the same way that product choice binds an IT department to a vendor. The business as a whole will succeed or suffer based on how well these long-term choices match the business's requirements. Making these decisions properly is an art form that requires a deep understanding of the technology, the business requirements, and the forces driving the evolution of both. The decisions made at the intermediate level determine whether an IT department is a Perl, Python, PHP, or Java shop, whether it uses MySQL or Postgres, and what key infrastructure is used for development and integration. At the intermediate level, a Windows shop can determine that it makes sense to use Linux or other open source operating systems. With an understanding of the true costs of supporting open source, an IT department can determine if it is worth the effort to reduce costs by using Linux instead of Windows. The answer should be based more on money than on open source religion. At the intermediate level, enough data should be available through experimentation and experience to make an informed decision. There is no need for most IT departments to move beyond the intermediate level. Rising to the advanced and expert levels means becoming a full-fledged software development shop, which is a wise choice for only a small number of IT departments because of the high level of skill that must be maintained. In summary, the intermediate level involves:
5.1.5. When the Advanced and Expert Levels Make SenseMoving to the advanced and expert levels will be a reasonable step for only the small number of IT departments that genuinely need to develop their own solutions. The advanced and expert levels are about using open source as a platform, integrating and extending applications, and creating new ones to meet a company's specific needs. Development at the intermediate level is about extending an application in ways that have been anticipated or for which the context has been set by others. Development at the advanced and expert levels means designing and building an entire application from the ground up. This is a much more difficult skill to obtain and institutionalize. At the advanced and expert levels, an IT department can do anything. This means that even more of the focus we described in the previous section is required to avoid spreading resources too thin. At this level of skill, an IT department can create a high-performance application to meet a business's precise requirements. The challenge, then, as with any custom development, is to properly document the development and maintain the skills to support it. Without careful attention to these matters, the high-performance custom solution of today can easily become the legacy albatross of tomorrow. The other opportunity that advanced- and expert-level skills afford is the ability to participate in or lead development of open source projects. It is not uncommon for IT departments to encourage participation in the development of open source that is highly relevant to their requirements. The largest danger for IT departments is to follow the lead of a single person who is able to perform at the advanced and expert levels and forgo the skill building and institutional support required to keep a project going once that person leaves the organization. To summarize, the advanced and expert levels involve:
5.1.6. Institutional Skill BuildingOne of the biggest dangers in using open source, which also can appear in many other areas of IT, is pooling knowledge in one person, thereby creating a significant vulnerability should that person leave the company. One of the reasons IT departments rely on vendors and consultants is to avoid this situation, and instead to document or otherwise preserve the skills of the organization rather than of a single individual. Transferring skills from one person to other members of the team, and documenting and systematically preserving those skills, is the essence of institutionalization. At many points in this book, we have emphasized the concept of institutionalizing skills to avoid the key-person problem. Now we will explain what the process of institutionalizing skills involves. First, let's look at what happens in the typical key-person problem. A talented programmer takes the lead on a project and creates a brilliant solution to an urgent problem facing the company. The IT department's managers often recognize that should that talented programmer leave the company, the department will be in a vulnerable position. But in the crush of day-to-day priorities, this priority gets lost in the shuffle. Then, something happens that lures the talented programmer away. In her final two weeks on the job, the talented programmer attempts to pass along the knowledge and skill required to support her efforts. Unfortunately, this attempt is rarely successful and the department must scramble to figure out how to support the talented programmer's work in her absence. The better course of action, and the one required for prudent use of open source, is to identify systematically the skills that are required to support the talented programmer's work. This is harder than it appears, because it is not easy to create an accurate list of the skills required to support an open source project, and it is even more difficult to then document and transmit these skills. Most of an IT department's skills are never documented or transmitted systematically. Instead, job descriptions define the sort of person needed to perform a job and the skills she requires. While on the job, she learns what is required from colleagues or other sources and maintains that knowledge by doing the work repeatedly. The key to institutionalization is not only to identify the skills to include in a job description, but also to have a group of people who perform the work regularly and to maintain an appropriate level of documentation for the organization's future needs. In building systems for the space shuttle or a commercial software product, much more must be documented than for most of the systems in your average commercially oriented IT department. As open source has grown in popularity, it is increasingly possible to purchase support services from a new category of company that has been created to sell support services for open source. Chapter 6 describes the sort of services being offered by such consultants. Creating relationships with small consulting firms or individuals who are expert in open source also can help provide access to skills. However, to choose the right firm or manage these relationships, you must already have some level of skill in-house. With open source, there really is no way out of developing and maintaining certain skills. At the end of the journey toward open source adoption, what will a company achieve? In one word: empowerment. As we describe at length in Chapter 10, using open source changes an IT department into a more powerful and self-sufficient organization. To achieve this level of benefits, however, two other thorny issues must be addressed: applying open source to the right problems, and creating processes required to manage the introduction of open source into an organization. |
