Open Source - Ownership

Discussion

Eric Raymond on legimate ownership of open source projects

Eric Raymond:

"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 had 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 significant that in the case of major projects, such transfers of control are generally announced with great 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. The third way of acquiring 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 group dedicated to the application area) that the project appears to be orphaned, and that you are considering taking responsibility for it." (http://gnu.kldp.org/cb/homesteading/homesteading-4.html)

Manuel DeLanda

His comments on the above:

" Raymond compares these three ways of legitimizing leadership to the three ways in which land tenure may become legitimate in the tradition of Anglo-American common law, as systematized by John Locke (homesteading and laboring a piece of previously unowned land; title transfers; and the claiming of abandoned land). Although I am far from knowledgeable in the history of law, Locke's ideas seem to me to bear more on the question of the legitimacy, not the nature, of private ownership. But at any rate, it is clear that open-source leaders can only be said to own their projects in a metaphorical sense, and that the real issue is the source of legitimacy for their decisions.

Now, two challenges to that legitimacy may be mounted: the first is to fork the project, that is, to install a new leader who will now direct or maintain an alternative version of the program under development; the second is to add pieces of code which have not been approved by the project leader (these are known as "rogue patches"). Although forking is not always necessarily a bad thing (the BSD project has forked at least three times, but each variant has micro-specialized on a particular aspect, such as security or portability), I already suggested that it does have consequences on the developers of applications, who need to be reassured that an operating system will become a stable standard. Rogue patching, on the other hand, directly affects the central pragmatic goal of the open-source movement, the creation of programs that are robust to crashes, because without careful addition of patches tested and approved by a leader, there is no guarantee that a new piece of code will not introduce bugs, and that these will go unnoticed by other community members.

Raymond analyses the community norms which prevent forking and rogue patching from being widespread phenomena (hence endangering the integrity of the community) using the other component of the problem of intellectual property: incentive. While monetary incentives to produce do not seem to be a problem for self-motivated hackers, incentives not to destroy the legitimacy of a project are needed. These may be understood, he argues, if we picture these communities as involved in an economy of reputation. That is, as if what is being "exchanged" in these communities was not monetary values but less-tangible values such as peer-recognition of one's skills and contributions." (http://www.cddc.vt.edu/host/delanda/pages/opensource.htm)