Evaluating Open Source Software Viable for Public and Private ...

equableunalaskaΑσφάλεια

9 Δεκ 2013 (πριν από 3 χρόνια και 10 μήνες)

111 εμφανίσεις

Evaluating Open Source Software Viable for Public and Private
Organizational Use



Anthony W. Hamann

Computer Science Department

University of Wisconsin


Platteville

hamanna@uwplatt.edu



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 an
d 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 sof
tware 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 t
he 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 wit
h 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.


O
pen 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 th
e
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 ar
e 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 l
icenses 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 whol
e 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 a
s
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
-
publi
cized 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.
A
n

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 c
ode.
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 proh
ibit 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 gov
ernment 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 Specifi
c 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 r
estriction 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
Lin
ux

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 par
t
icular hardware

cannot be a condition o
f 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 i
mportant 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 evaluate

compared to

a proprietary software alternative.


The following
highlights some of these
factors ar
e

and while it is

not

meant to be

a complete list
it does show some of the

major
issues that organizations

face when considering

OSS
use
.



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,

and

the time and resources
needed to

train 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.


Upf
ront 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
]

Th
is is attributed to the

costs
of the

added time

that

it tak
es,
the expertise that is required,
and the
training
that

both the IT department

and a
ny other
end
-
user needs to use the system,
any
on
-
site development

needed, system integri
ty
testing and all the other costs
which

pile up

to get

a dependable system onlin
e.


Th
is

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
. Unfortun
ately 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 softw
are 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
organi
zation doing malicious things to the system or the data that it stores.
S
ecure piece
S
oftware does not present opportunities for incursions to happen and provides measures
that document and actively
restricts the ability of people to circumvent

an establi
shed
system.


Security is a huge issue especially for government agencies, but private organizations
have just as much to lose.
Many

OSS projects have been found to have less security
problems than proprietary software

equivalents
.
But
, while some OSS ma
y 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 pr
oblem 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 software

more vulnerable

to

a party with
malicious intent
. It is simply easier

to find weakn
esses 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 id
entifying 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 the
y
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
.
I
mplementing 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
spent

a lot
of money to
fund
groups that

are

attempt
ing

to find a solution to this problem. Shown in the Table 1
are some of the r
esults 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 s
uch a system in place, testing
of
OSS wi
ll 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
/
KLOC

AMANDA

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.48
4

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
corrupt
ion

the entire syste
m. 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 w
ill 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 n
eeds 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 program
s 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 syste
m. 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 w
ell 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.



Refe
rences


[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. (
http://opensource.mit.edu/papers/maccormackrusnakbaldwin2.pdf
)
.


[2] Automating and Accelerating Open Source Quality. Coverity, Inc.
(
http://scan.coverity.com/
)
.


[3] Ira

Heffan. How to Safely Participate in an

Open Source Project. O’Reilly Open
Source Convention. Wednesday, August 3rd, 2005.

(http://conferences.oreillynet.com/cs/os2005/view/e_sess/7483005)
.


[4] Mozilla. (http://www.mozilla.com)
.


[5] Nicholas Economides, Evangelos Katsamakas.

Linux vs. Windo
ws: A comparison of
application and platform innovation incentives for open source and proprietary software
platforms.

Revised September 2005.
(http://opensource.mit.edu/papers/economideskatsamakas.pdf).


[6] Open Source Initiative. (http://www.opensource
.org/docs/definition.php).