Open Source Open Source

Julita Vassileva Social Computing Class 2009/10 Social Computing Class 2009/10

Based on Based on
• Eric Raymond’s (1998‐2000) Eric Raymond s (1998 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. Good programmers know what to write.  2 G d k h tt it Re‐ Great ones know what to rewrite (and reuse). cycle 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  Wisdom rapid code improvement and effective debugging. Of 6. Release early. Release often. And listen to your customers. 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 as if they re your most valuable  9. If you treat your beta‐testers as if they're 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  ideas from your users. Sometimes the latter is better. id f S i h l i b

Preconditions for the Bazaar Style Preconditions for the Bazaar Style
• 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.

Need  Need a seed

• 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 is absolutely critical that the coordinator be able It 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 programming (Gerald Weinberg) Ego‐less programming (Gerald Weinberg) • Ego‐boost effect  reputation  economic  behaviour ( tilit b h i (utility max)  market  self‐ ) k t lf organziation, more elaborate and efficient  than any central planning…  th 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 (Linus T (Li 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…  Zealotry open source development   is an end in itself

Commercial software is fine,  as long as I get the source or it does what I want it to do

open source development is  merely means to an end 

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 can hack anything”. Anyone 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's name from a project Removing a person s 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 owner of a software project is the person who The 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 found the project to 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 g owner, one can acquire ownership by homesteading – The usual means of transfer in settled areas is transfer of  title.  – In case that land title may be lost or abandoned — by  y y adverse possession—one moves in, improves it, and  defends title as if homesteading

– But what is the “yield” of the noosphere that has to be But what is the  yield of the noosphere that has to be  defended? 
– Can’t be use of software, money or power REPUTATION

Gift Culture Gift Culture
• Human beings have an innate drive to Human 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 gift is defined as A 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‐excludable in that it is difficult or impossible non excludable 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  diminishes what is available for someone else. So any piece of  d 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  is bl i able 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

• Id if i Identifying with the group’s needs ih h ’ d
– Importance of a meeting place (discussion forum)

• Att h Attachment to the group (pure altruism) t t th ( lt i ) • A side‐effect of private behavior 

Back to Open Source (Raymond):  Altruism or reputation?
• The “Joy of Hacking” and producing high  The  Joy of Hacking and producing high quality software is essential, without it there  won t be hackers  won’t be hackers “Craftsmanship model” Craftsmanship 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. 2. 3. 4. Good reputation among one's peers is a primary reward Prestige is a good way (and in a pure gift economy, the only way)  to attract attention and cooperation from others 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 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. 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 can analyze the Lockean property customs as We 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  big  satisfaction”? E.g. why do many of the “big men”/tribal elders humorously deprecate  themselves? 
– The negative Euro‐American attitude towards “ego”.  Acceptable are only disguised forms like “peer‐repute”,  “self esteem”, “professionalism”, “pride of self‐esteem professionalism pride 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 t  done yet, impression that the project isn’t “done” 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) p


high risk, lonely l l


dead end moderate risk, crowded

low risk, well populated


Project structure and ownership Project structure and ownership
• Single owner/maintainer Single 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 follows responsibility ‐ technical arguments over design are Authority follows responsibility  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 conflicts are resolved with the above two rules Most 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

• 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 and Hacker Culture have evolved Academia 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 • T Torvalds suggested that Linux was successfully developed in  ld 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 “lowest hanging fruit” ‐‐ For the most part we have been picking the  lowest 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  

• How is open source software or free (libre) How is open source software or free (libre) software different from user generated  content? • Compare the current trends of opening APIs  to 3 party developers (FB, Google, Amazon,  to 3rd party developers (FB Google Amazon etc.) with open source development