BBS水木清华站∶精华区

发信人: reden (鱼 ~ 梦娜丽莎的微笑 流星的故事), 信区: Linux 
标  题: Homesteading the Noosphere -- by Eric S. Raymond 
发信站: BBS 水木清华站 (Mon Dec 21 21:27:16 1998) 
 
Homesteading the Noosphere 
 
by Eric S. Raymond 
 
April 1998  
 
 
After observing a contradiction between the `official' ideology defined by open-source licenses 
and the actual behavior of hackers, we examine the actual customs which regulate the ownership 
and control of open-source software. We discover that they imply an underlying theory of 
property rights homologous to the Lockean theory of land tenure. We relate that to an analysis 
of the hacker culture as a `gift culture' in which participants compete for prestige by giving 
time, energy, and creativity away. We then examine the implications of this analysis for 
conflict resolution in the culture, and develop some prescriptive implications.   
 
1. 矛盾的现象 
 
任何人观察忙碌, 巨大生产力的网际网路开放原始码软体世界一阵子, 一定都会注意到一个很有趣的矛盾, 
开放原始码玩家们, 所说及所做之间的矛盾 -- 即开放原始码官方的意识形态及其实际的实践.  
 
文化是善於应变的机器. 开放原始码文化是对应到一系统可指认出的驱力及压力. 一如往常, 文化对环境的 
适应力显示出清析的意识形态, 及隐含地, 潜意识或半意识的意识形态. 而, 并非不寻常地, 半意识的适应 
力扮演与清析的意识形态同样重要的地位.  
 
在本文, 我们将深掘此一矛盾的根, 并用来发掘这些驱力及压力. 我们将演绎一些关於玩家文化习俗的有趣 
的事.  并透过建议一些方式, 以升华这一玩家文化的知识层次.  
 
方括号记号请见参考文件及文末释义.  
 
 
2. 玩家意识形态的多样性 
 
网际网路开放原始码文化的意识形态(玩家们说他们所相信的)本身是相当复杂的话题. 所有成员都同意开放 
原始码(也就是, 软体可以免费散播及能够毫无困难地演化及修改成适合自己所需)是件好事, 并值得投入大 
量群体的力量. 这样的一致很有效地定义了文化的成员资格.  不过, 有许多理由值得我们考量, 尤其是许多 
个体及次文化信念的多样化.  
 
一种是狂热; whether open source development is regarded merely as a convenient means to an end 
(好的工具, 有趣的玩具, 及有意思的游戏) or as an end in itself.  
 
狂热之辈会说``自由软体是我的生命! 我生命的意义在於生产有用, 优美程式及资讯资源, 然後送给人家.'' 
中等热诚者会说``开放原始码是好东西, 我愿意花下大量时间协助''. 低度热诚之流则会说``对, 开放原始 
码有时还可以. 我玩弄它, 并且尊重建造它的人们''.  
 
另一种是对商业软体或企图统治商业软体市场的企业的敌意.  
 
非常反对商业的人会说``商业软体是偷窃及聚财. 我写自由软体来结束这个恶魔.'' 中等反商业的人会说`` 
商业软体一般还好啦.  程式设计师需要有收入, 但是那些推行劣质产品并且胡搞一通的则是恶魔'' 不反商 
业的人会说``商业软体还好啦.  我用或写开放原始码软体是因为我比较喜欢它''.  
 
这样的态度组合表现出九种开放原始码次文化. 值得将这分别指出的原因是它们暗示着不同的议题, 及不同 
的适应, 及合作的行为.  
 
从历史上来看, 最引人注目及最有组织的玩家文化是非常狂热及非常反商业的. 由Richard M. 
Stallman(RMS)所设立的自由软体基金会, 自1980年代早期, 大力支持着开放原始码的发展, 包含了像Emacs 
及GCC到目前为止, 在网际网路开放原始码世界依然是最基本的, 而且看来依然会在未来继续下去.  
 
For many years the FSF was the single most important focus of open-source hacking, producing a 
huge number of tools still critical to the culture. The FSF was also long the only sponsor of 
open source with an institutional identity visible to outside observers of the hacker culture. 
They effectively defined the term `free software', deliberately giving it a confrontational 
weight (which the newer label ` open source' just as deliberately avoids).  
 
