Evaluating Open Source Software Viable for Public and Private Organizational Use
Anthony W. Hamann
Computer Science Department
University of Wisconsin – Platteville
Abstract
The concept of open source software has been around since the beginning of the modern computer. For a long time it has not had a significant presence in either the private or the public sector of the computer industry. However, software developed as open source is becoming popular and major companies as well as government agencies are attempting to determine if its stability, reliability and other issues will allow them to use it in their system architectures. To this end, the Department of Homeland Security of the United States is looking into ways of testing and establishing procedures for including open source software. [2] Companies like IBM and Sun Microsystems are establishing open source communities. This paper explains the basic concepts of open source software and evaluates both what makes open source software attractive while at the same time what causes many to be skeptical of its use beyond the user at home.
Introduction
Simply defined, Open source software is software that is distributed along with the human readable code. This gives the end user the advantage of modifying the software, fix bugs and make improvements. Many such software projects are large communities around them that test, fix, modify, and improve the project. A project with a large amount of participation can produce software with a limited number of defects which is available for anyone to download and use. This is very attractive to home users, especially those that have the time and expertise to integrate and use this software, but organizations which depend on their computer infrastructure to perform critical business functions require software that is reliable, stable and will work with the rest of their system.
History of Open Source Software
The concept of OSS is not a new for the computer industry. At the inception of modern computing, programs that did not have the complexity of software today. They often required an organization who purchased a program to get the source code. Many systems required daily modification. Any changes to the format of data or changes in the system required that organization to go back and modify source code. For instance a program written to create sales reports would have to be modified if the name of the volume changed. The data was moved or the space for data needed to be expanded.
Open source software as it is known today began in the late 80’s when personal computers became attainable and feasible. It has grown largely with the rise of the Internet. Some of the largest, earliest and better known open source projects have been Linux operating systems. Other well known projects include server systems like Apache, scripting languages PHP and Perl, database systems like MySQL, office productivity tools like OpenOffice, and a wealth of other software that spans the entire spectrum of the computing world.
The newest development of Open Source Software is that organizations are beginning to be interested in using open source software and integrate various projects into their infrastructure. Projects that are getting the most attention are those that make up LAMP (that is Linux, Apache, MySQL, PHP or PERL) each of which have a significant following. Of the organizations that are considering what role open source software may have, many are agencies of governments for a variety of nations including the United States. Also now many organizations like Sun Microsystems, IBM and Microsoft are sponsoring open source projects of their own.
What Makes Software Open Source?
Open Source Software (OSS) simply is software that is distributed with the human readable source code. OSS not bound to any particular computer language nor is it bound to any particular platform. OSS ranges from very low level programs like drivers or operating systems to very high level scripts. There are a variety of licenses for different OSS projects but any license will include the ten following concepts as outlined by the Open Source Initiative [6].
Free Redistribution
This is perhaps the most noted and obvious aspect of open source software. The project in whole or in part cannot be sold or require any sort of royalty or any other sort of fee. This applies to any project that contains code from another open source project.
There also must not be any restriction put on any party from distributing a OSS project as a component of an aggregate software distribution containing programs from several different sources.
Source Code
This is also an essential component of open source licensing. The source code must accompany the program or there must be a "well-publicized means of obtaining the source code." [6] In other words source code for a project cannot be hidden, buried or put into a format that does not allow others from finding, reading or altering the source code. An image file (gif, jpeg, png, tiff, etc.) of the source is not acceptable. It also must be the source code and not in an “intermediate forms such as the output of a preprocessor or translator.” [6]
Derived Works
OSS Licenses must allow the user to modify and derive other work from the source code. As an example, someone develops a simple text editor and distributes it with an OSS license. At that point anyone can download the source and modify it by adding a spellchecker and distribute it. This is allowed and in some ways encouraged as long as anything that is developed from another OSS project has the same type of license.
Integrity of the Author's Source Code
An allowance is made for developers desiring to protect their source code by forbidding anyone to distribute it in a modified form. In this case the license needs to allow other developers to distribute “patch files” that allow end-users that download the software to modify it themselves.
No Discrimination Against Persons or Groups
Provisions in the license cannot exist that prohibit any particular group of people from downloading the software or the code. As much as it is not necessary for non-computer geeks to acquire and pretends to read code it is not nice nor is it allowed to discriminate.
No Discrimination Against Fields of Endeavor
An OSS license also cannot discriminate against people based on the purpose or intent that they have for the software. OSS developers cannot place restrictions limiting the kind of users allowed to use and benefit from their project. The government and Microsoft are end-users too.
Distribution of License
Redistribution of an OSS project must guarantee the same rights of the original license and must not require the end user to execute any additional license.
License Must Not Be Specific to a Product
Licenses may not require end-users to buy any product to use the software. For example, a developer cannot require you to buy his garage band’s newest CD to download his open media player.
License Must Not Restrict Other Software
This restriction is similar to the above restriction with regard to the products. End-users cannot be forced to buy other programs in order to obtain a copy of the program. That is not to say there cannot be requirements of a particular platform, a certain Linux operating system for instance, in order to make the software run but it cannot be a condition of the license in order to obtain a copy of the project.
License Must Be Technology-Neutral
This restriction is also similar to the above two restrictions. End-users cannot be forced to buy particular equipment in order to obtain a copy of the program. Again it does not mean that a software project is supposed to work of any machine that an end-user has but having particular hardware cannot be a condition of the license nor can it forbid using an alternative to the hardware for which the software was designed.
OSS Issues That End-Users Must Consider
An organization has many issues when considering whether or not to implement any software product. It is important to understand that some of the issues that are not unique to OSS but are of a somewhat different nature in that they are often difficult to evaluatecompared to a proprietary software alternative. The following highlights some of these factors are and while it is not meant to be a complete list it does show some of the major issues that organizations face when consideringOSSuse.
Cost
Cost is not limited the amount of money that an organization pays to obtain a software program. The sources of cost come from as follows. All of these add to the cost of using any software program.
- The cost of a program also includes the amount of time to integrate into the system, andthe time and resources needed totrain members of the organization to use the software.
- Resources needed to modify and test the software to avoid conflicts, errors and other problems.
- Cost of dealing with problems when they do occur.
- Depending on the system, consultants or more experienced professionals may need to be hired.
Upfront the cost of OSS software is free. However, it is estimated that for an organization, the total cost of implementing a Linux server is higher than implementing a commercial equivalent. [5] This is attributed to the costs of the added time that it takes, the expertise that is required, and the training that both the IT department and any other end-user needs to use the system, any on-site development needed, system integrity testing and all the other costs which pile up to get a dependable system online.
This issue really comes down to Total Cost of Ownership. When a company decides to use OSS and expends the cost to modify it and to test it and everything else it must do in order to ensure that it is something the business can depend on it. Unfortunately the investment put into a integrating OSS is not something that can be recovered in anyway since it cannot be sold or leased to anyone else but can only be distributed for free. With more traditional proprietary software the cost of the actual software exists but part of that cost include some of the implementation costs, as well as testing, and the risk that is imposed by the system developed.
Security
Security is the value of protection software has against people inside and outside of an organization doing malicious things to the system or the data that it stores. Secure piece Software does not present opportunities for incursions to happen and provides measures that document and actively restricts the ability of people to circumvent an established system.
Security is a huge issue especially for government agencies, but private organizations have just as much to lose. ManyOSS projects have been found to have less security problems than proprietary software equivalents. But, while some OSS may be more secure it has two major problems.
First, OSS comes as is, there is no one that stands behind the software and any security problems that are found may be left to the organization to find and fix. Along with that if losses due to a security problem can’t be recover. If it were a commercial developer there are certain legal remedies that don’t exist with OSS.
Second, anyone can download the source code to OSS and as I have indicated above, makes such softwaremore vulnerableto a party with malicious intent. It is simply easier to find weaknesses which are a part of any software program. So, even if an OSS project is not as vulnerable it still can be less secure than a proprietary software equivalent.
Testing
Testing is the process of identifying and correcting problems or bugs in a system. Not only is the amount of testing done important, but equally important is the quality of the testing done. A large group of people can all test a piece of software and not identify a bug because they testing is not thorough or the environment in which the testing was done did not represent the environment in which the software may be implement.
OSS software has an advantage in that a project with a high level of participation has the possibility of people all over the world testing a particular piece of software. However that is not the case for every OSS projects and many times OSS software can be a complete unknown to an organization looking to implement it. A project that has had a large volume of testing still my have unknown bugs due to the inexperience of the testers and the fact that now of the testing involves a larger system than what the typical tester has access. Implementing OSS may mean an organization has to do its own testing or use software with unknown and potential dangerous and costly bugs.
The Department of Homeland Security of the United States has spenta lot of money to fund groups that are attempting to find a solution to this problem. Shown in the Table 1 are some of the results that one such group Coverity, Inc. It actually shows some very positive results for many commonly used OSS projects. Coverity is also working on an automated solution for testing software. Still even with such a system in place, testing of OSS will always be a task for the end-user rather than the developer because the liability is place solely on the end-user.
Table 1: Detailed Results of OSS Project Testing done by Coverity [2]
Project / Current # Defects / Original # Defects / Lines of Code / Defects / KLOCAMANDA / 0 / 108 / 88,426 / 0.000
apache-http / 24 / 32 / 128,065 / 0.187
ethereal / 5 / 143 / 1,167,470 / 0.004
Firebird / 192 / 163 / 301,850 / 0.636
Firefox / 7 / 108 / 338,272 / 0.021
FreeBSD / 632 / 635 / 1,582,166 / 0.399
Gaim / 50 / 113 / 325,531 / 0.154
gcc / 173 / 140 / 750,271 / 0.231
Gnome / 211 / 896 / 539,898 / 0.391
icecast / 2 / 12 / 37,476 / 0.053
Inetutils / 29 / 29 / 72,287 / 0.401
Linux-2.6 / 782 / 1062 / 3,271,429 / 0.239
MPlayer / 191 / 284 / 490,746 / 0.389
Net-SNMP / 61 / 148 / 173,265 / 0.352
NetBSD / 2394 / 3230 / 5,087,378 / 0.471
OpenLDAP / 0 / 158 / 262,404 / 0.000
OpenSSL / 34 / 66 / 202,010 / 0.168
OpenVPN / 7 / 7 / 69,970 / 0.100
Perl / 68 / 89 / 485,001 / 0.140
PHP / 42 / 204 / 421,667 / 0.100
PostgreSQL / 294 / 295 / 816,681 / 0.360
ProFTPD / 25 / 26 / 89,382 / 0.280
Python / 14 / 96 / 273,980 / 0.051
Samba / 0 / 216 / 314,484 / 0.000
snort / 44 / 48 / 90,986 / 0.484
SQLite / 6 / 31 / 54,472 / 0.110
Squid / 12 / 53 / 136,288 / 0.088
tcl / 65 / 69 / 120,702 / 0.539
wxWidgets / 28 / 73 / 329,208 / 0.085
X.org / 1441 / 1681 / 2,353,985 / 0.612
xine / 189 / 347 / 578,994 / 0.326
XMMS / 0 / 6 / 117,000 / 0.000
Compatibility
Compatibility is how well software interacts with other software in a system. It includes how software uses memory, network resources, files, etc. A compatibility conflict can cause corrupt data, corruption of the program or other programs on the system or the corruption the entire system. Having software that is compatible is very important and important to validate.
Proprietary software especially that which is custom made can make compatibility part of the requirements of the project. Commercial third-party software of any quality will if nothing else follows industry standards. However, like the testing issue, OSS is an unknown. While many OSS projects follow standards with regard to file formats, GUI layout, and the protocols that it uses the level at which it does all of these needs to be known be the end-users and many times this requires more testing and troubleshooting efforts.
Liability
Liability is the risk of using a software program and the risk of the problems that result from its failure. Since all software programs has defects which testing as discussed before can only limit but never remove. The liability of software is very much tied the cost of the system as well as compatibility and security issues.
Liability for several reasons is a big problem. As already mentioned, OSS comes as is and has no one standing behind it. Potential losses incurred from either the failure of a system or problems that the software has, security problems for example, cannot be recovered and can represent the largest cost of a system. A computer system can contain financial data, trade secrets, intellectual property and allow business to connect to their clients with whom it is important to maintain good relations. All of this means that it is important for a computer system that a business can trust.
In the case of a proprietary system, liability in part is shared with the company that designed and created the system. So if an accounting system crashes due to a defect and the daily transactions of the bank using it are lost as well as some account information, the organization has recourse to recover damages. This is partially why professional accounting systems cost a lot of money. OSS project do not have this protection and the liability is held by the organization using OSS.
Conclusion
The contemporary concept of Open Source has been around for twenty years or so, many issues legal and otherwise continue to be a problem for organizations considering implementing OSS. While some remain very excited at the possibility of using OSS because of the fact that it has no upfront cost but it is important to consider what it will take to implement, train end users, and maintain. Using the categories I mentioned an organization can determine if OSS is a viable solution.
OSS as it becomes more and more popular is seen by many to be a future option. Most agree that for the now the cost and risk prevent OSS from having more than a small margin of the market. Linux servers are thought to make up only 3% of the current market share. [5] Also traditional commercial software companies are beginning to using open source development for select projects. So given more time OSS is likely to become a viable option for many different kinds of organizations to build their systems with.
References
[1] Alan MacCormack, John Rusnak, Carliss Baldwin. Exploring the Structure of Complex Software Designs: An Empirical Study of Open Source and Proprietary Code. June 2005. (
[2] Automating and Accelerating Open Source Quality. Coverity, Inc. (
[3] IraHeffan. How to Safely Participate in an Open Source Project. O’Reilly Open Source Convention. Wednesday, August 3rd, 2005.
(
[4] Mozilla. (
[5] Nicholas Economides, Evangelos Katsamakas.Linux vs. Windows: A comparison of application and platform innovation incentives for open source and proprietary software platforms. Revised September 2005. (
[6] Open Source Initiative. (