Benefits of Using Open Source Software

The outline flow of this section is as follows:

• Organisational benefits from the use of Open Source Software
  • Reliability
  • Stability
  • Auditability
  • Cost
  • Flexibility and Freedom
  • Support and Accountability

Introduction

Open Source's proponents often claim that it offers significant benefits when compared to typical commercial products. Commercial products typically favour visible features (giving marketing advantage) over harder-to measure qualities such as stability, security and similar less glamorous attributes. As a shorthand, we shall describe this phenomenon as quality vs features.

Open Source Software developers are evidently motivated by many factors but favouring features over quality is not noticeable amongst them. For many developers, peer review and acclaim is important, so it's likely that they will prefer to build software that is admired by their peers. Highly prized factors are clean design, reliability and maintainability, with adherence to standards and shared community values preeminent.

"The Open Source community attracts very bright, very motivated developers, who although frequently unpaid, are often very disciplined. In addition, these developers are not part of corporate cultures where the best route to large salaries is to move into management, hence some Open Source developers are amongst the most experienced in the industry. In addition all users of Open Source products have access to the source code and debugging tools, and hence often suggest both bug fixes and enhancements as actual changes to the source code. Consequently the quality of software produced by the Open Source community sometimes exceeds that produced by purely commercial organisations." (QINETIQ2001).

"... This psychological effect is really important in explaining why so many projects are started out of the blue, with seemingly no reward. Although it may seem surprising at first view, it is not that rare if we put it in context. For instance, most of the history of information science and programming, in fact, started this way in academic circles. And still many non-applied sciences advance thanks to the work of scientists who feel more rewarded by research in itself than by money. Although this effect of self-reward is perhaps not so common in the world of proprietary software development, it is today a strong force in the open source community. And what is even more important, it seems clear that it has an extremely good impact on developer's productivity, an interesting effect in a discipline where differences in productivity from person to person are often a matter of orders of magnitude." (CONECTA2000).

There is abundant anecdotal evidence for truth in those claims but reliable and comparable statistical measures are not available to our knowledge. There are a number of principal reasons adduced for this:

• Authors are motivated by pride and peer recognition rather than a development plan supplied by the marketing department. Most want to use the software themselves and they prefer robustnesss before adding features.
• Authors are likely to consider it a ‘win’ if they can reduce the complexity and improve the maintainability of software. This rarely comes high on the product plan for commercial software.
• Where several authors work in parallel, the best-of-crop solution can be chosen in place of the only solution (as would be typical for a commercial product).
• Where source code is freely published and widely distributed, the users of the product will often discover and correct defects themselves. If no commercial entity benefits from that work, the motivation to do so for the common good is much higher.

Many of the qualities that are claimed for Open Source Software are exactly those that are wanted by those who have to use or deploy software, yet run almost directly counter to the commercial needs of typical software development businesses, where a continuous revenue stream (usually through the mechanism of upgrades or high-priced support) is needed. [CONECTA2000] addresses some of the economic drivers in more depth and provides models which can reverse this apparent conflict of interests.

In the following paragraphs we look at the claims, outline why they are considered benefits and describe the ways that the Open Source process provides substance to the claims.

Reliability

Reliability is a loose term. Broadly, we can take it to mean the absence of defects which cause incorrect operation, data loss or sudden failures, perhaps what many people would mean when they use the term `bug'. Strictly, a bug would also mean failure to meet the specification, but since most Open Source projects dispense with the concept of anything easily recognisable as a formal specification, it's hard to point to that as good way of defining what is a bug and what is a feature. Determining what constitutes a bug is usually by agreement amongst the developers and users of the software (an overlapping community in many cases). Obvious failure to perform is easily recognised as a bug, as is failure to conform to appropriate published standards. Security related failings (exploits or vulnerabilities) are clearly bugs too. Each of these kinds of bugs is usually addressed with speedy fixes wherever possible and Open Source advocates will claim very rapid time-to-fix characteristics for software.

Severe defects tend to be fixed within hours of their being detected, a process wich is undoubtedly assisted by the availability of the source code. Able developers who discover a bug will commonly also fix it and then report it to the maintainers as well as issuing an updated version of the software on their own authority. Users of the software can choose whether to use the unofficial fix or wait for an `official' version. By `official' we mean a release blessed by the project team itself or a trusted authority such as one of the main distributors of Open Source packages. This mechanism clearly works very well in practice.

