open source final online

8/8/2019 Open Source Final Online

1/16

OpenSource:

UnderstandingIts Applicationin the Voting

Industry

A publication of the Election Technology Coun


2/16

Who We Are

The Election Technology Council (ETC) is a 50(c)6 trade association consisting of voting technology providers

in the United States. The current membership of the Council represents the voting system platforms for over 90%

of the registered voters in the U.S. and providers of other technology platforms such as electronic pollbooks and

voter registration/election management software.

The mission of the ETC is to promote the common interests of the election industry vendor community. The

goal of the ETC is to support policies that help voters exercise their right to vote and have their votes accuratelyrecorded, veried and counted.

Toward that goal, we support:

Independent verication of electronic voting

Training and deployment of sufcient poll workers and voting equipment to efciently and

accurately serve the electorate

Voting procedures and equipment that increase voter participation

Long-term stability of voting procedures and the regulatory framework that oversees elections

Transparency among regulatory and certication agencies

Sufcient funding for the states to carry out federal mandates in the eld of election administration

The objective of the ETC is specically to:

Educate and inform the public, regulatory authorities and customer interest groups of possible

implications and outcomes of public policy and regulatory requirements, as anticipated by the

vendor community. The efforts of the ETC will be focused upon the following organizations:

-Federal Regulatory authorities, including the EAC, TGDC, and NIST

-Federal Legislative authorities, including Congress and relevant committees

-Customer interest groups, including such organizations as NASED, NASS,

The Election Center, IACREOT, and NACRC.

-State level chief election ofcers

-Academia-State level legislative bodies

It is important to understand what the ETC does not do. The ETC does NOT:

Lobby for any particular type of voting process

Lobby on any subject or situation that does not apply to all ETC members

Collaborate on pricing or market division

For more information on the activities of the ETC, visit www.electiontech.org.


3/16

Executive Summary In recent years, the potential for open

source software has been proposed for use in

voting systems. All too often, this proposal has

not claried the term open source for the benet

of policymakers or the elections community. For

the elections community, the frequent use of this

term, without an appropriate clarifying denition,

has resulted in confusion about its meaningand viability for voting. In reality, many of the

proposals for open source are more appropriately

characterized as calls for software disclosure.

No individual effort has examined the practical

challenges of implementing open source software

in the current election administration environment

since the implementation of the Help America Vote

Act of 2002 which created a federal certication

process for voting systems.

It is clear that open source software plays arole in the software industry marketplace, but the

potential benets, as put forth by its proponents,

fail to capture the nuances associated with the

voting industry which differ signicantly from the

standard commercial software marketplace. All

of the products offered for voting purposes must

be of sufcient quality to pass federal and/or state

certication requirements prior to their acceptance

and use in an election. In a pure open source

software development model, active testing of the

product by the end-user (i.e., election ofcials)during its deployment is a critical facet of the

softwares development. In a proprietary model,

signicant time and resources are spent in the

initial design of the software and hardware prior to

pursuing product certication and deployment.

Underlying this argument over open

source is the attempt to establish the principle

of transparency for products that are involved

in the American voting experience. Dr. Joseph

Hall (007) describes a transparent system as one

that supports accountability, public oversight,

comprehension and access to the entire process.

(p. ) These characteristics of a transparent process

represent a valuable foundation for discussions

over the viability of an open source model versus

a proprietary model. Unfortunately, the discussion

has too often focused on an either/or approach

rather than recognizing the separate challenges

associated with each environment.

Make no mistake, it is clear that open source

should be recognized as a potential product substitute

for proprietary software systems. Articles entitled

Microsoft vs. Open Source: Who Will Win?

help to illustrate the conicting dynamic between

those who embrace the supremacy of open source

over proprietary platforms. However, rather than a

conict model for these two product offerings, further

research should be done to explore the challenges

of offering an open source product in a regulatedenvironment. It is the current regulatory environment

which represents the most signicant hurdle for the

use of open source software in the voting industry.

By understanding open source as a market

alternative to proprietary systems, it will become

