How Do You Decide If OSS Works for You?

Background

The adoption of open source software can be as simple as downloading one software package, installing it, and using it on a single computer, or implementing an entire Linux server cluster to do complex tasks, or anything in between. This section will focus on smaller-scale implementations of OSS, which are more relevant to most nonprofit organizations.

All organizations should consider implementing OSS. But in any organization, it is necessary to make a case for what can be a significant internal change. This section lays out some of the factors you might need to address in weighing the costs and benefits of OSS versus proprietary solutions. (Later sections of the primer offer more concrete examples.)

Concepts

There are two concepts to consider:

Total Cost of Ownership: TCO is a familiar term to many people - it represents a calculation of how much technology costs to implement and maintain over time.

Strategic Value: Strategic Value takes additional factors into account beyond the costs related to the technology itself. In the nonprofit context this means accounting for the mission-based value that a technology might bring to an organization; for example the impact on staff productivity, or on the quality of services delivered to clients.

OSS can influence both the TCO of technology, as well as the strategic value that it brings to an organization.

TCO Considerations

TCO is a calculation of the entire cost of implementing a technology solution. This includes the initial cost of acquiring the software (purchase price or license fees), hardware costs, installation costs (staff time or consultant costs), end-user training costs, and the cost of maintaining the software (annual maintenance fees, support costs, and upgrade costs). This entire spectrum of costs should be considered when comparing any two solutions, whether one, both or neither is OSS.

The most obvious place where OSS has an advantage in terms of costs are in the software acquisition costs, maintenance costs, and upgrade costs. OSS is almost always freely available, usually has no license fees or annual maintenance fees (there are some exceptions, although they are not mandatory fees - they are generally for support) and upgrades are also generally free. However, the acquisition costs of many kinds of software packages are far outweighed by the other kinds of costs (consultant time, staff training, administration, etc.), so software that is free is not necessarily less expensive in TCO terms than software that you have to pay for.

• Compatibility with mission-critical applications

  Key questions to ask when evaluating OSS technology:  

  What are the software applications critical to your organization?

    What operating systems will they run on?

    Another important factor to take into account is compatibility between the open source solution you are considering and any mission-critical applications. In particular, when considering using Linux as an operating system, be aware that many software vendors, especially smaller ones, still do not support versions of their software that can run on Linux. This is especially true of 'niche' software products for the nonprofit sector, such as case tracking programs for legal-services organizations, or mortgage-tracking programs used by affordable-housing groups. Organizations that depend heavily on one of these programs find that, if they want to use Linux, they must also maintain a Windows machine dedicated to running that mission-critical program. If that is likely to be the situation, the costs of maintaining that additional machine need to be included in the TCO. In addition, any inconvenience to users could be considered a drain on strategic value.

  Doing a TCO analysis on an OSS vs. proprietary solution is dependent on the complexity of the software, the end user impact, the administration costs, as well as the acquisition cost of the proprietary solution.

• Software Acquisition Cost

  Key questions to ask about software acquisition costs:

  With a proprietary solution, how large will software acquisition costs be relative to other costs?

  With a proprietary solution, how easy will it be to get discounted software?

  Some proprietary products, like simple tools or small applications, have very low software acquisition costs. Other products, like complex databases, financial or fundraising packages, or server operating systems have high acquisition costs. In some cases, nonprofit organizations can get many software packages donated or at reduced costs, which may reduce or eliminate the acquisition cost for the software.

  Sometimes, however, organizations are limited in how many copies of a product will be reduced-price or donated (for example, an organization can only get 50 user licenses of Microsoft Office XP from DiscounTech, so a medium to large organization would not be able to take full advantage of this donation.) However, virtually all open source software is available for no acquisition cost whatsoever, and no multiple licenses are needed.

  Another factor to keep in mind is that with proprietary software, you may have to pay for separate software tools that are not needed with the OSS solution. For example, separate software is available to perform automated backups of Microsoft Windows servers, whereas with the Linux operating system, automated backup tools are included.

• Implementation costs

  Key questions to ask about implementation costs:

  What is the ease of implementation in terms of resources needed (time and money)?

  What kind of expertise might be needed for this software, whether it is proprietary or open source?

  What kind of expertise do you have available?

  For some software, implementation is quite easy, and will take a staff person 10-30 minutes to install. More complex applications (financial, client management packages, etc.) take days of staff and/or consultant time to implement, and convert information from an old system.

  When evaluating the options for a particular solution, be aware that in some cases open source projects can be more difficult to install than their proprietary counterparts, especially if people are new to OSS. It is worth looking carefully at the installation documentation for any solution you are planning to implement.

  Something else to consider is that if your organization needs consultant support, it is not always as easy to find consultants who are familiar with open source technologies, although that is slowly changing. You may need to consider seeking out a different consultant in order to move to open source technologies, if you now depend on a consultant who is unfamiliar with them.

