In conflicts over open-source software we can identify four major issues:
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.