11. The Value of Humility
Having established that prestige is central to the hacker culture's
reward mechanisms, we now need to understand why it has seemed so
important that this fact remain semi-covert and largely unadmitted.
The contrast with the pirate culture is instructive. In that culture,
status-seeking behavior is overt and even blatant. These crackers
seek acclaim for releasing "zero-day warez" (cracked software
redistributed on the day of the original uncracked version's release)
but are closemouthed about how they do it. These magicians don't like
to give away their tricks. And, as a result, the knowledge base of
the cracker culture as a whole increases only slowly.
In the hacker community, by contrast, one's work is one's statement.
There's a very strict meritocracy (the best craftsmanship wins) and
there's a strong ethos that quality should (indeed must) be
left to speak for itself. The best brag is code that ``just works'',
and that any competent programmer can see is good stuff. Thus, the
hacker culture's knowledge base increases rapidly.
A taboo against ego-driven posturing therefore increases productivity.
But that's a second-order effect; what is being directly protected
here is the quality of the information in the community's
peer-evaluation system. That is, boasting or self-importance is
suppressed because it behaves like noise tending to corrupt the vital
signals from experiments in creative and cooperative behavior.
The hacker culture's medium of gifting is intangible, its
communications channels are poor at expressing emotional nuance, and
face-to-face contact among its members is the exception rather than
the rule. This gives it a lower tolerance of noise than most other
gift cultures, and goes a long way to explain the example in public
humility required of its tribal elders.
Talking softly is also functional if one aspires to be a maintainer of
a successful project; one must convince the community that one has
good judgement, because most of the maintainer's job is going to be
judging other people's code. Who would be inclined to contribute work
to someone who clearly can't judge the quality of their own code, or
whose behavior suggests they will attempt to unfairly hog the
reputation return from the projectıĵ Potential contributors want
project leaders with enough humility and class be able to to say, when
objectively appropriate, ``Yes, that does work better than my version,
I'll use it'' -- and to give credit where credit is due.
Yet another reason for humble behavior is that in the open source
world, you seldom want to give the impression that a project is
`done'. This might lead a potential contributor not to feel needed.
The way to maximize your leverage is to be humble about the state of
the program. If one does one's bragging through the code, and then says
``Well shucks, it doesn't do x, y, and z, so it can't be that good'',
patches for x, y, and z will often swiftly follow.
Finally, I have personally observed that the self-deprecating behavior
of some leading hackers reflects a real (and not unjustified) fear of
becoming the object of a personality cult. Linus Torvalds and Larry
Wall both provide clear and numerous examples of such avoidance
behavior. Once on a dinner expedition with Larry Wall I joked
``You're the alpha hacker here -- you get to pick the restaurant''.
He flinched audibly. And rightly so; failing to distinguish their
shared values from their leaders has ruined a good many communities,
a pattern of which he and Linus cannot fail to be fully aware.
On the other hand, most hackers would love to have Larry's problem,
if they could but bring themselves to admit it.