• Hardware costs

  Key questions to ask about hardware:

  Is this a situation where you may need multiple servers?

  Does the proprietary software being evaluated have any special hardware requirements? Does it require vendor-certified hardware?

  In many situations, you will be implementing software on existing hardware, so there will be no additional hardware costs. However, if you are implementing a network for the first time, server hardware costs will likely be an issue. In general, the larger your network needs (in terms of capacity) the more hardware savings you are likely to realize with the Linux operating system and other OSS. Research has shown that servers based on Linux (as opposed to Microsoft Windows) can handle more traffic, hold more accounts and do more processing given the same hardware (see: www.apache.com/pdf/linux-windows.pdf). Thus in a situation where you might need multiple Windows servers, you'll be able to buy fewer Linux servers.

  Another way that Linux lowers hardware costs is by allowing the use of generic, industry standard servers. Proprietary software companies sometimes require that their programs be run on specially 'certified' -- and therefore more expensive -- servers. For example, an organization that uses Novell for their network will often have to buy Novell-certified hardware in order to get Novell support. Certified hardware tends to be significantly more expensive. Linux, by comparison, is designed to run on cheap, industry-standard hardware.

  In general, the more high-end system, the more using Linux is likely to save money on hardware.

• Training costs

  Key questions to ask about training costs:

  Will implementing this software (whether OSS or not) require end-user training?

  Will you rely on in-house staff to support this solution, and if so, what is their current knowledge of the solution?

  For end-user solutions (like office applications, financial packages, etc.), training is by far the most costly part of implementing new technology. Staff who are going to use this software on a day-to-day basis must be trained to use it. Most non-technology staff will be unfamiliar with non-Windows operating systems and applications, so implementing an open-source solution that replaces a well known and used application on a wide-spread basis must be considered carefully. The benefits of using a solution like Open Office, for example, may or may not outweigh the wide variety of training costs that will be incurred. But the long-term training implications (once the staff are trained, you only require standard on-going training, and training of new employees) should also be factoredin.

  For software that has little or no end-user impact (file servers, database servers, etc.), the only training costs to think about are training your technology staff (or 'accidental techies') to handle the new systems. These costs become a larger factor when a) you rely on in-house staff, rather than outside consultants, to support the solution, and b) your in-house staff does not have experience using OSS.

• Maintenance Fees

  Key question to ask about maintenance fees:

  Does the proprietary alternative require annual maintenance fees?

  Some software products have annual maintenance fees. For all practical purposes they can be thought of as annual license fees, since they are typically calculated as a percentage of the original software license acquisition fee. These fees should be included in your TCO analysis.

  Most OSS has no annual maintenance fees, since it had no license acquisition cost to begin with. Some enterprise-level Linux distributions (like RedHat) do have annual maintenance fees, usually for support. However, very few nonprofits fit into the categories of organizations that would make use of these enterprise-level packages, and they are not mandatory - it is possible to use RedHat, for example, at no cost .

