aboutsummaryrefslogtreecommitdiff
path: root/books/tecnopolitica/cathedral-bazaar.mdwn
blob: 4089a7e0879d9fedeac715f2d8f8913f40e44733 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
[[!meta title="The Cathedral & The Bazaar"]]
[[!tag jogo software foss economics]]

* [The Cathedral and the Bazaar](http://www.catb.org/~esr/writings/cathedral-bazaar/)
* Author: Eric S. Raymond
* ISBN: 978-0-596-00108-7
* Publisher: O'Reilly

## Phenomenology

* Linus Law: "Given enough eyeballs, all bugs are shallow" (page 30);
  "debugging is parallelizable" (page 32).

* Delphi Effect: "the averaged opinion of a mass of equally expert (or equally
  ignorant) observers is quite a bit more reliable a predictor than the opinion
  of a single randomly chosen observer" (page 31).

* Brooks Law: "complexity and communication costs of a project rise with the
  square number of developers" (pages 32, 49).

## Freedom and hierarchy

* Kropotkin is cited at page 52: "principle of understanding" versus the
  "principle of command".

* Visão libertariana: "The Linux world behaves in many respects like a free
  market or an ecology, a collection of selfish agents attempting to maximize
  utility, which in the process produces a self-correcting spontaneous order
  more elaborate and efficient than any amount of central planning could have
  achieved." (page 52). Logo em seguida ele nega a existência de um autruísmo
  puro.

## Economics

A very liberal point of view:

* Homesteading the Noosphere: "customs that regulate the ownership and control
  of open-source software [...] imply an underlying theory of property rights
  homologous to the Lockean theory of land tenure" (65).

* Open Source as a gift economy like a reputation game (81 - 83):

    Most ways humans have of organizing are adaptations to scarcity
    and want. Each way carries with it different ways of gaining social status.

    The simples way is the _command hierarchy_ [where] scarce goods are allocated
    by onde central authority and backed up by force. Command hierarchies scale
    very poorly; they become increasingly inefficient as they get larger.

    [...]

    Our society is predominantly an exchange economy. This is a sofisticated
    adaptation to scarcity that, unlike the command model, scales quite well.
    Allocation of scarce goods is done in a decentralized way through trade
    and voluntary coopreation.

    [...]

    Gift cultures are adaptations not to scarcity but to abundance. They arise
    in populations that do not have significant material scarcity problems
    with survival goods.

    [...]

    Abundance makes command relationships difficult to sustain and exchange
    relationships an almost pointless game. In gift cultures, social status
    is determined not by what you control but by _what you give away_.

    -- 80-81

He also explains that the reputation game is not the only drive in the
bazaar-style ecosystem: satisfation, love, the "joy of craftsmanship" are also
motivations for software development (pages 82-83), which is compatible
with the gift economy model:

    How can one maximize quality if there is no metric for quality?
    If scarcity economics doesn't operate, what metrics are available
    besides peer evaluation?

    Other respondents related peer-esteem rewards and the joy of hacking
    to the levels above subsistence needs in Abraham Maslow's well-known
    'hierachy of values' model of human motivation.

    -- 82-83

Cites both Ayn Rand and Nietzsche at page 88 when talking about "selfless"
motives, besides their "whatever other failings", saying that both
are "desconstructing" 'altruism' into unacknowledged kinds of self-interest.

## The value of humility

    Furthermore, past bugs are not automatically held against a developer; the fact
    that a bug has been fixed is generally considered more importante than the fact
    that one used to be there. As one respontend observed, one can gain status by
    fixing 'Emacs bugs', but not by fixing 'Richard Stallman's bugs' -- and it
    would be considered extremely bad form to criticie Stallman for _old_ Emacs
    bugs that have since been fixed.
    
    This makes an interesting contrast with many parts of academia, in which
    trashing putatively defective work by others is an important mode of gaining
    reputation. In the hacker culture, such behavior is rather heavily tabooed --
    so heavily, in fact, that the absence of such behavior did no present itself to
    me as a datum until that one respondent with an unusual perdpective pointed it
    out nearly a full year after this essay was first published!

    The taboo against attacks on competence (not shared with academia) is even more
    revealing than the (shared) taboo on posturing, because we can relate it to a
    difference between academia and hackerdom in their communications and support
    structures.
    
    The hacker culture's medium of gifting is intangible, its communications
    channels are poor at expressing emotional nuance, and face-to-face contact
    among its members is the exception rather than the rule. This gives it a lower
    tolerance of noise than most other gift cultures, and goes a long way to
    explain both the taboo against posturing and the taboo against attacks on
    competence. Any significant incidence of flames over hackers' competence would
    intolerably disrupt the culture's reputation scoreboard.

    -- 90-91

What about Linus behavior, then?

    The same vulnerability to noise explains the model of public humility required
    of the hacker community's tribal elders. They must be seen to be free of boast
    and posturing so the taboo against dangerous noise will hold.
    
    Talking softly is also functional if one aspires to be a maintainer of a
    successful project; one must convince the community that one has good
    judgement, because most of the maintainer's job is going to be judging other
    people's code. Who would be inclined to contribute work to someone who clearly
    can't judge the quality of their own code, or whose behavior suggests they will
    attempt to unfairly hog the reputation return from the project? Potential
    contributors want project leaders with enough humility and class to be able to
    to say, when objectively appropriate, ``Yes, that does work better than my
    version, I'll use it''—and to give credit where credit is due.

    -- 91