Open Source

Open Source

Julita Vassileva
Social Computing Class 2009/10
Social Computing Class 2009/10
 Based on
Based on
• Eric Raymond
Eric Raymond’ss (1998
(1998‐2000)
2000)
– The Cathedral and the Bazaar
– Homesteading the Noosphere
Homesteading the Noosphere
• Peter Kollock (1999)
– The Economics of Online Cooperation
 Tenets of Open Source
Tenets of Open Source
1. Every good work of software starts by 
1 Every good work of software starts by EGO
scratching a developer's personal itch.
2 G d
2. Good programmers know what to write. 
k h tt it
Great ones know what to rewrite (and reuse). cycle Re‐

3. ``Plan to throw one away; you will, anyhow.'' (Fred 
Brooks, The Mythical Man‐Month, Chapter 11)
4. When you lose interest in a program, your last duty 
to it is to hand it off to a competent successor.
 Tenets of Open Source
Tenets of Open Source
5. Treating your users as co‐developers is your least‐hassle route to 
rapid code improvement and effective debugging. Wisdom
6. Release early. Release often. And listen to your customers. Of
Crowds
7. Linus’ Law: Given enough eyeballs, all bugs are shallow 
Given a large enough beta‐tester and co‐developer base, almost 
every problem will be characterized quickly and the fix will 
become obvious to someone. “Someone finds the problem, and 
somebody else understands it.
somebody else understands it ”
8. Smart data structures and dumb code works a lot better than the 
other way around.
9. If you treat your beta‐testers
9. If you treat your beta testers as if they
as if they're
re your most valuable 
your most valuable
resource, they will respond by becoming your most valuable 
resource.
10. The next best thing to having good ideas is recognizing good 
id
ideas from your users. Sometimes the latter is better.
f S i h l i b
Preconditions for the Bazaar Style
Preconditions for the Bazaar Style Need 
Need
a
seed
• One cannot code from the ground up in bazaar style. 
– One can test, debug and improve in bazaar style, but it 
would be very hard to originate a project in bazaar mode. 
– Your nascent developer community needs to have 
Your nascent developer community needs to have
something runnable and testable to play with.
• When you start community‐building, you need to 
present a plausible promise. 
t l ibl i
– Your program doesn't have to work particularly well. It can 
be crude, buggy, incomplete, and poorly documented. 
, ggy, p , p y
What it must not fail to do is (a) run, and (b) convince 
potential co‐developers that it can be evolved into 
something really neat in the foreseeable future.
g y
 How clever do you have to be to start 
a successful OS project?
f l
1. It
It is absolutely critical that  the coordinator be able 
is absolutely critical that the coordinator be able
to recognize good design ideas from others.
2. Beware of being too clever and original! Keep things 
g g p g
simple and robust instead of too elegant or clever… 
p j
3. A bazaar project coordinator or leader must have 
good people and communications skills.
 Factors in Open Source Success
Factors in Open Source Success
• Ego‐less
Ego‐less programming (Gerald Weinberg)
programming (Gerald Weinberg)
• Ego‐boost effect Æ reputation Æ economic 
b h i
behaviour ( tilit ) Æ market Æ
(utility max) Æ k t Æ self‐
lf
organziation, more elaborate and efficient 
th
than any central planning… 
t l l i
• Importance of the communications medium
• Importance of leadership without coercion
• Evolution of cooperative customs / norms
o ut o o coope at e custo s / o s
 Open Source Ideology
Open Source Ideology
Attitude to commercial 
software
Commercial software is evil Free Software Foundation
Free Software Foundation
(Richard Stallman), 
Defined GPL and uses it 
as a weapon against hoarding
Emacs, GCC

Pragmatists
(Li
(Linus T
Torvalds, Eric Raymond)
ld E i R d)
Not necessarily anti‐commercial
Uses GPL as a tool
Linux, Perl, Tcl, Python…
y
Microsoft is evil… 
Commercial software is fine, 
as long as I get the source or
it does what I want it to do Zealotry

open source development is  open source development  
merely means to an end  is an end in itself
 Ideology expressed in licenses