Thus, perceptions of the hacker culture from both within and outside it tended to identify the 
culture with the FSF's zealous attitude and perceived anticommercial aims (RMS himself denies 
he is anticommercial, but his program has been so read by most people, including many of his 
most vocal partisans). The FSF's vigorous and explicit drive to ``Stamp Out Software 
Hoarding!'' became the closest thing to a hacker ideology, and RMS the closest thing to a 
leader of the hacker culture.  
 
The FSF's license terms, the ``General Public Licence'' (GPL), expresses the FSF's attitudes. 
It is very widely used in the open-source world. North Carolina's Sunsite is the largest and 
most popular software archive in the Linux world. In July 1997 about half the Sunsite software 
packages with explicit license terms used GPL.  
 
But the FSF was never the only game in town. There was always a quieter, less confrontational 
and more market-friendly strain in the hacker culture. The pragmatists were loyal not so much 
to an ideology as to a group of engineering traditions founded on early open-source efforts 
which predated the FSF. These traditions included, most importantly, the intertwined technical 
cultures of Unix and the pre-commercial Internet.  
 
The typical pragmatist attitude is only moderately anticommercial, and its major grievance 
against the corporate world is not `hoarding' per sboth rather well. We'll return to the d00dz for contrast later in the paper.  
 
 
 
 
5. Locke and Land Title 
 
To understand this generative pattern, it helps to notice a historical analogy for these customs that is far outside 
the domain of hackers' usual concerns. As students of legal history and political philosophy may recognize, the 
theory of property they imply is virtually identical to the Anglo-American common-law theory of land tenure!  
 
In this theory, there are three ways to acquire ownership of land.  
 
On a frontier, where land exists that has never had an owner, one can acquire ownership by homesteading, 
mixing one's labor with the unowned land, fencing it, and defending one's title.  
 
The usual means of transfer in settled areas is transfer of title, that is receiving the deed from the previous 
owner. In this theory, the concept of `chain of title' is important. The ideal proof of ownership is a chain of deeds 
and transfers extending back to when the land was originally homesteaded.  
 
Finally, the common-law theory recognizes that land title may be lost or abandoned (for example, if the owner 
dies without heirs, or the records needed to establish chain of title to vacant land are gone). A piece of land that 
has become derelict in this way may be claimed by adverse possession -- one moves in, improves it, and 
defends title as if homesteading.  
 
This theory, like hacker customs, evolved organically in a context where central authority was weak or 
nonexistent. It developed over a period of a thousand years from Norse and Germanic tribal law. Because it 
was systematized and rationalized in the early modern era by the English political philosopher John Locke, it is 
sometimes referred to as the `Lockean' theory of property.  
 
Logically similar theories have tended to evolve wherever property has high economic or survival value and no 
single authority is powerful enough to force central allocation of scarce goods. This is true even in the 
hunter-gatherer cultures that are sometimes romantically thought to have no concept of `property'. For example, 
in the traditions of the !Kung San bushmen of the Kalahari Desert, there is no ownership of hunting grounds. But 
there is ownership of water-holes and springs under a theory recognizably akin to Locke's.  
 
The !Kung mand relationships difficult to sustain and exchange relationships an almost pointless 
game. In gift cultures, social status is determined not by what you control but by what you give away.  
 
Thus the Kwakiutl chieftain's potlach party. Thus the multi-millionaire's elaborate and usually public acts of 
philanthropy. And thus the hacker's long hours of effort to produce high-quality open source.  
 
