path: root/books/tecnopolitica/cathedral-bazaar.md
diff options
authorSilvio Rhatto <rhatto@riseup.net>2017-09-30 14:06:22 -0300
committerSilvio Rhatto <rhatto@riseup.net>2017-09-30 14:06:22 -0300
commit23ac9f57b9b4c761cb8edc5bfa0c0de77ec89326 (patch)
tree3dab0ec66d67cd62b7e815fea4d62da481042b7b /books/tecnopolitica/cathedral-bazaar.md
parent9c21d35c535a4956960851d3c438d58af5f67d92 (diff)
Change extension to .md
Diffstat (limited to 'books/tecnopolitica/cathedral-bazaar.md')
1 files changed, 137 insertions, 0 deletions
diff --git a/books/tecnopolitica/cathedral-bazaar.md b/books/tecnopolitica/cathedral-bazaar.md
new file mode 100644
index 0000000..4089a7e
--- /dev/null
+++ b/books/tecnopolitica/cathedral-bazaar.md
@@ -0,0 +1,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