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.