Open Source

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 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 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 • One cannot code from the ground up in bazaar style. 

Need  Need a seed

– 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 (utility max) Æ ) Æ market Æ 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 Free Software Foundation Free Software Foundation (Richard Stallman),  Defined GPL and uses it  as a weapon against hoarding Emacs, GCC

Commercial software is evil

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

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… 

open source development is  merely means to an end 

Zealotry open source development   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 ((OSD).  ) Software Guidelines, which became the Open Source Definition 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 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 — 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’tt be hackers Æ won be hackers Æ “Craftsmanship 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. 2. 3. 4.

5.

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 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, l lonely l

K

Unknown

dead end moderate risk, crowded

Known U low risk, well populated

U U

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