Eric Raymond, Part II: “Homesteading the Noosphere”

Part II (Part I is here)

In Raymond’s essay, “Homesteading the Noosphere,” he traces out the unspoken rules of the open-source community, likening them to the Anglo-American common-law theory of land tenure, positing a discrepancy between the legal and sociological foundations of the culture. In doing so, he is working both as an anthropologist and as PR representative: he wishes to distance the open-source movement as a whole from the anti-capitalist stance implied by the legal structure of its licenses.

To develop his argument, Raymond invokes the concept of the “noosphere.” This is “the territory of ideas, the space of all possible thoughts.” (78) He conceives it as a resource, the raw material floating out there in software development land. The licenses that open-source software is published under, which forbids anyone from restricting how it’s used or distributed, implies the non-ownership of ideas. After all, anyone is free to do whatever she wants with the software, and thus no one controls access, and no money is exchanged between users and developers; there are no legal owners. In practice, however, asserts Raymond, there are owners of open-source software projects. The noosphere is not anarchic; it is a commons that is homesteaded.

Raymond claims that the noosphere works roughly according to John Locke’s theory of land tenure, whereby settlers can “claim” sections of land merely by occupying it and improving it. Once so claimed, land only passes hands when it is gifted, inherited, or abandoned by the original homesteaders. In this last case, anyone is free to move into the abandoned land, and can claim ownership if they work to improve it in some material way. This is how open-source projects work: there is always a project owner, defined as the person who is recognized by the community as controlling the distribution of modifiable copies. That is, ownership is defined in relation to community expectations; there is nothing legally preventing other programmers from taking a piece of open-source software and releasing their own versions of it (as opposed to submitting their improvements back to the original owner); however, this practice, known as forking, almost never occurs. Thus in practice, the hacker community respects ownership of a project. Only when serious disputes arise over the direction of a piece of software, and defensible reasons are published publicly and legitimated by a large portion of the user and developer base, will a program be forked. This is heavily frowned upon because it splits the developer base between two different versions of the software, thus leading to a great deal of duplicated effort in the future (though Raymond notes that when projects are forked, after a brief period of time one fork usually dominates and the other is disbanded). By contrast, “pseudo-forking” occurs regularly: two or more superficially different variants of a program are developed concurrently, with large portions of the code for each merged together periodically, so that each pseudo-fork benefits from the other(s). This sort of development is a triumph for open-source software (it rarely occurs in closed-source projects), as it leads to greater variety while maintaining high efficiency and cohesive community at the same time. Examples include the various “distributions” of Linux and specialized versions of such programs as Firefox and GIMP (a powerful Photoshop-like image manipulation program).

The reason that the noosphere functions so well as a commons is that the hacking community is fundamentally based upon a gift economy. The raw materials are abundant: disk space, network bandwidth, and computing power. The yield from the noosphere for hackers is reputation: their work only has meaning within the community. Just as no one would follow an inappropriately forked project, few hackers would code if they weren’t rewarded by reputation rewards from the community. They want their work to be visible, to be seen, understood, used, and appreciated by others. Thus hackers play by the community rules. By the same token, Raymond notes, you don’t become a hacker by calling yourself a hacker; you become a hacker when other members of the community deem you as such, which occurs when you contribute gifts—in the form of code—to the community. This is what keeps open-source projects going. Hackers are acting in their own self-interest, by simultaneously partaking in activities they love and maximizing their own reputation incentives. Likewise, because the community depends upon credit being allocated where it’s due, the entire community reinforces behavior that plays by the rules.

Raymond believes that the software gift economy is the key to open-source efficiency. Stated simply, people are more motivated when they work for intrinsic rather than extrinsic reward. Raymond sites one study that reaches the same conclusion from the other direction: performance bonuses for salaried workers only motivate those accomplishing simple tasks (such as flipping burgers or digging ditches); for more complex work they can actually demotivate. Why? Because monetary rewards reposition the worker’s task as a means instead of an end. In the open-source gift economy, the work is always an end in itself, and the result is highly motivated coders!

In Part III, I will cover Raymond’s discussion of open-source business models and the role that his own work has played in shifting many commercial software companies to an open-source model.

The book is available on Amazon.

An online version of the essays collected in the book are available from the author’s site, here.


Tagged with:

1 Comment

  1. […] Part II, I’ll look at the sociological and legal elements of open-source project […]

Leave a Reply

Comments are closed.