Ideology expressed in licenses
• A broad consensus theory of what `free software' or `open source' is. 
• The clearest expression of this common theory is in the various open‐
source licenses, all of which have crucial common elements
• In 1997 these common elements were distilled into the Debian Free 
, p
Software Guidelines, which became the Open Source Definition ((OSD). 
)
Under the guidelines defined by the OSD, an open‐source license must 
protect an unconditional right of any party to modify (and redistribute 
modified versions of) open‐source software.
Æ “Anyone
Anyone can hack anything
can hack anything”..
Æ No one prevents anyone from taking any given open‐source product, 
duplicating the sources, and running off with them in different evolutionary 
directions, but all claiming to be the product. (forking)
• However in reality forking happens extremely rarely
However, in reality forking happens extremely rarely
Æ The open‐source culture has an elaborate but largely unadmitted set of 
ownership customs. These customs regulate who can modify software, the 
circumstances under which it can be modified, and (especially) who has the 
right to redistribute modified versions back to the community
right to redistribute modified versions back to the community
 Taboos in OS culture:
Taboos in OS culture:
• There is strong social pressure against forking 
g p g g
projects. It does not happen except under plea of 
dire necessity, with much public self‐justification, 
and requires a renaming
and requires a renaming.
• Distributing changes to a project without the 
cooperation of the moderators is frowned upon, 
except in special cases like essentially trivial 
porting fixes.
• Removing a person
Removing a person'ss name from a project 
name from a project
history, credits, or maintainer list is absolutely not 
done without the person's explicit consent.
 Ownership in Open Source?
Ownership in Open Source?
• The
The owner of a software project is the person who 
owner of a software project is the person who
has the exclusive right, recognized by the 
community at large, to distribute modified versions.
y g , f
• Three ways of acquiring ownership of a project
– to
to found the project
found the project
– to have the ownership handed to you by the previous 
owner
– to observe that it needs work and the owner has 
disappeared or lost interest
 Locke and Land Title
Locke and Land Title
• The Anglo‐American common‐law theory of land 
tenure – 3 ways of acquiring land ownership:
– On a frontier, where land exists that has never had an 
q p y
owner, one can acquire ownership by homesteading g
– The usual means of transfer in settled areas is transfer of 
title. 
– In case that land title may be lost or abandoned —
y by 
y
adverse possession—one moves in, improves it, and 
defends title as if homesteading
– But
But what is the 
what is the “yield”
yield  of the noosphere
of the noosphere that has to be 
that has to be
defended? 
– Can’t be use of software, money or power
Æ REPUTATION
 Gift Culture
Gift Culture
• Human
Human beings have an innate drive to 
beings have an innate drive to
compete for social status; it's wired in by our 
evolutionary history.
• Three forms of social organizations, each with 
its own definition of status
– Command hierarchy (status ‐> access to power)
– Exchange economy (status ‐> having control of 
things to use or trade, money)
– Gift economy (status Æ what you give away)
Detour to Online Communities in 
General: Gifts (based on Kollock, 1999)
• A
A gift is defined as 
gift is defined as
(1) the obligatory transfer, 
(2) of inalienable objects or services
(2) of inalienable objects or services,
(3) between related and mutually obligated 
transactors. 
transactors
• Generalized exchange – a kind of network‐
wide accounting system in which a benefit
wide accounting system, in which a benefit 
given to a person is reciprocated not by the 
recipient but by someone else in the group
recipient but by someone else in the group.
 Public goods (Kollock)
Public goods (Kollock)
• Public goods
Public goods
– indivisible in that one person's consumption of the 
good does not reduce the amount available to
good does not reduce the amount available to 
another (e.g. watching fireworks display)
– non
non‐excludable
excludable in that it is difficult or impossible 
in that it is difficult or impossible
to exclude individuals from benefiting from the 
good 
• Social dilemma
– Challenges in providing public goods: motivation
g p gp g
and coordination
 Digital goods (Kollock)