evident that efforts to mandate its use without

sufcient product offerings would be unwise and

premature. Given the economic dynamics of the

marketplace, state and federal governments should

not adopt unfair competitive practices which showpreferential treatment towards open source platforms

over proprietary ones. Legislators who adopt policies

that require open source products, or offer incentives

to open source providers, will likely fall victim to

a perception of instituting unfair market practices.

At worst, policymakers may nd themselves

encouraging the use of products that do not exist and

market conditions that cannot support competition.

Market dynamics should remain the ultimate

arbiter over whether an open source platform or

a proprietary product offering is the best solutionto t the needs of an election jurisdiction. In an

effort to further educate those who are responsible

for providing oversight on the operation of voting

systems (i.e., federal, state, and local election

ofcials), it is important to identify the challenges

associated with an open source product offering and

how both open and proprietary systems differ in their

approaches and abilities to support state and local

election ofcials.

Without a better understanding of open

source, those who advocate it as a policy movement,

rather than a separate and distinct product offering,

may nd themselves doing more harm than good.

David Beirne

Executive Director

April 009

Microsoft vs. Open Source: Who Will Win?, HBS

Working Knowledge. Harvard Business School, June 6, 005.

http://hbswk.hbs.edu/item/484.html.


4/164

I. What is Open Source?Open source software can be dened as

software that is made available freely to all.

(Hippel, 00, p. 09) However, open source

development models, which produce open source

software, are dened as a process for software

developers who voluntarily collaborate to

develop software that they or their organizations

need. (Hippel, 00, p. 09) In an effort toreconcile these denitions, the term open

source will be used to refer to an environment

in which the software source code is available

for inspection, analysis, and programming

enhancements through a communal effort.

The Open Source Initiative outlines

various criteria governing licensing that must

be present for software to be considered open

source (see inset on page 5). Fundamental to

its criteria, open source is software that mustbe freely exchanged and permits user generated

adjustments (OSI, 009). Given the licensing

parameters outlined by the Open Source

Initiative, it is clear that open source is typically

used to describe a specic product offering and

its governing licensing terms. It does not refer

to simply disclosing software source code to the

general public.

For software that is generated through

private investment and subject to copyright and

intellectual property restrictions, but is thenmade freely available for public review, the term

disclosed software is more appropriate. This

denition for disclosed software is also more

indicative of the intent behind advocacy groups

and legislation calling for open source software

in voting systems. The involvement of the

government in requiring the willful disclosure

of all proprietary software to the general public

calls into view the specter of intellectual property

rights and the potential for a government taking

in violation of the United States Constitution

(Hall, 007). Based on the lack of currently

viable open source developed voting technology,

it is clear that advocacy groups are encouraging a

disclosed software model rather than a true open

source requirement.

Over the last twenty years, open source

Open Voting Consortium, draft legislation for

State of California, www.openvotingconsortium.org/legis-

lation/draft., retrieved /0/009.

products have been offered and represent a

clearly identied alternative to product platforms

that are governed by traditional proprietary

claims. Products such as Apache software

for servers, the Linux operating system, and

various le sharing/communication software

platforms represent some of the more successful

open source projects to date (Woods, 005).

All of these platforms benet from the lackof a regulated environment and possess an

established community of contributors who

are users of the products and benet from its

operation.

One voting system provider that is

often used as an illustration of the viability

of open source in voting products, is from a

company named Software Improvements. In

00, the electronic voting software (referred

to as eVACS) used by the Australian CapitalTerritory Electoral Commission was made

publicly available under the GNU general

public license (GPL), one of two popular

licenses available for open source platforms.

While Software Improvements was lauded for

its open source licensing, it decided to begin

restricting access to its source code in an effort

to protect its intellectual property investment.

Carol Boughton, Software Improvements

Managing Director at the time, was quoted as

saying, We need to nd a way that still ensurestransparency and access, but protects our

intellectual property. (Deare, 004, p. ) Under

its revised licensing, Software Improvements

software would be available to only authorized

persons. While the eVACS software was

not developed in an open source model, its

