12. Global Implications of the Reputation-Game Model
|
12.
|
The reputation-game analysis has some more implications that may not
be immediately obvious. Many of these derive from the fact that one
gains more prestige from founding a successful project than from
cooperating in an existing one. One also gains more from projects
which are strikingly innovative, as opposed to being `me, too'
incremental improvements on software that already exists. On the
other hand, software that nobody but the author understands or has a
need for is a non-starter in the reputation game, and it's often
easier to attract good notice by contributing to an existing project
than it is to get people to notice a new one. Finally, it's much
harder to compete with an already successful project than it is to
fill an empty niche.
| |
Thus, there's an optimum distance from one's neighbors (the most
similar competing projects). Too close and one's product will be a
``me, too!'' of limited value, a poor gift (one would be better
off contributing to an existing project). Too far away, and nobody
will be able to use, understand, or perceive the relevance of one's
effort (again, a poor gift). This creates a pattern of homesteading in
the noosphere that rather resembles that of settlers spreading into a
physical frontier -- not random, but like a diffusion-limited fractal
wave. Projects tend to get started to fill functional gaps near the
frontier.
| |
Some very successful projects become `category killers'; nobody
wants to homestead anywhere near them because competing against the
established base for the attention of hackers would be too hard.
People who might otherwise found their own distinct efforts end up,
instead, adding extensions for these big, successful projects.
The classic `category killer' example is GNU Emacs; its variants fill the
ecological niche for a fully-programmable editor so completely that
nobody has even attempted a truly different design since the early
1980s. Instead, people write Emacs modes.
| |
Globally, these two tendencies (gap-filling and category-killers)
have driven a broadly predictable trend in project starts over time.
In the 1970s most of the open source that existed was toys and demos.
In the 1980s the push was in development and Internet tools. In
the 1990s the action shifted to operating systems. In each case,
a new and more difficult level of problems was attacked when the
possibilities of the previous one had been nearly exhausted.
| |
This trend has interesting implications for the near future. In early
1998, Linux looks very much like a category-killer for the niche
`open-source operating systems' -- people who might otherwise 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.
| |