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
|