licensing did incorporate an initial open source

approach towards its disclosure (Deare, 004).

The example of Software Improvements

illustrates the conicting nature of transparency

and marketability, but it also illustrates how

the attempt to disclose software has been

misconstrued as open source. While lauded as a

pioneer for its licensing and software disclosure,

the company had to examine its long-term

viability. The resulting decision of Software

Improvements to restrict access to its software

is a rational approach to a problem and points to

the need for an examination of the characteristics


5/165

Open Source Criteria

The following is a list of criteria associated with

open source software:

. Free Redistribution: The license

shall not restrict any party from selling or

giving away the software as a component of

an aggregate software distribution containing

programs from several different sources. The

license shall not require a royalty or other fee

for such sale.

. Source Code: The program must

include source code, and must allow distribution

in source code as well as compiled form.

Where some form of a product is not distributed

with source code, there must be a well-

publicized means of obtaining the source codefor no more than a reasonable reproduction cost

preferably, downloading via the Internet without

charge.

. Derived Works: The license

must allow modications and derived works,

and must allow them to be distributed under

the same terms as the license of the original

software.

4. Integrity of the Authors Source

Code: The license may restrict source code

from being distributed in modied form only

if the license allows the distribution of patch

les with the source code for the purpose

of modifying the program at build time. The

license must explicitly permit distribution of

software built from modied source code. The

license may require derived works to carry

a different name or version number from the

original software.

5. No Discrimination Against Persons

or Groups: The license must not discriminate

against any person or group of persons.

6. No Discrimination Against Fields

of Endeavor: The license must not restrict

anyone from making use of the program in a

specic eld of endeavor.

for both open source and disclosed sourcesoftware models and their impact on a companys

viability. In fact, there remains a multitude

of licensing options available for open source

platforms, but some are characterized as being

less than true open source if they do not adhere

to the licensing terms embraced by the Open

Source Initiative (Woods, 005).

It is the dueling nature of transparency

and marketability which continues to cause

debate within the open source community and

those who attempt to use open source productsas a foundation for future software enterprises

(Woods, 2005). Much of this internal conict

within the open source community can be traced

to its beginning and the ideas embraced which

are more indicative of a social movement rather

than a series of product offerings.

7. Distribution of License: The

rights attached to the program must apply to all

to whom the program is redistributed without

the need for execution of an additional license

by those parties.

8. License Must Not Be Specifc to a

Product: The rights attached to the programmust not depend on the programs being part of

a particular software distribution.

9. License Must Not Restrict

Other Software: The license must not place

restrictions on other software that is distributed

along with the license software. For example,

the license must not insist that all other

programs distributed on the same medium must

be open-source software.

0. License Must Be Technology-

Neutral: No provision of the license may be

predicated on any individual technology or style

of interface.

(Source: Open Source Initiative, www.opensource.org/

docs/osd, retrieved on March 4, 008.)


6/166

Disclosed vs. Open: ClarifyingMisconceptions The issue of transparency and security

of voting system software are foremost on the

minds of advocates when it comes to a policy

discussion on what is characterized as open

source. It is conceded that a pure open source

development model may yield comparablebenets in the long-term. However, taking a

software product that was once proprietary and

disclosing its full source code to the general

public will result in a complete forfeiture

of the softwares security. The subsequent

disclosure of software to the general public

will become dependent on the existence of a

robust improvement process to address any

identiable shortcomings within the software.

The subsequent improvements will also become

entirely dependent on the quality of the softwaresource code reviewers in whether or not all

potential bugs have been identied. Although

computer scientists chafe at the thought of

security through obscurity, there remains

some underlying truths to the idea that software

does maintain a level of security through the

lack of available public knowledge on the inner

workings of a software program (Wheeler,

005). However, if proprietary software is

ripped open through legislative at, whatever

security features exist are completely lost until

such time that the process improvement model

envisioned by the open source community has

an opportunity to take place (Hall, 007).

If we apply this approach to the use of

voting systems and the desire to maintain the

utmost security, the difculty of transitioning