The pattern with closed-source software is typically that a defect report needs to be filed and then there will be a delay before the vendor determines when or whether to issue an updated release. Users of the software are much more at the mercy of the vendor's internal processes than with the Open Source arrangement and the personal experience of the authors is that it can be extremely frustrating to move from the Open Source to the closed model.

"The market greatly values robustness, and the Open Source model, particularly as practiced by Linux, encourages a large market of early adopters (compared to the size of the early market for commercial products) who actively help debug the software. Consequently much Open Source software becomes highly robust at a surprisingly early stage of its development, and mature Open Source products are setting new industry standards for bulletproofness." (QINETIQ2001)

Stability

In a business environment software is mostly a necessary evil, a tool to do a job. Unless the job changes or more efficient processes are discovered then there is rarely pressure or need to alter the software that is being used to assist the task. This is more or less directly counter to what motivates software vendors who are in the unenviable position of supplying a commodity that does not wear out or age much. The vendors need a stable revenue stream to be able to keep their business going whilst their customers have not the slightest desire to change or upgrade any product that is working well enough to suit their needs. If a software supplier can establish a virtual monopoly and then force upgrades onto its audience (as has been the history of the software industry since the mid 1960s) then the profits can be very high.

Software vendors can apply a number of tactics to persuade their customers to upgrade more or less willingly. Typical tactics include moving to allegedly new and improved file formats (which require the new and improved software to read them) or to withdraw support and bug fixes for older versions after a short period. The problem for users of the software is that they rarely have much control over that process and are left isolated if they choose to remain with older versions that they consider to be acceptable. This has cost and control implications for the business.

Open Source Software is not a panacea in the world of ever-changing software, but the worst effects of vendor-push can be mitigated. The way that Open Source products tend to conform closely to standards efforts has an inertial effect, since standards change but slowly and interchange formats are often particularly stable. As a result, incompatible file formats can be less of an issue. If they are standards-based then they typically aren't an issue at all, and if they are formats unique to the software product — proprietary formats in a sense - then they cannot be undocumented since the source code that uses them is itself published. In practice the track record of Open Source projects is usually good; when incompatible formats are used it is commonplace for a Perl or similar converter program to be shipped with them which will upgrade data to the new format.

In the real world, no business is static and software changes to meet new requirements. A choice to use Open Source software can provide a counter to the pressures to upgrade for the vendor's commercial purposes but cannot shelter every user from any change. Having access to the source code can allow a business to choose to support itself on an old version where necessary and we belive that in general it gives more options and choice to the users. Nonetheless, some upgrading and maintenance effort will always be needed. Putting the choice in the hands of the users rather than the suppliers is hard to criticise.

Auditability

A rarely-understood benefit of Open Source software (any software where the source code is published) is its auditability. Closed-source software forces its users to trust the vendor when claims are made for qualities such as security, freedom from backdoors, adherence to standards and flexibility in the face of future changes. If the source code is not available those claims remain simply claims.

By publishing the source code, authors make it possible for users of the software to have confidence that there is a basis for those claims. Whether this takes the form of an cursory and informal inspection or more rigorous auditing, what's clear is that without access to the source, third party inspection is impossible. At present the industry does not insist on third party inspection or certification, but it's possible that as open source models become more popular then expectations of audits will rise.

An often-quoted example of this in real life is the Interbase product from Borland (Inprise). This CERT advisory notice carries the following summary:

"Interbase is an open source database package that had previously been distributed in a closed source fashion by Borland/Inprise. Both the open and closed source versions of the Interbase server contain a compiled-in back door account with a known password."

The back door account was discovered when Borland released the source code of the software for public use. One is left wondering how many other software projects contain similar features — and it's not possible to know if the source code remains closed.