• Upgrade Fees

  Key questions to ask about upgrade fees:

  How often might you need to upgrade this software?

  Are upgrades available at a nonprofit discount, and if so does your organization qualify?

  Keeping software relatively up to date is important. It increases stability, security and features. It is not necessary to upgrade at every version change, but it is critical to install security patches, and when features that you want are improved, or there are dramatic stability improvements (for example, the upgrade from Windows 98 to Windows 2000), upgrading is important.

  Obviously, the cost of upgrading a single copy of a software product is much less expensive than having to do a site-wide upgrade. You can often get upgrades of proprietary software at discounted fees or donated. The vast majority of open source software has no upgrade fees at all. You can simply download the upgraded version, and install.

  In some situations (like for the Linux distribution, RedHat) it might be easier to go to a local computer store and get a new boxed version of RedHat than spend the time downloading the CD image, and burning it to CD. But that CD image is always available at no cost. (This is not true for all Linux distributions: for example, you cannot get Lindows for free.)

  Administration & Support

  Key questions to ask about administration and support:

  What sources of support are available for the open source option? How would they fit into your overall IT support strategy?

  How important a factor is reliability in your choice of solution?

  Are viruses and other security problems common with the proprietary option?

  All software - whether applications, databases, or operating systems -- requires administration and support of some type. In some cases, you will have your staff provide the support; in other cases, you will hire consultants to do it. Characteristics of the software that determine the level of support needed include how reliable the software is, how vulnerable it is to security problems, and how complex it is to use both for end-users and the administrator. Factoring these into your consideration of OSS is important.

  Using Linux as the primary example, there have been numerous studies and surveys that show fairly conclusively that Linux is more stable and more secure than Windows. In a survey of companies that implement Linux solutions, quoted in LinuxWorld (http://www.linuxworld.com/story/33838.htm):

  The poll was conducted among 2,500 corporate customers around the world, and no fewer than 95% of them rated Linux's reliability as its most important contribution to business value, followed by cost of acquisition (89%) [sic].

  Nonprofits interviewed for this primer that use Linux placed a similar importance on its reliability, as well as security (see Case Studies section). Without exception, every one said that after they moved to Linux, their network was more stable and stayed up longer. Participants also agreed that it is easier to secure their network using Linux. In part this is because Linux and related operating systems were used for the Internet several years before Windows adopted Internet technology, and the open nature of the code enabled developers to snuff out many potential security problems even before the Internet became popular. In part because of these design advantages, computer viruses have not affected Linux, while they are prevalent on Windows.

  While the complete value of increased reliability and security is difficult to quantify, IT labor costs are an area where several nonprofits we talked to experienced clear cost savings. For example, the Springfield Neighborhood Housing Services' consultant said that organizations using Windows for networking usually spend about twice the amount of time on server maintenance than those using Linux, primarily due to more virus problems and system crashes with Windows.

  For an organization that relies on consultants for support, this time saved translates directly into costs saved. For an organization that uses in-house support staff, the savings may be more complex to calculate. However, if you are in a situation where you have multiple servers, one administrator can handle more Linux servers than Windows servers.

  It is also reasonable to assume that the greater reliability and security of Linux systems improves the productivity of end users. Staff can get more work done if their systems are out of commission less often. Fewer network outages are also likely to improve morale. As most of us have learned the hard way, having your computer crash and destroy the document you were writing or being unable to use e-mail for several crucial hours
  during the day is incredibly frustrating.

  While it is often the case, one cannot generalize Linux's reliability to all OSS. There are many OSS projects that are neither more stable nor more secure than their proprietary alternatives, so doing research will be important for comparison.

  In addition to the reliability and security of a solution, you also need to account for its complexity. Complexity can increase support costs in one of two ways: either by increasing the time needed to perform certain tasks, or by requiring a more highly skilled (and thus more expensive) person to do the job. With regard to the first point, our experience and that of the organizations we interviewed is that OSS is not necessarily more difficult (or easier) to administer than proprietary software. An important caveat, however, is that this assumes that the administrator is familiar with OS solution. If not, additional training costs will be incurred (see Training section above).

  With regard to the second point - whether OSS support staff and consultants are more expensive - our experience is that this is less of a concern than many nonprofits expect. For example, Linux administrators tend to be only marginally more expensive (0-10%) than Windows administrators. The larger issue faced by the organizations we interviewed tended to be finding staff and consultants who work with nonprofits and have OSS skills. In the case of networks, there are many more Windows administrators than Linux administrators available in most areas. Again, this does not necessarily hold for all OSS. And, in addition, the open source community affords its users many more informal sources of support than are available with proprietary software (see 'Support'section).

Summary Worksheet

Below is a worksheet you can use to help you calculate the TCO of a proprietary vs. open source system.

Example: File/Mail/Web server providing mail for 25 users with a 4 year investment period

1- There also exist commercial distributions such as RedHat Enterprise or SuSE that range in cost from $80 upwards depending on levels of support and inclusion of proprietary high-end features. However, for the purposes outlined here, any distribution listed above will have the necessary features.

2 - Since this is server software, there will be no training implication for end users.

3 - Based on the assumption that upgrading the OS in 2 years or so will cost the same as the acquisition cost - which is not always the case.

4 - This estimate is based on the assumption that regular, scheduled maintenance will take place

5 - The assumption that Linux maintenance will take fewer hours than Windows maintenance is based on the information in one of the case studies, and is borne out by the experience of four of the authors of this primer who have experience with both operating systems.

Strategic Value

Besides TCO (Total Cost of Ownership), you need to consider what we will refer to as Strategic Value. This type of value is harder to quantify, but can often be more important in the decision process.

One facet of strategic value for open source solutions is the ability to solve problems in ways that would not be possible with proprietary solutions. This includes customizing software to exactly fit the needs of organizations. It also includes having software that is secure enough to enable a wider variety of remote communication and data sharing. For example, an environmental organization put small, inexpensive Linux servers in remote locations that can be easily remotely accessed for administration purposes, but are still very secure. Because of the lower cost, and flexibility of OSS, it is possible to solve problems that may not have had affordable, ready solutions in the past.

Control (or lack thereof) is another strategic consideration that leads some nonprofits to opt for OSS. They may have had a bad experience relying on a proprietary software package designed to serve their particular 'niche' of the nonprofit sector. If the vendor of that software goes out of business, or decides to stop supporting that product, then its customers will likely have nowhere else to turn for support. With OSS, if the original developer disappears the product can live on, supported by its community of users and other developers. So, in the long run, the open source approach can provide a degree of risk mitigation.

Lastly, we would point out another strategic factor unique to nonprofits: philosophical. The philosophical underpinnings of OSS (community-based development, volunteer effort, freely available software, community support) are very much in line with the mission of organizations in the nonprofit sector. Some organizations have focused on this more than others, specifically if their mission is more related to technology (like alternative media organizations, for example). In general, we would argue that all other things being equal, making a choice to implement OSS in a nonprofit organization would add more mission-based value.

Further reading:

http://www.newsfactor.com/perl/story/22012.html

http://australianit.news.com.au/articles/0,7204,6749366%5E15306%5E%5Enbv%5E,00.html

http://www.infoworld.com/infoworld/article/03/08/29/34FElinux_1.html

http://eweek.com/article2/0,3959,1234349,00.asp

http://www.ibm.com/linux/RFG-LinuxTCO-vFINAL-Jul2002.pdf

http://www.itweek.co.uk/News/1131114