There are consistent patterns in the way the hacker culture values contributions and returns peer esteem for them. It's not hard to observe the following rules:

1. If it doesn't work as well as I have been led to expect it will, it's no good—no matter how clever and original it is.

Note the phrase `led to expect'. This rule is not a demand for perfection; beta and experimental software is allowed to have bugs. It's a demand that the user be able to accurately estimate risks from the stage of the project and the developers' representations about it.

This rule underlies the fact that open-source software tends to stay in beta for a long time, and not get even a 1.0 version number until the developers are very sure it will not hand out a lot of nasty surprises. In the closed-source world, Version 1.0 means ``Don't touch this if you're prudent.''; in the open-source world it reads something more like ``The developers are willing to bet their reputations on this.''

2. Work that extends the noosphere is better than work that duplicates an existing piece of functional territory.

The naive way to put this would have been: Original work is better than mere duplication of the functions of existing software. But it's not actually quite that simple. Duplicating the functions of existing closed software counts as highly as original work if by doing so you break open a closed protocol or format and make that territory newly available.

Thus, for example, one of the highest-prestige projects in the present open-source world is Samba—the code that allows Unix machines to act as clients or servers for Microsoft's proprietary SMB file-sharing protocol. There is very little creative work to be done here; it's mostly an issue of getting the reverse-engineered details right. Nevertheless, the members of the Samba group are perceived as heroes because they neutralize a Microsoft effort to lock in whole user populations and cordon off a big section of the noosphere.

3. Work that makes it into a major distribution is better than work that doesn't. Work carried in all major distributions is most prestigious.

The major distributions include not just the big Linux distributions like Red Hat, Debian, Caldera, and SuSE., but other collections that are understood to have reputations of their own to maintain and thus implicitly certify quality —like BSD distributions or the Free Software Foundation source collection.

4. Utilization is the sincerest form of flattery—and category killers are better than also-rans.

Trusting the judgment of others is basic to the peer-review process. It's necessary because nobody has time to review all possible alternatives. So work used by lots of people is considered better than work used by a few,

To have done work so good that nobody cares to use the alternatives any more is therefore to have earned huge prestige. The most possible peer esteem comes from having done widely popular, category-killing original work that is carried by all major distributions. People who have pulled this off more than once are half-seriously referred to as `demigods'.

5. Continued devotion to hard, boring work (like debugging, or writing documentation) is more praiseworthy than cherrypicking the fun and easy hacks.

This norm is how the community rewards necessary tasks that hackers would not naturally incline towards. It is to some extent contradicted by:

6. Nontrivial extensions of function are better than low-level patches and debugging.

The way this seems to work is that on a one-shot basis, adding a feature is likely to get more reward than fixing a bug—unless the bug is exceptionally nasty or obscure, such that nailing it is itself a demonstration of unusual skill and cleverness. But when these behaviors are extended over time, a person with a long history of paying attention to and nailing even ordinary bugs may well out-rank someone who has spent a similar amount of effort adding easy features.

A respondent has pointed out that these rules interact in interesting ways and do not necessarily reward highest possible utility all the time. Ask a hacker whether he's likely to become better known for a brand new tool of his own or for extensions to someone else's and the answer ``new tool'' will not be in doubt. But ask about (a) a brand new tool which is only used a few times a day invisibly by the OS but which rapidly becomes a category killer, versus (b) several extensions to an existing tool which are neither especially novel nor category-killers, but are daily used and daily visible to a huge number of users

and you are likely to get some hesitation before the hacker settles on (a). These alternatives are about evenly stacked.

Said respondent gave this question point for me by adding ``Case (a) is fetchmail; case (b) is your many Emacs extensions, like vc.el and gud.el.'' And indeed he is correct; I am more likely to be tagged ``the author of fetchmail'' than ``author of a boatload of Emacs modes'', even though the latter probably have had higher total utility over time.

What may be going on here is simply that work with a novel `brand identity' gets more notice than work aggregated to an existing `brand'. Elucidation of these rules, and what they tell us about the hacker culture's scoreboarding system, would make a good topic for further investigation.