14. Causes of Conflict
|
14.
|
In conflicts over open-source software we can identify four major issues:
| |
- Who gets to make binding decisions about a projectıĵ
- Who gets credit or blame for whatıĵ
- How to reduce duplication of effort and prevent rogue versions
from complicating bug trackingıĵ
- What is the Right Thing, technically speakingıĵ
| |
If we take a second look at the ``What is the Right Thing'' issue,
however, it tends to vanish. For any such question, either there is
an objective way to decide it accepted by all parties or there isn't.
If there is, game over and everybody wins. If there isn't, it reduces
to ``who decidesıĵ''.
| |
Accordingly, the three problems a conflict-resolution theory has to
resolve about a project are (A) where the buck stops on design
decisions, (B) how to decide which contributors are credited and how,
and (C) how to keep a project group and product from fissioning into
multiple branches.
| |
The role of ownership customs in resolving issues (A) and (C) is
clear. Custom affirms that the owners of the project make the binding
decisions. We have previously observed that custom also exerts heavy
pressure against dilution of ownership by forking.
| |
It's instructive to notice that these customs make sense even if one
forgets the reputation game and examines them from within a pure
`craftmanship' model of the hacker culture. In this view these
customs have less to do with the dilution of reputation incentives
than with protecting a craftsman's right to execute his vision in his
chosen way.
| |
The craftsmanship model is not, however, sufficient to explain hacker
customs about issue (B), who gets credit for what (because a pure
craftsman, one unconcerned with the reputation game, would have no
motive to care). To analyze these, we need to take the Lockean theory
one step further and examine conflicts and the operation of property
rights within projects as well as between them.
| |