to an open source or disclosed software

environment is revealed. Elections occur

each year, not every two to four. By forcing

the openness of proprietary software to thegeneral public, all security is sacriced for the

sake of transparency. While laudable based on

perception, the pursuit of widespread public

disclosure of proprietary software without

consideration of a product improvement model

would have a signicant negative impact

on market conditions. In a statement before

the California legislature in 006, Deirdre

Mulligan and Joseph Hall illustrated the

difculties surrounding the use of an open source

model in a regulated industry such as voting:

Given the fact that any modied voting system

software must be recertied at both the federal and

state level, it would also be difcult for a company

to optimize or customize open source voting

software for their customers when they wouldhave to have the resulting product certied. (p.

8) In a subsequent article entitled Transparency

and Access to Source Code in Electronic Voting,

Dr. Hall also acknowledges the danger associated

with opening proprietary software to full public

disclosure. Since computer scientists have yet to

nd a method for writing bug-free software, public

disclosure of the system source code will inevitably

result in disclosing vulnerabilitiesIn the case of

voting systems, disclosing information on known

vulnerabilities arguably helps would-be attackersmore than system defenders. (Hall 007)

Dan Wheeler, computer scientist and

author, summarizes the challenge of transparency

and security best with the following observation:

When a program began as closed source and

is then rst made open source, it often starts

less secure for any users (through exposure of

vulnerabilities), and over time (say a few years)

it has the potential to be much more secure than

a closed program.....Just making a program

open source doesnt suddently make a program

secure, and just because a program is open

source does not guarantee security. (Wheeler,

005) This observation perfectly describes the

hazards associated with disclosing proprietary

software without consideration for an appropriate

transition. It also underscores the need to pursue

an appropriate balance of respecting the role of

intellectual property and transparency when it

comes to voting system software. Given the critical

nature of voting system software to our nationsinstitutions, it is possible to protect intellectual

property while instituting government controls for

the deposit and subsequent investigation of voting

system software should the need arise in close

election contests.


7/167

History of Open SourceIn the 960s and 970s, much of the

software used in computers was a result of

collaborative work within academic institutions

(Hippel, 00). This communal approach to

software development was seen as an expression

of the university culture and the free exchange of

ideas. This all changed when the Massachusetts

Institute of Technology (MIT) licensed thefruit of these labors to a commercial rm who

subsequently restricted access to the software.

In response, Richard Stallman from MITs

Articial Intelligence Laboratory founded the

Free Software Foundation in 985. The Free

Software Foundation was meant to protect these

communal software development efforts from

future commercialization and ensure continued

free access to software products (Hippel, 00).

The General Public License (GPL) wasdeveloped by Stallman as a means of protecting

the future work of software developers. The

GPL ensured that source code would remain

publicly available and all subsequent software

improvements would also remain open for

contributions. The initial free software

movement was recast in 998 as open

source in an effort to make this new software

development environment more palatable to the

private sector. Open source was now a reference

not just to source code and its availability, butthe actual licensing and distribution of the

software product itself (Perens, 005).

From the initial pursuit of the Free

Software Foundation to its General Public

License and now the Open Source Initiative,

which attempts to balance the need for

commercialization of open source products, the

issue of licensing remains a point of contention

for those involved in the software community.

The initial evolution to open source began more

as a social movement and has now morphed

into a potential business approach and series of

alternative product offerings.

The remaining core difference between

existing open source software offerings and the

voting systems industry is the strict external

regulation of voting system products. It is

the contrast in upfront design requirements

associated with a commercial voting system

product offering versus the continuous software

Popularity of Current OpenSource Projects Given the needs of an open source projectto garner a sufcient number of contributors, further

examination needs to be done on the most popular

open source projects available and how voting system

software offerings might be able to garner such a robust

support system and project leadership.

SourceForge.net is an online portal of currentopen source projects. Below is a listing of the most

popular open source projects (based on total number of

downloads since the projects inception) available on

sourceforge.net:

Software Name (total # of downloads)

. eMule (479,794,489)

. Azureus (,97,77)

. Ares Galaxy (88,70,07)

4. 7-Zip (6,44,644)

5. FileZilla (56,675,7)6. GTK+ and The GIMP installers for Windows

(55,84,80)

7. Audacity (55,78,880)

8. DC++ (54,7,04)

9. BitTorrent (5,974,805)

0. Shareaza (46,805,0)

Source: http://sourceforge.net as retrieved on 2/20/2009.

Below is a listing of current open source voting software

efforts currently underway and the number of downloads

for each:. OpenSTV (8,84)

. FREE e-democracy project (,446)

. evm (,44)

4. EML Voting Project (96)

5. Verifyable Electronic Voting (688)

6. SOLON-free election program ()

7. electronic voting platform (55)

8. osdv-sharp (0)

9. Open Source Democracy (0)

0. Secure Electronic Voting System (0)

Source: http://sourceforge.net as retrieved on 4/8/2009.

Based on the current lack of popularity for the open

source voting applications, the recruitment and viability

contributors to a voting system project will remain a

signicant challenge. At a minimum, this points to a

need for other incentives to assist with recruitment and

retention of open source contributors.


8/168

Idea/Need

Experiment/ProofofConcept

PublicPrototype

CommunityFormation

throughareleasecycle

Release1.0(orhigher)Stagnation/

abandonmentEvolution/stability

Source: Woods, D. (2005) Open Source for the Enterprise, p. 17, Figure 1-1.

Figure 1: The Open Source Life Cycle

Open source projects rely on a

core set of contributors in order to remain

active and mature as a process building

towards a functioning product. Each project

begins with the initial determination of an

idea or need which can originate from any

one person or community. The next step

in the process is the initial development

for a proof of concept to determine the

feasibility of the project, leading directly

into the initial public prototype. Thepublic prototypes development is the core

infrastructure surrounding the project and

consists of the initial steps at programming

for the new software program. The intent

of the public prototype is to assist in

the creation of a community around the

prototype with a clear understanding of

the original projects proof of concept.

Through time, the initial prototype is opened

for review and contributions are made by

others within the community. Each subsequent

addition to the software program is released

reecting an incremental evolution in the

product development. After this initial core

development, the project will either become

stagnant or will continue to evolve and mature.

Stagnation or abandonment of open source

projects may occur through a perception

of completion for the project, poor projectleadership which removes incentives for future

contributors, or simply through lack of interest

(Woods, 005).


9/169

improvement cycle indicative of an open source

model that provides the most signicant point of

divergence in comparing the two models (Woods,

005).

II. Accountability in an OpenSource Model

An open source model relies upon a seriesof contributors as part of its communal approach

for reviewing software and building toward a full

product offering (Reid, 004). Since open source

arguably diminishes the monetary incentive for

contributing to an open source software project,

what are the motivating factors for those who

wish to contribute? Forrest Cavalier divided

contributors into three different types:

. Need-driven consumer: has self-

interest, no technical knowledge,but reports defects

. User-developer: capable and

genuinely interested in product,

motivation comes from a specic need or

for pursuit of recognition

. Core developer: active in

development, has ability to

foster credibility for project within

community. (Siedlok, 00, p.6-7)

In a publication from Eric von Hippel and Georg

von Krogh (00), the characteristics of opensource contributors were further examined.

Hippel and Krogh found that most of those users

who downloaded open source software are free

riders in that they do not actively contribute to a

project. Of those who do contribute, most do so

from a personal motivation that is tied towards

learning and pure enjoyment from programming.

Open source contributions typically come

from users of the software rather than software

manufacturers (Hippel, 00).

The obvious question surrounding the

initial viability of an open source platform is

How do you recruit and maintain an initial core

set of contributors? In the report, Dynamics

of Open-Source Contributors, three conditions

were outlined for the successful recruitment of

contributors to an open source project:

. The contributors performance must be

visible;

. The amount of effort exhibited by the

contributor must be recognized;

. The performance of the contributor

must be seen as a signal of the

contributors talent.

(Lerner, 00, p. 4)

These three conditions point to the need for

a pure open source platform to recognize

contributors for their talent and skills in lieuof the nancial incentives associated with

a proprietary undertaking. Robert Hahn

(00) provides a succinct examination on the

personality characteristics of an open-source

contributor:

Programmers often ourish as part

of communities that prize cooperation and

openness. Status within the community is

largely derived from showing how good one is

at programming--which requires showing offthe source code-- and how committed one is to

furthering the collective effort--which requires

providing source code for others to work from.

(p.)

Due to the volunteer nature of an open

source model, the issue of accountability in this

environment provides a stark contrast to the

accountability within a traditional proprietary

offering. In commercial product offering, the

individual company is held accountable for

delivering a product that meets all applicablestandards and for meeting project milestones.

Contract requirements are often used to establish

performance milestones and clearly delineate

the responsibilities of a provider. Within a

corporate structure, liability is clearly delineated

to the company. In an open source environment,

a volunteer group of collaborators will not be

so clearly subject to nancial liability or have

a clear line of accountability. It is possible

that a hybrid approach could be undertaken for

an open source project which is launched in

partnership with a private company, but the issue

of intellectual property investment and concerns

over the long-term viability of the companys

product will likely trigger a need to adopt a

more restrictive licensing approach, one more

indicative of a traditional proprietary model.


10/160

toward the development of a viable product.

The open source model incorporates product

improvements during its initial design,

but relies signicantly on the paralleldevelopment process prior to the products full

implementation.

In a commercial setting, there is

substantial risk presented if the design phase

fails to adequately capture the needs of the

market. If so, the market will not deem the

product a success and the product will fail

unless the process begins again. With a linear

model for development, the commercial

product offering lends itself towards a nite

process that is driven by external factors suchas product certication and customer support.

The open source model, with its

continuous nature and framework, will require

substantial project leadership to determine

adequate points of completion for the next

product enhancement in order to achieve

product certication and customer delivery.

These models capture the complexities and

illustrate the challenges an open source model

would confront in a regulated industry.

Define

RequirementsDes ig n I mple me nta tion I nte grat ion

FieldTesting

Support

Define

RequirementsDesign FieldTesting Support

ParallelDevelopment Integration

Figure 2: Contrasting Commercial Project and Open Source ProjectDevelopment Cycles

Source: Siedlok (00), Characteristics and applicability of Open Source-based Product Development Model in Other

than Software Industries. p. 9. obtained from, Lighthouse Case Studies, 999, Open Source Software. A Grassroots

Development Model, Alliance for Converging Technologies.

Commercial/Proprietary Development

Open Source Development

Figure illustrates the commercial/

proprietary and open source development models.

The most striking contrast between the two models

is the need for parallel development for an opensource product offering versus the linear line of

development in the proprietary model.

In a proprietary model, the requirements

for software are dened based on initial feedback

from potential consumers and market demand.

This feedback is incorporated into the design phase

and the process is dedicated towards taking the

product design into the implementation phase.

This model is linear with the aim of deploying an

initial product based on the intense attention given

to the products design.In an open source model, the software

requirements are dened and incorporated into

the initial design with attention given to the

need to solicit user feedback during actual eld

testing. During this same period of eld testing,

parallel development and new design features are

integrated into the software solution.

While both models incorporate continuous

product improvements, the commercial model is

front loaded with time and resources dedicated


11/16

III. Applicability toVoting Systems

Since 00, the barriers for new voting

system providers to enter the market have

signicantly increased due to rising federal

certication costs. In addition to federal

certication costs, any potential provider must

also secure state certication and incur this

additional cost prior to securing any purchaseagreements for the products. The initial capital

outlays just for federal product certication

alone can surpass $4 million dollars which

does not include the start-up costs associated

with research and development (Beirne, 008).

In addition to the problems illustrated with

establishing a sufcient community of open

source contributors, the nancial challenges

associated with an open source project are

substantial.It is not impossible for an open source

project to receive adequate nancial support for

the initial development of a software product, but

this would likely have to be a continuous funding

source either through individual sponsorships or

a corporate partnership (Hall, 007). If history

is a lesson in this regard, the direct involvement

of a corporation may result in licensing which

is less than fully transparent as witnessed with

Software Improvements out of Australia. In a

proprietary model, the nancial risks associatedwith achieving certication, or potentially facing

decertication, is born by the manufacturer. In

an open source model, the nancial risks are

dispersed and may remain unclear as to who will

be the responsible party to shepherd the product

through both state and federal certication and

ultimately responsible for preparing all of the

necessary documentation required.

In a pure open source development

model, the number of contributors across a wide

spectrum collaborating for a mutual pursuit may

yield benets over the long-term. However,

it can be argued that the communal nature of

an open source project and the length of time

associated with its development undermines its

full potential (Reid, 004). The combination of

contributors exhibiting specialized knowledge

in particular areas of software and the lack of a

strong management core can lead to problems

with the management of the project leading to

this signicant increase in product development

time (Woods, 005).

Dan Wheeler (005) provides a good

summary on the difculties of an open source

model. Wheeler points to three critical success

points for any open source endeavor:

.) It has to be reviewed.