CONECTA2000 notes:

"We can easily see that open source software has a distinct advantage over proprietary systems, since it is possible to easily and quickly identify potential security problems and correct them. Volunteers have created mailing lists and auditing groups to check for security issues in several important networking programs and operating system kernels, and now the security of open source software can be considered equal or better than that of desktop operating systems. It has also already been shown that the traditional approach of security through obscurity leaves too many open holes. Even now that the Internet reaches just a part of the world, viruses and cracker attacks can pose a significant privacy and monetary threat. This threat is one of the causes of the adoption of open source software by many network-oriented software systems."

One example of third-party auditing is the Linux Security Audit project which performs by-eye auditing of open source software packages and maintains a database of results.

At present company auditors are not known to be asking about the suitability and auditability of key software packages which support crucial business processes. A plausible reason is that they simply don't know that it can be done. That situation is not guaranteed to continue.

Cost

Most current Open Source projects are also available free of royalties and fees, leading to the confusion around the commonly used term `free software'. Regrettably the English language does not have separate concepts for free-of-charge and free as in unconstrained; other languages are better equipped to describe the difference between `freedom' and `free of charge' (libre vs. gratis). Proponents of free software licences tend to emphasise liberty over cost although in practice the main open source projects are free in both senses of the word.

From a business perspective the purchase cost of software is only one factor; total cost of ownership (TCO) is what really matters. Other things being equal, the solution with lowest TCO is usually the most desirable one. Arguments in favour of low TCO for open source software include:

• Possibly zero purchase price
• Potentially no need to account for copies in use, reducing administrative overhead
• Claimed reduced need for regular upgrades (giving lower/nil upgrade fees, lower management costs)
• Claimed longer uptimes and reduced need for expensive systems administrators
• Near-zero vulnerability to viruses eliminating need for virus checking, data loss and downtime
• Claimed lower vulnerability to security breaches and hack attacks reducing systems administration load
• Claimed ability to prolong life of older hardware while retaining performance

Some longer-term claims are more difficult to substantiate yet they need to be taken into account:

• Better adherence to standards permits competition in the market, reducing vendor lock-in and consequent monopoly pricing
• Availability of source code provides greater continuity and security against
  • Financial collapse of vendors of key products
  • Vendors choosing to withdraw support for unprofitable products
• Protection against being required to fit your IT strategy to the cash needs of your software supplier

Unfortunately in this area there are numerous claims and counter claims. Reliable TCO information is practically unobtainable, although the case studies which form part of this guide provide a large amount of circumstantial evidence in favour of the argument. Most businesses will have to chose the argument on on its merits and choose to back the use of Open Source software where it seems most likely to provide either a clear cost win, or valuable leverage over entrenched suppliers.

Flexibility and Freedom

In a business context, software flexibility is about being able to choose solutions suitable for the needs of the users. Many commercial software products will claim flexibility as a built-in feature and some will undoubtedly be correct. Our view is that that flexibility should really mean business flexibility, so that as requirements in the business change, solutions should not be unreasonably constrained by software. In particular, we view this as being especially important in the area of infrastructure components — the architecture of the IT solution rather than any one package.

