More on this book
Community
Kindle Notes & Highlights
Read between
November 29, 2021 - April 4, 2022
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.
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.
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.”
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.
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.
What does “ownership” mean when property is infinitely reduplicable, highly malleable, and the surrounding culture has neither coercive power relationships nor material scarcity economics?
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.
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.
Gift cultures are adaptations not to scarcity but to abundance.
Abundance makes command relationships difficult to sustain and exchange relationships an almost pointless game.
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.
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.
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.
It is fashionable in some circles to describe human property as an arbitrary social convention, but this is dead wrong.
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.
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.
Nevertheless, their results do suggest that some kinds of scarcity-economics rewards actually decrease the productivity of creative workers such as programmers.
“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.
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!
I then continue to develop a qualitative theory of when it is economically rational for software to be closed.
Buckminster Fuller gave us the concept of “ephemeralization”,
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.
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.
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.
but we’ll see shortly that there is empirical evidence that approximately 95% of code is still written in-house.
It includes technical-specialist code like device drivers. Almost nobody makes money selling device drivers,
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
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.
As a thought experiment, let us suppose that the Internet came equipped with the theoretically ideal micropayment system — secure, universally accessible, zero-overhead.
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?
F. A. Hayek’s “calculation problem”
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.
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.
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.
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.
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.
Twenty years of repeatedly watching brilliant ideas, promising starts, and superior technologies crushed by slick marketing.
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.
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.
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.
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.