The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary
Rate it:
Open Preview
25%
Flag icon
Human beings generally take pleasure in a task when it falls in a sort of optimal-challenge zone; not so easy as to be boring, not too hard to achieve. A happy programmer is one who is neither underutilized nor weighed down with ill-formulated goals and stressful process friction. Enjoyment predicts efficiency.
25%
Flag icon
It may well turn out that one of the most important effects of open source’s success will be to teach us that play is the most economically efficient mode of creative work.
26%
Flag icon
A moderately anticommercial person might say “Commercial software in general is OK because programmers deserve to get paid, but companies that coast on shoddy products and throw their weight around are evil.”
27%
Flag icon
The typical pragmatist attitude is only moderately anticommercial, and its major grievance against the corporate world is not “hoarding” per se. Rather it is that world’s perverse refusal to adopt superior approaches incorporating Unix and open standards and open-source software.
28%
Flag icon
There is strong social pressure against forking projects. It does not happen except under plea of dire necessity, with much public self-justification, and requires a renaming.
29%
Flag icon
What does “ownership” mean when property is infinitely reduplicable, highly malleable, and the surrounding culture has neither coercive power relationships nor material scarcity economics?
29%
Flag icon
According to the standard open-source licenses, all parties are equals in the evolutionary game. But in practice there is a very well-recognized distinction between “official” patches, approved and integrated into the evolving software by the publicly recognized maintainers, and “rogue” patches by third parties. Rogue patches are unusual, and generally not trusted.
31%
Flag icon
And the distinction between noosphere and ergosphere is only of practical importance if one wishes to assert that ideas (the elements of the noosphere) cannot be owned, but their instantiations as projects can. This question leads to issues in the theory of intellectual property which are beyond the scope of this essay.
32%
Flag icon
Gift cultures are adaptations not to scarcity but to abundance.
32%
Flag icon
Abundance makes command relationships difficult to sustain and exchange relationships an almost pointless game.
32%
Flag icon
In making this “reputation game” analysis, by the way, I do not mean to devalue or ignore the pure artistic satisfaction of designing beautiful software and making it work.
34%
Flag icon
Forking projects is bad because it exposes pre-fork contributors to a reputation risk they can only control by being active in both child projects simultaneously after the fork.
34%
Flag icon
Surreptitiously filing someone’s name off a project is, in cultural context, one of the ultimate crimes. Doing this steals the victim’s gift to be presented as the thief’s own.
Alexander Bandukwala
This coupled with thbe prior complaints make customization a pain
34%
Flag icon
If I fork or rogue-patch your project, I am saying: “you made a wrong decision by failing to take the project where I am taking it”; and anyone who uses my forked variation is endorsing this challenge.
Alexander Bandukwala
Very agressive framing
35%
Flag icon
I could write an entire other essay on the unhealthy roots of this part of our cultural inheritance, and the astonishing amount of self-deceptive harm we do by believing (against all the evidence of psychology and behavior) that we ever have truly “selfless” motives. Perhaps I would, if Friedrich Wilhelm Nietzsche and Ayn Rand had not already done an entirely competent job (whatever their other failings) of deconstructing “altruism” into unacknowledged kinds of self-interest.
36%
Flag icon
Yet another reason for humble behavior is that in the open source world, you seldom want to give the impression that a project is “done”.
Alexander Bandukwala
This seems bad
38%
Flag icon
It is fashionable in some circles to describe human property as an arbitrary social convention, but this is dead wrong.
41%
Flag icon
Another way of resolving conflicts is by seniority — if two contributors or groups of contributors have a dispute, and the 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 (that is, the side with the most property rights in the whole project) wins.
Alexander Bandukwala
This is essentially proof of stake
42%
Flag icon
hacker ownership customs seem intimately related to (and may derive directly from) the practices of the academic world, especially the scientific research community. This research community has similar problems in mining a territory of potentially productive ideas, and exhibits very similar adaptive solutions to those problems in the ways it uses peer review and reputation.
43%
Flag icon
Nevertheless, their results do suggest that some kinds of scarcity-economics rewards actually decrease the productivity of creative workers such as programmers.
43%
Flag icon
“The more complex the activity, the more it’s hurt by extrinsic reward.” Interestingly, the studies suggest that flat salaries don’t demotivate, but piecework rates and bonuses do.
43%
Flag icon
Indeed, these results suggest that the only time it is a good idea to reward performance in programming is when the programmer is so motivated that he or she would have worked without the reward!
44%
Flag icon
I then continue to develop a qualitative theory of when it is economically rational for software to be closed.
44%
Flag icon
Buckminster Fuller gave us the concept of “ephemeralization”,
45%
Flag icon
gift culture behavior arises in situations where survival goods are abundant enough to make the exchange game no longer very interesting; but while this appears sufficiently powerful as a psychological explanation of behavior, it lacks suffiency as an explanation of the mixed economic context in which most open-source developers actually operate.
Alexander Bandukwala
The splitting here makes me deeply uncomfortable. Wojld nlove a behavioral economics analysis
45%
Flag icon
computer programs like all other kinds of tools or capital goods, have two distinct kinds of economic value. They have use value and sale value.
45%
Flag icon
First, code written for sale is only the tip of the programming iceberg. In the pre-microcomputer era it used to be a commonplace that 90% of all the code in the world was written in-house at banks and insurance companies.
45%
Flag icon
but we’ll see shortly that there is empirical evidence that approximately 95% of code is still written in-house.
45%
Flag icon
It includes technical-specialist code like device drivers. Almost nobody makes money selling device drivers,
46%
Flag icon
Accordingly, most programmer-hours are spent (and most programmer salaries are paid for) writing or maintaining in-house code that has no sale value at all
46%
Flag icon
In other words, software is largely a service industry operating under the persistent but unfounded delusion that it is a manufacturing industry.
Alexander Bandukwala
I still dont buy this maintenance/service argument
47%
Flag icon
Under the efficiency-seeking conditions of the free market we can predict that this is the sort of price structure most of a mature software industry will ultimately follow.
Alexander Bandukwala
Huge foresight of Software service pricing
48%
Flag icon
Why don’t people who know the open-source community exists universally exhibit free-rider behavior behavior, waiting for others to do the work they need, or (if they do the work themselves) not bothering to contribute the work back into the commons?
Alexander Bandukwala
This is comedic in hindsight
48%
Flag icon
Supposing I write a fix for an irritating bug, and suppose many people realize the fix has money value; how do I collect from all those people? Conventional payment systems have high enough overheads to make this a real problem for the sorts of micropayments that would usually be appropriate.
49%
Flag icon
As a thought experiment, let us suppose that the Internet came equipped with the theoretically ideal micropayment system — secure, universally accessible, zero-overhead.
49%
Flag icon
How do you know what price to ask? How would a potential buyer, not having seen the patch yet, know what is reasonable to pay for it?
49%
Flag icon
F. A. Hayek’s “calculation problem”
49%
Flag icon
Sitting on the patch gains nothing. Indeed, it incurs a future cost — the effort involved in re-merging the patch into the source base in each new release.
Alexander Bandukwala
Incentive for monorepos
54%
Flag icon
In this model, you release software in binaries and source with a closed license, but one that includes an expiration date on the closure provisions.
56%
Flag icon
In summary, the following discriminators push towards open source: Reliability/stability/scalability are critical. Correctness of design and implementation cannot readily be verified by means other than independent peer review. The software is critical to the user’s control of his/her business. The software establishes or enables a common computing and communications infrastructure. Key methods (or functional equivalents of them) are part of common engineering knowledge.
57%
Flag icon
If present trends continue, the central challenge of software technology and product management in the next century will be knowing when to let go — when to allow closed code to pass into the open-source infrastructure in order to exploit the peer-review effect and capture higher returns in service and other secondary markets.
63%
Flag icon
Applications, on the other hand, will have the most tendency to remain closed. There will be circumstances under which the use value of an undisclosed algorithm or technology will be high enough (and the costs associated with unreliability will be low enough, and the risks associated with a supplier monopoly sufficiently tolerable) that consumers will continue to pay for closed software.
Alexander Bandukwala
How narrow can this be?
65%
Flag icon
I still carried in my head the unexamined assumption that hacker amateurs, gifted though they might be, could not possibly muster the resources or skill necessary to produce a usable multitasking operating system.
67%
Flag icon
Twenty years of repeatedly watching brilliant ideas, promising starts, and superior technologies crushed by slick marketing.
68%
Flag icon
Our success after Netscape would depend on replacing the negative FSF stereotypes with positive stereotypes of our own — pragmatic tales, sweet to managers’ and investors’ ears, of higher reliability and lower cost and better features.
68%
Flag icon
One of the things that seemed clearest was that the historical Unix strategy of bottom-up evangelism (relying on engineers to persuade their bosses by rational argument) had been a failure.
72%
Flag icon
Linux will continue to lead the way, the sheer size of its developer community overpowering the higher average skill of the open-source BSD people and the tiny HURD crew.
73%
Flag icon
That is, while hackers can be very good at designing interfaces for other hackers, they tend to be poor at modeling the thought processes of the other 95% of the population
Alexander Bandukwala
Maybe theyre bad even for other hackers
73%
Flag icon
I believe the problem for 2001 and later is whether we can grow enough to meet (and exceed!) the interface-design quality standard set by the Macintosh, combining that with the virtues of the traditional Unix way.
Alexander Bandukwala
They didn't
74%
Flag icon
Yes, the success of open source does call into some question the utility of command-and-control systems, of secrecy, of centralization, and of certain kinds of intellectual property. It would be almost disingenuous not to admit that it suggests (or at least harmonizes well with) a broadly libertarian view of the proper relationship between individuals and institutions.