ArticlePDF Available


In this essay we argue that the current social and ethical structure in the Open Source Software (OSS) Community stem from its roots in academia. The individual developers experience a level of autonomy similar to that of a faculty member. Furthermore, we assert that the Open Source Software Community’s social structure demands benevolent leadership. We argue that it is difficult to pass off low quality open source software as high quality software and that the Open Source development model offers strong accountability. Finally, we argue that Open Source Software introduces ethical challenges for universities and the software development community.
Ethical Issues in Open Source Software
Open Source Software (OSS) and the emer-
gence of an entire Open Source Movement
have practical, political, economic and eth-
ical ramifications for software development
and software use. In this article we examine
ethical issues that have been raised by open
source software and its challenge to com-
mercial software models. First we will trace
the history and impetus of the open source
movement, examining its forerunners,
including UNIX, Stallman’s Free Software
Foundation, and Linux. Next we will define
Open Source and examine its development
model. Lastly, we present the ethical issues
raised by OSS and attempt to demonstrate
how human values are interwoven with the
economic and technical choices that OSS
The field of software development, like
many technological fields, has its roots
intertwined with academia. Academia has a
long-standing tradition of sharing ideas and
results, as long as appropriate credit is
given to the originators. This tradition is
most easily observed in the rich collection
of scholarly journals used by the research
community. These journals provide a forum
Info, Comm & Ethics in Society (2003) 1: 193–205
©2003 Troubador Publishing Ltd.
Open Source
F S Grodzinsky
Sacred Heart University, Fairfield, CT, USA
K Miller
University of Illinois Springfield, Springfield, Illinois. USA
M J Wolf
Bemidji State University, Bemidji, MN, USA
In this essay we argue that the current social and ethical structure in the Open Source Software (OSS)
Community stem from its roots in academia. The individual developers experience a level of autonomy
similar to that of a faculty member. Furthermore, we assert that the Open Source Software Community’s
social structure demands benevolent leadership. We argue that it is difficult to pass off low quality open
source software as high quality software and that the Open Source development model offers strong
accountability. Finally, we argue that Open Source Software introduces ethical challenges for universi-
ties and the software development community.
for the dissemination of ideas and results.
In addition, they provide a vehicle for
researchers to advance new ideas and
enhance the quality of existing theories.
These traditions are deeply engrained in
the Computer Science and Software
Engineering academic communities.
The field of software development also
shares a close connection with industry.
The first ties occurred with hardware
developers. IBM, for example, in conjunc-
tion with researchers at Harvard University,
built its first computer in 1944. Over the
next 15 years, IBM would bundle hardware,
software and services in a single package,
rarely distinguishing among the various
components. Then in 1969 IBM adopted a
new marketing policy in which software
and services were marketed separately from
hardware. Therefore, in order to have any
opportunity for profitability for the pro-
gramming division, the source code would
need to be kept confidential. This separa-
tion became complete in 1981 when IBM
partnered with Intel and Microsoft to
develop the personal computer (The
History of IBM). Hewlett Packard (HP)
was another company that first marketed
hardware and then later software. In 1966,
HP’s first computer was developed to con-
trol a variety of laboratory instruments. In
1969, HP marketed its first time-sharing
operating system (About HP, 2003).
Perhaps the most interesting connection
between software development, industry
and academia surrounds the history of Unix.
Unix was first developed in the early 1970’s
at AT&T Bell Labs in New Jersey, USA,
largely due to the efforts of K. Thompson,
D. Ritchie, M. D. McIlroy, J. F.Ossanna
(Ritchie, 1996). One of their design goals
was to develop a portable operating system.
Thompson demonstrated the portability of
Unix by mailing magnetic tapes containing
Unix source code and utilities to friends
(Moffitt,2002). At the same time, AT&T
gave away source code and licenses to uni-
versities for Unix Level 6. AT&T even pub-
lished two books that contained the source
code along with commentary.
The Computer Science Department at
the University of California, Berkeley, was
one such licensee that used the source code
extensively for research projects. Eventually,
they enhanced the Unix source code to
include many new features and were freely
distributing their enhanced versions. People
throughout the world added many addition-
al features, some of which are used to run
the Internet today. Throughout the 1980’s
there was confusion as to just what ‘Unix’
meant. There were lawsuits and counter
lawsuits over which parts of Unix software
source code could be freely given away and
which parts required a royalty even to use in
binary form. As we will see later, these
issues largely went away in the early 1990's
when Linus Torvalds introduced Linux.
While these developments were taking
place in industry, the hacker culture was
developing at many of the major research
laboratories across the United States. The
hacker culture involved people who loved
to program and enjoyed being clever about
it. By the early 1970’s this culture was
engrained at the Massachusetts Institute of
Technology and had a significant impact on
Richard Stallman’s attitudes about software
development. He says, “Whenever people
from another university or a company
wanted to port and use a program, we glad-
ly let them. If you saw someone using an
unfamiliar and interesting program, you
could always ask to see the source code, so
that you could read it, change it, or canni-
balize parts of it to make a new program
(Stallman, 1999). The idea that source code
could be freely exchanged, changed and
used appealed to him as an efficacious soft-
ware development technique. However,
that system of development began to break
down in the late 1970's and early 1980's as
the changes noted above were taking place
in industry. A further impact was the fact
that industry was hiring many of the best
software developers and programmers from
the computing labs, and those individuals
were taking the software they developed
with them. To Stallman, succumbing to this
industrial model of software development
was tantamount “to making the world a
worse place” (Stallman, 1999). In response
to commercialization within the software
development industry, Stallman began the
Grodzinsky et al: Ethical Open Source Software
PPeerrhhaappss tthhee mmoosstt iinntteerreessttiinngg
ccoonnnneeccttiioonn bbeettwweeeenn ssooffttwwaarree
ddeevveellooppmmeenntt,, iinndduussttrryy aanndd
aaccaaddeemmiiaa ssuurrrroouunnddss tthhee
hhiissttoorryy ooff UUnniixx..
Grodzinsky et al: Ethical Open Source Software
GNU project in 1984 with a goal of “creat-
ing a new software sharing community”
(Stallman, 1999). The GNU project goal
was to develop an entire Unix-like operat-
ing system, complete with all the utilities,
in order to build a community of develop-
ers dedicated to writing free software. All
of the source code would be freely available
for modification and use by anyone who
was willing to make further changes.
The Free Software Foundation (FSF) was
started in 1985 largely to support this objec-
tive (The GNU Project, 2002). By the early
1990's, the GNU project had succeeded in
many ways. Useful software development
and environment tools, plus the General
Public License (GPL), had been developed
under the auspices of the Free Software
Foundation. However, GNU still lacked the
core of an operating system – the kernel.
However, when Linus Torvalds developed
and released the Linux kernel under the
GNU GPL the picture was completed.
With the Linux kernel and the tools devel-
oped by GNU, the world now had a com-
plete, functional operating system with all
of the source code freely available for
inspection, modification and improvement.
As the Linux kernel developed and
matured, people began to take note of the
software development methodology used
to create it. In 1998, those who advocated
the software development process that is
afforded by shared source code started a
movement called the Open Source
Initiative (OSI). The Open Source
Initiative shares many of the same goals as
the Free Software Foundation (Open
source initiative, 2002). However its focus
is grounded in the development methodol-
ogy that arises when source code is open
and free to all who want it. On the other
hand, the FSF is a proponent of a philoso-
phy that puts the notion of free software
first. According to the FSF there are four
freedoms that are essential for free soft-
1. Freedom to run the program, for any
2. Freedom to study how the program
works, and adapt it to your needs.
3. Freedom to redistribute copies so you
can help your neighbor.
4. Freedom to improve the program, and
release your improvements to the public,
so that the whole community benefits.
Requiring that all derivative works of
GPL software also be licensed under the
GPL, if and when they become published,
propagates these freedoms. This protec-
tion is known as copyleft and prevents
source code from being swallowed up in a
commercial venture (See Appendix B).
The OSI is less focused on philosophical
tenets emphasized by Stallman and more
focused on promoting open source as a
development methodology. This promo-
tion is evident in the emergence of other
important software cultures including the
Perl culture under Larry Wall, John
Osterhout's Tcl and Guido van Rossum's
Python languages. “All three of these com-
munities expressed their ideological inde-
pendence by devising their own, non-GPL
licensing schemes” (Raymond, 2000).
What motivates a developer to write OSS?
In the previous section we have alluded to
the philosophy of Richard Stallman and
members of the Open Source Initiative.
Linus Torvalds believes that good software
development starts by the scratching of a
personal itch: the curiosity and desire to see
if something can be done. In The Cathedral
and the Bazaar, Eric Raymond depicts the
OSS developer as one who has found the
golden mean between underutilization and
over-utilization caused by ill-formulated
project goals. Raymond’s “happy program-
mer,” conforms to the Aristotelian model of
one, who while enjoying the freedom to
experiment and excel, brings forth imagina-
tive and creative software (Raymond, 2001).
Which, if any of these depictions still holds
true? We will begin by examining the Open
Source Software Development Community
including the Open Source Definition as a
social contract. Then we will explore some
of the ethical issues that might explain the
motivations of the OSS movement: autono-
my, quality, and accountability. Finally we
will close this section with analysis of
whether Open Source can be considered a
public good.
3.1TheOpen Source Software
Development Community
The Open Source Software development
community emerged out of a parting of the
ways with Richard Stallman and the Free
Software Foundation. While the details of
the contentious debate are beyond the
scope of this paper, we will try to articulate
some of the major points. Stallman’s vision
was one of a community of programmers
who were doing something for the good of
humankind. Although he acknowledges
that open source and free software belong
to the same category of software, Stallman
maintains that there was an ideological
shift within those advocating for open
source. Stallman asserts that while the
GNU Project holds onto the concept of
freedom, the OSS community tries to
appeal to businesses. Because business val-
ues profit above all, he argues that values of
community and freedom are lost in the
OSS development model. Citing examples
of proprietary software that work with
Linux, Stallman wonders if OSS developers
will shun or support them (Stallman, 1999).
Open Source advocates argue that OSS is
primarily a development methodology
grounded in the philosophy of making
source code open and free to all who want
it. Developers self-select according to their
interest in a project. Users and developers
co-exist in a community where software
grows and expands based on personal
needs. These enhancements make the proj-
ect more globally desirable as it fits more
and more requirements. Linus Torvalds,
the epitome of the open source developer
•Release early and often
Delegate everything you can
Be open (Raymond, 2001, p.309).
It usually takes one interested developer to
write a piece of core code to get a project
going. Torvalds believes that it is the
responsibility of the originator of the proj-
ect to listen to the users who will find the
bugs and those who will fix them. In this
type of scenario, “users are rewarded by the
daily improvement in the work” (Raymond,
2001, p. 315).
Creators of OSS typically use the soft-
ware themselves as it is being developed;
therefore, the users are involved in the soft-
ware development from the beginning.
When software is created solely for com-
mercial gain, there is always a danger that
the customer is treated merely as a means
to a financial end: financial enrichment of
the software developer. Open source soft-
ware removes that temptation.
Empirical evidence suggests that devel-
opers are less concerned with the ideologi-
cal split between the FSF and the OSS,
than with the idea of making free software
available to all. Eric Raymond explains, “A
side effect of the rapid growth of Linux was
the induction of a large number of new
hackers for which Linux was their primary
loyalty and the FSF's agenda primarily of
historical interest” (Raymond, 2000). He
maintains that it was the Netscape
announcement in February 1998 that it
would distribute Navigator 5.0 in source
that changed the environment dramatically.
The idea that ‘free software’ could be
exploited within the commercial communi-
ty excited the hacker culture and caused
the parting of the ways between free soft-
ware and open source advocates.
As with all software, quality is a major
issue when evaluating Open Source
Software. It has been argued that with open
source software “you get what you pay for.”
If a developer is not paid for creating and
maintaining a piece of software, then he/she
may not feel the same obligation to do a
quality job. Linus Torvalds argues that pro-
grammers tend to find projects that interest
them, and if the programmer loses interest
in a piece of code, there is usually a co-
developer out there willing and able to con-
tinue on the project. The reason that Linux
is so successful is that it interests people to
develop a complete, open operating system.
While it is true that there might be less suc-
cess in developing a less glamorous project,
developers would usually not undertake it,
rather than do a shoddy job. Their reputa-
tions among their peers are at stake. In the
hacker community, “one’s work is one’s
statement...and there’s a strong ethos that
quality should (indeed must) be left to speak
for itself...Boasting or self-importance is
suppressed because it behaves like noise
tending to corrupt the vital signals from
experiments in creative and cooperative
behavior”. (Raymond, 2000).
Grodzinsky et al: Ethical Open Source Software
IItt hhaass bbeeeenn aarrgguueedd tthhaatt wwiitthh
ooppeenn ssoouurrccee ssooffttwwaarree yyoouu ggeett
wwhhaatt yyoouu ppaayy ffoorr..
Grodzinsky et al: Ethical Open Source Software
Thus within the community of those
working on the project, individual interest
and work contribute to a larger goal: a
working project for all. In addition,
because it is open source, others may take
advantage of the software once it is avail-
able on line. Floridi and Saunders in their
paper entitled Internet Ethics: the
Constructionist Values of Homo Poieticus main-
tain that a collaborative project relies on an
“unsuspected but evident interest, shared
by a growing community” and the coordi-
nation of efforts to produce a global prod-
uct based on “local specific components.”
They name this phenomena ‘distributed
constructionism.’ They maintain that
the Internet facilitates communication
amongst users irrespective of distance and
creates an environment that encourages
and facilitates production of OSS like
Linux (Floridi et al., 2003).
3.2The Open Source Definition:
A social contract
The formalization of the OSS community
came about with the development of the
Open Source Definition and the OSI. In
1997, Bruce Perens published a set of guide-
lines to articulate the developers’ commit-
ment to open source software and its users
(Perens, 2002). The Debian Free Software
Guidelines were incorporated into and
became the basis of the Open Source
Definition (See Appendix A). The OSI pub-
lished licenses that met the Open Source
Definition and declared that software dis-
tributed under any of these licenses would
be 'OSI Certified.' The OSI offers copies of
these licenses for anyone to use and modify
for their own business model. The Mozilla
Public License has been the one most often
used since 1998. Most of these licenses give
permission for the software to be used.
Some ask that a copyright and year be
included when redistributing the software.
Most of them present the software ‘as is’
and indemnify themselves against liability.
The social contract articulated in the
guidelines is fairly clear about what the
OSS is offering to others. But what do OSS
developers expect in return? What moti-
vates developers to contribute to an open
source project? Is it altruism, i.e., do they
consider it a ‘pro bono’ project that con-
tributes to the public good? Is it a reaction
against corporate greed? Does it make
them feel part of a select community with
special talents? Clearly all of these play a
part in OSS developer motivation to abide
by this contract. Beyond that, however,
there is also a sense that developers see
their involvement as “enlightened self
interest” (Kollock, 1999). Their contribu-
tions lead to software that they want and
often need. OSS is an alternative for users;
developers are themselves users of comput-
ing, almost always heavy users. Developers
and users participate voluntarily in a devel-
opment environment that emphasizes
cooperation and mutual support under the
OSI guidelines. They have found the envi-
ronment satisfying enough to make OSS a
major challenger to commercial software.
One perceived attraction for OSS develop-
ers is the autonomy of the developer.
While developers who embrace OSS
do gain a measure of autonomy not avail-
able to developers working on commercial
software, the claim for complete autonomy
doesn’t appear to be valid. OSS developers
work as volunteers, and can join or quit an
effort strictly on their own initiative. These
volunteers are not coerced into participa-
tion and willingly contribute. Therefore,
one might assume that the OSS developer
can be depicted as a libertarian
ideal, unshackled by corporate controls.
However, there are several types of control
in OSS, even though no single developer is
in charge of an OSS project. As an OSS
developer, the developer cannot be sure
that his/her contribution will be accepted
into the canonical version that is continu-
ously evolving. This contribution may be
embraced or rejected in the short term, and
if accepted may be changed or replaced
later. The developer is free to contribute or
not, but any single developer cannot claim
ultimate control over the use of his/her
contribution. In Homesteading the Noosphere,
Eric Raymond states, “the open-source cul-
ture has an elaborate but largely unadmit-
ted set of ownership customs. These cus-
toms regulate who can modify software, the
circumstances under which it can be modi-
fied, and (especially) who has the right to
redistribute modified versions back to the
community”(Raymond, 2000).
Open source software has the seemingly
useful feature that at any point, any one
with appropriate technical skills can modi-
fy the code and take the project in a direc-
tion that diverges from the direction others
are taking it (called 'code forking'). Thus,
one of the perceived benefits of a piece of
open source software is that it has the
opportunity to evolve rapidly into compet-
ing programs where, presumably, Darwin’s
theories of evolution can take over: the
best piece of software for the current envi-
ronment will survive. If code forking is
prevalent, we might expect to see many
innovations occur in open source software
development. However, Raymond gives
two very pragmatic reasons for the low
incidence of code forking in many success-
ful OSS projects. The first major reason for
projects to persist is a fear of diluting the
developer community for the project --
both child projects have fewer developers,
thus weakening the entire project, especial-
ly relative to the parent project. Secondly,
shortly after a code fork the child projects
cannot exchange code. In addition,
Raymond adds that “there is strong social
pressure against forking projects” in the
open source community. According to
Raymond the open source community is
best viewed as a gift culture where one's
social status is determined by what one
gives away. In addition to the practical con-
cerns, forking a project cuts right to the
core of the culture-it damages someone's
Thus, given both the pragmatic and cul-
tural pressure to avoid code forking, the
developers of an open source project must
take special care to avoid the symptoms of
groupthink. A newcomer to open source
development has very little in terms of rep-
utation to bring to the table when he/she
proposes a new piece of code or a new tack
on development for a project. Project lead-
ers, who are less open to new ideas and
ways of doing things, may miss the innova-
tion of the newcomer's idea. Not only will
the project lose the good idea, but it also
faces the potential of losing a good devel-
oper. Thus, open source project leaders and
developers must show a great willingness to
take in new ideas, evaluate them thought-
fully, and respond constructively in order to
nurture both the idea and the developer of
the idea.
Project leaders must exercise similar
abilities when a subgroup comes with an
idea that is controversial. Care must be
taken that the larger group does not ride
roughshod over the smaller group's idea.
Again, in addition to losing out on a good
idea and potentially driving people away
from the project, doing so will discourage
future innovators from taking their ideas
forward. Note that the proprietary soft-
ware development model is not subject to
this argument. The innovative developer
who meets resistant project leaders or man-
agement is typically free to leave the organ-
ization, and he/she regularly does. In fact
there are social norms that actually encour-
age this type of behavior; we call these peo-
ple entrepreneurs.
So it appears that the autonomy experi-
enced by an open source developer is much
like the autonomy experienced by a univer-
sity faculty member: freedom to choose
which projects to work on. Thus, an open
source developer has increased autonomy
when compared to a corporate developer.
Whereas, the corporate developer might
find a supportive social structure to take a
project in a new direction, the social struc-
ture in the Open Source community can
work to suppress this type of entrepreneur-
ial endeavor.
3.4 Software quality
Quality software, in the traditional sense, is
software that meets requirement specifica-
tions, is well tested, well documented and
maintainable (Schach, 2002). Advocates of
OSS claim that its developers/users are
motivated to do quality work because not
only are they developing software for their
own use, but their reputations among their
peers also are at stake. Critics of OSS claim
that volunteers will not do professional
quality work if there is no monetary com-
pensation. They also claim that documen-
Grodzinsky et al: Ethical Open Source Software
OOppeenn ssoouurrccee pprroojjeecctt lleeaaddeerrss
aanndd ddeevveellooppeerrss mmuusstt sshhooww aa
ggrreeaatt wwiilllliinnggnneessss ttoo ttaakkee iinn
nneeww iiddeeaass
Grodzinsky et al: Ethical Open Source Software
tation and maintenance are non-existent.
While it is true that documentation and
maintenance are concerns, OSS advocates
assert that OSS meets users’ requirements,
is tested by its developers and is constantly
being upgraded. Documentation evolves as
more and more users become interested in
the software and use it. For example, books
on Linux can be found everywhere.
The question of whether OSS is of high-
er or lower quality than comparable com-
mercial software is essentially an empirical
rather than philosophical question. The
answer to this question is not readily avail-
able, but we can cite some preliminary
anecdotal evidence on this issue. The
Apache web server is OSS that competes
with commercial web servers. The web
server market is a potentially lucrative one,
and we expect commercial software devel-
opers to compete for that market with high
quality software. Yet despite commercial
alternatives, according to third party
observers (Netcraft, 2002) the OSS Apache
server is by far the most used web server.
According to an August, 2002 survey,
63% of web servers on the Internet are
Apache. At least in this market segment, it
appears that OSS is sufficiently high quali-
ty for most users. Of course, Apache is free
and other servers aren't; the cost motiva-
tion might explain some of Apache's popu-
larity. But if the Apache server were of sig-
nificantly lower quality than commercial
alternatives, then it would be surprising to
see its widespread use. This raises the ques-
tion of whether market-dominance and
popularity should be a benchmark for soft-
ware quality. Does the fact that Microsoft
Windows runs on some 90% of home com-
puters assure us of its quality? We would
argue that popularity and quality might be
linked if it can be shown that there is a level
of expertise about software quality in the
people making the choices. System admin-
istrators have more expertise than an aver-
age user of a home computer system.
Therefore, when a majority of these profes-
sionals choose an OSS alternative, it
deserves notice.
The Apache example illustrates an
important distinction among OSS users.
Initially, first adopters of OSS are its devel-
opers and as the code becomes more
known, OSS gains users who were not
involved in the development. These users
adopt the OSS for many reasons, but some
of these new users (particularly non-pro-
grammers), appreciate the product, though
they may not understand or care about the
process that developed it. All users of OSS
gain if the software delivers needed func-
If an OSS project pleases its developers,
but does not gather a following outside the
developing community, that may be fine
with the developers; if a commercial proj-
ect only pleases its developers, it is a finan-
cial failure. The OSS model has different
kinds of successes, and fewer outright fail-
ures. The rewards for developers in an OSS
project are likely to be less tangible than
rewards for a successful commercial prod-
uct, but that does not make the rewards
less real. The public has potential gains in
the OSS movement that do not require
large investments by the public.
Another distinction between OSS proj-
ects and commercial projects is the lack of
a release date. While open source develop-
ers anticipate frequent releases, there are
no release deadlines. The announcements
of a release day by a commercial vendor
impose pressure on developers to cut cor-
ners, thus increasing the possibility of
errors in the software. Furthermore, such a
deadline has a tendency to impose on the
autonomy of the developer.
Finally we note that both open source
and proprietary developers share the same
professional ethical responsibility to devel-
op solid, well-tested code. The social pres-
sure in the open source community to
avoid code forking provides incentives for
project leaders to ensure that the code is
the best it can be. On the other hand, when
an open source developer believes there is
too much risk associated with a particular
piece of code, he/she can rewrite it and
release it. While there is a reputation risk
in doing so, there is the opportunity to
publicly demonstrate that the forked prod-
uct is superior. In a proprietary model,
however, a developer’s main avenue of
TThhee OOSSSS mmooddeell hhaass ddiiffffeerreenntt
kkiinnddss ooff ssuucccceesssseess,, aanndd ffeewweerr
oouuttrriigghhtt ffaaiilluurreess..
recourse is to ‘blow the whistle’ on his/her
manager or employer. To do so entails
grave personal risk to one's livelihood, pro-
fessional standing, lifestyle and family.
Worse yet, the developer will likely not
have the opportunity to demonstrate the
wisdom of his/her ways.
3.5 Open Source
and Accountability
In her article entitled Computing and
Accountability, Helen Nissenbaum cites four
barriers to accountability:
1. The problem of many hands,
2. bugs,
3. computer as scapegoat and
4. ownership without liability.
She asserts that these barriers can lead to
“harm and risks for which no one is answer-
able and about which nothing is done”
(Nissenbaum, 1994). We will examine how
OSS may have addressed barriers 1 and 2.
Number 3 is a general issue and number 4
does not apply because there is not soft-
ware ownership per se in open source. The
Open Source Definition #1 addresses her
fourth point (See Appendix A).
“Where a mishap is the work of ‘many
hands’, it can be difficult to identify who is
accountable because the locus of decision
making is frequently different from the
mishap’s most direct causal antecedent;
that is, cause and intent do not converge”
(Johnson, 1995). In open source, however, if
a developer were to write irresponsible
code, others contributing to the open
source software would be unlikely to accept
it. So, in this case, there is built-in individ-
ual accountability. If a developer were part
of a large company, where all programming
parts contribute to a large commercial ven-
ture, it then would fall on both the compa-
ny and the individual to accept responsibil-
ity for the problematic software product.
Often this is not done. So the many hands
problem referred to by Nissenbaum in
Computing and Accountability can be
reduced in OSS because parts of code can
be ascribed to various developers, and their
peers hold them accountable for their con-
Nissenbaum argues that accepting bugs
as a software fact of life has issues regarding
accountability (Nissenbaum, 1994). The
open source approach to software develop-
ment treats the bug problem with a group
effort to detect and fix problems. Torvalds
states, “given enough eyeballs, all bugs are
shallow” (Raymond, 2001, p. 315). The per-
son that finds a bug in OSS may not be the
person to fix it. Since many adept develop-
ers examine OSS code, bugs are found and
corrected more quickly than in a develop-
ment effort where only a few developers
see the code. In this group effort, account-
ability is not lost in the group, but is
instead taken up by the entire group. The
question of whether this group accounta-
bility is as effective as individual responsi-
bility is, again, empirical. The examples of
Apache and Linux (Webcab solutions,
2003) offer at least anecdotal evidence that
some OSS demonstrates high reliability.
Don Gotterbarn is also concerned about
issues of professional accountability in OSS
(Wolf et al, 2002). In addition to worries
about sufficient care in programming and
maintaining OSS, Gotterbarn points out
that an OSS licensing agreement forces the
authors of the software to relinquish con-
trol of the software. If someone puts OSS
to a morally objectionable use, then the
developers have no right to withdraw the
software from that use.
Gotterbarn’s objection has some theo-
retical interest, for the OSS licensing agree-
ments clearly state that no one who follows
the OSS rules can be blocked from using
the software. But if we accept the idea that
software developers have a moral duty to
police the use of the software they distrib-
ute, especially when the software is utility
software, we fall into a practical and theo-
retical thicket. How is a vendor to know
the eventual use of software, especially
when the software is utility software (such
as an operating system or a graphics pack-
age)? Are software developers empowered
to judge the ethics of each customer or per-
spective customer? These responsibilities
are overreaching ethically, and far too
Grodzinsky et al: Ethical Open Source Software
AAccccoouunnttaabbiilliittyy iiss nnoott lloosstt iinn tthhee
ggrroouupp,, bbuutt iiss iinnsstteeaadd ttaakkeenn uupp
bbyy tthhee eennttiirree ggrroouupp
Grodzinsky et al: Ethical Open Source Software
ambitious in a practical sense.
Furthermore, the relinquishment of con-
trol argument has practical significance
only if existing competing software models
include effective control over the use of
software. (That is, should OSS be held to a
higher standard than commercial software
in relation to ethical responsibility for
downstream use?) We are unaware of any
action by existing commercial software
vendors to police the uses to which their
software is put. Commercial software ven-
dors are certainly concerned that people
who use their software have paid for it.
Once paid for, vendors concerned about
ethical use do not police commercial soft-
3.6 Is Open Source a Public
The claim that OSS is a revolutionary idea,
a departure from previous models of intel-
lectual property, is worth examining.
Although clearly distinct from a commer-
cial model of software development, OSS
can be seen as a continuation of previously
accepted traditions in academics in general,
and in mathematics in particular.
Academia has long had the tradition of
sharing ideas without direct payments.
Scholarly journals do not pay authors (and
in fact may charge them for pages printed).
Law has not protected mathematical for-
mulae and formal descriptions of natural
laws. Copyright covers the expression of
ideas, but not the ideas themselves; patent
has (at least traditionally) protected the
practical application of ideas, but not the
physical laws underlying the ideas. So, if
software is viewed as an extended mathe-
matical object, akin to a theorem, then
OSS could be a natural extension of the
long tradition of free ideas in mathematics.
Does that make it a public good?
Peter Kollack, a sociologist at the
University of California at Los Angeles,
examines the idea of public goods on line in
his paper entitled The Economies of Online
Cooperation: Gifts and Public Goods in
Cyberspace. He defines public goods as
those things that are non-excludable and
indivisible. Because the Open Source
Definition prohibits discrimination against
persons or groups or against fields of
endeavor (see Appendix A), it supports the
definition of a public good being non-
excludable. Public goods in cyberspace can
benefit the users of cyberspace irrespective
of whether they have contributed to these
goods or whether these goods have come
from groups or individuals. The fact that
one person using OSS does not affect its
availability to the whole supports Kollack's
idea of indivisibility. He maintains that
“[a]ny piece of information posted to an
online community becomes a public good
because the network makes it available to
the group as a whole and because one per-
son’s ‘consumption’ of the information does
not diminish another person’s use of it”
(Kollock,1999). If a user downloads a copy
of Linux, for example, it does not diminish
its availability for other users. So by this
definition, we concur that OSS is a public
However, is there an active interest
among developers to create a public good?
Are OSS developers actually motivated to
do good by contributing software to the
public, and by maintaining it in a group
effort? Some developers argue that they
can customize OSS, and if others find the
customizations useful, then they have pro-
vided a public good. However, there could
be another possible motivation for OSS. It
might be a philosophical or instinctive ani-
mus towards existing commercial software
developers. Bertrand Meyer recites with
dismay the many negative statements by
OSS advocates about commercial software
development and developers (Meyer,
2000). Some see ‘Microsoft bashing’ as a
central theme of the OSS movement. Since
most OSS competes directly with
Microsoft products, some friction between
OSS advocates and the largest commercial
software corporation seems inevitable. But
if OSS development is motivated primarily
by its opposition to commercial software
producers, then its ethical underpinnings
are less benign than if OSS is motivated
primarily by an altruistic desire to help
HHoowweevveerr,, iiss tthheerree aann aaccttiivvee
iinntteerreesstt aammoonngg ddeevveellooppeerrss ttoo
ccrreeaattee aa ppuubblliicc ggoooodd??
computer users. Since the OSS movement
is, by design, decentralized and evolving, it
seems impossible to gauge with any preci-
sion the motivations of all its members. But
the often-repeated disdain for commercial
business practices seems more in tune with
the hacker culture than with a culture of
altruism. So, we would argue that for the
most part, the altruism involved in the cre-
ation of a public good in the case of OSS is
more of a by-product of developers who are
interested in creating tools that are of use
for themselves. Customization and expan-
sion of Linux, for example, came from
developers who wanted applications for
their own use and then shared their code.
Nowhere can OSS be considered more of
a public good than in the academic com-
munity. Computer Science departments are
expected to be on the cutting edge of tech-
nology in their curricular offerings.
The price of commercial software, even
with educational discounts, often straps a
department's budget. Academic institu-
tions have strong financial motivations to
adopt open source software. GNU compil-
ers, for example, have largely replaced pro-
prietary versions that cost the university
software fees as well as licensing fees.
Linux is appearing as the operating system
of choice often replacing Solaris. As more
and more applications run on Linux, uni-
versities will have less incentive to buy
from vendors who offer a UNIX platform.
They will buy cheaper hardware and run
Linux. One caveat to this scenario is the
availability of staff that can support the
Linux platform and the availability of doc-
umentation for OSS.
Using OSS at a university raises interest-
ing ethical questions. One could argue that
a university should expose its students to
multiple perspectives so students develop
skills to make judgments about the world
around them. A university that exposes its
students to a single point of view fails to
help a student develop these skills. Thus, a
university should provide a learning envi-
ronment where future computer science
professionals are exposed to both propri-
etary and open source software, and be
given experiences to develop software eval-
uative skills. Part of this evaluation would
come from using the software and evaluat-
ing the effectiveness from a user's perspec-
tive. However, an important part of the
evaluative process, at least for computer
science students, involves accessing the
source code. Open source software makes
looking at the source code easy. While it is
true that some proprietary software ven-
dors are willing to share their source code
with universities for educational purposes,
others are not. It is precisely when the soft-
ware vendor is unwilling to share source
code with university faculty, or makes it
onerous on the university, that the universi-
ty is faced with an ethical dilemma: How
does it respond to proprietary software ven-
dors that interfere with its duty to educate
its students? OSS provides a partial solution
to that problem. These questions are fur-
ther complicated by the relationship that
software companies often share with many
universities. It is not uncommon for a soft-
ware company to make generous contribu-
tions to a computer science department for
access to the department's graduates, or to
sponsor a faculty member's research.
Faculty at these institutions must take care
not to let the largess interfere with their
ethical responsibilities to their students.
If a university is part of the open source
community, we might expect them to be a
contributor as well as a user of OSS. For
many places of higher education, especially
research institutions, this is not an issue as
university faculty and students develop
much open source software. But those
institutions, whose faculty and students are
not making such contributions, are faced
with making the choice of contributing in
some other way.
One approach might be a cash donation
to an appropriate foundation that supports
open source development for the value the
software brings to the educational environ-
ment. This is not always easy to do.
Anecdotally, a federal employee who want-
ed to do this reported two problems:
1. Accountants in her agency balked at
making a contribution; they thought it
might be illegal.
2. She tried but could not get additional
clarifying information from the OSS
foundation. Contact people listed at the
foundation did not return her emails
and phone calls. She ended up not mak-
ing a donation and feeling bad about it.
It may be argued that merely exposing stu-
dents to open source software may fulfill the
university’s ethical obligation to support OSS
Grodzinsky et al: Ethical Open Source Software
Grodzinsky et al: Ethical Open Source Software
since doing so meets the OSS community's
goal of building the OSS user community.
Finally, we explore an issue that is
becoming part of the mission of many insti-
tutions of higher education: service learn-
ing. The choice between open source soft-
ware and proprietary software plays into
service learning as well. Consider a scenario
where a software engineering class is to
produce a piece of software for a local char-
ity. The choice between open source alter-
natives and proprietary alternatives is not
to be taken lightly. Seemingly, open source
software makes good sense for both the
students and the charitable organization.
The cost is low and, presumably, the quali-
ty is sufficient. Yet there are long-term
costs that are faced by the charity (as well
as any business making such a choice).
How expensive will it be to maintain the
software? Is there enough open source
expertise available to maintain it? And,
finally, what documentation and user train-
ing can be expected if OSS is the software
of choice. An extension of the service
model might offer some on-going support
to these charities.
OSS is no longer an academic curiosity. We
have demonstrated that certain OSS prod-
ucts are making a significant niche for
themselves in computing environments.
Both Apache and Linux are increasing in
popularity. The OSS model is distinct from
commercial software development from
several viewpoints: as a software engineer-
ing process, as an economic plan, and as a
marketing strategy. In both models, howev-
er, developers have certain obligations and
responsibilities to their users. In our analy-
sis we have argued that open source soft-
ware’s successes may be due in part to the
sheer number of people who get involved,
and to the users who are engaged from the
start of development.
We have found that the authors of OSS
have complex motivations, some laudatory,
and others less so. OSS has produced some
successes, and the public has benefited
from these. There are questions about reli-
ability and professionalism, but evidence
against the quality of OSS is not, as yet,
convincing to us. It does not appear likely
that OSS will displace commercial software
in the foreseeable future, and we have not
uncovered any ethical imperative that it
should. Yet, OSS has distinct economic
advantages for many especially in the aca-
demic arena. It can help bridge the digital
divide and can involve growing numbers of
people in computing, both as developers
and users. Developers of OSS strive to be
the best they can to contribute to the sus-
tainable whole and thus secure their repu-
tation ethically among their peers.
OSS and commercial software can coex-
ist, each giving the public the goods it
desires. Both advocates and critics of OSS
have an ethical obligation to respect each
other and to avoid inaccurate and mean-
spirited accusations. All software develop-
ers have ethical obligations for quality and
openness (Software engineering code of
ethics, 1999). OSS is a novel development
of traditional ideas of sharing academic
intellectual property, but OSS exists in a
world dominated by commercial enter-
prise. As such, OSS challenges the status
quo in a way that can be a constructive
check on excesses of traditional free enter-
prise systems. In a time when many for-
profit corporations have disappointed the
public with their lack of ethical behavior,
OSS has the potential to be a positive ethi-
cal force in the world of computing.
Hackers who get involved in OSS develop-
ment can contribute to the sustainable
whole and, thus ethically secure their repu-
tation among their peers. This is a way to
publicly excel at hacking without illegal and
unethical harm to others.
Open Source Definition
Open source doesn't just mean access to
the source code. The distribution terms of
open-source software must comply with
the following criteria:
AAllll ssooffttwwaarree ddeevveellooppeerrss hhaavvee
eetthhiiccaall oobblliiggaattiioonnss ffoorr qquuaalliittyy
aanndd ooppeennnneessss..
A.1Free Redistribution
The license shall not restrict any party
from selling or giving away the software as
a component of an aggregate software dis-
tribution containing programs from several
different sources. The license shall not
require a royalty or other fee for such sale.
A.2 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 code for no more
than a reasonable reproduction cost-prefer-
ably, downloading via the Internet without
charge. The source code must be the pre-
ferred form in which a developer would
modify the program. Deliberately obfuscat-
ed source code is not allowed. Intermediate
forms such as the output of a preprocessor
or translator are not allowed.
A.3 Derived Works
The license must allow modifications and
derived works, and must allow them to be
distributed under the same terms as the
license of the original software.
A.4Integrity of The Author's
Source Code
The license may restrict source-code from
being distributed in modified form only if
the license allows the distribution of
“patch files” with the source code for the
purpose of modifying the program at build
time. The license must explicitly permit
distribution of software built from modi-
fied source code. The license may require
derived works to carry a different name or
version number from the original soft-
A.5No Discrimination
Against Persons or Groups
The license must not discriminate against
any person or group of persons.
A.6No Discrimination
Against Fields of Endeavor
The license must not restrict anyone from
making use of the program in a specific field
of endeavor. For example, it may not restrict
the program from being used in a business,
or from being used for genetic research.
A.7 Distribution of License
The rights attached to the program must
apply to all to whom the program is redis-
tributed without the need for execution of
an additional license by those parties.
A.8 License Must Not Be
Specific to a Product
The rights attached to the program must
not depend on the program's being part of
a particular software distribution. If the
program is extracted from that distribution
and used or distributed within the terms of
the program's license, all parties to whom
the program is redistributed should have
the same rights as those that are granted in
conjunction with the original software dis-
A.9The License Must Not
Restrict Other Software
The license must not place restrictions on
other software that is distributed along
with the licensed software. For example,
the license must not insist that all other
programs distributed on the same medium
must be open-source software.:
“To copyleft a program, we first state that
it is copyrighted; then we add distribution
terms, which are a legal instrument that
gives everyone the rights to use, modify,
and redistribute the program's code or any
program derived from it but only if the dis-
tribution terms are unchanged. Thus, the
code and the freedoms become legally
Grodzinsky et al: Ethical Open Source Software
Grodzinsky et al: Ethical Open Source Software
About HP: History and Facts.
Accessed 2003.
Barr, J. Live and let license: A primer on soft-
ware licensing in the Open Source context,
May 23, 2001.
Computers, Ethics and Social Values. Johnson, D.J.
and Nissenbaum H., eds. Prentice Hall: New
Jersey, 1995.
Floridi, L. and Sanders, J.W. Internet Ethics:
the Constructionist Values of Homo
Poieticus. In The Impact of the Internet on Our
Moral Lives, Cavalier, R., ed. New York:
SUNY, 2003.
Kollock, P. The Economies of Online
Cooperation: Gifts and Public Goods in
Cyberspace. In Communities in Cyberspace,
Smith, M. and Kollock, P., eds. London:
Routledge, 1999.
Meyer, B. The Ethics of Free Software.
Software Developers Online.
m0003d/0003d.htm, login required, March
Miller, R. 90% Windows, 5% Mac, 5% Linux?
Not true! The Register.,
June 13, 2001.
Moffitt, N. Nick Moffitt's $7 History of Unix. Accessed
Netcraft Web Server Survey., 2002.
Nissenbaum, H. Computing and
Accountability. Communications of the ACM,
37, 1, January 1994.
Open Source Initiative (OSI)., 2002.
Perens, B. Debian Social Contract., 2002.
Raymond, E.S. Homesteading the Noosphere. tuxe-, 2000.
Raymond, E.S. “The Cathedral and the Bazaar”,
in Readings in Cyberethics, eds. Spinello and
Ta vani, Jones and Bartlett, 2001.
Ritchie, D.M. The Evolution of the Unix Time-
sharing System. cm.bell-, 1996.
Schach, Stephen, Object Oriented and Classical
Software Engineering (fifth ed). McGraw Hill,
2002. p. 137.
Software Engineering Code of Ethics and
Professional Practice(5.2)., 1999.
Stallman, R.M. The GNU Operating System
and the Free Software Movement. In Open
Sources: Voices from the Open Source
Revolution, Stone, M., Ockman, and
DiBona, C., eds. , 1999.
The GNU Project and the Free Software
Foundation (FSF). and, 2002.
The History of IBM.
tory/index.html Accessed spring 2003.
WebCab Solutions – Linux Reliability. Accessed
Wolf, M.J., K. Bowyer, D. Gotterbarn, and K.
Miller. Open Source Software: Intellectual
Challenges to the Status Quo, panel presen-
tation at 2002 SIGCSE Technical Symposium,
SIGCSE Bulletin, 34(1), March 2002, pp. 317-
Fran Grodzinsky
Sacred Heart University, Fairfield,
Reproducedwith permission of thecopyrightowner. Further reproduction prohibitedwithoutpermission.
... Open Source Software (OSS) is a set of computer programs with two fundamental characteristics [1,2]: (1) it has been promoted in a collaborative way; and (2) the source code is open and, consequently, it can be modified. As a result, four abilities are identified as being associated with the OSS movement [3]: (1) to implement this software for any intention, (2) to analyze the software functionalities and adapt them, (3) to make copies and (4) to make improvements to the software and distribute it. ...
... Open Source Software (OSS) is a set of computer programs with two fundamental characteristics [1,2]: (1) it has been promoted in a collaborative way; and (2) the source code is open and, consequently, it can be modified. As a result, four abilities are identified as being associated with the OSS movement [3]: (1) to implement this software for any intention, (2) to analyze the software functionalities and adapt them, (3) to make copies and (4) to make improvements to the software and distribute it. ...
Full-text available
In the last few decades, the Open Source Software (OSS) diffusion has grown remarkably in companies. In this context, the present study has analyzed the factors that incentivize OSS implementations for enterprise purposes, linking two perspectives: (1) managerial and (2) educational. Thus, the Delphi methodology was applied to a panel of experts with two aims: (1) to know managers’ perceptions about organizational users’ motivations toward OSS after receiving OSS training and (2) to develop a forecasting study to examine the OSS diffusion in the medium term in companies and educational centers. In this context, the Self-Determination Theory (SDT) was the theoretical approach through which we identified the motivational factors. Specifically, three SDT motivations were added: (1) autonomy, (2) competence and (3) relatedness. The 104 selected experts were managers from companies with employees who have studied in educational centers where OSS usage is mandatory. The results show that managers perceive that OSS training incentivizes OSS implementations in companies. At the same time, user motivations are considered to be extremely relevant, especially autonomy. In addition, is the results foresee a similar level of OSS implementation in the business and educational fields in the medium term. Finally, conclusions, practical implications and limitations are discussed.
... It is this larger challenge to the status quo that is of immediate interest, since the means by which OSS developers present their products to public audiences can tell us about how those developers wish for their projects to be compared to and distinguished from proprietary competition. There has been a tremendous amount of research into the means by which OSS products and communities might be evaluated, often in terms of the social dynamics of a particular community (Aberdour, 2007;Casaló, Cisneros, Flavián, & Guinalíu, 2009;Lemley & Shafir, 2011) or how users determine the value of a specific program (Gallego, Luna, & Bueno, 2008;Grodzinsky, Miller, & Wolf, 2003;Raghu, Sinha, Vinze, & Burton, 2009). However, relatively little has been discussed about the explicit rhetorical appeals and efforts developers make through various media to gain new users/customers. ...
... Raymond (2000) famously referred to this model as the "cathedral" approach to software development (as opposed to the relatively chaotic OSS "bazaar"), in which isolated groups of skilled craftsmen work within a clear hierarchy to release a polished commercial product. Until that product is ready for its release (to maximize profitability), access thereto is often highly restricted, with only its developers-and perhaps a population of beta testers, users given early access to the software in order to help identify bugs and other problems with it-having any knowledge of its features or capabilities (Zittrain, 2004;Grodzinsky, Miller, & Wolf, 2003). Generally located within a single corporate institution-and often existing as one or more teams within a single department-the development community often possesses a highly formalized hierarchy, and this hierarchy is often supported by specialized information management systems to facilitate specialization among individual developers or teams of developers (Hendry, 2008). ...
The increasing prominence and variety of open source software (OSS) threaten to upset conventional approaches to software development and marketing. While a tremendous amount of scholarship has been published on the differences between proprietary and OSS development, little has been discussed regarding the effect of rhetorical appeals used to promote either type of software. This chapter offers just such an examination, focusing its scrutiny on the websites for three pairs of competitors (operating system, Web browser, and image manipulation program). The means by which the OSS websites promote their programs provide a significant set of insights into the potential trajectory of OSS development and its widespread public acceptance, in terms of both its initial philosophy and its perceived alternative nature to traditional software products and models.
... with specific computational configurations to produce quantified text data. Open source software (OSS) is a public good and alternative programming operating system that users can use, modify and develop mutually according to their respective data processing needs (Kollock & Smith, 1999;Grodzinsky et al., 2003). The quantified data are checked and re-verified by human-led annotation or manual data classification by humans. ...
The younger generations have always been at the forefront of and contributed significantly to social movements that are critical of state policies or respond to socio-political situations. This is also what happened in large movements involving young people in Indonesia, conventionally in the form of demonstrations and digital movements. This study seeks to explore the relationship between youth political participation, digital media, and the development of youth political identity by analyzing young people’s engagement in some of the most significant political protests in Indonesia during the mass protests of #ReformasiDikorupsi, a movement opposing the amendments of several important bills, and #TolakOmnibusLaw, a movement opposing the establishment of a new single bill related to labor and investment, between 2019 and 2020. By analyzing quantitative data through data mining from Twitter from October 2019 to November 2020 with the social network analysis method, this study discusses online youth participation in social movements and the way they shape their political identity. Our research found that young people play an active and central role in building online and offline movements. In particular, the online movement contributes to the growth of the offline protest movement, and vice versa, because of concerns about the practice of illiberal democracy.
... Prior studies stress the importance of considering ethical issues in OSS projects by using various examples and referring to ethical principles [54,56,73]. Unfortunately, a study revealed that instructing participants to consider the ACM code of ethics does not affect their ethical decision-making in software engineering tasks [68]. ...
Full-text available
Given the rapid growth of Open-Source Software (OSS) projects, ethical considerations are becoming more important. Past studies focused on specific ethical issues (e.g., gender bias and fairness in OSS). There is little to no study on the different types of unethical behavior in OSS projects. We present the first study of unethical behavior in OSS projects from the stakeholders' perspective. Our study of 316 GitHub issues provides a taxonomy of 15 types of unethical behavior guided by six ethical principles (e.g., autonomy).Examples of new unethical behavior include soft forking (copying a repository without forking) and self-promotion (promoting a repository without self-identifying as contributor to the repository). We also identify 18 types of software artifacts affected by the unethical behavior. The diverse types of unethical behavior identified in our study (1) call for attentions of developers and researchers when making contributions in GitHub, and (2) point to future research on automated detection of unethical behavior in OSS projects. Based on our study, we propose Etor, an approach that can automatically detect six types of unethical behavior by using ontological engineering and Semantic Web Rule Language (SWRL) rules to model GitHub attributes and software artifacts. Our evaluation on 195,621 GitHub issues (1,765 GitHub repositories) shows that Etor can automatically detect 548 unethical behavior with 74.8% average true positive rate. This shows the feasibility of automated detection of unethical behavior in OSS projects.
... So the basic expectation is that people will give to the project, especially if they also benefit from it. For example, Grodzinsky et al. write about the ethical responsibilities of open source developers, including the obligation of organizations who use open source software to also contribute to the community, and the obligation to produce high-quality code [25]. Yu writes about the reciprocity in firms' open source policies, and how it contributes to their business performance [65]. ...
Full-text available
A tenet of open source software development is to accept contributions from users-developers (typically after appropriate vetting). But should this include interventions done as part of research on open source development? Following an incident in which buggy code was submitted to the Linux kernel to see whether it would be caught, we conduct a survey among open source developers and empirical software engineering researchers to see what behaviors they think are acceptable. This covers two main issues: the use of publicly accessible information, and conducting active experimentation. The survey had 224 respondents. The results indicate that open-source developers are largely open to research, provided it is done transparently. In other words, many would agree to experiments on open-source projects if the subjects were notified and provided informed consent, and in special cases also if only the project leaders agree. While researchers generally hold similar opinions, they sometimes fail to appreciate certain nuances in the stand of developers. Examples include observing license restrictions on publishing open-source code and safeguarding the code. Conversely, researchers seem to be more concerned than developers about privacy issues. Based on these results, it is recommended that open source repositories and projects include research considerations in their access guidelines, and that researchers take care to ask permission also when not formally required to do so. We note too that the open source community wants to be heard, so professional societies and IRBs should consult with them when formulating ethics codes.
... The Siegel Institute Journal of Applied Ethics, Vol. 2 [2017] due to the possibility of many different hands modifying and changing the source code (Grodzinsky, Miller & Wolf, 2003). ...
This paper will describe various leadership theories and how they were formed, current leadership perspectives for information technology (IT) and the impact they can have on an IT workforce due to negative impressions and conditions. It will then relate current ethical issues faced by Information Technology to the key driving forces behind IT today along with detailing the current ethical issues faced by IT Leadership. Finally it will recommend some future research to help IT Leadership navigate the ethical and leadership issues faced today and to prepare for the future issues that will appear as technology advances.
Over the past few years, managers have been hard pressed to become more data-driven, and one of the prerequisites in doing so is through the adoption of Business Intelligence (BI) tools. However (1) the adoption of BI tools remains relatively low (2) the acquisition costs of proprietary BI tools are relatively high and (3) the level of satisfaction with these BI tools remain low. Given the potential of open source BI (OSBI) tools, there is a need for analyzing barriers that prevent organizations from adopting OSBI. Drawing a systematic review and a Qualitative Survey of BI Experts, this study proposes a framework that categorizes and structures 23 barriers to OSBI adoption by organizations including 4 that were identified by BI Experts but not explicitly found in the literature. This paper contributes to OSS and Information Systems (IS) research literature on BI adoption in general and provides specific insights to practitioners.
Conference Paper
Full-text available
Özet. Mekansal büyük veri, yapay zeka algoritmaları, akıllı şehir tasarımları gibi mekansal bilgi sektörünün doğrudan ilişkili olduğu konular, teknik uzmanlığın, toplumsal boyutlarıyla birlikte ele alınmasını gerektirmektedir. Mekansal bilgi sektörü, yalnızca teknik bir alan değil, içinde hukuksal, etik, politik ve ekonomik etmenleri de barındıran çok yönlü bir disiplindir. Dolayısıyla, sektörün karşılaştığı sorunların ve gelecekte karşılaşılması olası sorunların yalnızca teknik gelişmeler ile çözülmesi mümkün görünmemektedir. Mekansal bilgi sektörü çalışanlarının, çalıştıkları konuya ilişkin bütüncül bir yaklaşıma sahip olmaları ve çalışma alanlarının sosyal yönlerini de keşfetmeleri oldukça önemlidir. Bu çalışmada, mekansal bilgi sektörü için gerekli görülen bu farkındalık ve dönüşüm süreci 'mekansal bilgi sektöründe sosyal dönüşümler' olarak ele alınmaktadır. Çalışmanın amacı, mekansal bilgi sektörünün toplumun bütün kesimleriyle diyalog halinde çok disiplinli bir çalışma alanı haline gelmesi için bir tartışma başlatmaktır. Sosyal dönüşümün sağlanması için, dört farklı model (sosyal model, veri paylaşım modeli, değer modeli ve eğitim modeli) önerilmiş ve bu modellerin birbiriyle ilişkisi çerçevesinde atılması gereken adımlar tartışılmıştır. Çalışmada, bilişsel özgürlüğe ulaşmak için, teknik dünya ile sosyal dünya arasında bir köprü kurulması gerektiği vurgulanmış, bu köprüyü kuracak olan bireylerin yetişmesine yönelik olarak teknik eğitimin içinde sosyal konulara daha fazla yer verilmesi gerektiği belirtilmiştir. Bu çalışma, mekansal bilgi sektöründe sosyal dönüşümün yaşanması için kurumsal düzeyde çalışmaların yapılmasının elzem olduğunu ileri sürmektedir. Abstract. The issues addressed by the spatial information sector, such as big data, artificial intelligence algorithms, smart city designs, require technical expertise and social factors to be evaluated together. Accordingly, the spatial information sector is not only a technical field but a multidimensional discipline that includes legal, ethical, political, and economic factors. Therefore, it is not possible to solve the current problems and possible future problems only with technical developments. The experts of the spatial information sector are expected to have a holistic approach and explore the social aspects of their actions. In this study, this process of awareness and transformation, which is deemed indispensable for the spatial information sector, is discussed as 'social transformations in the spatial information sector'. This study aims to initiate a discussion to make the spatial information sector a multidisciplinary discipline in dialogue with all segments of society. In order to achieve this social transformation, four different models (social model, data sharing model, value model, and education model) are proposed, and the steps that should be taken within the framework of these models are argued. Moreover, this study emphasizes that a bridge must be established between the technical world and the social world to reach 'cognitive freedom'. Consequently, it is suggested that social issues should be mentioned more in technical education to educate individuals who will build this bridge. Finally, this study asserts that it is essential to take action at the institutional level to realize social transformation in the spatial information sector.
Full-text available
In this chapter, we argue that the web is a poietically- enabling environment, which both enhances and requires the development of a "constructionist ethics". We begin by explaining the appropriate concept of "constructionist ethics", and analysing virtue ethics as the primary example. We then show why CyberEthics (or Computer Ethics, as it is also called) cannot be based on virtue ethics, yet needs to retain a constructionis t approach. After providing evidence for significant poietic uses of the web, we argue that ethical constructionism is not only facilitated by the web, but is also what the web requires as an ethics of the digital environment. In conclusion, we relate the present discussion to standard positions in CyberEthics and to a broader project for Information Ethics.
I anatomize a successful open-source project, fetchmail, that was run as a deliberate test of some surprising theories about software engineering suggested by the history of Linux. I discuss these theories in terms of two fundamentally different development styles, the "cathedral" model of most of the commercial world versus the "bazaar" model of the Linux world. I show that these models derive from opposing assumptions about the nature of the software-debugging task. I then make a sustained argument from the Linux experience for the proposition that "Given enough eyeballs, all bugs are shallow", suggest productive analogies with other self-correcting systems of selfish agents, and conclude with some exploration of the implications of this insight for the future of software.
This paper presents a brief history of the early development of the UNIX™ operating system. It concentrates on the evolution of the file system, the process-control mechanism, and the idea of pipelined commands. Some attention is paid to social conditions during the development of the system. This paper is reprinted from Lecture Notes on Computer Science, No. 79, Language Design and Programming Methodology, Springer-Verlag, 1980. During the past few years, the UNIX operating system has come into wide use, so wide that its very name has become a trademark of Bell Laboratories. Its important characteristics have become known to many people. It has suffered much rewriting and tinkering since the first publication describing it in 1974,1 but few fundamental changes. However, UNIX was born in 1969 not 1974, and the account of its development makes a little-known and perhaps instructive story. This paper presents a technical and social history of the evolution of the system.
I anatomize a successful open-source project, fetchmail, that was run as a deliberate test of some theories about software engineering suggested by the history of Linux. I discuss these theories in terms of two fundamentally different development styles, the "cathedral" model, representing most of the commercial world, versus the "bazaar" model of the Linux world. I show that these models derive from opposing assumptions about the nature of the software-debugging task. I then make a sustained argument from the Linux experience for the proposition that "Given enough eyeballs, all bugs are shallow," suggest productive analogies with other self-correcting systems of selfish agents, and conclude with some exploration of the implications of this insight for the future of software.
From the Publisher:This text provides an introduction to the process of software engineering. The revision concentrates on updating the book to reflect the most current trends and innovations in the field. The Universal Modeling Language (UML) has become an industry standard and now permeates this new edition. In this text, it is used for object-oriented analysis and design as well as when diagrams depict objects and their interrelationships. Design patterns, frameworks and software architecture have also become a popular topic in the field of software engineering and are part of a new chapter on reuse, portability, and inoperability. The inoperabilty material includes sections on such hot topics as OLE, COM, and CORBA (you'll want to mention that this material is covered). Some material from the 3rd edition has been reorganized into a new chapter on planning and estimating, including feature points and COCOMO II. While the text has been updated, the traditonal features which have defined the previous three editions of Schach's book have been retained. These include a balanced coverage of the object-oriented model along with the classical model (as reflected in the title) and an emphasis on metrics. The special considerations of object-oriented life-cycle models, object-oriented analysis, and object-oriented design are also retained in this edition.
Conference Paper
Richard Stallman is the founder of the GNU Project, launched in 1984 to develop the free software operating system GNU. The name ``GNU'' is a recursive acronym for ``GNU's Not Unix''. He is also the principal author of the GNU Compiler Collection, a portable optimizing compiler which was designed to support diverse architectures and multiple languages. The compiler now supports over 30 different architectures and 7 programming languages. Stallman also wrote the GNU symbolic debugger (gdb), GNU Emacs, and various other programs for the GNU operating system.
This article attempts to explain why there is a tendency toward diminished accountability or the impacts, harms, and risks of computing, and it offers recommendations for reversing it.
After observing a contradiction between the 'official' ideology defined by open-source licenses and the actual behavior of hackers, we examine the actual customs which regulate the ownership and control of open-source software. We discover that they imply an underlying theory of property rights homologous to the Lockean theory of land tenure. We relate that to an analysis of the hacker culture as a 'gift culture' in which participants compete for prestige by giving time, energy, and creativity away. We then examine the implications of this analysis for conflict resolution in the culture, and develop some prescriptive implications.
"Why would anyone give away such valuable advice? What can explain the amount of cooperation that does occur in online communities? In this chapter I wish to analyze how the economies of cooperation change as one moves to the Internet. I argue that there are fundamental features of online interaction which change the costs and benefits of social action in dramatic ways. "Because the metaphor of gift giving has been used to describe online interaction and exchange, I will begin with a brief discussion of the concept of the gift. I then discuss social dilemmas - situations in which individually reasonable behavior leads to collective disaster - and in particular examine the challenge of providing public goods (to be defined below). Subsequent sections detail the shift in the economics of cooperation, discuss the motivations that drive contributions and collaboration, and provide two striking examples of online collective action. I close with a strong caution against assuming that the shifting economics of online interaction guarantee high levels of cooperation."