Cover | Table of Contents | Colophon

Table of Contents

Chapter 1: The Nature of Open Source

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This book is a long and thorough answer to the question, is open source right for you? The intended audience is the typical Information Technology (IT) department that is charged with supporting a business with appropriate application of technology. This book is written from an IT department's perspective and is organized around the common problems that face those who struggle in the trenches. The goal of Open Source for the Enterprise is to help technology and business executives determine whether they can benefit from using open source in their environments.

Open source began as free software built by thousands of volunteers who shared the results of their work without charging any fees. Billions of dollars of value has been created based on this simple structure. The adoption of open source software has become a cultural phenomenon. The basic facts regarding the growth of the open source movement are amazing.

Open source success stories are well known and more arise every week. For instance, the city of Munich chose OpenOffice.org, an open source suite of desktop applications, very publicly sticking a finger in the eye of Microsoft, which aggressively sought the contract. Amazon.com dumped Sun hardware and software in favor of Linux, the most popular open source operating system available. Apache, an open source web server architecture, is the most popular web server in the world. Perl, a robust scripting language, is used to run huge, highly scalable sites such as Ticketmaster. Large financial companies are creating massive clusters of Linux machines for crunching numbers in complex portfolio analysis. This is just the tip of the iceberg. The examples of corporate success for open source would fill a phone book.

Internationally, open source is being adopted by entire governments. Smaller communities are using it to create versions for their specific languages. China, Brazil, Thailand, Peru—are all adopting open source software officially and are spending millions to improve the software and encourage its adoption.

All of this success has changed the nature of open source. No longer can one assume that the typical open source project comprises a small band of programmers toiling away in obscurity. Major technology vendors got open source religion and made broad and long-term commitments to open source software. IBM released as open source its Eclipse platform for creating development tools, a project on which it spent $40 million. IBM has become the largest corporate proponent of Linux, and it spends hundreds of millions of dollars to support and market that platform. Hewlett-Packard uses open source in all sorts of ways, from supporting development of useful projects to releasing device drivers into the marketplace. Novell has purchased several major open source-related companies, and is creating a large and integrated collection of open source applications for enterprise use. Nearly every important enterprise-grade software product has support for Linux. Even commercial web servers based on Apache are available, including Hewlett-Packard's Secure Web Server for OpenVMS.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The Open Source Debate

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

One way of looking at this book is as a tour of the benefits and responsibilities of using open source. The opportunity provided by open source is too large to ignore for any organization that seeks to support its operations with software.

The scope of open source has grown beyond basic development tools to become a top-to-bottom infrastructure for computing of all stripes, including development environments, databases, operating systems, web servers, application servers, and utilities for all types of data center management. Open source now encompasses a huge variety of end-user applications, such enterprise applications as Enterprise Resource Planning (ERP) and Customer Relationship Management (CRM), tools such as portals and data warehouses, and integration tools for messaging as well as for web services. All of these can be the foundation of the sort of automation and productivity gains that can lead to a company's competitive advantage.

But in most organizations, discussing open source brings up strong opinions on all sides that obscure pragmatic analysis of the key question: can you use open source profitably at your organization?

There is no simple answer to this question. People on both sides have good points to make and are also protecting their own interests. At its worst, the debate becomes a cartoonish farce.

Programmers, systems administrators, and other technologists who are fascinated by various open source programs might tout the fact that the software is free. While this is true, managers sometimes suspect a hidden agenda of seeking more cool toys to play with, without adequate consideration of the other costs that are incurred when using any piece of software, including the costs of evaluation, testing, installation, configuration, customization, upgrades, operations, and support.

Managers frequently take the opposite position, that open source is not worth considering because it can lack features of commercial software such as support and maintenance services, installation scripts, and documentation. For good reasons, managers like the idea of one throat to choke if something goes wrong. It is a remedy for the finger pointing that characterizes all commercial technology support in multivendor installations. But hiding behind this objection ignores the fact that technologists at tens of thousands of companies have proved that the risks and responsibilities of using open source are manageable.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Understanding Your Open Source Readiness

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Whether open source will work at any company depends on both the capabilities of the company and the maturity of the open source software. The fact is that some open source is so rickety that it isn't useful to anyone except the most highly skilled. If you browse the popular directories of open source software, it doesn't take long to find dormant projects that have not been updated for years. For example, Cheetah, a Python-powered template engine, was posted on the www.freshmeat.net site on July 15, 2001, was updated July 16, 2001, and hasn't been touched since. Other open source software, such as the Apache Web Server, is at the other end of the quality spectrum; it is widely considered better in every way than all the commercial alternatives, and it is as easy to use. Thousands of projects occupy the space in between these two extremes.

