The trivial case is that in which the project has a single
owner/maintainer. In that case there is no possible conflict. The
owner makes all decisions and collects all credit and blame. The only
possible conflicts are over succession issues -- who gets to be the
new owner if the old one disappears or loses interest. The community
also has an interest, under issue (C), in preventing forking. These
interests are expressed by a cultural norm that an owner/maintainer
should publicly hand title to someone if he or she can no longer
maintain the project.

The simplest non-trivial case is when a project has multiple
co-maintainers working under a single `benevolent dictator' who owns
the project. Custom favors this mode for group projects; it has been
shown to work on projects as large as the Linux kernel or Emacs, and
solves the ``who decides'' problem in a way that is not obviously worse
than any of the alternatives.

Typically, a benevolent-dictator organization evolves from an
owner-maintainer organization as the founder attracts contributors.
Even if the owner stays dictator, it introduces a new level of possible
disputes over who gets credited for what parts of the project.

In this situation, custom places an obligation on the owner/dictator
to credit contributors fairly (through, for example, appropriate
mentions in README or history files). In terms of the Lockean property
model, this means that by contributing to a project you earn
part of its reputation return (positive or negative).

Pursuing this logic, we see that a `benevolent dictator' does not in
fact own his entire project unqualifiedly. Though he has the right
to make binding decisions, he in effect trades away shares of the
total reputation return in exchange for others' work. The analogy with
sharecropping on a farm is almost irresistible, except that a
contributor's name stays in the credits and continues to `earn' to
some degree even after that contributor is no longer active.

As benevolent-dictator projects add more participants, they tend to
develop two tiers of contributors; ordinary contributors and
co-developers. A typical path to becoming a co-developer is taking
responsibility for a major subsystem of the project. Another is to
take the role of `lord high fixer', characterizing and fixing many
bugs. In this way or others, co-developers are the contributors who
make a substantial and continuing investment of time in the project.

The subsystem-owner role is particularly important for our analysis
and deserves further examination. Hackers like to say that `authority
follows responsibility'. A co-developer who accepts maintainance
responsibility for a given subsystem generally gets to control both
the implementation of that subsystem and its interfaces with the rest
of the project, subject only to correction by the project leader
(acting as architect). We observe that this rule effectively creates
enclosed properties on the Lockean model within a project, and has
exactly the same conflict-prevention role as other property
boundaries.

By custom, the `dictator' or project leader in a project with
co-developers is expected to consult with those co-developers on key
decisions. This is especially so if the decision concerns a subsystem
which a co-developer `owns' (that is, has invested time in and taken
responsibility for). A wise leader, recognizing the function of the
project's internal property boundaries, will not lightly interfere
with or reverse decisions made by subsystem owners.

Some very large projects discard the `benevolent dictator' model
entirely. One way to do this is turn the co-developers into a voting
committee (as with Apache). Another is rotating dictatorship, in
which control is occasionally passed from one member to another within
a circle of senior co-developers (the Perl developers organize
themselves this way).

Such complicated arrangements are widely considered unstable and
difficult. Clearly this perceived difficulty is largely a function of
the known hazards of design-by-committee, and of committees
themselves; these are problems the hacker culture consciously
understands. However, I think some of the visceral discomfort hackers
feel about committee or rotating-chair organizations is because
they're hard to fit into the unconscious Lockean model hackers use for
reasoning about the simpler cases. It's problematic, in these complex
organizations, to do an accounting of either ownership in the sense of
control or ownership of reputation returns. It's hard to see where
the internal boundaries are, and thus hard to avoid conflict unless
the group enjoys an exceptionally high level of harmony and trust.