9. Ownership Rights and Reputation Incentives
We are now in a position to pull together the previous analyses into a
coherent account of hacker ownership customs. We understand the
yield from homesteading the noosphere now; it is peer repute in the
gift culture of hackers, with all the secondary gains and side-effects
that implies.
From this understanding, we can analyze the Lockean property customs
of hackerdom as a means of maximizing reputation incentives;
of ensuring that peer credit goes where it is due and does not go
where it is not due.
The three taboos we observed above make perfect sense under this analysis.
One's reputation can suffer unfairly if someone else misappropriates
or mangles one's work; these taboos (and related customs) attempt to
prevent this from happening.
-
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. (This would generally
be too confusing or difficult to be practical.)
-
Distributing rogue patches (or, much worse, rogue binaries) exposes
the owners to an unfair reputation risk. Even if the official code
is perfect, the owners will catch flak from bugs in the patches (but
see ).
-
Surreptitiously filing someone's name off a project is, in cultural
context, one of the ultimate crimes. It steals the victim's gift
to be presented as the thief's own.
All three of these taboo behaviors inflict global harm on the
open-source community as well as local harm on the victim(s).
Implicitly they damage the entire community by decreasing each
potential contributor's perceived likelihood that gift/productive
behavior will be rewarded.
It's important to note that there are alternate candidate explanations
for two of these three taboos.
First, hackers often explain their antipathy to forking projects by
bemoaning the wasteful duplication of work it would imply as the child
products evolved in more-or-less parallel into the future. They may
also observe that forking tends to split the co-developer community,
leaving both child projects with fewer brains to work with than the
parent.
A respondent has pointed out that it is unusual for more than one
offspring of a fork to survive with significant `market share' into
the long term. This strengthens the incentives for all parties to
cooperate and avoid forking, because it's hard to know in advance
who will be on the losing side and see a lot of their work either
disappear entirely or languish in obscurity.
Dislike of rogue patches is often explained by observing that they can
complicate bug-tracking enormously, and inflict work on maintainers
who have quite enough to do catching their own mistakes.
There is considerable truth to these explanations, and they certainly
do their bit to reinforce the Lockean logic of ownership. But while
intellectually attractive, they fail to explain why so much emotion
and territoriality gets displayed on the infrequent occasions that the
taboos get bent or broken -- not just by the injured parties, but by
bystanders and observers who often react quite harshly. Cold-blooded
concerns about duplication of work and maintainance hassles simply do
not sufficiently explain the observed behavior.
Then, too, there is the third taboo. It's hard to see how anything
but the reputation-game analysis can explain this. The fact that this
taboo is seldom analyzed much more deeply than ``It wouldn't be fair''
is revealing in its own way, as we shall see in the next section.