Not all users of open source are equal. Given the IT budget of Amazon, Google, Yahoo!, or Ticketmaster and the pedigree of their engineering staff, it is no wonder that they can make open source work. They could write their systems in assembly language. But when you look far from the gurus of Silicon Valley and focus instead on the city of Houston, or on the Ernie Ball Company, a guitar-string maker that's run entirely on open source software, you must realize that there is some middle ground. You don't have to be an MIT Ph.D. to make open source work for your business or organization.

The difference between the successful open source implementation, in which the value of open source is realized for a company, and the unsuccessful one, in which the struggle to use open source is not worth the effort, amounts to knowing your problem, knowing the software, and knowing yourself.

The key to a successful outcome in applying open source is a thorough understanding of answers to the following questions:

• What problem are you trying to solve?

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The Nature of Open Source

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The way that open source comes to life, evolves, and finds its way to new groups of users is a profoundly democratic, decentralized, and somewhat chaotic process. For commercial software, investors demand a plan reflecting what the software will do and who will buy it. Vendors pay for sales staff, marketing and advertising departments, and conferences and events to let potential buyers know about their products. The trade press offers a steady stream of product reviews. Analysts write reports on new types of products.

Open source is a grass-roots effort. Open source developers create code to meet their own needs, and throw it up on the Internet so that others can interact with it and make it better. Nobody buys you lunch. Nobody is going to call you on the phone and suggest that using open source is a good idea. In most cases, you will have to find out about open source software yourself. It will not come to you. This is slightly less true now than it used to be (see the upcoming sidebar, "Open Source Sales and Marketing"). IBM will call you about Linux, but the conversation will quickly get to hardware and services. Newly formed support companies are also encouraging use of open source, but none of this changes the fact that open source means taking responsibility.

The way that open source grows is an amazing demonstration of community evolution. It turns out that communities are not interested in documentation until late in the cycle, and even then the documentation does not tell you what you need to know about the project's health and how well the software works.

So, when you go looking for open source to fill your needs, it can be difficult to understand what is happening with a particular project. For the most popular and widely used projects, a lot of information is available, including books, magazines, conferences, and even consultants offering services. But leaving the most popular products aside, there are many sources of raw data but a dearth of useful information.

If finding and evaluating open source is this difficult, one might ask, why bother? The reason is that open source has grown to such an extent that huge opportunities are waiting for IT departments. Many of the newly formed open source support companies are focused on drawing IT's attention to these opportunities.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

What Is Open Source?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

We've been sharing software since computers were invented. Significant portions of the early IBM operating systems, such as HASP (a print spooler), were developed in the field by users sharing and improving the software. IBM happily accepted that informally shared software, called it "field development," and then included it in the operating system that helped run the huge mainframes that were the company's vehicle for making money.