.) The people reviewing the code must

know how to write a secure program..) Once found, the problems need to be

xed quickly and distributed. (p.7)

Although Wheeler points to the potential

advantage of open source and its ability to be

xed immediately, this doesnt translate well

to a voting industry environment in which the

immediacy of xing software is dependent upon

certication programs either at the federal or

state levels.

Deploying product improvements on areasonable schedule is a critical area of support

for current voting system providers and would

remain an area of concern for an open source

environment. It is likely that an open source

project would be concerned with marketing

a core software solution, but would lack the

structure to support products as they are elded

by local election ofcials. In addition to

software support, the issue of accountability in

such an open source environment remains an

area for further research.For the sake of argument, let us assume

that an open source voting system is developed,

marketed and deployed in the United States.

Lets also assume that a state legislature requires

a new feature to its ballot tabulation function

such as instant runoff voting. Unfortunately, the

open source voting system described does not

have this capability; therefore, a product upgrade

must be pushed through state and federal

certication. From an open source product

standpoint, who would be the responsible party

for generating this enhancement and nancing

the certication effort? The outstanding answer

to this question illustrates the underlying

challenges of operating an open source product

in a regulated environment and the lack of a

clear line of accountability for maintaining an

open source product.


12/16

iv. SummaryCommercial and Open Source software