Digital goods (Kollock)
• Online interaction can reduce the costs of contributing to the 
production of a public good in numerous ways (distribution
production of a public good in numerous ways (distribution, 
coordination costs). 
– Digital information– one person's use of the information in no way 
d
diminishes what is available for someone else. So any piece of 
h h l bl f l f
information posted to an online community becomes a public good
– The size of the group necessary to produce many public goods is often 
reduced to one. So no coordination costs.  Also no fear of contributing 
d d S di i l f f ib i
to a lost cause. 
– Shifts in the economies of production mean that an individual 
i able
is bl to produce many public goods on their own. And the decrease 
d bli d h i A d h d
in contribution and coordination costs as well as the potential 
amplification in the value of the contribution (because of the huge 
audience) makes it more likely that an individual will experience a
audience) makes it more likely that an individual will experience a 
net benefit from providing the good.
Motivations for contributing (Kollock)
• Seeking reciprocity (after gifting) 
– Expectation of repeated interactions
– Importance of persistent identity
• Seeking reputation
– Important that contributions are visible for the entire 
community, recognition of contributions
• Seeking self‐efficacy
k lf ff
– Able to observe changes attributable to their actions
• Identifying with the group’s needs
Id if i ih h ’ d
– Importance of a meeting place (discussion forum)
• Attachment to the group (pure altruism)
Att h t t th ( lt i )
• A side‐effect of private behavior 
 Back to Open Source (Raymond): 
Altruism or reputation?
• The
The “Joy
Joy of Hacking
of Hacking” and producing high 
and producing high
quality software is essential, without it there 
won be hackers Æ “Craftsmanship
won’tt be hackers Æ Craftsmanship model
model”
• If scarcity economics doesn’t operate, what 
metrics are available besides peer evaluation?
metrics are available besides peer‐evaluation? 
• ``You may not work to get reputation, but the 
reputation is a real payment with 
i i l ih
consequences if you do the job well.'' 
 Why reputation is worth playing for
Why reputation is worth playing for
1. Good reputation among one's peers is a primary reward
2. Prestige is a good way (and in a pure gift economy, the only way) 
to attract attention and cooperation from others
3. If the gift economy is in contact with or intertwined with an 
exchange economy or a command hierarchy reputation may spill
exchange economy or a command hierarchy, reputation may spill 
over and earn higher status also outside the gift economy
4. In the Open Source culture, the artifacts one gives away are very 
complex. It is much harder to objectively distinguish a fine gift
complex. It is much harder to objectively distinguish a fine gift 
from a poor one. Accordingly, the success of a giver's bid for status 
is delicately dependent on the critical judgment of peers.
5. The Hacker culture is relatively pure, there are no other ways of 
gaining status other than by peer‐reputation.
i i h h b i
 Ownership rights and reputation 
incentives
• We
We can analyze the Lockean property customs as 
can analyze the Lockean property customs as
a means of maximizing reputation incentives
• Explaining the three taboos
Explaining the three taboos
– Forking is bad, it exposes pre‐fork contributors to a 
reputation risk
reputation risk 
– Distributing rogue patches exposes the owners to an 
unfair reputation risk
unfair reputation risk
– Dropping a contributor’s name off a project –
ultimate crime (like stealing reputation earned by
ultimate crime (like stealing reputation earned by 
somebody else)
 The Problem of Ego
The Problem of Ego
• How to explain the fact that many hackers show 
great reluctance to admit that their behaviour is
great reluctance to admit that their behaviour is 
motivated by the desire for peer‐repute or “ego‐
satisfaction”?? E.g. why do many of the 
satisfaction E.g. why do many of the “big
big 
men”/tribal elders humorously deprecate 
themselves? 
– The negative Euro‐American attitude towards “ego”. 
Acceptable are only disguised forms like “peer‐repute”, 
“self
self‐esteem
esteem”, “professionalism”
professionalism , “pride
pride of 
of
accomplishment”. 
 The Value of Humility
The Value of Humility
• Hacker culture versus Pirate culture
• Protecting the quality of information for 
reputation judgment (based on work only)
• Humility of leaders:
– They need to convince the community that they 
They need to convince the community that they
have good judgment and will give credit where it 
is due
• Humble behaviour allows to maintain the 
impression that the project isn’tt “done”
impression that the project isn done  yet, 
yet,
and invites more contributions
 Reputation model implications
Reputation model implications
• Reputations rewards are higher if you start a 
successful new project than if you contribute 
to an existing project, but attracting others to 
a new project is harder and riskier
– Optimum distance from one’s neighbours (not 
“me too” and not too far ahead)
• Most people work  in the “homesteading 
p p g
frontier”, new projects fill gaps around it
• Some very successful projects become 
Some very successful projects become
“category killers” 
Homesteading frontier is similar to research frontier
by Dr. Tom Brzustowski, (2004, then president of NSERC)
http://www.usask.ca/research/nserc25.shtml
p

K high risk,
K l
lonely
l

Unknown

dead end

moderate risk,
crowded

Known

U U
low risk, U
well populated U
 Project structure and ownership
Project structure and ownership
• Single
Single owner/maintainer
owner/maintainer
• A “benevolent dictator” and co‐maintainers
• A project manager (benevolent dictator) and 
j (b l di ) d
co‐developers (responsible for sub‐systems, 
consulted on key decisions)
l d k d ii )
• Voting committees of co‐developers (Apache)
• Rotating dictatorship (Perl)
 Conflict resolution