Today, this would not even be considered open source by its strictest definition. Many believe that software can be defined as open source only if it meets the 10 criteria in the "Open Source Definition" that is published and maintained by the Open Source Initiative (OSI; http://www.opensource.org/).

In the academic and scientific community, sharing software has always been a routine part of research and teaching activities. Many books tell the story of Arpanet, and how the Internet was developed and improved by sharing code over the network, with hardly a thought about licensing.

When PCs proliferated, starting in the early 1980s, a thriving exchange of software developed. This evolved into freeware , software that was available for use at no charge, and shareware , software that was available to try, but with the proviso that if you used it regularly, you should send in a small licensing fee. Extremely popular programs such as PKZIP, a file compression program created by Phil Katz, grew at amazing rates under this model.

Here we get to the key difference between open source and all other forms of software sharing. Open source is not just about giving away useful tools. It is about sharing source code and keeping it sharable. Remember that in open source, unlike in shareware or freeware, all of the source code used to build an application is shared, not just the executable version that allows you to run the program but not see how it works or be able to improve it. At its core, open source is about a cycle of innovation in which those who have the skills share ideas and build on each other's work.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Where Does Open Source Come From?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Most of the time, open source is born out of a need that leads to inspiration. Somebody somewhere who is frustrated, bored, or in some other state of creative readiness starts with an initial thought that begins with one of these phrases: "Wouldn't it be cool if" or "I am sick of having to put up with..." or "I bet a lot of people would like...". The end of these statements is a description of some sort of software. In open source parlance, this is called scratching a developer's personal itch .

Linus Torvalds thought it would be cool to have a full Unix implementation that ran on the Intel chip set, and he created Linux. Larry Wall was interested in a language to help him with system programming tasks, and he created the Perl language. A group of people building their own web sites were frustrated with the NCSA web server and started sharing patches to it; these patches became the Apache web server (a-patch-y server; get it?).

The key thing to remember is that at first the designers and builders of open source applications were the primary users as well. This is the first principle of open source:

Open source software is most frequently built by programmers for other programmers.

So, what follows inspiration? Well, hard work, of course. The inspired developer now sets to work, creating the masterpiece that will solve the problem at hand. There is no formal requirements-gathering process. There is no market research. There is nothing but a smart, driven person thinking about what he wants to do and then setting about doing it.

After toiling alone at a keyboard, the inspired developer creates something that he is proud of and then shares it with others. This is the real birth of an open source project. If other programmers are captivated by the way the software meets a need they also have, they will join the project as either users or developers of the software. If such a community forms, the open source project is on its way to faster development and wider recognition. The second principle of open source, then, is as follows:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

How Does Open Source Grow?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

So, there the inspired developer sits, with a handful of competent developers contributing to the project, all of them working away to make the software better. How does this work? The inspired developer is now the acknowledged leader of the project, but the position doesn't come with much authority. Frequently, no legal agreements of any kind define the relationships in the community, except for the open source software license used to declare the software's terms of use. Usually there is a shared source code repository, perhaps a web site that is used to organize the work of the project, and an email list that is used for communication. Any rules or structure are informal and are a matter of community acceptance and voluntary compliance. Very few projects have stated these rules in writing. The Apache Software Foundation's community process is a rare example of a formal process, but even this process must be voluntarily accepted.

Because of this loose structure, an open source project is usually more like a high school rock band in a garage than the orderly and planned engineering process used in designing complex products such as automobiles. Rock bands break up and re-form quite often before (and after) they become successful. Open source projects are the same.

As a result, an informal community culture forms. Generally, the project leader—who is usually the inspired developer, but sometimes is someone else who is more suited to the task—starts setting the agenda and making a few rules. For example, is testing important? Is backward compatibility important? Are users welcome to participate or are they an annoyance? Are decisions made by a group vote or by one person?

The structure of open source communities can be all over the map. Some have a project leader and others have a community of developers. For example, the Apache Software Foundation is a meritocracy. There are no project leaders per se, but natural leaders emerge as they gain respect from peers working on the project.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

How Does Open Source Die?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In some respects, most open source projects never really die. Even if the original developers abandon the project, the source code usually remains available so that it's possible for someone interested in the code to pick it up at a later date and bring it back to life. This lowered risk of losing access to an application, in fact, is one of the advantages that comes from using open source. If a proprietary company builds a product and then goes out of business, the source code might be gone forever; with open source, there's always an opportunity for a user to pick up development himself (or fund some other party to continue development).

That being said, many open source projects do "die" in the sense that they become dormant or are abandoned by their developers. Many open source projects die, because a community never forms around the need. In the early days, such deaths were invisible. But now, thanks to the rise of public web sites such as SourceForge (http://sourceforge.net/index.php), where open source projects can be started and shared, many stillborn projects are there for all to see. For example, not much has been happening with the Skydiver's Online Logbook project (http://skydivelogbook.sourceforge.net/).

The second way that open source projects die is that they never reach completion. The inspired developer creates some software that partially meets the original need, and then for one of many potential reasons he loses interest in the project. The inspired developer gets married, has a baby, gets a new job, has a big project at work, gets bored, starts learning guitar, whatever. For some reason, he is no longer compelled to work on the project, so there it sits, in a half-completed state. Sometimes, at some point another developer picks up where the inspired developer left off, but usually the project just languishes and the source code collects digital dust.

One common reason that open source projects die is that the community behind the project has a schism and some of the developers copy the source code to a new repository and start doing things their own way. This is known as

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Leadership in the Open Source Life Cycle

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You can define success for an open source project as a community of developers making steady progress creating software to meet a need. Greg Stein, the chairman of the Apache Software Foundation, who has been deeply involved in many different open source projects, observes that there are two keys to the success of an open source project:

Figure 1-1: The open source life cycle

• A clear, shared focus for the project's vision among the developer community (i.e., strong shared values among the developer and user communities)
• A project lead who encourages and rewards community participation

From the perspective of an IT department using open source, evaluating leadership quality is crucial, because it is such an important factor in the long-term viability of an open source project.

It is much easier to understand the concept of leadership in the commercial world than in the world of open source. In the commercial world, somebody is writing payroll checks, a formal corporate structure is in place, and people are assigned authority. People come and go, but who is in charge is not really at issue most of the time. Staff generally is motivated by getting paid, the challenge of the work, and the status and rewards of building a successful business.

Take out the formal authority and the getting paid part, and you are left with the motivation for most open source developers. They are working for the love of the craft and for the rewards of creating a successful open source project.

When a project leader is rigid, doesn't accept and acknowledge the contributions of others, and is hostile to new directions for a project, it is much harder for a community to form.

"When someone comes to a project lead with an idea, the right attitude is to respond 'Cool idea, why don't you run with it' in most cases," says Stein. "Reconciling differences of opinion and at the same time keeping people motivated requires diplomacy, an inclusive attitude, and a generous, secure personality."

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Second-Generation Trends in Open Source

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Some of the characteristics that governed the early days of open source have changed now that open source has become popular. Today, open source software is often being created not just for programmers, but also for end users. The OpenOffice project has created versions of nearly all popular desktop applications for word processing, spreadsheets, presentations, and email. Today's open source projects are starting to compete with successful commercial projects, by developers who want to create a better solution or by commercial companies seeking to create open source alternatives for their own purposes.

It is also becoming more common for large and small companies to use open source code as the basis of applications they have built, either as products or for internal use. Sun Microsystems has been a strong sponsor of the development of open source solutions including OpenOffice, which has become an increasingly credible alternative to Microsoft Office. SAP released a version of a database it bought from another company as open source to provide a database alternative to power its enterprise applications.

The early days of open source focused on creating infrastructure that could be used to create programs. The GNU C compiler enabled the creation of languages such as Perl and development tools such as Emacs so that they could run on a wide variety of platforms. The Linux kernel itself, Apache, databases including MySQL and Postgres, graphical user interface toolkits such as GTK (which led to the GNOME desktop) and Qt (which is the basis of the KDE desktop), and hundreds of other programs have resulted in a top-to-bottom application stack that helps developers create the tools they need, from the bare metal operating system right up to the user interface layer.

The existence of this complete stack has resulted in a proliferation of applications aimed at specific groups of users. Open source has become a new way to start a software business. A developer creates an open source product, gets help from a community of developers who are interested in the area, and runs a consulting business selling services to put the open source software to work. Open source content management systems such as Bricolage and Plone (both of which are covered in detail in Appendix E) have consulting firms operating on this model. Open source products exist for ERP software, portals, data warehouses, and enterprise application integration. The maturity of the stack has created a huge opportunity for IT. Learning how to take advantage of it is the point of this book.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The Different Roots of Commercial Software

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Commercial software comes into existence in a completely different way. At the core of the creative process for commercial software is a vision that many people will pay for the software being created. For open source software, the intended audience and the developer are usually the same. So there is no mystery about what the audience wants. The requirements process consists of developers deciding among themselves what they want the software to do.

Commercial software companies must somehow determine what the intended customers want. This introduces a large amount of risk into the process, because determining requirements means making lots of assumptions about whom the audience is. The economics of commercial software resemble those of a health club. Customers pay to join the club, because they can get access to a much better facility than if they built it themselves. But the club has to have the exercise machines the customers want. In commercial software, costs are shared across all customers and the company must create software that is powerful and configurable enough to solve business problems in all sorts of different environments.

Figuring out the needs of the market is a key skill for a commercial software company, and many people are involved in the process. Investors in the company, or the product marketing department, might conduct research to understand what customers want. Prototypes might be built and put in front of the target audience.

The problem for most commercial software companies is that it is fiendishly difficult to tell if they are getting it right. The ultimate test is if the software sells, and the sales staff frequently plays a key role in requirements gathering. But even if they get the first version right, the same issues of what the customers want must be revisited with every new version.

What generally happens with a successful software company is that the first version of the product is released, a few initial sales are made, and these customers start providing more and more information about what they like about the product.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Productization: The Key to Understanding the Challenge of Using Open Source

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Perhaps the simplest way to understand what you are getting into by using open source is to think of it in terms of the productization idea introduced earlier in this chapter:

Using open source software means taking on the burden of overcoming the lack of productization.

Most open source projects are only partially productized. But all of the information required for you to work around the lack of productization is available.

The key questions are:

• How large of a burden will it be to overcome the lack of productization?
• Will it be easy or difficult for you to overcome?
• Are the risks worth the benefit derived from the software?

The models described in the next chapters are aimed at answering those questions:

• The Open Source Maturity model helps define the size of the productization gap.
• The Open Source Skills and Risk Tolerance model helps gauge how hard it will be for an IT organization to overcome the productization gap.
• The Software Cost and Risk model provides a framework for understanding the total costs, the risks, and the benefits of using an open source product.

It is no accident that the most skilled engineering teams in the country are also the largest users of open source. For them, the cost of overcoming the productization gap is small. The rest of this book will help IT departments understand the size of the gap for them.

In fairness to the open source community, we should mention another interpretation. From the perspective of a person with the required open source skills, the lack of productization is not a problem. Productization might even get in the way of a developer's needs. From this perspective, the barrier to wider adoption is not the lack of productization, but the lack of skills in those who desire to use open source—the skills gap mentioned earlier.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Comparing the Risks of Commercial and Open Source Software

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The episodic, sporadic, incremental evolution of open source is in sharp contrast to the more methodical design process that most commercial projects go through. This chapter has pointed out that IT technologists and executives who are seeking to understand the opportunity open source provides must understand the nature of commercial software, which is born out of a completely different process and has different strengths and weaknesses.

But the different processes can easily obscure the nature and quality of the end product. Whether open source or commercial software is better for a particular company or a particular purpose is a complex decision that is a function of the quality of the software, how well it fits to a particular task, and the skills present in the development team. The models that we describe in subsequent chapters provide a framework for understanding these issues.

The fact is that most software, open source and commercial, has problems that must be overcome for it to be useful. Figure 1-2 shows how the best software from the open source world shares certain characteristics, as does the worst. But most software is not located at the extremes of this scale. Most software falls into a gray area, meaning it has significant problems that might or might not be showstoppers, depending on the context.

Commercial software vendors would have you think their software is perfect and without blemish. However, anyone who has bought commercial software and used it extensively finds all sorts of rough edges. This is true even for the best software from the best companies. The closer you get to a commercial software product, the uglier it looks. Most software is in the gray area, which means that in the evaluation process the nature of the software's defects must be revealed to determine whether a program is suitable for your company. In the following discussion, we will examine some important differences between open source and commercial software that affect the evaluation process, and differences in the risk of owning and operating each type of software.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 2: Measuring the Maturity of Open Source

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The difference between evaluating open source and commercial software is that in open source it is all up to you. Nobody teaches you how the product works. No experts call to explain everything. No whitepapers provide summaries of features and functionality. Nobody buys you lunch. You have to spend time gathering information and understanding the software. In other words, evaluating open source thoroughly enough to reduce risk is real work.

This chapter is a guide to doing that work.

Measuring the maturity of any software, commercial or open source, is far more an art than a science. This chapter will focus on the specific elements of an open source project, and those elements will serve as a guide to determining its maturity. Maturity, for the purposes of this chapter, is an indicator not only of age, but also of various dimensions of quality. It is also a proxy for the question, How much work is really required to use this software?

If some of the key elements of maturity are lacking—if information is difficult to find, if code is poorly structured and difficult to read, if forums are inactive and documentation is scant, if the project in general is of low quality—it translates into more work for those who would use the software. Problems will be hard to address. Help will be hard to find. Customization and configuration will be difficult. If the elements of maturity are present, the software will be much easier to use.

As the last chapter illustrated, most software, commercial or otherwise, exists in the gray area between mature and ill-formed. Almost every potentially valuable program also comes with significant drawbacks. The key to the successful deployment of software of any kind is to understand how the software will provide value and how you will avoid or compensate for the drawbacks inherent in using the software. The larger picture of whether a particular open source project will work for a particular purpose goes beyond issues of maturity, of course. Determining how the software will be used, who will be using it, and what it will fully cost are important factors that must be taken into account.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Open Source Traps

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

All of the open source traps we identify in this section can be avoided if careful research and sober thinking of the type described in this and the following two chapters precede commitment to the use of open source. Let's face it: many IT departments gravitate toward open source without adequately considering the issues involved, simply because it is exciting. It represents an interesting opportunity for the technologist and a way to save money for the business. The pitfalls outlined in this section occur because of overconfidence on the part of technologists, lack of due diligence, and poor communication.

Getting burned while selecting open source is usually the result of mistakes made in one of these broad categories:

• It requires more work than expected.
• It does not work well with existing systems.
• It is harder to extend than anticipated.
• Getting answers from the open source development team is impossible.

The good news is that most of the time it is easy to determine in advance whether these problems are likely to occur. And even if they are unavoidable, there is no barrier to overcoming them. Figuring out what an open source program does, and fixing it, is always possible.

The danger lies in rushing into using an open source program just because it is easy to get something running. Avoiding traps requires discipline. Here are six common ways of getting burned:

• Selecting a product that is ill-suited for the technical skill set of the people responsible for running it. Ill-suited in this case can mean it uses a technology stack that the company's IT department has little or no experience with.
• Selecting a product that has withering community support. This means you have no support, and almost every question will have to be answered the hard way—by experimenting with the product or reading the code.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The Elements of Open Source Maturity

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

As mentioned previously, the elements of open source maturity are direct indicators of the potential difficulties you can encounter when using open source. The specific elements of open source maturity we will discuss are:

• Leadership and culture
• Vitality of community
• Quality of end-user support
• Extent and scope of documentation
• Quality of packaging
• Momentum
• Quality of code and design
• Quality of architecture
• Testing practices
• Integration with other products
• Support for standards
• Quality of project site
• License type
• Potential for commercial conflicts
• Corporate commitment

Each of these strengths is directly related to the difficulty an IT department will encounter when using the software. These criteria are not absolute. Some are fuzzy, some are matters of taste and judgment, and many overlap in different ways.

As an IT department becomes more adept at using open source, the weaknesses that are difficult to overcome during an open source deployment will become easier to understand and identify.

One of the most important factors in evaluating the maturity of an open source project is the quality of its leadership. Are they serious developers with a strong understanding of technology and the kinds of problems that you, with a business at risk, are facing? What previous successes do they have to show for their work?

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The Open Source Maturity Model

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The Open Source Maturity model attempts to quantify the maturity of an open source product. This should help an enterprise decide whether to adopt the product for long-term use.

This model assumes the following:

• A functional specification of requirements exists
• A functional specification has been matched to a product functionality list, and a short list of products that match has been created

The IT department uses the results of these two steps to determine which product from the short list is suitable for adoption. It should be noted that this evaluation process might be too resource intensive for the short-term use of an open source product but is a very wise investment for medium to long-term use.

We assess maturity in three major areas:

Product criteria

Product criteria are specifics about the product itself. Since open source software (OSS) products are often under rapid development, with major advances made in a few weeks to a few months, we list momentum as a criterion to offset the age criterion. This helps us spot products that aren't mature enough today but are worthy of keeping an eye on.

Use criteria

Use criteria are specifics about what it takes to use the product from day to day, from the effort of initial installation and configuration to the work required for daily upkeep and support mechanisms available to help in tailoring the product to an enterprise's needs and fixing defects encountered.

Integration criteria

Integration criteria are specifics about what it takes to make the product work in the enterprise's environment. This is often overlooked during evaluations and is a critical factor to consider if you want to win with open source in the enterprise.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 3: The Open Source Skill Set

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In Chapter 2, we determined how to evaluate the maturity of an open source project. In this chapter, we look at what an IT department must bring to the task of using open source. Making open source a key part of an IT infrastructure involves a commitment to acquiring and maintaining a certain set of skills. The exact skill set for any open source project depends on the maturity of the technology used to build it, how well it matches the needs of an application, and the importance of the application in an organization.

The last chapter showed clearly that all open source projects are not created equal. At the most mature end of the spectrum, using open source is pretty much exactly like using commercial software. Mature open source projects offer everything commercial products do, plus the benefits of a thriving community, online resources, and a fully developed ecosystem. At the least mature end of the spectrum, open source projects can be little more than an idea, and some code that partially implements that idea. Using this sort of open source means, in effect, that you've joined the development team.

Choosing the right open source to use in an enterprise depends on the skill level of the company's IT department. Beginners will be able to use only the most mature open source. As an IT department's skill level increases, more and more value can be found in all sorts of open source projects.

The way that open source will be used is also key to understanding the commitment required. Trying open source in an experimental or low-performance context requires much less of an investment in terms of acquiring knowledge and skill building than choosing to use open source for a mission-critical function. The skills required of an IT department to handle each type of project are vastly different. In a low-performance context, you might have days to fix a problem, whereas mission-critical systems might need to be fixed in minutes.

This chapter explores the skills needed to handle open source of varying maturities and examines the risks companies take by using open source. When properly planned and executed, open source adoption can be a rewarding adventure that increases the power of an IT department.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Preventing an Open Source Nightmare

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

IT departments end up creating open source nightmares, because they don't ask the right questions and they don't prepare for the responsibilities and risks involved. Of course, implementation of commercial technology often ends in a nightmare, too, but that is a different story.

The typical open source nightmare begins when a lead architect or a development team approaches management and suggests using open source for a particular project. In many ways, such requests resemble a child asking a parent if she can have a puppy. The parent generally replies, "Yes, if you promise to take care of it." The child promises to do so, not knowing anything about housebreaking a puppy, what it will take to feed and groom it, and how often it needs to go for a walk. After a while, the child just plays with the puppy and the parent is left to clean up the mess.

While this is a cruel analogy for technologists, it does accurately illustrate one of the major problems with using open source in the enterprise: the difficulty of understanding an IT department's skills. One major cause of open source failure is that the business staff doesn't know the IT department's skill level, and the IT department has an unrealistic view of its own skill level. The amount of work involved in evaluating and deploying open source is also frequently underestimated by IT teams with little open source experience.

The most common open source nightmare involves using open source in a project and having implementation take three or four times as long as expected, because so much needed to be learned to get the job done. A worse situation occurs when the implementation goes smoothly, and the difficulty of supporting or changing an open source project is discovered after the software is in production.

Then, of course, there is the problem of having the person who championed the use of open source leave the company after implementation but before any institutional skills have been built. This is known as a

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Open Source Skill Levels

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

It is impossible to capture precisely and on a simple scale a detailed assessment of an IT department's open source skills. What's more, the skills required for any particular implementation can vary widely, depending on the maturity of the open source project. The goal of this model, then, is not to create an authoritative aptitude test, but rather, to help an IT department understand what skills are required to use open source projects in different situations.

The Open Source Skills and Risk Tolerance model will serve four purposes:

• It is a guide to self-assessment that can combat the frequent over-optimism of IT departments and technologists in general. All technologists feel in their hearts like highly skilled innovators. The descriptions presented of the specific skills an IT department has to have at each level can assist in making a sober judgment about what sort of open source is appropriate.
• It gives the authors a quick way to talk about what sort of skill level will be needed in the later chapters that review specific open source projects.
• In understanding the skills required at each level, an IT department will be able to create an organized plan for creating and improving institutional skills so that the cost of using open source drops and the potential value created from using open source grows.
• If an IT department chooses to use consultants to help in evaluating and implementing open source, the model provides a framework for evaluating the skills of a consultant or consulting firm, or other service providers.

The skill levels presented here are intended to imitate the stages of technology adoption made famous by Geoffrey Moore in his book, Crossing the Chasm . In the book, Moore presents a model for how technology is adopted based on a diffusion model that was first created to explain the adoption of technology in agriculture.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Open Source Skills Inventory

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This section provides a precise definition of what is meant by each category of skills in each level, so an IT department can understand exactly the sort of skills it will need to succeed using open source. (In Chapter 5, a program on skill improvement will be proposed.)

Open source started as primitive fundamental elements, languages, and operating systems that were combined and recombined to create the incredible trove of software available today. Appendix A examines the different sorts of platforms that can be constructed with open source.

One of the earliest and still most active areas of open source is the creation of tools for developers. The keyboard mappings of Emacs and vi editors are deeply embedded in the brains of millions of developers. Other tools such as Ant are used widely to compile and assemble programs. Open source is bundled together with its own set of tools, such as tar.

The fact is, when you start digging into an open source project, you might encounter 5, 10, or 15 open source or Linux development tools or commands that are crucial to understanding how to compile and construct the project on your computer. The first few times you wade through this it can be slow going. But eventually you become one of the informed, and a process that started out taking 6 to 8 hours now takes 15 minutes.

The most important tools to understand are:

Utilities for dealing with distribution archives (tar, gzip, bzip, zip, unzip, etc.)

Almost all open source projects are distributed as downloadable "tarballs."

The GNU configure and build system (autoconf, automake, libtool, gettext, m4, and perl)

This system is the most popular among open source projects written in C, C++, and other low-level languages. It uses the three-step process of

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

How Maturity Affects Required Skills and Resources

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

One policy that is reasonable, especially for beginners, in the early stages of skill building is to just forget about all but the most mature open source projects. This means that many powerful programs are available—Linux, Apache, Mozilla, MySQL—but it perhaps misses the point of pursuing an open source strategy.

In fact, the most mature rank of open source is only the tip of the iceberg. A huge number of open source projects are less mature but still extremely valuable. Some of the biggest wins in open source can come from using a well-built but obscure program created to solve just the problem an IT department has. The key to success in using such software is to evaluate and experiment to really understand what you are getting into.

For example, different gaps in maturity require different skills:

• A beginner can overcome a lack of documentation, but evidence of bugs that require expertise to fix are showstoppers.
• As a beginner, all the needed features must be included. But an advanced- or expert-level team can add them.
• If the community is small, plan on time for reading code, experimenting, and figuring things out for yourself.

The odds are against most projects—even the ones that deserve to be more popular. So, it is wise to plan for how the product will be supported if development slows to a crawl.

The good news is that flying blind is not required. The only things standing in the way of evaluating a project are skill and time.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Skills and Risks

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

One useful exercise when considering open source is to define your organizational personality with regard to risk. The more risk an IT department assumes, the greater the immaturity of the projects it can use. Supporting mission-critical applications with open source requires maintaining a larger pool of institutional skills.

The decision to use open source should be made carefully in the context of how critical a system is to business operations. The more important the system, the more skills are required to support an open source project.

The key question is how the demands for skill change as the risk goes up. Here are some categories of importance for systems:

Experimental

If an experimental application breaks, it generally is not a big problem. Nobody expected it to work in the first place. When a system is installed for evaluation or on a trial basis to support one project, for example, a failure might not be a disaster.

Low priority

A low-priority system can be down for a day without bothering anyone. This provides time to resolve problems, and life goes on without major interruptions in the case of an outage. A Wiki used for documentation or project management, or a weblog used for internal use, can fall into this category.

Operational

Operational systems must run well and not be down for more than an hour or two. This is where the required understanding of an open source program and the skill level start to creep out of the intermediate level and toward the advanced level. An address book or calendaring system, or any actively used database, might fall into this category. People can find a way of living without the system for an hour or so, but they need it to be working soon.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Open Source Skill Building

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Using technology to solve problems in business is rarely easy. Many traps and obstacles lie waiting. Open source projects are not immune to any of the common failures of requirements gathering, project management, or technical glitches that knock projects off track. IT departments must learn to be on the lookout for such problems and understand how to prevent them.

The point of this chapter was to show that open source is a seductively powerful tool. You can quickly make it do amazing things. This can lead an IT department to rush ahead and take advantage of the power of open source without asking the right questions about how it will be supported.

The most common nightmare is that one person understands open source and creates infrastructure or applications using it that nobody else in the IT department understands. When that person leaves, the department is left with an unmaintainable mess. Of course, the same thing happens with custom code or ancient applications. The remedy is a systematic identification of skills needed to support open source and a program for maintaining them inside a departme