solutions must be recognized as separate and

distinct product offerings. Each is characterized

by its own unique management structures and

trade-offs when it comes to accountability.

The term open source must be properly

distinguished from disclosed software Too

often the term open has been used incorrectlyto convey a policy slogan rather than a true

product substitute.

Open source software has successfully

navigated its inherent structural challenges to

offer products that are widely seen as clear

substitutes for other commercial products.

Most notably, these substitutes have occurred

with software that has been able to establish a

robust community of contributors, but operate

in an unregulated environment in which thecontinuous product improvement associated

with open source can be freely implemented.

These open source products are typically found

in areas with widespread impact and a large

number of users. Platforms associated with

le sharing, web servers, communications,

and operating systems are examples of these

successful projects. In contrast, current open

source voting system projects suffer from the

lack of a robust contributor base and must

operate in a regulated environment.In recognition of the historical pursuit

of open source software as a product substitute

for commercial offerings, state and federal

policymakers need to avoid creating unfair

trade practices by favoring one type of product

offering over another. While the challenges

confronting an open source environment in a

regulated industry are signicant, they are not

impossible to overcome. Various licensing

options are available to open source products

which may lend themselves toward the

development of viable voting system solutions,

but this should be done through the normal

conuence of events associated with market

conditions, not through legislative at.

While open source should be

recognized for its potential, the consistent

mischaracterization of disclosed software

as open source must be put to rest. Widely

distributing proprietary software into the public

domain may address perceptions regarding

transparency, but the average member of the

public lacks the technical knowledge necessary to

review the software in question. If policymakers

