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 that 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. Projects tend to get started to fill functional gaps near the frontier (see [NO] for further discussion of the lure of novelty).
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 no competitor has gotten much beyond the one-man project stage 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 operating systems 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 third millenium begins, 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 was 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 rigueur in commercial applications for the last decade. Another is the amount of buzz surrounding application-toolkit projects like KDE and GNOME.
A respondent to this essay has pointed out that the homesteading analogy also explains why hackers react with such visceral anger to Microsoft's ``embrace and extend'' policy of complexifying and then closing up Internet protocols. The hacker culture can coexist with most closed software; the existence of Adobe Photoshop, for example, does not make the territory near GIMP (its open-source equivalent) significantly less attractive. But when Microsoft succeeds at de-commoditizing [HD] a protocol so that only Microsoft's own programmers can write software for it, they do not merely harm customers by extending their monopoly; they also reduce the amount and quality of noosphere available for hackers to homestead and cultivate. No wonder hackers often refer to Microsoft's strategy as ``protocol pollution''; they are reacting exactly like farmers watching someone poison the river they water their crops with!
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 [KN]. 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 be delivered only by those already well inside the culture.