For those of us who toil in IT, the puzzle that open source represents really is just a new version of the choice to build or to buy. Open source offers a “middle” way, a way to acquire technology that is almost built, without having to buy.
However, choosing to use open source changes a company that takes up the challenge, which is perhaps its biggest reward. Building the skill to handle open source empowers a company to save money, attract more talented employees, gain more leverage when negotiating with vendors, and, most of all, better meet the needs of a business. This final chapter will take a look at important issues that will arise in choosing to use open source, and the way an IT department will be transformed once that choice is made.
One of the strongest objections voiced regarding the use of open source in the enterprise is the lack of “one throat to choke.” This concept refers to the accountability that commercial vendors have for solving problems with their products. IT departments get a feeling of comfort from knowing that if anything goes wrong with a commercial product, they can always call up the vendor and get some sort of assistance, or at least have someone to yell at. Oh, and let’s not forget, having someone to blame. Commercial open source support companies think they will be successful because they will become the “one throat to choke” for open source.
Examined closely, one throat to choke is a pathetic form of recourse for an IT executive. It is like a salesperson hiring a sales consultant to have someone to blame in case he does not make his quota. Nobody managing a sales staff would ever stand for this.
IT executives should know the products they rely on, what they do well, and what they do poorly. When problems arise, they should have contingency plans and failovers in place that provides adequate time for problem solving. Needing one throat to choke means an IT executive is not doing his job of understanding requirements, making appropriate choices, and designing robust systems. IT departments that use vendor software in the way that it is intended do not need one throat to choke.
To be the sort of IT executive that does not need one throat to choke you have to be confident that you understand the products you are choosing, and that you understand your needs. From such a perspective, open source is much less scary.
If an IT executive or anyone else claims that open source is not viable because they want one throat to choke, perhaps the response should be “Why are we planning on having any throats to choke?”
The argument against one throat to choke is not an argument against using commercial software. Rather, it is an argument against using commercial software as an improper crutch to avoid obtaining an adequate level of competence and a robust design for IT infrastructure.
The choice that the manager of every IT department must make, and the choice that presents itself repeatedly in different contexts, is how much to buy and how much to build. There is no right answer in general; everything depends on understanding the requirements, the technology being considered, the department’s skills, and the availability of time and money.
In practice, what happens is that the executive in charge of making these choices has to consider for each system whether he prefers to be a manager of resources (a bias toward buying a commercial solution), or whether he prefers to construct a solution on his own (a bias toward building with open source).
In fact, this is usually a false tradeoff. Commercial software is not all buy, and open source is not all build. In any project, commercial software must be extended and customized, which amounts to building. And open source software has lots of functionality that provides a running start.
One frequent mistake when choosing to buy is thinking that the simple act of buying solves a problem. Almost every purchased solution comes with a requirements gap between what the software does out of the box and what it should do at a particular company. In most cases, for a system of any size or importance, a significant amount of work will be involved to configure or customize that solution to solve that company’s problem.
Open source projects don’t have to be bought, but they don’t have to be built from scratch either. This book has stated clearly that certain skills are involved in using open source. However, depending on the problem being solved, if an open source project is sufficiently productized, it might not require any more work than a commercial product.
There is no easy way out, and the art of IT is making this decision properly in each new context. All the companies that are famous for innovative use of open source are heavy users of commercial products. (Linus Torvalds himself caused a stir when he chose a commercial source-code management system for the Linux project. Why? Because it solved a well-understood problem better than open source alternatives did.) It rarely makes sense to be all buy or all build, yet when some IT executives argue against open source, they are essentially arguing that buy is always the right choice.
Making this tradeoff is an art and is one of the most important services that IT managers provide to their companies. There are two parts to it: deciding when to consider building and understanding how much work is involved.