attempt to strip the intellectual property from

voting system software, it raises two important

areas of concern. The rst is the issue of property

takings without due process and compensation

which is prohibited under the United StatesConstitution. The second area of concern is

one of security. The potential for future gains

with software security will be lost in the short-

term until such time that an adequate product

improvement model is incorporated. Without a

process improvement model in place, any security

features present in current software would be

lost. At the same time, the market incentives

for operating and supporting voting products

would be eliminated. For these reasons, opensource should be recognized for its potential as

a substitute and not as a requirement for current

voting systems.

We visited Dr. Halls comments on the

principle of transparency in the American voting

experience with accountability, public oversight,

comprehension and access to the entire process

as expressions of this transparency. Open Source

products, just like their proprietary brethren, have

failings in these areas. The level of accountability

present within an open source product offeringis weakened due to its diffuse contributor base

and lack of clear liability. Public oversight is

arguably just as diminished in an open source

environment since the layperson is unable to read

and understand software source code adequately

enough to ensure total access and comprehension.

If a third party is charged with this oversight

function to remedy this situation, this is would

be no different than any other regulatory process

that institutionalizes an oversight function.

However, effective oversight does not need to

be predicated on the removal of intellectual

property protections. Providing global access to

current proprietary software would undermine the

principles of intellectual property and severely

damage the viability of the current marketplace.


13/16

Works Cited

Beirne, D. (007) Broken: the regulatory

process for the voting industry. The

Election Technology Council. Retrieved

March , 009 from http://www.electiontech.

org/ETC-BROKEN.pdf.

Deare, S. (004, November 8). Evoting pioneer plays

politics with open source.LinuxWorldretrieved on January 6, 009 from http://

www.linxworld.com.au/index

Hahn, R. W. ed. (00). Government Policy toward

Open Source Software. Washington, D.C.:

AEI-Brookings Joint Center for Regulatory

Studies.

Hall, J. L. (006) Transparency and access to

source code in electronic voting. Retrieved

March , 009 from http://josephhall.org/

papers/jhall_evt06.pdf.Hall, J. L. (007) Contractual barriers to

transparency in electronic voting. Retrieved

March 8, 009 from http://josephhall.org/

papers/jhall_evt07.pdf.

Hippel, E. von and Krogh, G. von (00).

Open Source Software and the

Private-Collective Innovation Model

Issues for Organization Science.

Organization Science, Vol. 4, No. March/

April 00. Retrieved on March , 009 from

opensource.mit.edu/papers/hippelkrogh.pdf.Lerner, J., Pathak, P.A. and Tirole, J. (006). The

Dynamics of Open Source Contributors. The

Roots of Innovation, Vol. 96, No. . Retrieved

on March , 009 from http://econ-www.mit.

edu/les/3023.

Open Source Initiative(OSI) (007). The open

source denition. Retrieved March 4, 2008

from http://www.opensource.org/docs/osd.

Mulligan, D. K. and Hall, J.L. (006)

Prepared statement before the senate

elections, reapportionment &

constitutional amendments committee

open source software-does it have a

place in californias electoral system?.

Retrieved March , 009 from josephhall.org

nqb2/media/Mulligan_Hall_OSHRG_

Statement.pdf.

Perens, B. (006). The Emerging Economic

Paradigm of Open Source. Retrieved on

March 4, 008 from http://perens.com/Articles/

Economic.html.

Siedlok, F. (00). Characteristics

and applicability of open source-based

product development model in other

than software industries. (Masters Thesis,

University of Durham Business School, 00).Retrieved February 5, 009 from http:

opensource.mit.edu/papers/siedlok.pdf.

Wheeler, D. (008) Secure Programming for

Linux and Unix HOWTo, Is Open Source

Good for Security? Retrieved on March 4,

008 from http://www.dwheeler.com.

Woods, D. and Guliani, G. (005) Open Source for the

Enterprise. Sebastopol, CA: OReilly Media,

Inc.


14/16


15/16

This Page Intentionally Left Blank


16/16

open source final online

Documents