发信人: reden (鱼 ～ 梦娜丽莎的微笑 流星的故事), 信区: Linux
标 题: Homesteading the Noosphere -- by Eric S. Raymond
发信站: BBS 水木清华站 (Mon Dec 21 21:27:16 1998)
Homesteading the Noosphere
by Eric S. Raymond
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.
任何人观察忙碌, 巨大生产力的网际网路开放原始码软体世界一阵子, 一定都会注意到一个很有趣的矛盾,
开放原始码玩家们, 所说及所做之间的矛盾 -- 即开放原始码官方的意识形态及其实际的实践.
文化是善於应变的机器. 开放原始码文化是对应到一系统可指认出的驱力及压力. 一如往常, 文化对环境的
适应力显示出清析的意识形态, 及隐含地, 潜意识或半意识的意识形态. 而, 并非不寻常地, 半意识的适应
在本文, 我们将深掘此一矛盾的根, 并用来发掘这些驱力及压力. 我们将演绎一些关於玩家文化习俗的有趣
的事. 并透过建议一些方式, 以升华这一玩家文化的知识层次.
原始码(也就是, 软体可以免费散播及能够毫无困难地演化及修改成适合自己所需)是件好事, 并值得投入大
量群体的力量. 这样的一致很有效地定义了文化的成员资格. 不过, 有许多理由值得我们考量, 尤其是许多
一种是狂热; 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
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
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
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
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)
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
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
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: 220.127.116.11]