Conflict resolution
• Two conflict resolution rules:
– Authority
Authority follows responsibility 
follows responsibility ‐ technical arguments over design are 
technical arguments over design are
easily resolved following the territorial rule
– Seniority wins —if two contributors (groups) have a dispute, and the 
dispute cannot be resolved objectively and neither owns the territory
dispute cannot be resolved objectively, and neither owns the territory 
of the dispute, the side that has put the most work into the project as 
a whole wins
• Most
Most conflicts are resolved with the above two rules
conflicts are resolved with the above two rules
• But if these two rules point in different directions, and the 
authority of the project leader is weak or absent – the 
conflicts are hard to resolve, long and painful battles ensue
 Acculturation
• How do new members learn the norms?
How do new members learn the norms?
– hidden clues – secrets to be discovered by 
newcomers who aspire to join the group (e g from
newcomers who aspire to join the group (e.g. from 
reading archives, readme, following discussions). 
– one becomes involved in the culture by attaching 
one becomes involved in the culture by attaching
oneself to specific projects (immersion in social 
context, learning from example of behaviors by 
experienced hackers)
– parallels with Academia; some hackers have 
education / background in academia
 Gift outcompetes exchange
Gift outcompetes exchange
• Academia
Academia and Hacker Culture have evolved 
and Hacker Culture have evolved
gift cultures as most optimal social way to 
cooperate for generating and checking high‐
cooperate for generating and checking high
quality creative work
• Explicit incentives hamper creativity 
Explicit incentives hamper creativity
– presenting any task as a means rather than an end 
in itself seems to demotivate
in itself seems to demotivate
 Limitations (Kollock)
Limitations (Kollock)
• Online interaction can significantly reduce the costs of 
g y
providing some public goods, but there are limitations to 
online cooperation
• Torvalds
T ld suggested that Linux was successfully developed in 
t d th t Li f ll d l di
part because it was considered inherently interesting and 
because one person was able to write the core of the 
program. 
– More mundane applications may not attract attention. 
– Many public goods, even digital public goods, require the coordinated 
Many public goods even digital public goods require the coordinated
activities of a large group from the very beginning. Such public goods 
are less likely to be produced.
– For the most part we have been picking the 
For the most part we have been picking the “lowest
lowest hanging fruit
hanging fruit” ‐‐
it would be hard/impossible to produce something really innovative
 Structural features of successful 
community (Kollock)
(1) ongoing interaction, 
(2) identity persistence
(2) identity persistence, 
(3) knowledge of previous interactions,
( )
(4) making sure contributions are visible and that 
k b bl d h
contributors are recognized for the efforts, 
(5) well defined and defended group boundaries  
 Questions
• How
How is open source software or free (libre)
is open source software or free (libre)
software different from user generated 
content?
• Compare the current trends of opening APIs 
to 3rd party developers (FB, Google, Amazon, 
to 3 party developers (FB Google Amazon
etc.) with open source development