Page suivante Page précédente Table des matières

11. La valeur de l'humilité

Ayant établi que le prestige est au centre du mécanisme de valorisation de la culture hackeur, il nous faut à présent comprendre pourquoi il semblait si important que ce fait reste si longtemps dans l'ombre et très peu admis.

Le contraste d'avec la culture des pirates informatiques est instructif. Dans cette culture, il est connu et même flagrant qu'on recherche un certain statut. Les crackeurs cherchent la considération pour avoir mis en ligne des « warez premier jour » (logiciels crackés le jour de la sortie du programme original, protégé) mais restent muets quant à la façon dont ils l'ont fait. Ces magiciens n'aiment pas donner leurs trucs. C'est pour cela que la base de connaissances de la culture des crackeurs n'augmente que très lentement, dans l'ensemble.

Dans la communauté des hackeurs, inversement, le travail de chacun est ce qu'il publie. C'est une méritocratie très stricte (le meilleur artisan gagne) et il y a une déontologie très suivie qui veut qu'il faut laisser parler la qualité. La meilleure des vantardises est un code qui « marche, tout simplement », et dont tout bon programmeur peut voir la bonne facture. Ainsi, la connaissance de la base culturelle des hackeurs augmente rapidement.

Un tabou contre l'égocentrisme augmente donc la productivité. Mais c'est un effet de second ordre ; ce qui est directement protégé est ici la qualité de l'information au sein du système d'évaluation par les pairs. C'est-à-dire que l'auto-satisfaction et l'intérêt personnel sont supprimés puisqu'ils pourrait sinon bruiter les signaux vitaux des expériences en comportements créatifs et coopératifs.

Le médium du don dans la culture hackeur est intangible, les canaux de communication sont pauvres en ce qui concerne l'expression des nuances émotionnelles et le face-à-face entre ses membres plutôt l'exception que la règle. Cela lui donne une moindre tolérance en bruit que dans la plupart des autres cultures, et cela va explique en grande partie que les aînés de la tribu se doivent de respecter une certaine humilité en public.

Ne pas fanfaronner a aussi une utilité fonctionnelle si l'on veut aspirer à maintenir un projet réussi : il faut convaincre la communauté que notre jugement est bon, parce que le travail d'un responsable de projet consiste essentiellement à évaluer correctement le code des autres. Qui voudrait proposer son travail à une personne inapte à juger de la qualité d'un code, ou dont le comportement général tend à montrer qu'elle essaiera injustement de s'en attribuer seule le mérite ? Les contributeurs potentiels sont à la recherche de gens assez humbles pour dire, là où les faits objectifs le justifient : « oui, cela fonctionne mieux que ma propre version, je le prends. » — et d'en rendre le mérite à l'auteur.

Une autre raison de cette humilité est que dans le monde des logiciels au source ouvert, on ne cherche que très rarement à donner l'impression qu'un projet est « fini ». Cela pourrait mener un contributeur éventuel à penser que son apport n'est pas nécessaire. Pour maximiser son influence au sein de la communauté, il faut rester humble quant à l'état de ses programmes. Si quelqu'un vante son code, mais ajoute « Mince alors ! Il ne fait pas x, y et z. Il ne doit pas être aussi bien que ça finalement ! », les patchs pour x, y et z suivront généralement peu après.

Enfin, j'ai personnellement remarqué que le comportement auto-dépréciateur de certains chefs de file hackeurs reflète une peur réelle (et pas forcément injustifiée) de devenir l'objet d'un culte de la personnalité. Linus Torvalds et Larry Wall apportent tous deux un nombre incalculable d'exemples clairs de ce genre de comportement. Un jour, lors d'une sortie avec Larry Wall, j'ai fait une plaisanterie: « Tu es le meilleur hackeur de nous tous — tu vas pouvoir choisir le restaurant ». Il sursauta très nettement. Et pour cause ; ne pas distinguer leurs valeurs respectives de celles de leurs meneurs a détruit nombre de communautés, un schéma que Linus et lui-même ne peuvent d'ignorer. D'un autre côté, beaucoup de hackeurs adoreraient avoir le problème de Larry, s'ils pouvaient se résoudre à l'admettre.


Page suivante Page précédente Table des matières