Although proponents of open source software often voice emotional or philosophical arguments for its adoption, there are benefits in attempting an objective or strategic analysis of the factors responsible for its success, Two such analyses are presented here: a pro-con analysis and a forcefield analysis. For a more subjective approach, see Russell Pavlicek’s 2000 book Embracing Insanity: Open Source Software Development.
A commonly-employed strategic framework is the “pro-con” analysis, which attempts to bring a degree of objectivity to an assessment. In their 2006 report Open Source Software: A Primer for Health Care Leaders, Michael Goulde and Eric Brown present an excellent brief discussion of the pros and cons of open source software from the standpoint of health care organizations. Their analysis (here slightly reorganized to fit more clearly into the pro-con framework) has applicability to other types of organizations as well.
Excerpting from Goulde and Brown:
Health care organizations that develop their own applications using their own programming staff find open source attractive for four reasons. One is the low cost and ease of acquiring the software. Another is the growing selection of open source projects from which to choose, which frees organizations from dependence on any one supplier. The third is wide support for open source standards, making it easy to switch from one project to another. Finally, the ability to view and modify the source code offers more flexibility.
. . .
Small health care organizations, such as group practices, clinics, and most hospitals, do not develop any software themselves. They may engage consultants to customize standard, off-the-shelf applications. For them, the benefits of open source are the lower acquisition cost of the many pieces of software they need to build a complete IT environment and the flexibility and lower cost their consultants achieve. Also, by relying on open source solutions, they reduce the risk of getting locked into proprietary software, which gives them greater flexibility and more options in the future.
Again excerpting from Goulde and Brown:
[Health care] organizations often must arrange their own project support. They face the risk that the community developing the open source software may become inactive and cease enhancing it. They are also concerned about requirements for redistributing derivative works and modifications, which could place them in the position of making proprietary intellectual property available to competitors.
One “con” which might be added to Goulde and Brown’s analysis is that adopting open source software might reduce the budgets of IT departments, so they might disparage rather than embrace it.
Another method of strategic analysis often employed in the business world is “forcefield analysis,” in which the forces promoting the adoption of some change in technology or business practices are contrasted with those opposing it. The objectivity here comes from carefully considering the drawbacks of open source software rather than focusing exclusively on its advantages.
In this case the change of interest is the adoption of open source software by organizations (it’s also adopted by individuals, but that’s the subject of a subsequent chapter). A drawback may not in itself qualify as a force opposing the adoption of open source software, but it will certainly be capitalized on and drawn attention to by forces such as competing commercial software developers.
Depending on one’s perspective, open source software can be described as “free” or as having “zero acquisition cost,” with the implication that there will be maintenance or support costs down the line. Either way, acquiring open source software is apt to be viewed as an option worthy of careful consideration.
Under the general heading of quality come stability, in the sense of freedom from crash-producing bugs, and reliability, in the sense of consistent operation. Its proponents argue that open source software is of uniformly high quality because its source code has been carefully scrutinized and beta versions have been tested by large numbers of people before a final version is released.
Facts of life in the commercial software world are market shifts, platform obsolescence, and “version creep,” leading to incompatibility headaches. In the best case, commercial vendors strive to maintain maximum backward compatibility with legacy documents and data, and to provide a migration path for users, but unfortunately seldom without a glitch here and there. In the worst case, a vendor goes out of business and end users are left to wrestle with migration as technological innovation spawns incompatibilities.
Open source software is often designed to accommodate technological change by anticipating and making provision for it. In the best case, participating in an active project with forward-looking design and deprecation mechanisms enables users to contribute to the evolution of the product, which therefore advances in tandem with hardware and operating system innovation. Incompatibilities are caught early in beta-test versions and released versions are reliable even on antique legacy platforms. In the worst case, such as a project abandoned because of total obsolescence, end-users can band together and underwrite the development of software patches and migration technologies, drawing on the project’s archived body of source code to ease the task.
The net result is a reassuring feeling of confidence that systems built using open source software rest upon a solid foundation. Time and money invested in their development will produce a return for a long time to come. Unlike with commercial software systems, the rug cannot be pulled out from under them by the sudden announcement that Vacillation, Inc., is ceasing development of its unprofitable Ephemeral product line.
As discussed early, open source software can justifiably be termed a new paradigm. A corollary of this is that many people do not know exactly what is meant by “open source software,” hence they tend to equate it with things they do know about, particularly commercial software products, leading them to make inferences about it that are inaccurate.
Because open source software is indeed a new paradigm, evaluating it as an option may be difficult in the framework of established procedures for commercial products.
The key issue here is that adopting open source software involves moving into new territory, as expressed in the Oceania metaphor, and raises fears that it’s something “too good to be true,” whereas the commercial software paradigm is a familiar and comfortable one. Committing to something with unknown pitfalls is understandably daunting.
Without going into this topic in depth, open source software can be made available under a wide variety of licenses ranging from minimally to highly restrictive when commercial use is involved. Reading the fine print of license provisions when comparing different open source software products can be confusing, and even people familiar with open source software may have different interpretations of specific license provisions.
A logical question often posed by commercial vendors is if non-commercial software is adopted, who, if anyone, can be relied on to provide technical support in the event problems arise? And what will the cost of technical assistance be compared to that of purchasing commercial software with assured vendor support, either included with the license or on a per-incident basis?
As mentioned earlier, IT departments may resist adoption of open source software because it would negatively impact their budgets.