For examined in this way, it is quite clear that the society of open-source hackers is in fact a gift culture. Within 
it, there is no serious shortage of the `survival necessities' -- disk space, network bandwidth, computing power. 
Software is freely shared. This abundance creates a situation in which the only available measure of 
competitive success is reputation among one's peers.  
 
This observation is not in itself entirely sufficient to explain the observed features of hacker culture, however. 
The cracker d00dz have a gift culture which thrives in the same (electronic) media as that of the hackers, but 
their behavior is very different. The group mentality in their culture is much stronger and more exclusive than 
among hackers. They hoard secrets rather than sharing them; one is much more likely to find cracker groups 
distributing sourceless executables that crack software than tips that give away how they did it.  
 
What this shows, in case it wasn't obvious, is that there is more than one way to run a gift culture. History and 
values matter. I have summarized the history of the hacker culture elsewhere in [HH]; the ways in which it 
shaped present behavior are not mysterious. Hackers have defined their culture by set of choices about the 
form which their competition will take. It is that form which we will examine in the remainder of this paper.  
 
7. The Joy of Hacking 
 
In making this `reputation game' analysis, by the way, I do not mean to devalue or ignore the pure artistic 
satisfaction of designing beautiful software and making it work. We all experience this kind of satisfaction and 
thrive on it. People for whom it is not a significant motivation never become hackers in the first place, just as 
people who don't love music never become composers.  
 
So perhaps we should consider another model of hacker behavior in which the pure joy of craftsmanship is the 
primary motivation. This `craftsmanship' model would have to explain hacker custom as a way of maximizing 
both the opportunities for craftsmanship and the quality of the results. Does this conflict with or suggest different 
results than the `reputation game' model?  
 
Not really. In examining the `craftsmanship' model, we come back to the same problems that constrain 
hackerdom to operate like a gift culture. How can one maximize quality if there is no metric for quality? If 
scarcity economics doesn't operate, what metrics are available besides peer evaluation? It appears that any 
craftsmanship culture ultimately must structure itself through a reputation game -- and, in fact, we can observe 
exactly this dynamic in many historical craftsmanship cultures from the medievalerwise write competing 
OSs are now writing Linux device drivers and extensions instead. And most of the lower-level tools the culture 
ever imagined having as open-source already exist. What's left?  
 
Applications. As the year 2000 approaches, it seems safe to predict that open-source development effort will 
increasingly shift towards the last virgin territory -- programs for non-techies. A clear early indicator is the 
development of GIMP, the Photoshop-like image workshop that is open source's first major application with the 
kind of end-user-friendly GUI interface considered de rigeur in commercial applications for the last decade. 
Another is the amount of buzz surrounding application-toolkit projects like KDE and GNOME.  
 
Finally, the reputation-game analysis explains the oft-cited dictum that you do not become a hacker by calling 
yourself a hacker -- you become a hacker when other hackers call you a hacker. A `hacker', considered in this 
light, is somebody who has shown (by contributing gifts) that he or she both has technical ability and 
understands how the reputation game works. This judgement is mostly one of awareness and acculturation, 
and can only be delivered by those already well inside the culture.  
 
 
13. Noospheric Property and the Ethology of Territory 
 
To understand the consequences of property customs, it will help us to look at them from yet another angle; that 
of animal ethology, specifically the ethology of territory.  
 
Property is an abstraction of animal territoriality, which evolved as a way of reducing intra-species violence. By 
marking his bounds, and respecting the bounds of others, a wolf diminishes his chances of being in a fight 
which could weaken or kill him and make him less reproductively successful.  
 
Similarly, the function of property in human societies is to prevent inter-human conflict by setting bounds that 
clearly separate peaceful behavior from aggression. It is sometimes fashionable to describe human property 
as an arbitrary social convention, but this is dead wrong. Anybody who has ever owned a dog who barked 
when strangers came near its owner's property has experienced the essential continuity between animal 
territoriality and human property. Our domesticated cousins of the wolf are instinctively smarter about this than a 
good many human political theorists.  
 
Claiming property (like marking territory) is a performative act, a way of declaring what boundaries will be 
defended. Community support of property claims is a way to minimize friction and maximize cooperative 
behavior. These things remain true even when the ``property claim'' is much more abstract than a fence or a 
dog's bark, even when it's just the statement of the project maintainer's name in a README file. It's still an 
abstraction of territoriality, and (like other forms of property) our instinct-founded models of property are 
territorial ones evolved to assist conflict resolution.  
 