To obtain flexibility at the architectural level, experience shows that it is often best to pick tried and trusted standards for interworking. If that is done, then best-of breed solutions can be selected for particular components within the architecture. Provided that the solutions can interwork suitably, the business should be able to avoid lock-in to a particular supplier and over-dependency. This is notoriously hard to manage, requiring a real act of will from management. What happens most often is that a vendor will make a `feature sale', emphasising something which cannot be done through the standard infrastructure. If they succeed then the business can become dependent on that particular solution and unable to choose alternatives at a later date. Any astute vendor will attempt to do this, only vigilant managers can avoid the lock-in that follows. Proprietary data formats are a particularly good tool for vendors to use. If they can establish a bridgehead, their competition will not only have to provide competing functionality, but also data conversion tools from a (typically) undocumented or even protected format.

Open Source projects have very little motivation to attempt this kind of lock-in strategy. Since there is no commercial benefit to be had, adherence to de-jure or de-facto standards (where they exist) is typically high. Where standards for interworking do not exist, the fact that the source code is published means that proprietary data formats can't be used to manipulate lock-in. This at least partly explains the relative success of Open Source software in infrastructure areas. Many vendors have tried to create web servers to compete with Apache, but because the network protocol used between browsers and the web server is well specified they have had to compete on quality or features rather than through more insidious tactics. Any vendor that controlled the lions' share of the browser and the server market would feel strongly tempted to exclude competitors by proprietary extensions to the HTTP protocol if they thought they could get away with it. No single vendor has yet managed to control both ends of this equation to a great enough degree.

"Open Source software tends to be free of dependency on related products. Purchasers often perceive that the product works best with other products from the same manufacturer. Open Source software offers its users greater freedom to purchase other products, avoiding lock-in to particular manufacturers." (QINETIQ2001).

Business users are most likely to obtain long-term flexibility through the careful choice of standards for interworking and data exchange, followed by vigilance to ensure that freedom from proprietary lock-in is maintained in critical areas. The drawback is that standards inevitably lag in terms of glamorous features, making the feature-based ploy an easy one for proprietary vendors to use. Open Source products are strong in this area, not only from the point of view of adherence to standards but also by helping to mitigate against insidious lock-in if they are chosen as core infrastructure components.

"It is the use of proprietary standards and protocols that effectively mandates the purchase of further products from the same supplier. Mandating the use of open internet standards (as in the e-GIF) rather than proprietary formats, and developing XML-based data definitions, for intra-Government, and Government-to-Citizen interoperability, is a practical approach to controlling the [proprietary lock-in]". (QINETIQ2001).

The choice is not easy. Many weaker managements simply roll-over and buy from a single supplier, but they pay a high price.

Open Source software provides further flexibility through freedom.

Freedom from a single vendor

Software vendors can go out of business, and they can arbitrarily decide to cease development of a product. How would your business cope if it relied on such a product? Open-source software allows you to retain not just the right to use the software you already have, but the ability to continue to use it as your needs change.

Freedom to modify your software

You aren't limited to what one company believes you need. Proprietary software vendors must cater for many different companies, predominantly their own. Open-source software can be tailored for the way you do business. It is usually within the resources of all but the smallest companies to modify Open Source software to suit their own needs (and potentially then to make those enhancements available as a public good). If in-house development skills don't exist, a short email to the project's mailing list will usually find a suitable consultant.

Support and Accountability

It may appear counter-intuitive at first, especially to someone used only to dealing with proprietary software, but whilst the models for obtaining support and accountability for Open Source software are clearly different, the Open Source outcome is generally better than for all but unusual cases of user-vendor relationships.

One of the most common counter-arguments to the use of Open Source software is characterised as the ‘who do I sue?’ question; in other words, who is liable if the software doesn't work?

This argument seems plausible in theory. Unfortunately, though, that isn't what aplies in all but the rarest of circumstances. A moment's inspection of typical EULA (End User Licence Agreements) will dispel that myth. All usual software licences explicitly disclaim responsibility or liability for anything more serious than defects on the distribution medium, with the responsibilities being a one-way street and resting on the user, not the supplier. Proprietary software licences are intended to absolve the vendor of liability for almost any problem you may incur. Major vendors have large legal teams whose job it is to prevent the vendor from being liable for anything. This does not seem unreasonable – the vendor wants to sell software, not spend months or years at a time defending protracted tort and liability suits.

Open-source software does not differ from proprietary software in this respect. Open-source licences typically disclaim all liabilities and warranties, including such basic warranties as merchantability and fitness for purpose. Those in the know, who have adopted Open Source Software already, will shrug their shoulders and choose the practical benefits of increased reliablility and security over illusory options to sue or pursue other remedies from a negligent vendor.

Detractors of open-source software quite rightly point out that the free licence to use the software includes no support contract. But they neglect to mention the other side of that issue: many proprietary software licences have no support included either. Indeed, the majority of mass-market proprietary software support is aimed at hand-holding for inexperienced users. Just as proprietary vendors will sell support contracts with agreed service levels, suppliers and third parties will provide support for open-source software. An example of this is the Gnat translator for the Ada programming language, as reported in [CONECTA2000] and elsewhere.

"ACT Europe was founded in 1996 to provide support for commercial, industrial and military uses of the GNAT Professional Ada 95 28 development environment in Europe. It was founded jointly by Ada Core Technologies Inc (ACT), and by the European members of the GNAT Ada 95 project. ACT is a privately held corporation and was founded in August 1994 by the principal authors of the GNAT Ada 95 compiler system. ACT was founded without any initial capital other than some small loans from the principles, and has existed entirely from revenue from its inception. ACT claims to be currently profitable. The people involved in both ACT and ACT Europe (from now on, ACT) have been working with Ada for over twenty years, starting with the development of a working Ada compiler for preliminary Ada in 1979, and the first validated Ada 83 system in 1983. This work was done at New York University by a team dedicated to the technical success of the Ada language, which moved to ACT after its foundation. GNAT is the most widely used Ada 95 development system, available on many platforms, from workstations and PCs to bare boards. Ada solutions using GNAT encompass conventional, real-time, embedded, and distributed systems applications. The GNAT technology has always been based on free software, and more specifically on the GNU toolset. The GNAT compiler is integrated with the GCC (the GNU C compiler) back-end. The GNAT debugger is based on GDB (the GNU debugger) that has been adapted for Ada 95. GLIDE, the GNAT integrated development environment, is based on Emacs, which has been adapted and complemented to create a friendlier and complete environment. The GTKAda GUI technology leverages on the GTK graphical toolkit and provides an advanced GUI builder. These are a few but significant examples of the technological offering of ACT. All the products being distributed by ACT are free software, usually under a GPL or LGPL-like licence. Since its foundation, ACT has established strategic partnerships with hardware and software manufacturers providing Ada 95 capabilities. In the former category is ACT's relationship with Silicon Graphics, Inc., whose new SGI Ada 95 product is based on GNAT. As of 1999, SGI sold over a billion dollars of Ada related software and equipment. ACT has relationships with several other hardware manufacturers such Compaq and Hewlett Packard. Commercial customers of ACT Europe include Aerospatiale, Alenia, BNP, Boeing, British Aerospace, Canal+, CASA, Dasa, Ericsson, Hughes, Lockheed, TRW, etc."

To add some context to that quote above, Ada is a language designed specifically for military, industrial and aerospace mission-critical and safety-critical systems where human life is routinely risked if software systems do not function correctly.

Some software vendors produce free software, and obtain large parts of their revenue from service and support (e.g. BA.net). In other situations, open-source consultants will provide training and/or support for software they recommend. However, the fundamental advantage of open-source software when it comes to support is that it's always possible to retain a company to provide support. Because the source code is freely available, organisations are not limited to obtaining support from the authors. There is no restriction on other suppliers learning enough about the software to provide adequate support whenever demand exists.

Speaking from a personal perspective, the authors feel obliged to point out that when software is as reliable as Apache, MySQL and similar projects, support dwindles as an issue. When software works reliably, support for it ceases to be a frontline concern.

References

"Analysis of the Impact of Open Source Software" (PDF) [QINETIC2001], Peeling & Satchell, QinetiQ, 2001. This document was commissioned by UK Government to analyse the impact of Open Source Software from a Government Policy perspective.

Free Software / Open Source: Information Society Opportunities for Europe? (HTML) [CONECTA2000], European Working Group on Libre Software, 2000. "The working group on libre software was created at the initiative of the Information Society Directorate General, with the purpose to analyze the free software phenomenon, create a set of recommendations for the Community and create a paper to be presented to the Commission. The group featured both people from the Commission and representative members from the EU countries. After several meeting, the group finalized a paper, edited by Carlo Daffara and Jesús M. González-Barahona and presented at the IST'99 conference in Helsinki, during the special session track on libre software, and at the workshop on free software held the 23 of March 2000 in Brussels."