4. Ownership and Open Source
What does `ownership' mean when property is infinitely reduplicable,
highly malleable, and the surrounding culture has neither coercive
power relationships nor material scarcity economicsıĵ
Actually, in the case of the open-source culture this is an easy
question to answer. The owner(s) of a software project are those
who have the exclusive right, recognized by the community at large,
to re-distribute modified versions.
(In discussing `ownership' in this section I will use the singular, as
though all projects are owned by some one person. It should be
understood, however, that projects may be owned by groups. We shall
examine the internal dynamics of such groups later in this paper.)
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 .
That public redistribution is the fundamental issue is easy
to establish. Custom encourages people to patch software for personal
use when necessary. Custom is indifferent to people who redistribute
modified versions within a closed user or development group. It is
only when modifications are posted to the open-source community in
general, to compete with the original, that ownership becomes an
issue.
There are, in general, three ways to acquire ownership of an
open-source project. One, the most obvious, is to found the project.
When a project has only one maintainer since its inception and
the maintainer is still active, custom does not even permit a
question as to who owns the project.
The second way is to have ownership of the project handed to you by
the previous owner (this is sometimes known as `passing the baton').
It is well understood in the community that project owners have a duty
to pass projects to competent successors when they are no longer
willing or able to invest needed time in development or maintenance
work.
It is significant that in the case of major projects, such transfers
of control are generally announced with some fanfare. While it is
unheard of for the open-source community at large to actually
interfere in the owner's choice of succession, customary practice
clearly incorporates a premise that public legitimacy is important.
For minor projects, it is generally sufficient for a change history
included with the project distribution to note the change of
ownership. The clear presumption is that if the former owner has not
in fact voluntarily transferred control, he or she may reassert
control with community backing by objecting publicly within a
reasonable period of time.
The third way to acquire ownership of a project is to observe that it
needs work and the owner has disappeared or lost interest. If you
want to do this, it is your responsibility to make the effort to find
the owner. If you don't succeed, then you may announce in a relevant
place (such as a Usenet newsgroup dedicated to the application area)
that the project appears to be orphaned, and that you are considering
taking responsibility for it.
Custom demands that you allow some time to pass before following up
with an announcement that you have declared yourself the new owner.
In this interval, if someone else announces that they have been
actually working on the project, their claim trumps yours. It is
considered good form to give public notice of your intentions more
than once. More points for good form if you announce in many relevant
forums (related newsgroups, mailing lists); and still more if you show
patience in waiting for replies. In general, the more visible effort
you make to allow the previous owner or other claimants to respond,
the better your claim if no response is forthcoming.
If you have gone through this process in sight of the project's user
community, and there are no objections, then you may claim ownership
of the orphaned project and so note in its history file. This,
however, is less secure than being passed the baton, and you cannot
expect to be considered fully legitimate until you have made
substantial improvements in the sight of the user community.
I have observed these customs in action for twenty years, going back
to the pre-FSF ancient history of open-source software. They have
several very interesting features. One of the most interesting is
that most hackers have followed them without being fully aware of
doing so. Indeed, the above may be the first conscious and reasonably
complete summary ever to have been written down.
Another is that, for unconscious customs, they have been followed with
remarkable (even astonishing) consistency. I have observed the
evolution of literally hundreds of open-source projects, and I can
still count the number of significant violations I have observed or
heard about on my fingers.
Yet a third interesting feature is that as these customs have evolved
over time, they have done so in a consistent direction. That
direction has been to encourage more public accountability, more
public notice, and more care about preserving the credits and change
histories of projects in ways which (among other things) establish
the legitimacy of the present owners.
These features suggest that the customs are not accidental, but are
products of some kind of implicit agenda or generative pattern in the
open-source culture that is utterly fundamental to the way it operates.
An early respondent pointed out that contrasting the Internet hacker
culture with the cracker/pirate culture (the ``warez d00dz'' centered
around game-cracking and pirate bulletin-board systems) illuminates
the generative patterns of both rather well. We'll return to the
d00dz for contrast later in the paper.