This ethological analysis at first seems very abstract and difficult to relate to actual hacker behavior. But it has 
some important consequences. One is in explaining the popularity of World Wide Web sites, and especially 
why open-source projects with websites seem so much more `real' and substantial than those without them.  
 
Considered objectively, this seems hard to explain. Compared to the effort involved in originating and 
maintaining even a small program, a web page is easy, so it's hard to consider a web page evidence of 
substance or unusual effort.  
 
Nor are the functional characteristics of the Web itself sufficient explanation. The communication functions of a 
web page can be as well or better served by a combination of an FTP site, a mailing list, and Usenet postings. 
In fact it's quite unusual for a project's routine communications to be done over the Web rather than via a 
mailing list or newsgroup. Why, then, the popularity of Web sites as project homes?  
 
The metaphor implicit in the term `home page' provides an important clue. While founding an open-source 
project is a territorial claim in the noosphere (and customarily recognized as such) it is not a terribly compelling 
one on the psychological level. Software, after all, has no natural location and is instantly reduplicable. It's 
assimilable to our instinctive notions of `territory' and `property', but only after some effort.  
 
A project home page concretizes an abstract homesteading in the space of possible programs by expressing 
it as `home' territory in the more spatially-organized realm of the World Wide Web. Descending from the 
noosphere to `cyberspace' doesn't get us all the way to the real world of fences and barking dogs yet, but it 
does hook the abstract property claim more securely to our instinctive wiring about territory. And this is why 
projects with web pages seem more `real'.  
 
This ethological analysis also encourages us to look more closely at mechanisms for handling conflict in the 
open-source culture. It leads us to expect that, in addition to maximizing reputation incentives, ownership 
customs should also have a role in preventing and resolving conflicts.  
 
14. Causes of Conflict 
 
In conflicts over open-source software we can identify four major issues:  
 
     Who gets to make binding decisions about a project?  
     Who gets credit or blame for what?  
     How to reduce duplication of effort and prevent rogue versions from complicating bug tracking?  
     What is the Right Thing, technically speaking?  
 
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.  
 
15. Project Structures and Ownership 
 
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.  
 
16. Conflict and Conflict Resolution 
 
We've seen that within projects, an increasing complexity of roles is expressed by a distribution of design 
authority and partial property rights. While this is an efficient way to distribute incentives, it also dilutes the 
authority of the project leader -- most importantly, it dilutes the leader's authority to squash potential conflicts.  
 
While technical arguments over design might seem the most obvious risk for internecine conflict, they are 
seldom a serious cause of strife. These are usually relatively easily resolved by the territorial rule that authority 
follows responsibility.  
 
Another way of resolving conflicts is by seniority -- if two contributors or groups of contributors have a dispute, 
and the dispute cannot be resolved objectively, and neither owns the territory of the dispute, the side that has 
put the most work into the project as a whole (that is, the side with the most property rights in the whole project) 
wins.  
 
These rules generally suffice to resolve most project disputes. When they do not, fiat of the project leader 
usually suffices. Disputes that survive both these filters are rare.  
 
Conflicts do not as a rule become serious unless these two criteria ("authority follows responsibility" and 
"seniority wins") point in different directions, and the authority of the project leader is weak or absent. The most 
obvious case in which this may occur is a succession dispute following the disappearance of the project lead. I 
have been in one fight of this kind. It was ugly, painful, protracted, only resolved when all parties became 
exhausted enough to hand control to an outside person, and I devoutly hope I am never anywhere near anything 
of the kind again.  
 
Ultimately, all of these conflict-resolution mechanisms rest on the wider hacker community's willingness to 
enforce them. The only available enforcement mechanisms are flaming and shunning -- public condemnation of 
those who break custom, and refusal to cooperate with them after they have done so.  
 
17. Acculturation Mechanisms and the Link to Academia 
 
An early version of this paper posed the following research question: How does the community inform and 
instruct its members as to its customs? Are the customs self-evident or self-organising at a semi-conscious 
level, are they taught by example, are they taught by explicit instruction?  
 
Teaching by explicit instruction is clearly rare, if only because few explicit descriptions of the culture's norms 
have existed to be used up to now.  
 
Many norms are taught by example. To cite one very simple case, there is a norm that every software 
distribution should have a file called README or READ.ME that contains first-look instructions for browsing the 
distribution. This convention has been well established since at least the early 1980s, but up to now it has never 
been written down. One derives it from looking at many distributions.  
 
On the other hand, some hacker customs are self-organizing once one has acquired a basic (perhaps 
unconscious) understanding of the reputation game. Most hackers never have to be taught the three taboos I 
listed in Section Three, or at least would claim if asked that they are self-evident rather than transmitted. This 
phenomenon invites closer analysis -- and perhaps we can find its explanation in the process by which hackers 
acquire knowledge about the culture.  
 
Many cultures use hidden clues (more precisely `mysteries' in the religio/mystical sense) as an acculturation 
mechanism. These are secrets which are not revealed to outsiders, but are expected to be discovered or 
deduced by the aspiring newbie. To be accepted inside, one must demonstrate that one both understands the 
mystery and has learned it in a culturally approved way.  
 
The hacker culture makes unusually conscious and extensive use of such clues or tests. We can see this 
process operating at at least three levels:  
 
     Password-like specific mysteries. As one example, there is a USENET newsgroup called 
     alt.sysadmin.recovery that has a very explicit such secret; you cannot post without knowing it, and 
     knowing it is considered evidence you are fit to post. The regulars have a strong taboo against revealing 
     this secret.  
     The requirement of initiation into certain technical mysteries. One must absorb a good deal of technical 
     knowledge before one can give valued gifts (e.g. one must know at least one of the major computer 
     languages). This requirement functions in the large in the way hidden clues do in the small, as a filter for 
     qualities (such as capability for abstract thinking, persistence, and mental flexibility) which are necessary 
     to function in the culture.  
     Social-context mysteries. One becomes involved in the culture through attaching oneself to specific 
     projects. Each project is a live social context of hackers which the would-be contributor has to investigate 
     and understand socially as well as technically in order to function. (Concretely, a common way one does 
     this is by reading the project's Web pages and/or email archives) It is through these project groups that 
     newbies experience the behavioral example of experienced hackers.  
 
In the process of acquiring these mysteries, the would-be hacker picks up contextual knowledge which (after a 
while) does make the three taboos and other customs seem `self-evident'.  
 
One might, incidentally, argue that the structure of the hacker gift culture itself is its own central mystery. One is 
not considered acculturated (concretely: no one will call you a hacker) until one demonstrates a gut-level 
understanding of the reputation game and its implied customs, taboos, and usages. But this is trivial; all 
cultures demand such understanding from would-be joiners. Furthermore the hacker culture evinces no desire 
to have its internal logic and folkways kept secret -- or, at least, nobody has ever flamed me for revealing them!  
 
Respondents to this paper too numerous to list have pointed out that hacker ownership customs seem 
intimately related to (and may derive directly from) the practices of the academic world, especially the scientific 
research commmunity. This research community has similar problems in mining a territory of potentially 
productive ideas, and exhibits very similar adaptive solutions to those problems in the ways it uses peer review 
and reputation.  
 
Since many hackers have had formative exposure to academia (it's common to learn how to hack while in 
college) the extent to which academia shares adaptive patterns with the hacker culture is of more than casual 
interest in understanding how these customs are applied.  
 
Obvious parallels with the hacker `gift culture' as I have characterized it abound in academia. Once a 
researcher achieves tenure, there is no need to worry about survival issues (Indeed, the concept of tenure can 
probably be traced back to an earlier gift culture in which ``natural philosophers'' were primarily wealthy 
gentlemen with time on their hands to devote to research.) In the absence of survival issues reputation 
enhancement becomes the driving goal, which encourages sharing of new ideas and research through journals 
and other media. This makes objective functional sense because scientific research, like the hacker culture, 
relies heavily on the idea of `standing upon the shoulders of giants', and not having to rediscover basic 
principles over and over again.  
 
Some have gone so far as to suggest that hacker customs are merely a reflection of the research community's 
folkways and are actually (for most) acquired there. This probably overstates the case, if only because hacker 
custom seems to be readily aquired by intelligent high-schoolers!  
 
There is a more interesting possibility here. I suspect academia and the hacker culture share adaptive patterns 
not because they're genetically related, but because they've both evolved the one most optimal social 
organization for what they're trying to do, given the laws of nature and and the instinctive wiring of human 
beings. The verdict of history seems to be that free-market capitalism is the globally optimal way to cooperate 
for economic efficiency; perhaps, in a similar way, the reputation-game gift culture is the globally optimal way to 
cooperate for generating (and checking!) high-quality creative work.  
 
This point, if true, is of more than (excuse me) academic interest. It suggests from a slightly different angle one 
of the speculations in The Cathedral And The Bazaar; that, ultimately, the industrial-capitalist mode of software 
production was doomed to be outcompeted from the moment capitalism began to create enough of a wealth 
surplus for many programmers to live in a post-scarcity gift culture.  
 
18. Conclusion: From Custom to Customary Law 
 
We have examined the customs which regulate the ownership and control of open-source software. We have 
seen how they imply an underlying theory of property rights homologous to the Lockean theory of land tenure. 
We have related that to an analysis of the hacker culture as a `gift culture' in which participants compete for 
prestige by giving time, energy, and creativity away. We have examined the implications of this analysis for 
conflict resolution in the culture.  
 
The next logical question to ask is "Why does this matter?" Hackers developed these customs without 
conscious analysis and (up to now) have followed them without conscious analysis. It's not immediately clear 
that conscious analysis has gained us anything practical -- unless, perhaps, we can move from description to 
prescription and deduce ways to improve the functioning of these customs.  
 
We have found a close logical analogy for hacker customs in the theory of land tenure under the 
Anglo-American common-law tradition. Historically [Miller], the European tribal cultures that invented this 
tradition improved their dispute-resolution systems by moving from a system of unarticulated, semi-conscious 
custom to a body of explicit customary law memorized by tribal wisemen -- and eventually written down.  
 
Perhaps, as our population rises and acculturation of all new members becomes more difficult, it is time for the 
hacker culture to do something analogous -- to develop written codes of good practice for resolving the various 
sorts of disputes that can arise in connection with open-source projects, and a tradition of arbitration in which 
senior members of the community may be asked to mediate disputes.  
 
The analysis in this paper suggests the outlines of what such a code might look like, making explicit that which 
was previously implicit. No such codes could be imposed from above; they would have to be voluntarily 
adopted by the founders or owners of individual projects. Nor could they be completely rigid, as the pressures 
on the culture are likely to change over time. Finally, for enforcement of such codes to work, they would have to 
reflect a broad consensus of the hacker tribe.  
 
I have begun work on such a code, tentatively titled the "Malvern Protocol" after the little town where I live. If the 
general analysis in this paper becomes sufficiently widely accepted, I will make the Malvern Protocol publicly 
available as a model code for dispute resolution. Parties interested in critiquing and developing this code, or 
just offering feedback on whether they think it's a good idea or not, are invited to contact me by email.  
 
19. Questions for Further Research 
 
该文化(及我自己)了解到, 不跟着一位仁慈的独裁者的模式是脆弱的. 这样的计划大多都失败了. A few 
become spectacularly successful and important (Perl, Apache, KDE). Nobody really understands 
where the difference lies. (There's a vague sense abroad that each such project is sui generis 
and stands or falls on the group dynamic of its particular members, but is this true or are 
there replicable strategies a group can follow?)  
 
As a matter of observable fact, people who found successful projects gather more prestige than 
people who do arguably equal amounts of work debugging and assisting with successful projects. 
Is this a rational valuation of comparative effort, or is it a second-order effect of the 
unconscious territorial model we have adduced here?  
 
-- 
    白马带著她一步步的回到中原。白马已经老了,只能慢慢的走, 
但终是能回到中原的。江南有杨柳、桃花,有燕子、金鱼…… 
汉人中有的是英俊勇武的少年,倜傥潇洒的少年……但这个美 
丽的姑娘就像古高昌国人那样固执: 
 
    「那都是很好很好的,可是我偏不喜欢。」  
 
※ 来源:·BBS 水木清华站 bbs.net.tsinghua.edu.cn·[FROM: 159.226.21.172] 

BBS水木清华站∶精华区