A la conquête

de la
Noosphère
par Eric Steven Raymond

<esr@thyrsus.com>

Après avoir observé une contradiction entre l'idéologie «officielle» définie par les licences de
logiciels à sources ouverts et le comportement réel des hackeurs, nous examinons les véritables
coutumes contrôlant cette culture. Nous découvrons que cela implique une théorie des droits de
possession sous-jacente, qui est proche de la théorie de Locke sur la propriété foncière. Nous
analysons la culture hackeur comme une «culture du don» dans laquelle les participants rivalisent
pour le prestige en donnant du temps, de l'énergie et de la créativité. Nous examinons ensuite les
implications de cette analyse pour la résolution des conflits dans cette culture et nous développons
quelques idées pour approfondir cette réflexion.

1. Une contradiction liminaire

Tout ceux qui observent le monde agité et formidablement prolifique des logiciels à sources ouverts
sur l'Internet depuis un certain temps ont inévitablement remarqué une contradiction intéressante
entre ce en quoi les développeurs de logiciels à sources ouverts déclarent croire et leur manière de se
comporter - entre l'idéologie officielle de la culture des logiciels à sources ouverts et les pratiques
réelles.

Les cultures sont des machines adaptatives. La culture des logiciels à sources ouverts est une réponse
à un ensemble identifiable de motivations et de contraintes. Comme d'habitude, l'adaptation d'une
culture à ce genre de circonstances se manifeste à la fois par une idéologie consciente, mais aussi
comme un savoir implicite, inconscient ou semi-conscient. Et, comme c'est souvent le cas, les
adaptations inconscientes sont partiellement en contradiction avec l'idéologie consciente.

Dans cet article, nous allons faire apparaître les origines de cette contradiction, et l'utiliser pour
découvrir les coutumes et les contraintes de cette culture. Nous allons en déduire quelques
mécanismes intéressants relatifs à la culture hackeur et à ses coutumes. Nous conclurons en
suggérant des manières de procéder qui permettent de tirer parti de la connaissance de cette culture
implicite.

2. Les différentes idéologies des hackeurs

L'idéologie de la culture des logiciels à sources ouverts sur Internet (celle en laquelle croient les
hackeurs) est un sujet déjà assez compliqué en lui-même. Tous ses membres s'accordent sur le fait
que les logiciels à sources ouverts (c'est-à-dire les logiciels librement redistribuables et qu'on peut
facilement faire évoluer et modifier en fonction de ses besoins) sont une bonne chose et valent la
peine qu'on s'y consacre de façon significative. Cette position définit efficacement l'appartenance à
cette culture. Pourtant, les raisons pour lesquelles des individus et différentes sous-cultures adhèrent
à cette croyance sont très variées.

L'un de ces degrés de liberté est le zélotisme. Le développement de logiciels à sources ouverts est
simplement vu, soit comme un moyen pratique pour atteindre un but (de bons outils, des gadgets
amusants et des jeux intéressants), soit comme une fin en soi.

Un zélote extrémiste pourrait dire: «Les logiciels libres sont ma vie! J'existe pour créer des
programmes utiles et beaux ou pour écrire des documentations et pour les distribuer librement.» Un
zélote 'modéré' dirait: «Les logiciels à sources ouverts sont une bonne chose, pour laquelle je suis
prêt à sacrifier une bonne partie de mon temps.» Une personne peu attachée à la cause dirait: «Oui,
les logiciels à sources ouverts sont parfois corrects. Je joue avec et je respecte les gens qui les font.»

Un autre degré de liberté est l'hostilité à l'égard des logiciels commerciaux et/ou des compagnies
perçues comme dominant le marché des logiciels.

Quelqu'un de très anti-commercial pourrait dire: «Les logiciels commerciaux, c'est du vol, de la
rétention d'information! J'écris des logiciels à sources ouverts pour mettre un terme à ce fléau!» Une
personne modérément anti-commerciale pourra dire: «Les logiciels commerciaux sont en général
acceptables, parce que les programmeurs méritent d'être payés, mais les compagnies qui se la coulent
douce en vendant de la camelote et en usant de leur poids pour imposer leurs produits sont
mauvaises.» Un pro-commercial dira par exemple: «Les logiciels commerciaux sont bons, j'utilise
/j'écris des logiciels à sources ouverts uniquement parce que je les trouve meilleurs.»

Les neuf attitudes qui découlent des combinaisons de ces catégories sont toutes présentes dans la
culture des logiciels à sources ouverts. Il est nécessaire de mettre en évidence ces distinctions car
cela induit différentes priorités et différents comportements adaptatifs et coopératifs.

Historiquement, l'organisation la plus connue et la mieux organisée de la culture hackeur a été à la

fois très zélote et très anti-commerciale. La Free Software Foundation (FSF) fondée par Richard M.
Stallman (RMS) a encouragé activement le développement des logiciels à sources ouverts depuis le
début des années 1980, en fournissant des outils tels que Emacs et GCC (1).

Pendant longtemps la FSF était le seul point de ralliement des développeurs de logiciels à sources
ouverts. Elle a conçu un grand nombre d'outils fondamentaux pour cette culture. La FSF était aussi le
seul sponsor des logiciels à sources ouverts avec une identité institutionnelle visible par des
observateurs extérieurs à la culture hackeur. En fait, ses membres ont défini le terme de «free
software» (logiciel libre), en lui donnant délibérément un nom provocateur (2).

Ainsi, la perception de la culture hackeur, à la fois de l'extérieur et de l'intérieur, tendait à être

identifiée avec l'attitude de la FSF, à la fois frénétique et perçue comme anti-commerciale (Richard
M. Stallman, lui-même, dément avoir cette attitude anti-commerciale, mais son attitude a été
interprétée comme telle par un très grand nombre de gens, dont ses plus fervents défenseurs). La
conduite énergique et explicite de la FSF pour «luttez contre la rétention des logiciels» (Stamp Out
Software Hoarding!), devint la doctrine des hackeurs et Richard M. Stallman est devenu le chef de
file de cette culture.

Les termes de la licence de la FSF, la «General Public License» (GPL), traduisent l'attitude de la
FSF. Elle est largement utilisée dans le monde des logiciels à sources ouverts. Le site Sunsite, en
Caroline du Nord, est le plus populaire des sites d'archives de logiciels dans le monde Linux. En
juillet 1997 à peu près la moitié des paquetages de logiciels de Sunsite utilisaient la licence GPL.

Mais la FSF n'a jamais été seule sur ce créneau. Il y a toujours eu un autre mouvement au sein de la
culture hackeur, plus calme, moins provocateur, et plus tolérant en ce qui concerne la vente des
logiciels. Les pragmatiques n'étaient pas tant fidèles à une idéologie qu'à un ensemble de traditions
scientifiques fondées aux débuts du mouvement des logiciels à sources ouverts, et antérieures à la
FSF. Ces traditions mêlaient, avant tout, la culture technique d'Unix et l'Internet pré-commercial.

L'attitude typique d'un pragmatiste est seulement modérément anti-commerciale, et son grief majeur
envers le monde des entreprises n'est pas la rétention des sources en elle-même. C'est plutôt un
ressentiment envers cette culture perverse qui refuse d'intégrer l'approche plus efficace d'Unix, des
standards et des logiciels à sources ouverts. Si le pragmatique déteste quelque chose en particulier
c'est moins souvent le fait d'être privé des sources de ses logiciels que le Roi du logiciel du moment;
IBM autrefois, Microsoft aujourd'hui.

Pour le pragmatique, la GPL est un outil important, mais pas une fin en soi. Son utilité principale
n'est pas d'être une arme contre la rétention d'informations, mais plutôt un moyen d'encourager la
communauté des développeurs au partage des logiciels et à l'adoption du modèle de programmation
de type «bazar». Le pragmatiste accorde plus de valeur aux bons outils et aux gadgets qu'il ne déteste
le commerce et il peut utiliser des outils commerciaux de bonne qualité sans se poser de problème de
conscience. En même temps, son expérience des logiciels à sources ouverts l'a habitué à une qualité
technique que très peu de logiciels fermés peuvent atteindre.

Pendant de longues années, le point de vue des pragmatistes était principalement exprimé, au sein de
la culture hackeur, comme un refus obstiné d'adopter la GPL en particulier ou les idées de la FSF en
général. Dans les années 80 et au début des années 90, cette attitude tendait à être associée aux
fanatiques de l'Unix de Berkeley, aux utilisateurs de la licence BSD et aux pionniers qui avaient tenté
de constituer un Unix libre à partir des sources de BSD. Cependant, ces efforts, n'ayant pas mené à la
consitution de communautés «bazar» de taille conséquente, furent un échec et n'ont produit que de
petits groupes dispersés et inefficaces.

Les pragmatiques ne commencèrent à avoir du poids qu'avec l'avènement de Linux en 1993-1994.

Bien que Linus Torvalds n'ait jamais souhaité s'opposer à Richard M. Stallman, il s'est posé en
exemple en regardant d'un oeil bienveillant la croissance de l'industrie commerciale autour de Linux,
approuvant l'utilisation de logiciels commerciaux de bonne qualité pour des tâches spécifiques, et en
raillant gentiment les éléments les plus puristes et les plus fanatiques de la culture hackeur.
La croissance rapide de Linux a eu pour conséquence l'arrivée d'un grand nombre de nouveaux
hackeurs dévoués à Linux et pour lesquels la FSF n'avait qu'un intérêt historique. Bien que la
nouvelle vague de hackeurs Linux décrive ce système comme «le choix d'une GNUvelle génération
(The choice of a GNU generation), la plupart tendent à se réclamer de Torvalds plutôt que de
Stallman.

De plus en plus, les puristes anti-commerciaux se retrouvèrent en minorité. Le fait que les choses ont
changé ne devint apparent qu'à l'annonce faite par Netscape en février 1998 de la mise en libre accès
des sources de Navigator 5.0, ce qui a attisé l'intérêt que l'industrie portait au «logiciel libre». Cette
annonce sans précédent a eu pour conséquence le changement de nom de «logiciel libre» à «logiciel
ouvert», qui s'est produit avec une facilité qui a surpris tous les acteurs de cette affaire.

Alors que le développement prenait de l'ampleur, le groupe des pragmatiques commençait lui aussi à
se diversifier au milieu des années 1990. D'autres communautés semi-indépendantes, conscientes
d'elles-mêmes, avec leurs propres chefs charismatiques, commencèrent à percer au sein de la culture
Unix/Internet. Parmi celles-ci, la plus importante, après celle de Linux, fut celle de Perl, dirigée par
Larry Wall. Plus petites, mais tout aussi importantes, furent les traditions construites autour des
langages Tcl de John Osterhout et Python de Guido Van Rossum. Ces trois communautés ont
exprimé leur indépendance idéologique en concevant leurs propres licences de logiciels à sources
ouverts, et en refusant la GPL.

3. Théorie libertine, pratique puritaine

Malgré tout, à travers ces changements, demeura un large consensus sur ce qu'étaient les «logiciels
libres» ou les «logiciels à sources ouverts». La preuve la plus éclatante de cette communauté
théorique réside dans l'existence de nombreux dénominateurs qui unissent les différentes licences de
logiciels.

En 1997, ces éléments communs furent distillés dans le manifeste du logiciel libre de la Debian, qui
est depuis devenu la définition du logiciel ouvert (Open Source Definition). Dans les lignes
directrices définies par l'OSD (Open Source Definition), une licence de logiciel ouvert doit protéger
un droit inconditionnel de toute partie à modifier le logiciel ouvert (et à en redistribuer les versions
ainsi modifiées).

Par conséquent, la théorie implicite de l'OSD (ainsi que celle des licences qui se conforment à l'OSD
telles que la GPL, la licence BSD, et la licence artistique de Perl) est que n'importe qui peut hacker
n'importe quoi. Rien n'empêche une demi-douzaine de personnes de prendre n'importe quel logiciel
ouvert (tel que GCC, le compilateur C de la FSF), de dupliquer ses sources, et de le développer dans
différentes directions, tout en clamant haut et fort qu'il s'agit là de la vraie version du programme.

En pratique, pourtant, de telles «scissions» n'arrivent quasiment jamais. Les ruptures dans les projets
majeurs ont été rares, et toujours accompagnées d'un changement de nom et d'un grand nombre de
justifications publiques. Il est clair dans des cas comme la séparation de GNU Emacs/ XEmacs, celle
de GCC/EGCS, ou encore les différents schismes des groupes de BSD, que les dissidents sentaient
qu'ils s'opposaient à une norme partagée par tous.

En fait, contrairement à la théorie du consensus selon laquelle tout le monde peut hacker n'importe
quoi, la culture des logiciels à sources ouverts dispose d'un ensemble de coutumes complexes, mais
très largement refoulées, sur la propriété. Ces coutumes décident de qui peut modifier un logiciel, des
circonstances selon lesquelles il peut le modifier, et (en particulier) qui a le droit de redistribuer les
versions modifiées à la communauté.

Les tabous d'une culture accentuent grandement ses règles. C'est pour cela qu'il serait utile pour la
suite que nous en résumions quelques-uns des plus importants.

- Il existe une forte pression sociale contre la scission de projets. Cela n'arrive pas, sauf si l'on plaide
l'absolue nécessité avec de nombreuses justifications publiques et un changement de nom du projet.

- Distribuer des modifications d'un projet sans la coopération des modérateurs est mal vu, sauf dans
certains cas, comme par exemple des corrections mineures pour porter le logiciel sous une nouvelle
architecture.

- Retirer le nom d'une personne de l'histoire d'un projet, des remerciements ou de la liste des
mainteneurs est absolument impossible sans le consentement explicite de la personne.

Dans le reste de cet article, nous examinerons en détail tabous et coutumes sur le droit de propriété.
Nous ne nous demanderons pas seulement comment tout cela fonctionne, mais aussi ce que cela
révèle sur la dynamique sociale sous-jacente et sur ce qui motive la communauté du logiciel ouvert.

4. Propriété et logiciels à sources ouverts

Que signifie le terme «propriété» lorsque ce qui est possédé est duplicable à l'infini, hautement
malléable, et que la culture environnante n'est plus capable de faire appliquer des lois, et n'est plus
dans une situation économique où les ressources sont limitées ?

En fait, dans le cas des logiciels à sources ouverts, c'est une question à laquelle il est facile de
répondre. Le (ou les) propriétaire(s) d'un projet est celui qui a (ou sont ceux qui ont) le droit exclusif,
et reconnu comme tel par l'ensemble de la communauté, d'en redistribuer des versions modifiées.

(Nous parlerons de «propriétaire» au singulier, comme si tous les projets appartenaient à une seule
personne. Cependant, il doit être clair que les projets peuvent appartenir à des groupes. Nous
examinerons les dynamiques internes de tels groupes plus tard dans cet article.)

Selon les licences ouvertes standard, tous sont égaux dans le jeu de l'évolution. En pratique, il y a
toutefois une distinction, reconnue par tous, entre les patchs (3)«officiels», approuvés et intégrés
dans le logiciel par les mainteneurs publiquement reconnus, et les patchs «pirates», proposés par des
tiers. Les patchs pirates sont peu fréquents et, en général, considérés comme peu sûrs.

Il est facile d'établir que la redistribution publique est un enjeu fondamental. L'usage encourage les
gens à patcher le logiciel pour un usage personnel lorsque c'est nécessaire, et de ne pas prêter
attention aux gens qui redistribuent des versions modifiées au sein d'un groupe fermé d'utilisateurs
ou de développeurs. C'est uniquement lorsque les modifications sont diffusées à la communauté en
général, en concurrençant l'original, que la notion de propriété du projet entre en ligne de compte.

Il existe en général trois manières de devenir le responsable d'un projet de logiciel ouvert. La
première, la plus évidente, est de le créer. Lorsqu'un projet ne compte qu'un mainteneur depuis son
origine et que ce mainteneur est toujours actif, l'usage ne permet même pas de remettre en cause cette
autorité.

La deuxième manière de devenir responsable d'un projet, c'est de se faire confier cette charge par le
précédent propriétaire (on appelle parfois cela «passer le relais»). Il est évident pour la communauté
que les responsables de projets ont le devoir de choisir un successeur compétent lorsqu'ils ne veulent
ou ne peuvent plus investir le temps nécessaire dans le développement ou la maintenance du projet.

Il est révélateur que dans le cas de projets importants, de telles passations de pouvoir sont
généralement annoncées à grand renfort de fanfare. Bien que la communauté du logiciel ouvert n'ait
jamais vraiment remis en cause le choix d'un successeur par le responsable d'un projet, il est
important que, dans la pratique, le dauphin apparaisse légitime aux yeux de la communauté.

Pour les projets mineurs, il est généralement suffisant de modifier le nom du propriétaire du projet
dans le fichier d'historique joint à la distribution (4). On présume que si le propriétaire précédent n'a
pas, en réalité, passé le relais volontairement, il ou elle pourra reprendre le contrôle de son projet,
soutenu par la communauté, en objectant publiquement dans un délai raisonnable.

La troisième façon de prendre les rênes d'un projet est d'avoir des idées de développement, alors que
le responsable précédent a disparu ou perdu tout intérêt pour ce programme. Si sa succession vous
intéresse, il vous faut le rechercher. S'il reste introuvable, alors vous devez annoncer dans un endroit
approprié (comme les forums de Usenet (5)) que le projet semble orphelin et que, dorénavant, vous
envisagez de prendre les choses en main.

L'usage veut que vous laissiez passer un peu de temps avant de vous déclarer le nouveau responsable
du projet. Si pendant ce laps de temps, quelqu'un annonce qu'il travaillait déjà sur ce projet, son
annonce l'emporte sur la vôtre. Il est de bon ton d'annoncer publiquement vos intentions plus d'une
fois. Vous vous légitimerez d'autant plus si vos annonces sont faites dans de nombreux forums
adéquats (forums connexes, listes de diffusions) et si vous faites preuve de patience en attendant
d'éventuelles réponses. En général, plus vos efforts seront visibles pour retrouver l'ancien propriétaire
ou d'autres prétendants, plus votre revendication sera légitimée, s'il n'y a pas de réponse.

Si vous avez passé avec succès toutes ces étapes devant l'assemblée des utilisateurs du projet et qu'il
n'y a pas d'objection, alors vous pouvez vous proclamer propriétaire de ce projet orphelin et inscrire
votre nom dans le fichier d'historique du projet. Cependant, cette méthode est moins sûre que celle
du passage de relais, et vous ne pouvez pas vous attendre à être considéré comme pleinement
légitimé, du moins pas avant d'avoir réalisé d'importantes améliorations sur le projet, aux yeux de
tous.

J'ai observé ces coutumes en action depuis 20 ans, depuis la pré-FSF, dans l'Antiquité des logiciels à
sources ouverts. Elles ont un certain nombre de caractéristiques très intéressantes. L'une des plus
intéressantes est que la plupart des hackeurs les ont respectées sans en être pleinement conscients. En
effet, ce qui est écrit ici semble être la première mise au point consciente et raisonnablement
complète jamais faite.

Autre fait intéressant, ces coutumes inconscientes ont été appliquées avec une cohérence
remarquable, voire surprenante. J'ai observé l'évolution de centaines de projets de logiciels à sources
ouverts, et je peux malgré tout compter sur les doigts d'une main le nombre de violations
significatives à ces règles.

Un troisième fait intéressant est que ces coutumes ont toujours évolué dans la même direction. C'est-
à-dire en responsabilisant davantage le public, en l'informant plus, et en prenant garde de préserver
les mérites et l'historique des projets de façon à établir la légitimité des propriétaires du moment
(entre autres choses).

Ces particularités suggèrent que ces coutumes ne sont pas fortuites, mais l'effet d'une organisation
spontanée, implicite, ou d'une finalité (generative pattern) dans la culture des logiciels à sources
ouvertes, essentielle à son fonctionnement.

L'une des premières remarques qu'on m'ait faite, portait sur l'enseignement qu'on pouvait tirer du
contraste entre la culture des hackeurs sur Internet et la culture des crackeurs ou pirates (l'activité des
«wArez d00dz» consiste à cracker des jeux et à pirater des BBS [Bulletin Board Systems]): toutes
deux ont leurs propres finalités. Nous reviendrons sur ce contraste plus tard.

5. Locke et la propriété foncière

Pour comprendre cette organisation spontanée, il est utile d'évoquer un cas historique assez
semblable, pourtant très éloigné du domaine habituel des hackeurs. Comme le sait n'importe quel
étudiant en histoire du droit et en philosophie politique, la théorie de la propriété dont il est question
ici est virtuellement identique aux théories des lois anglo-américaines de la propriété foncière!

Dans cette théorie, il y a trois façons d'acquérir la propriété d'une terre.

À la limite du monde connu, là où les terres n'ont encore jamais appartenu à personne, on les
conquiert en apportant son travail à la terre en friche, en la clôturant et en défendant son titre de
propriété.

Le moyen habituel pour hériter d'une terre dans une zone colonisée est le transfert de titre, c'est-à-
dire recevoir le titre des mains du propriétaire précédent. Dans cette théorie, le concept de «chaîne de
titres» est important. La preuve en est qu'on peut toujours remonter cette chaîne jusqu'au propriétaire
originel, qui a conquis le terrain.
Enfin, cette théorie prévoit le cas où un titre de terrain serait perdu ou abandonné (si par exemple le
propriétaire meurt sans héritier, ou si les registres nécessaires à l'établissement de cette chaîne de
titres pour des terrains inhabités ont disparu). Une étendue de terrain laissée en friche peut être
réclamée par une partie adverse - qui s'y installe, l'aménage, et la défend tout comme dans le cas
d'une conquête.

Cette théorie, comme les coutumes des hackeurs, a évolué de façon organique dans un contexte où
l'autorité centrale était faible ou non existante. Elle s'est développée sur une période d'un millénaire à
partir des lois tribales scandinaves et allemandes. Étant donné qu'elle fut systématisée et rationalisée
au début de l'ère moderne par le sociologue anglais John Locke, on l'appelle parfois théorie
«lockéenne» de la propriété.

Évidemment, des théories similaires ont eu tendance à apparaître partout où la propriété avait une
grande importance économique ou vitale et où aucune autorité n'était suffisamment puissante pour
centraliser l'allocation des denrées rares. Cela est encore vrai dans les cultures des chasseurs-
cueilleurs, perçues de façon romantique comme n'ayant pas de notion de «propriété». Par exemple,
dans la tradition des Bushmen !Kung San du désert du Kalahari, le territoire de chasse n'appartient à
personne. Mais il y a une propriété des points d'eau et des sources selon un modèle qui ressemble à la
théorie de Locke.

L'exemple des !Kung San est instructif, parce qu'il montre que les coutumes décrites par Locke ne
surviennent que là où le bénéfice attendu d'une ressource dépasse le coût de sa défense. Le territoire
de chasse n'est pas une propriété, car le profit de la chasse est hautement aléatoire, variable et (bien
que très prisé socialement) pas vraiment nécessaire à la survie quotidienne. Les points d'eau, au
contraire, sont vitaux et suffisamment localisés pour qu'on en défende l'accès.

La «noosphère» du titre de cet article est le territoire des idées, l'espace de toutes les pensées
possibles (6). Ce que l'on voit implicitement dans les coutumes du droit de propriété chez les
hackeurs est une théorie lockéenne de la propriété sur un sous-ensemble de la noosphère, l'espace de
tous les programmes. La «conquête de la noosphère», est donc entreprise par tous les fondateurs de
nouveaux projets de logiciel ouvert.

Faré Rideau <fare@tunes.org> fait remarquer à juste titre que les hackeurs n'opéraient pas
exactement dans le domaine des idées pures. Il soutient que le propre des hackeurs est
l'implémentation d'un projet - la focalisation délibérée sur la partie matérielle du travail
(développement, service, etc.), à laquelle sont associées la réputation, la confiance, etc. Il affirme
donc que l'espace couvert par les projets des hackeurs, n'est pas la noosphère, mais une sorte de dual
de celle-ci, c'est-à-dire l'espace des diverses implémentations possibles des projets (pour faire plaisir
aux astrophysiciens, il serait étymologiquement plus correct d'appeler cet espace dual «l'ergosphère»,
ou encore «la sphère du tangible»).

Mais la distinction entre noosphère et ergosphère n'est pas cruciale pour le propos de cet article. On
peut douter, à moins d'être un philosophe platonicien, de l'existence d'une quelconque «noosphère»
au sens de Faré. Et la distinction entre noosphère et ergosphère n'est que d'ordre pratique pour ceux
qui soutiennent la thèse que les idées (ou éléments de la noosphère) n'appartiennent à personne, alors
que leurs réalisations sous forme de projets ont des propriétaires. Cela nous mènerait à des questions
relevant de la propriété intellectuelle, et qui dépassent le cadre de cet article.

Néanmoins, pour éviter toute confusion, il est important de remarquer que ni la noosphère, ni
l'ergosphère, ne représentent l'ensemble des lieux virtuels des médias électroniques parfois appelés
(au grand dam de la plupart des hackeurs) «cyberespace». La propriété y est régulée par des règles
complètement différentes, plus proches de celles qui sont utilisées pour les biens matériels -
essentiellement, celui qui possède le média ou les machines sur lesquelles une partie du
«cyberespace» réside, possède, en conséquence, cette partie du cyberespace.

La structure lockéenne suggère fortement que les hackeurs respectent certaines coutumes afin de
protéger le bénéfice qu'ils espèrent retirer de leurs efforts. Ce bénéfice doit être plus important que
l'effort de création des projets, le travail de maintenance de l'historique des versions successives, le
temps passé à faire des notifications publiques, et le temps passé à ronger son frein avant de pouvoir
prendre possession d'un projet orphelin.

En outre, le «gain» apporté par les logiciels à sources ouvertes doit dépasser leur seule utilisation; il
doit aussi être compromis ou dilué par la scission d'un projet. Si seule l'utilisation du logiciel
comptait, il n'y aurait pas de tabou contre la scission, et le droit de propriété d'un projet de logiciel
ouvert ne ressemblerait en rien à la propriété foncière. En fait, ce monde alternatif (où l'usage des
logiciels est le seul gain) est celui qui est induit par les licences de logiciels à sources ouverts
existantes.

On peut, d'ores et déjà, éliminer certains candidats au titre de gain. Comme on ne peut contraindre
personne efficacement via une connexion réseau, la recherche du pouvoir est impossible. De plus, la
culture des logiciels à sources ouverts n'ayant rien qui ressemble de près ou de loin à de l'argent ou à
une économie de marché, les hackeurs ne peuvent donc pas rechercher un bien matériel quelconque.

Il existe cependant une façon de s'enrichir grâce aux logiciels à sources ouverts - et cette méthode
donne de précieux indices quant à ses véritables motivations. Parfois, la réputation acquise par
certains au sein de la culture hackeur peut se répandre dans le monde réel et avoir des répercussions
financières significatives. Cela peut ouvrir l'accès à une offre d'emploi plus intéressante, à un contrat
de consultant, ou aiguiser l'intérêt d'un éditeur.

Ce type d'effet de bord est rare et marginal pour la plupart des hackeurs, ce qui est insuffisant pour en
faire une explication convaincante, même si on ignore les protestations répétées des hackeurs
clamant qu'ils ne font pas ça pour l'argent, mais seulement par idéalisme ou par passion.

Pourtant, la médiatisation de cet effet de bord justifie un examen plus approfondi. Nous verrons plus
tard que la compréhension de la dynamique engendrée par la réputation dans la culture des logiciels à
sources ouverts permet en elle-même d'expliquer beaucoup de choses.

6. Culture du hack, culture du don

Pour comprendre le rôle de la réputation dans la culture des logiciels à sources ouverts, il est utile de
considérer tout cela d'un point de vue anthropologique ou économique plutôt qu'historique, et
d'examiner la différence entre des cultures d'échange et des cultures du don.

Les êtres humains ont un tendance innée à rivaliser pour leur statut social; c'est un comportement
profondément ancré dans notre histoire. Pendant les 90 % de cette histoire qui se sont déroulés avant
l'invention de l'agriculture, nos ancêtres vivaient regroupés en petites tribus nomades de chasseurs-
cueilleurs. Les individus des rangs sociaux les plus élevés avaient accès aux femmes les plus
robustes et aux meilleures parts pendant les repas. Cette course au statut social s'exprime elle-même
de différentes façons, dépendant largement du degré de pénurie des biens essentiels à la survie.

La plupart des modèles d'organisation des humains sont dictés par une adaptation aux pénuries et aux
désirs. Chaque modèle porte en lui-même ses différentes règles de progression sociale.

Le modèle le plus simple est le pouvoir centralisé. Dans ce système, la répartition des ressources
rares est faite par une autorité centrale et maintenu par la force. Le pouvoir centralisé n'est efficace
qu'à une petite échelle (7); il devient de plus en plus violent et inefficace lorsque sa taille augmente
(8). C'est pour cela qu'au-delà de la taille d'une grande famille, les pouvoirs centralisés sont, presque
toujours, des parasites d'un autre type d'économie, d'un type différent. Dans ce modèle, le statut
social est d'abord déterminé par l'accès à un pouvoir répressif.

Notre société est principalement dans une économie d'échanges. C'est une façon sophistiquée de
s'adapter aux pénuries qui, contrairement au modèle centralisé, s'adapte plutôt bien aux changements
d'échelle. La répartition des ressources rares est faite de manière décentralisée à travers le commerce
et la coopération volontaire (en fait, c'est l'effet dominant du désir de compétition que de produire un
comportement de coopération (9)). Dans une économie fondée sur l'échange, le statut social est
directement déterminé par le contrôle que l'on a sur les marchandises (pas nécessairement
matérielles) à utiliser ou à commercer.

La plupart des gens ont un modèle mental implicite pour les deux systèmes décrits précédemment, et
sur la manière dont ils interagissent. Le gouvernement, l'armée, et le crime organisé (par exemple)
sont des pouvoirs centralisés qui parasitent l'économie d'échange, plus vaste, que nous appelons le
«marché libre». Il existe cependant un troisième modèle, radicalement différent des autres et
rarement reconnu en tant que tel sauf par les anthropologues: la culture du don.

Les cultures du don ne sont pas des réponses à une pénurie, mais à une abondance. Elles surviennent
dans des populations qui ne souffrent pas de carences significatives en biens de première nécessité.
On peut observer des cultures du don en action dans les cultures aborigènes vivant dans des éco-
zones au climat doux et à la nourriture abondante. On peut aussi les observer dans certaines strates de
notre propre société, particulièrement dans le monde du spectacle et chez les gens très riches.

L'abondance rend les ordres imposés par la force difficiles à justifier et les échanges commerciaux
presque sans objet. Dans une culture du don, le statut social n'est pas déterminé par ce que vous
contrôlez, mais par ce que vous donnez.

D'où les cadeaux des participants à un réveillon entre amis. Ou les actes de philanthropie raffinés et
souvent ostentatoires d'un multi-millionnaire. Et les longues heures d'efforts du hackeur pour
produire des logiciels à sources ouverts de bonne qualité.

Si on en fait un telle lecture, il est clair que la culture des logiciels à sources ouverts est en fait une
culture du don. En son sein, nul ne manque sérieusement de «produits de première nécessité» -
l'espace disque, la bande passante réseau, la puissance de calcul. Le logiciel est librement partagé.
Cette abondance crée une situation où la seule évaluation possible de la réussite dans cette
compétition est la réputation que chacun acquiert auprès de ses pairs.

Cette observation ne suffit pas vraiment, cependant, à expliquer les caractéristiques que l'on observe
dans la culture hackeur. Les crackeurs d00dz (10)ont une culture du don qui prospère sur le même
média (électronique) que celui des hackeurs, mais leur comportement est très différent. Dans leur
culture, l'esprit de groupe est plus fort et plus exclusif que chez les hackeurs. Ils conservent
jalousement leurs secrets plutôt que de les partager; on trouvera plus fréquemment des groupes de
crackeurs qui distribuent des exécutables sans les sources pour cracker des logiciels que les astuces
pour les réaliser.

Tout cela prouve, au cas où ce n'était pas évident, qu'il existe plusieurs manières d'envisager la
culture du don. L'histoire et les valeurs jouent un rôle important. J'ai résumé l'histoire de la culture
hackeur dans «Une brève histoire des hackeurs» (For a brief History of Hackerdoom) (11); la façon
dont elle a façonné les comportements actuels n'est pas un mystère. Les hackeurs ont défini leur
culture par un ensemble de choix à propos de la forme que doit prendre leur compétition. C'est cette
forme que nous examinerons dans la suite de cet article.

7. Le plaisir du hack
En faisant cette analyse du «jeu des réputations», mon but n'est pas de dévaluer ou de fermer les
yeux sur la satisfaction purement artistique de mettre au point et de faire fonctionner un bon logiciel.
Nous avons tous l'expérience de ce genre de satisfaction et nous nous en réjouissons toujours. Ceux
pour qui cette sensation n'est pas une motivation importante ne deviennent jamais des hackeurs de
toutes manières, tout comme ceux qui n'aiment pas la musique ne deviennent pas compositeurs.

Il nous faut donc probablement rechercher un autre modèle comportemental des hackeurs, où le
plaisir de l'artisan est la motivation première. Ce modèle de «l'artisan» aurait à expliquer les
coutumes des hackeurs en tant que moyen d'optimiser à la fois les possibilités de créations et la
qualité des résultats. Cela entre-t-il en conflit avec le modèle du «jeu des réputations» ou cela
suggère-t-il des résultats différents?

Pas vraiment. En examinant le modèle de «l'artisan», on revient aux mêmes problèmes qui
contraignent la communauté des hackeurs à fonctionner au sein d'une culture du don. Comment peut-
on optimiser la qualité en l'absence de métrique pour cette dernière? En l'absence d'économie de la
pénurie, que reste-t-il en dehors de l'évaluation par les pairs? Il semble évident qu'en fin de compte,
toute culture d'artisan doit se structurer elle-même à travers un «jeu des réputations» - et, en fait, c'est
exactement cette dynamique que nous pouvons observer dans de nombreuses cultures d'artisan,
depuis le temps des guildes médiévales.
Le modèle de «l'artisan» cède à la «culture du don» un avantage important: elle explique bien mieux
la contradiction que nous avons exposée au début de cet article.

Finalement, la motivation de «l'artisan» n'est peut-être pas aussi éloignée du «jeu des réputations»
que nous aimerions le croire. Imaginez votre merveilleux programme enfermé dans un tiroir et plus
jamais utilisé. À présent, imaginez qu'il est utilisé avec efficacité et plaisir par un grand nombre de
personnes. Quel rêve vous satisfait le plus ?

Toutefois, nous garderons un oeil sur le modèle de l'artisan. Il plaît intuitivement à de nombreux
hackeurs, et il explique suffisamment bien certains aspects des comportements individuels.

Après la publication de la première version de cet article, un lecteur m'a écrit: «On ne travaille peut-
être pas pour la gloire, mais c'est la récompense directe et certaine de tout travail bien exécuté.» C'est
une remarque subtile et importante. Qu'il en soit ou non conscient, le travail de l'artisan induit sa
renommée; ainsi, qu'un hackeur considère ou non son propre comportement comme un élément du
«jeu des réputations», ce dernier ne l'en façonnera pas moins.

8. Les multiples facettes de la réputation

Il existe des raisons communes à toutes les cultures du don qui justifient la recherche d'une bonne
réputation auprès de ses pairs (prestige):

Premièrement, et c'est le plus évident, jouir d'une bonne réputation auprès de ses pairs est la
récompense la plus appréciable. Pour des raisons dues à notre évolution, dont on a parlé plus haut,
c'est un fait inscrit au plus profond de notre être. (Nombreux sont ceux qui subliment la recherche du
prestige sous des formes sans rapport évident à un groupe de pairs, telles que «l'honneur» «l'intégrité
éthique», «la piété», etc. Mais cela ne change pas le mécanisme sous-jacent.)

Deuxièmement, le prestige est un bon moyen (et, dans une pure culture du don, l'unique moyen)
d'attirer l'attention et la coopération des autres. Si quelqu'un est bien connu pour sa générosité, son
intelligence, son honnêteté, son charisme, ou pour d'autres qualités, il lui devient bien plus facile de
convaincre les autres qu'ils gagneront à s'associer avec lui.

Troisièmement, si votre économie du don est en contact ou mélangée avec une économie d'échanges
ou un pouvoir centralisé, votre réputation peut déborder de votre milieu originel et vous faire
atteindre un statut plus élevé.

Au-delà de ces raisons générales, les caractéristiques particulières de la culture des hackeurs font que
le prestige est encore plus précieux qu'il ne le serait dans une culture du don du «monde réel».

La principale de ces «conditions particulières» est que les artefacts qui sont donnés à la communauté
(ou, si on l'interprète différemment, qui représentent le signe visible de l'énergie et du temps
déployés) sont très complexes. Leur valeur n'est pas aussi évidente que celle de dons matériels ou de
l'argent dans une économie d'échanges. Il est plus difficile de distinguer objectivement un don
exceptionnel d'un don médiocre. Par conséquent, la réussite de l'enchère de celui qui brigue un statut
social plus élevé dépend fortement du jugement critique de ses pairs.

Une autre particularité de la culture des logiciels à sources ouverts est sa relative pureté. La plupart
des cultures du don sont compromises - soit par des liens avec l'économie d'échange tels que le
commerce de biens de luxe, soit par des relations avec un pouvoir centralisé telles que des
regroupements en familles ou en clans. Il n'existe rien de tel dans la culture des logiciels à sources
ouverts. En dehors de la réputation au yeux de ses pairs, il n'y a virtuellement aucun salut.

9. Droits de propriété et appâts de la réputation

Nous sommes maintenant prêts à faire aboutir l'analyse précédente en une théorie cohérente de la
coutume de la propriété chez les hackeurs. À présent, nous comprenons le bénéfice que l'on retire de
la conquête de la noosphère, c'est la réputation auprès de ses pairs dans la culture du don des
hackeurs, avec les gains indirects et les effets de bord que cela implique.

À partir de là, nous pouvons analyser les coutumes de la propriété lockéenne des hackeurs comme un
moyen d'optimiser la valeur de la réputation et d'assurer que la reconnaissance des pairs soit
accordée à ceux qui le méritent et pas aux autres.

Avec cette analyse, les trois tabous dont nous avons parlé plus haut prennent tout leur sens. La
réputation de quelqu'un peut souffrir injustement si on détourne ou mutile son travail; ces tabous (et
les coutumes qui en découlent) essayent de prévenir ce genre de situation.

- La scission de projets est mauvaise car elle expose la réputation des contributeurs du projet
d'origine, ce qu'ils ne peuvent éviter qu'en prenant part simultanément aux deux projets résultants.
(Cela serait généralement trop confus ou trop difficile pour pouvoir se faire en pratique.)

- La distribution de patchs pirates (ou, pire, de exécutables pirates) expose les propriétaires à un
risque injuste quant à leur réputation. Même si le code officiel est parfait, les propriétaires endureront
les critiques des bogues des patchs (mais voir note supra).

- Enlever discrètement le nom de quelqu'un d'un projet est, dans ce contexte culturel, l'un des plus
grands crimes qui soient.Cela transfère le bénéfice du don de la victime au voleur.

Ces trois tabous affectent l'ensemble de la communauté des logiciels à sources ouverts aussi bien que
leurs victimes. Implicitement, ils portent atteinte à l'ensemble de la communauté car ils rendent
moins probable le fait qu'un don ou travail de contributeur potentiel est récompensé.

Il est important de remarquer que deux de ces trois tabous peuvent s'expliquer autrement.

D'abord, les hackeurs expliquent souvent leurs appréhensions face à la scission d'un projet par le
temps perdu à faire tout le travail en double pour chacun des projets fils. Ils peuvent aussi observer
qu'une scission tend à couper l'équipe de développement en deux groupes, laissant ainsi les deux
projets fils avec moins de cerveaux que le projet père.
Un lecteur a remarqué qu'il est rare, à long terme, que plus d'un des projets fils survive avec une
«part de marché» suffisamment importante. Cela renforce la motivation qu'ont les différentes parties
de coopérer et d'éviter une scission. Il est en effet difficile de savoir à l'avance quel fils sera du
mauvais côté de la barrière et verra tout le travail effectué soit disparaître, soit sombrer dans l'oubli.

L'aversion pour les patchs pirates est souvent expliquée par le fait que cela complique
considérablement la correction des bogues, et que cela donne du travail supplémentaire à des
mainteneurs qui ont déjà suffisamment à faire avec leurs propres erreurs.

Il y a une grande part de vérité dans ces explications, et elles contribuent certainement à renforcer la
logique lockéenne de propriété. Mais, pour satisfaisantes qu'elles soient, ces théories n'arrivent pas à
expliquer pourquoi les rares cas où les tabous sont brisés suscitent autant d'émotions et de luttes
territoriales - pas seulement du fait des parties lésées, mais aussi des observateurs et des tiers qui
réagissent souvent de façon très sévère. Une inquiétude réfléchie quant aux ennuis provoqués par la
duplication du travail et de la maintenance ne suffit pas à expliquer les comportements observés.

Et puis, il y a le troisième tabou. Il est difficile d'envisager une autre explication que le jeu des
réputations pour décrire tout cela. Le fait que l'analyse de ce tabou dépasse rarement la simple
formule: «Ce ne serait pas bien!» est révélateur en lui-même, comme nous le verrons dans la section
suivante.

10. Le problème de l'ego

Au début de cet article j'ai mentionné que les fondements inconscients d'une culture sont souvent à
l'opposé de son idéologie consciente. Nous en avons déjà eu un exemple flagrant dans le fait que les
coutumes de propriété lockéenne ont été amplement suivies bien qu'elles violent l'esprit des licences
standards des logiciels à sources ouverts.

J'ai observé un autre exemple intéressant de ce phénomène en discutant de l'analyse du jeu des
réputations avec des hackeurs. Nombre d'entre eux rejetaient l'analyse et se montraient fortement
réticents à admettre que leur comportement puisse être motivé par leur réputation auprès d'un pair ou
par ce que j'appelais alors imprudemment la «satisfaction de l'ego».

Cela illustre un point important de la culture hackeur. Elle se méfie sciemment de la confiance et
méprise l'égocentrisme et les motivations fondées sur l'ego. L'auto-satisfaction a tendance à être
critiquée sans merci, même quand la communauté pourrait en retirer quelque chose. À tel point que
les aînés de la tribu doivent parler sans ambages et se déprécier de manière humoristique afin de
conserver leur statut. La manière dont cette attitude s'imbrique au sein d'une structure dont la
motivation principale repose apparemment entièrement sur l'ego, requiert des explications.

Cela découle certainement du caractère péjoratif de l'ego dans la culture europeo-américaine. La

matrice culturelle de la plupart des hackeurs leur enseigne que le désir de l'ego est une motivation
mauvaise (ou tout au moins immature) et que l'ego est, au mieux, une excentricité tolérable chez les
prime donne, et souvent un symptôme de pathologie mentale. Seules des formes subliminales et
déguisées comme «la réputation auprès des pairs», «l'estime de soi», «le professionnalisme» ou «la
fierté du travail accompli» en sont généralement acceptables.

Je pourrais écrire un autre essai sur les racines malsaines de notre héritage culturel, et sur la masse
étonnante d'illusions et de mal que nous nous faisons en croyant (contre toute évidence
psychologique et comportementale) que nous avons véritablement des motivations non personnelles.
Peut-être le ferais-je si Nietzsche et Ayn Rand (12)ne l'avaient pas déjà fait (quels qu'aient été leurs
échecs par ailleurs) en démystifiant fort bien «l'altruisme» comme des sortes d'égocentrismes
inconscients et inavoués.

Mais je ne suis pas en train de faire de la morale philosophique ou psychologique, aussi me

contentrai-je d'observer un moindre mal, causé par la croyance que l'ego est si démoniaque: cela a
rendu émotionnellement difficile pour les hackeurs le fait de comprendre consciemment la
dynamique de leur propre culture!

Mais nous n'en avons pas tout à fait terminé avec cette enquête. Le tabou frappant les comportements
dictés par l'ego est si intense dans la (sous)culture des hackeurs qu'on peut le suspecter de remplir
une fonction spécifique. En effet, les tabous concernant l'ego sont de bien moindre importance dans
nombres d'autres cultures du don, telles que les cultures corporatistes (des gens du spectacle ou des
grosses fortunes).

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 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 recherchent 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 sur leur manière de procéder. 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 parasiter 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 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 à sources ouverts, 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 d'entre nous - 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 ignorer.
D'un autre côté, beaucoup de hackeurs adoreraient avoir le problème de Larry, s'ils pouvaient se
résoudre à l'admettre.

12. Conséquences du modèle du jeu des réputations

L'analyse du jeu des réputations a plus de conséquences qu'il n'y paraît d'abord. Beaucoup d'entres
elles découlent du fait que l'on retire plus de prestige en ayant fondé un projet réussi qu'en ayant
simplement participé à un projet existant. Une autre conséquence en est que l'on retire plus de gloire
d'un projet fondamentalement innovant que d'améliorations incrémentales à un programme qui existe
déjà. D'un autre côté, un logiciel que personne, à part l'auteur, ne comprend ou n'utilise, n'est pas un
bon départ dans le jeu des réputations, et il est souvent plus aisé d'attirer l'attention sur soi en
contribuant à un projet existant qu'en créant un nouveau projet. Enfin, il est plus difficile de se
mesurer à un projet qui a déjà le vent en poupe que de remplir une niche vide.

Ainsi, il existe une distance optimale entre son projet et ceux des voisins (les projets concurrents les
plus similaires). Si la distance est trop petite, votre projet sera une redite sans valeur du projet
existant (il faudrait plutôt contribuer au projet existant). Si la distance est trop grande, personne ne
sera à même de comprendre, d'utiliser ou de percevoir le sens de l'effort d'un pair (là encore, le
cadeau sera de faible valeur). Tout cela crée un plan de conquête de la noosphère qui ressemble à
l'implantation de colons s'aventurant au-delà d'une frontière dans le monde physique (13). À tout
instant, on s'intéressait à la position de la frontière séparant les terres colonisées des terres encore
sauvages - pas aléatoirement, mais plutôt comme un agrégat fractal. Les projets tendent à démarrer là
où ils comblent des trous près de la frontière.

Certains projets à succès deviennent des «tueurs de concurrence». Personne ne voudra se tenir près
d'eux car se mesurer à une base déjà établie sera une tâche trop dure. Les gens qui en revanche feront
des efforts distincts finiront plutôt par contribuer à l'extension de ces projets à succès. L'exemple
classique du «tueur de concurrence» est GNU Emacs. Ses variantes remplissent la niche écologique
des éditeurs entièrement programmables, à tel point que personne n'a jamais vraiment essayé de créer
un programme très différent dans ce domaine depuis les années 80. Au lieu de cela les gens écrivent
des modules pour Emacs.

Globalement, ces deux tendances (remplir les vides et les tueurs de concurrence) ont conduit à des
modes dictant la naissance, en général prévisible, de projets à travers le temps. Dans les années 70, la
majorité des logiciels à sources ouverts existants étaient des gadgets et des démos. Dans les années
80, la tendance allait vers le développement et les outils Internet. Dans les années 90, elle s'est
tournée vers les systèmes d'exploitation (14). Dans chaque cas de figure, on s'attaquait à un niveau de
plus en plus élevé de problèmes, alors que les possibilités du précédent avaient été pratiquement
épuisées.

Cette tendance a des conséquences intéressantes pour un futur proche. Au début de l'année 1998,
Linux ressemble fort à un tueur de concurrence pour la niche des «systèmes d'exploitation à sources
ouverts» - et les gens qui auraient pu écrire des systèmes d'exploitation concurrents, écrivent plutôt à
présent des pilotes ou des extensions. Et la plupart des outils de bas niveau (15)dont les gens ont pu
espérer une version ouverte existent déjà. Que reste-t-il ?

Les applications. À l'approche de l'an 2000, il semble peu risqué de prédire que l'effort de
développement des logiciels à sources ouverts va peu à peu conquérir le dernier territoire vierge -
notamment avec des logiciels pour les non-spécialistes. Une prémisse claire en est le développement
de GIMP, l'équivalent de Photoshop pour la manipulation d'images, qui est la première application
ouverte importante avec une GUI (Graphical User Interface, ou interface homme-machine
graphique) digne de celles qui sont de rigueur dans les applications commerciales de la dernière
décennie. Un autre signe est le remue-ménage fait autour des projets d'outils d'environnement pour
logiciels KDE et GNOME.

Finalement, l'analyse du jeu des réputations explique le proverbe, souvent cité, que l'on ne devient
pas un hackeur en s'en donnant le titre - on le devient lorsque d'autres hackeurs disent de vous que
vous êtes un hackeur. Un «hackeur», vu sous cet angle, est quelqu'un qui a su prouver (par sa
contribution) qu'il ou elle a un potentiel technique et qu'il ou elle comprend le fonctionnement du jeu
des réputations. Ce jugement est essentiellement une prise de conscience ou un apprentissage qui ne
peut être délivré que par ceux qui sont déjà bien implantés dans cette culture.
13. Propriété de la noosphère et éthologie du territoire
Afin de mieux comprendre les conséquences des moeurs de propriété, il sera très utile de les aborder
sous un autre angle. En se plaçant du point de vue de l'éthologie animale, et plus spécifiquement, de
l'éthologie du territoire.

La propriété est une abstraction de la territorialité animale, qui a évolué de manière à réduire les
comportements violents au sein d'une même espèce. En marquant son territoire et en respectant celui
des autres, le loup réduit les risques de se retrouver au sein d'un conflit qui pourrait l'affaiblir ou le
tuer et diminuer ses chances de se reproduire.

Parallèlement, la fonction de la propriété au sein des communautés humaines est d'abord de prévenir
tout conflit intra-communautaire en définissant des marques qui séparent clairement un
comportement paisible d'un comportement agressif. Il semble parfois de bon ton de décrire ces
marques comme socialement arbitraires, mais cela est complètement faux. Quiconque a déjà fait
l'expérience d'avoir un chien qui aboie à l'approche d'un inconnu connaît la continuité essentielle
entre la territorialité animale et la propriété humaine. Nos cousins domestiques des loups le sentent
souvent mieux que bon nombre de théoriciens politiques.

Clamer sa propriété (ainsi que définir son territoire) est un acte représentatif, c'est un moyen de
déclarer quelles frontières seront défendues. Appuyer ce droit à la propriété est un moyen de
minimiser les conflits et de maximiser un comportement coopératif. Cela reste encore une réalité
lorsque le «droit à la propriété» est plus abstrait qu'un enclos ou qu'un aboiement de chien, alors
même qu'il est réduit à l'apparition du nom d'un responsable de projet dans un fichier LISEZMOI. Il
s'agit toujours d'une abstraction de la territorialité, et (comme dans d'autres formes de propriété) nos
modèles instinctifs de propriété sont des modèles territoriaux qui ont évolué en vue de résoudre les
conflits.

Cette analyse éthologique semble de prime abord très abstraite, et difficile à mettre en relation avec
le comportement réel des hackeurs. Mais elle a d'importantes conséquences. L'une d'elles est
d'expliquer la popularité des sites Web, et plus spécialement pourquoi les projets de logiciels à
sources ouverts avec un site web semblent beaucoup plus «réels» et substantiels que ceux qui n'en
disposent pas.

Tout bien considéré, cela semble difficile à expliquer. Comparée aux efforts impliqués par la création
et le maintien d'un programme, même petit, une page web est facile à maintenir, aussi est-il difficile
de considérer la page web comme la preuve d'un effort substantiel ou inhabituel.

Les caractéristiques fonctionnelles du Web lui-même sont encore une explication insuffisante. Les
fonctions de communication d'une page web peuvent être aussi bien, si ce n'est mieux, remplacées
par la combinaison d'un site FTP (16). Les sites FTP rassemblent un ensemble de fichiers, souvent
accessibles à n'importe qui, d'une liste de diffusion (17)et d'un forum de discussion. En fait, il est
relativement peu fréquent que les communications courantes concernant un projet se fassent sur le
Web plutôt que sur une liste de diffusion ou un forum de discussion. Pourquoi les sites Web
jouissent-ils donc d'une telle popularité en tant que localisation d'un projet ?

La métaphore implicite induite dans le terme de «home page» (littéralement, «document maison»)
est un indice important. Puisque fonder un projet de logiciel ouvert est une revendication territoriale
au sein de la noosphère (et reconnu comme tel par l'usage) ce n'est pas une importante contrainte
psychologique. Un logiciel, après tout, n'a pas de position géographique, et il peut être duplicable à
tout instant. Ceci est assimilable à notre notion instinctive de «territoire» et de «propriété», mais
seulement après quelques efforts.

La page d'accueil d'un projet concrétise l'abstraction de la colonisation de l'espace des programmes
possibles en le présentant comme un territoire conquis au sein du royaume du Web, territorialement
plus organisé. Passer de la noosphère au «cyberespace» ne nous donne pas tous les moyens de
protection du monde réel, des barrières ou des chiens qui aboient, mais cela ancre la propriété
abstraite de façon plus sûre pour notre notion instinctive de territoire. Et c'est pour cela que les
projets qui bénéficient d'une page web semblent plus «réels».

Cette analyse éthologique nous encourage aussi à regarder plus précisément les mécanismes
permettant de gérer les conflits dans la culture des logiciels à sources ouverts. Cela nous amène à
prévoir que, outre une maximisation des ressorts de la réputation, les coutumes de propriétés jouent
également un rôle dans l'évitement et la résolution des conflits.

14. Les causes de conflits

Les conflits au sein des logiciels libres peuvent être classés en quatre grandes catégories:

- Qui prend les décisions importantes du projet?

- Qui doit-on féliciter ou réprimander et pour quoi ?

- Comment réduire la duplication du travail et empêcher les versions pirates de compliquer la

recherche des bogues ?

- Quelle est la bonne voie, techniquement parlant ?

Pourtant, si l'on s'arrête sur la question: «Quelle est la bonne voie?», on constate que celle-ci ne tient
pas la route. Pour de telles questions, soit il existe une solution objective, acceptée par tous, soit il
n'en existe pas. S'il en existe, «eurêka!», et tout le monde y gagne. Sinon, cela se réduit à: «Qui prend
les décisions ?».

Par conséquent, les trois problèmes qu'une théorie de la résolution des conflits doit résoudre sont (A)
sur qui rejeter la responsabilité des choix de conceptions, (B) comment décider à quel contributeur
est attribué le travail, et (C) comment empêcher le groupe et le logiciel d'exploser en de multiples
branches.

Le rôle des coutumes traitant de la propriété permettent clairement de résoudre les points (A) et (C).
L'usage affirme que le propriétaire d'un projet prend les décisions importantes. Nous avions déjà
observé le fait que l'usage exerce aussi une forte pression contre la dilution des projets par scissions.

Il est instructif de remarquer que ces coutumes ont un sens même si l'on oublie le jeu des réputations
et que l'on examine la culture des hackeurs avec l'idée d'un pur modèle de «l'artisan». Dans cette
optique, les coutumes s'expliquent plus par une protection du droit de l'artisan à agir selon sa vision
des choses que pour empêcher l'atténuation de la motivation dûe à la réputation.

Cependant, le modèle de l'artisan n'est pas suffisant pour expliquer les coutumes des hackeurs à
propos du point (B), «qui remercie-t-on et pour quoi?» (car dans un modèle de pur artisan, quelqu'un
qui ne s'intéresse pas au jeu des réputations, ne devrait pas s'en préoccuper). Pour analyser cela, nous
avons besoin de creuser un peu la théorie lockéenne et d'examiner les conflits et l'application de
droits de propriétés aussi bien à l'intérieur qu'à l'extérieur des projets.

15. Structure et propriété des projets libres

Le cas le plus facile est celui dans lequel le projet n'a qu'un seul propriétaire/mainteneur. Aucun
conflit n'est alors possible. Le propriétaire prend toutes les décisions et récolte les bénéfices ou les
problèmes qu'engendre son projet. Le seul cas possible de conflit se présente lors de la succession -
qui va devenir le nouveau propriétaire si le précédent disparaît ou perd son intérêt pour le projet? La
communauté aussi a intérêt, d'après (C), à éviter les scissions. Ces intérêts sont exprimés par une
règle culturelle qui dit qu'un propriétaire/mainteneur doit publiquement passer la main à quelqu'un
s'il ne peut maintenir le projet plus longtemps.

Le cas non trivial le plus simple est lorsqu'un projet a plusieurs co-mainteneurs qui travaillent sous la
direction d'un «dictateur bienveillant». L'usage favorise ce type d'organisation pour les projets de
groupes. L'expérience montre que pour des projets aussi gros que le noyau Linux ou Emacs cela
fonctionne correctement, et résout le problème du «Qui décide?» d'une façon qui n'est pas forcément
la pire.

Typiquement, une organisation de type «dictateur bienveillant» est issue d'une organisation de type
propriétaire/mainteneur qui a su attirer des contributeurs. Même si le propriétaire reste le dictateur,
cela introduit un nouveau niveau de dissensions possibles à propos de la répartition des
remerciements pour les différentes parties du projet.

Dans cette situation, les coutumes obligent le propriétaire/dictateur à remercier les contributeurs de
façon équitable (à travers, par exemple, une notification appropriée de leurs noms dans les fichiers
LISEZMOI ou dans celui de l'historique du projet). Selon le modèle de la théorie lockéenne de la
propriété, cela signifie qu'en contribuant à un projet vous gagnez une part de sa renommée (en bien
ou en mal).

En poussant ce raisonnement plus loin, on constate qu'en réalité, le dictateur bienveillant ne détient
pas la totalité du projet de façon inconditionnelle. Bien qu'il ait le droit de faire des choix cruciaux, il
propose en effet aux autres des parts de la renommée de son projet en échange de leur travail.
L'analogie avec le métayage dans les fermes est presque incontournable, si ce n'est que le nom du
contributeur reste dans les remerciements et qu'il continue à être associé au projet, même après avoir
cessé d'y contribuer.

Quand les projets de type «dictateur bienveillant» rassemblent plus de participants, deux familles de
contributeurs tendent à se démarquer: les contributeurs ordinaires et les co-développeurs. Un
cheminement typique pour devenir un co-développeur est de prendre la responsabilité d'un sous-
système majeur du projet. Un autre est de se transformer en «chasseur de bogues», en débusquant et
en corrigeant un grand nombre de bogues. De cette façon ou d'une autre, les co-développeurs sont
des contributeurs qui s'investissent de façon substantielle et persistante dans le projet.

Le rôle de responsable d'un sous-système est particulièrement important pour notre analyse et mérite
qu'on s'y attarde. Les hackeurs aiment à dire que «l'autorité vient de la responsabilité». Un co-
développeur qui accepte la responsabilité de la maintenance d'un sous-système donné obtient en
général le contrôle de l'implémentation de ce sous-système et de ses interactions avec le reste du
projet, et seul le chef de projet (qui joue le rôle d'un architecte) peut lui faire des remarques. On
notera que cette règle délimite effectivement une propriété suivant le modèle lockéen à l'intérieur du
projet, et qu'elle a exactement le même rôle de prévention des conflits que les frontières ceignant
habituellement les propriétés.

L'usage veut que le «dictateur» ou le chef de projet dans un projet avec co-développeurs consulte
ceux-ci lors des décisions-clé. Plus particulièrement encore lorsque la décision concerne un sous-
système «appartenant» à un co-développeur (c'est-à-dire, qui y a investi du temps et en a pris la
responsabilité). Un chef de projet avisé, qui sait à quoi sert le découpage interne de son projet,
n'interférera avec, ni n'annulera, les décisions faites par le propriétaire d'un sous-système.

Certains projets très importants abandonnent entièrement le modèle du «dictateur bienveillant». On

peut procéder en transformant les co-développeurs en une commission de votants (comme pour
Apache (18)), ou encore ne faisant tourner le titre de dictateur; dans ce dernier type d'organisation le
pouvoir passe d'un membre à un autre au sein d'un cercle de co-développeurs aguerris (les
développeurs de Perl se sont organisés ainsi).

De tels arrangements sont généralement considérés instables et compliqués. Évidemment, ces

difficultés dépendent largement de la productivité d'une telle commission, de ses décisions ou de son
absence de décision. Ce sont des problèmes dont la communauté des hackeurs a parfaitement
conscience. Je soupçonne cependant que le malaise des hackeurs vis-à-vis des commissions ou des
organisations à pouvoir tournant vient du fait qu'elles cadrent mal avec le modèle inconscient de
Locke qu'ils utilisent pour résoudre les cas simples. Il est difficile, dans ces organisations complexes,
de tenir le décompte des propriétés de chacun en matière de parties contrôlées ou des gains de
réputation. Il est difficile de voir les frontières internes d'un tel projet, et donc difficile d'éviter les
conflits, à moins que le groupe n'atteigne un niveau exceptionnel d'harmonie et de confiance
réciproque.

16. Les conflits et leur résolution

Nous avons vu qu'au sein des projets la complexité des rôles tend à croître, d'une part à cause d'une
répartition de l'autorité de conception entre les membres de l'équipe, d'autre part à cause des droits de
propriété partiels sur des sous-parties du projet. Même s'il s'agit là d'une façon efficace de distribuer
la motivation, cela diminue aussi l'autorité du chef de projet - cela affaiblit surtout la position du chef
de projet lorsqu'il est nécessaire de prendre une décision pour étouffer les conflits dans l'oeuf.

Bien que les arguments techniques de conception du logiciel semblent être la cause la plus évidente
de discorde, ils sont rarement en cause. Ces problèmes sont généralement résolus assez facilement
par la règle qui dit que l'autorité vient des responsabilités.

Une autre façon de résoudre les conflits est de s'en remettre aux seniors - si deux contributeurs ou
groupes de contributeurs se querellent, qu'ils ne peuvent s'entendre de façon objective, et que
personne ne détient le territoire sur lequel se passe le conflit, alors la partie qui a contribué le plus
activement au projet (c'est-à-dire, la partie qui possède le plus de droits de propriété du projet)
l'emporte.

Ces règles suffisent généralement à résoudre la majeure partie des querelles. Lorsqu'elles sont
inefficaces, les ordres du chef de projet résolvent généralement le conflit. Les disputes qui survivent
à ces deux filtres sont rares.

Les conflits semblent ne jamais prendre de l'ampleur, à moins que ces deux critères («l'autorité vient
des responsabilités» et «les seniors l'emportent») ne donnent des directives opposées, et que l'autorité
du chef de projet soit défaillante ou absente. Le cas le plus évident dans lequel ce genre de choses
peut arriver est un conflit de succession consécutif à la disparition du chef de projet. J'ai eu l'occasion
d'être pris dans l'un de ces conflits. Cela fut horrible, désagréable, interminable, et ne prit fin que
lorsque toutes les parties furent trop fatiguées pour faire autre chose que de passer la main à un tiers.
Et j'espère sincèrement ne plus jamais participer à une telle chose.

Finalement, tous ces mécanismes de résolution de conflits reposent sur la volonté de la communauté
des hackeurs de les faire respecter. Les seuls manières de les appliquer sont d'incendier et d'occulter -
par une condamnation publique de ceux qui ont enfreint les règles et un refus de coopérer avec eux
après qu'ils l'ont fait.

17. Mécanismes d'acculturation et lien avec le modèle académique

L'une des premières versions de cet article a posé la question suivante: comment la communauté
informe et instruit ses membres de ses coutumes? Ces coutumes sont-elles évidentes ou s'auto-
organisent-elles de manière inconsciente, sont-elles apprises par l'exemple ou par un enseignement
explicite ?

Les transmettre par un enseignement explicite est visiblement rare, ne serait-ce que parce qu'il
n'existait aucune description explicite des normes de cette culture jusqu'à présent.

Bon nombre de règles sont enseignées par l'exemple. Pour donner un exemple simple, il existe une
norme qui dit que toutes les distributions de logiciels doivent proposer un fichier LISEZMOI ou
LISEZ.MOI qui contient les instructions nécessaires au parcours de la distribution. Cette convention
a été établie au moins depuis le début des années 80, mais jusqu'à présent elle n'a jamais été écrite
noir sur blanc. Chacun l'apprend en regardant un grand nombre de distributions.

D'un autre côté, certaines coutumes des hackeurs se sont auto-organisées une fois que ces derniers
ont atteint une compréhension basique (et peut-être inconsciente) du jeu des réputations. La plupart
des hackeurs n'ont jamais entendu parler des trois tabous dont j'ai parlé dans la section Théorie
libertine, pratique puritaine, mais diraient, si on le leur demandait, qu'ils sont si évidents qu'ils n'ont
pas besoin d'être transmis. Ce phénomène incite à une analyse plus fine - et peut-être pourrons-nous
y trouver une explication en examinant le processus à partir duquel les hackeurs acquièrent la
connaissance de leur culture.

Un grand nombre de cultures utilisent des règles cachées (ou plus précisément des «mystères» au
sens religieux ou mystique) comme un mécanisme d'acculturation. Ce sont des secrets qui ne sont
pas révélés aux étrangers, mais qui doivent être découverts ou déduits par l'apprenti newbie. Pour
être accepté par ses pairs, il doit démontrer aux autres qu'il comprend à la fois les «mystères» et qu'il
les a appris d'une façon culturellement correcte.

La culture hackeur utilise de façon massive et rarement consciente de tels indicateurs ou tests. On
peut voir ce processus se mettre en oeuvre au moins à trois niveaux:

- Mystères de type «mot de passe». Par exemple, il existe un forum de Usenet appelé
alt.sysadmin.recovery, qui dispose très explicitement d'un tel secret. On ne peut pas y participer sans
le connaître, et cette connaissance est considérée comme une preuve que l'on correspond au forum.
Ce secret est un puissant tabou pour les habitués du forum.

- La nécessité d'une initiation à certains mystères techniques. Chacun doit absorber une copieuse part
de connaissance en technique avant de pouvoir offrir des dons de valeur (i.e. chacun doit connaître
au moins l'un des langages de programmation standard). Ce préalable fonctionne à grande échelle à
la manière dont des indices cachés fonctionnent à petite échelle, comme un filtre recherchant des
qualités (telles que l'aptitude à l'abstraction, la persistance, l'adaptation), nécessaires pour s'intégrer
dans la culture.

- Les mystères de contexte social. Chacun s'implique dans la culture à travers un attachement
personnel à des projets spécifiques. Chaque projet possède un contenu social propre parmi les
hackeurs que les prétendants contributeurs doivent démonter et comprendre socialement aussi bien
que techniquement pour s'y intégrer (concrètement, la façon plus courante de faire cela est de lire la
page web ou les archives de la liste de diffusion du projet). C'est à travers les groupes qui font ces
projets que les débutants apprennent, par l'exemple, le comportement des hackeurs expérimentés.

Dans le processus d'acquisition de ces mystères, le prétendant hackeur assimile des connaissances
contextuelles qui (après un certain temps) vont rendre les trois tabous et d'autres coutumes
«évidents».

Certains pourraient, incidemment, soutenir le fait que la structure même de la culture du don des
hackeurs est son propre mystère. On n'est pas considéré comme acculturé (concrètement, personne
ne l'appellera un hackeur) avant d'avoir démontré un bon niveau de compréhension du jeu des
réputations et de ce qu'il implique: coutumes, tabous et usages. Mais c'est évident: toutes les cultures
exigent une telle compréhension de la part de ceux qui manifestent la volonté d'entrer. De plus, la
culture hackeur ne manifeste aucune envie de voir sa logique interne gardée secrète - ou, au moins,
personne ne m'a jamais incendié pour l'avoir révélée!

En commentant cet article, un grand nombre de gens ont signalé le fait que les coutumes de propriété
des hackeurs semblent intimement liées aux habitudes du monde universitaire (et pourraient même
en dériver directement), et plus précisément, de celui de la recherche scientifique. Cette communauté
de chercheurs rencontre des problèmes similaires pour exploiter un territoire aux idées
potentiellement productives, et exhibe des solutions adaptatives très semblables pour ces problèmes
dans le sens où elle utilise aussi l'approbation des pairs et le jeu des réputations.

Étant donné que de nombreux hackeurs ont fréquenté l'université (il est fréquent d'apprendre l'art du
hack à la faculté) le fait de dire que l'université partage certains comportements adaptatifs avec la
culture hackeur est bien plus qu'une simple anecdote dans la compréhension de la manière dont ces
coutumes sont appliquées.

Les parallèles avec la culture du don des hackeurs, telle que je l'ai caractérisée, abondent à
l'université. Une fois qu'un chercheur a conquis un domaine, il n'a plus à se soucier de la question de
sa survie (en effet, le concept de domaine remonte probablement à une culture du don plus ancienne,
dans laquelle les «philosophes naturalistes» étaient à l'origine des riches gentilshommes fortunés
avec du temps à consacrer à la recherche). En l'absence de problèmes de survie, l'amélioration de la
réputation devint la seule motivation, encourageant le partage des nouvelles idées et la consultation
de journaux et d'autres médias. Ceci est fonctionnel et objectif car la recherche scientifique, comme
la culture hackeur, repose largement sur l'idée qu'elle se tient sur des «épaules de géants», et de ne
pas devoir redécouvrir les principes de base encore et encore.

Certains ont poussé le raisonnement jusqu'à suggérer que les coutumes des hackeurs étaient
simplement un reflet de celles de la communauté scientifique et qu'en fait, elles étaient pour la
plupart acquises auprès de cette dernière. Cela exagère probablement la réalité, ne serait-ce que parce
que les coutumes des hackeurs semblent déjà être acquises par de brillants lycéens.

Il y a aussi une autre possibilité intéressante. Je suspecte l'université et la culture hackeur de partager
des comportements adaptatifs, non parce qu'ils sont reliés génétiquement, mais parce qu'elles ont
toutes deux développé l'une des organisations sociales les plus efficaces pour ce qu'elles essaient de
faire, étant données les lois de la nature et l'instinct humain. Le verdict de l'histoire semble être que le
capitalisme et le libre marché est une façon globalement optimale de coopérer pour engendrer une
économie efficace (19). Peut-être que, d'une manière similaire, le jeu des réputations de la culture du
don est la façon globalement optimale de coopérer pour créer (et contrôler!) un travail créatif de
qualité.

Si cela est vrai, c'est d'un intérêt bien plus qu'académique (si vous me le permettez). Vu sous un angle
légèrement différent d'une des spéculations de «La Cathédrale et le Bazar», cela suggère finalement
que le mode de production industrio-capitaliste du logiciel était condamné à être dépassé à partir du
moment où le capitalisme a commencé à créer suffisamment de surplus de richesses, permettant ainsi
à un bon nombre de programmeurs de vivre dans une culture du don d'après-rareté.

18. Conclusion: de la coutume à la loi coutumière

Nous avons examiné les coutumes qui régulent la propriété des logiciels à sources ouverts, et qui les
contrôlent. Nous avons montré comment ils sous-tendent une théorie des droits de propriété analogue
à la théorie lockéenne de la propriété foncière. Nous avons relié cela à une analyse de la culture
hackeur en tant que «culture du don», dans laquelle les participants rivalisent pour le prestige en
donnant du temps, de l'énergie, et de la créativité. Nous avons examiné les implications de cette
analyse pour la résolution des conflits dans cette culture.

Logiquement, la question suivante est: «Pourquoi tout cela est-il important ?». Les hackeurs ont
développé ces coutumes sans analyse consciente, et (jusqu'à présent) ils les ont également suivies
sans analyse consciente. Il n'est pas immédiatement évident que l'analyse consciente apporte un
quelconque gain en pratique - à moins que nous puissions passer de la description à la prescription et
déduire des manières d'améliorer le fonctionnement de ces coutumes.

Nous avons trouvé une bonne analogie des coutumes des hackeurs dans la théorie de la propriété
foncière selon la tradition législative anglo-américaine. Historiquement (20), les cultures tribales
européennes qui ont inventé cette tradition ont amélioré leur système de résolution des conflits en
passant d'un système de coutumes désarticulées et semi-conscientes à un ensemble de lois
coutumières mémorisées par les sages de la tribu - et, finalement, couchées sur papier.

Peut-être qu'avec l'augmentation de notre population, l'acculturation de tous les nouveaux membres
devenant plus difficile, il est temps pour la culture hackeur de faire quelque chose d'analogue - c'est-
à-dire d'écrire un code de bonne conduite afin de résoudre les diverses sortes de conflits qui
pourraient survenir dans le cadre de projets de logiciels à sources ouverts, et de créer une tradition
d'arbitrage dans laquelle les aînés de la communauté pourraient être amenés à intervenir en tant que
médiateurs dans les différends.

L'analyse exposée dans cet article suggère l'esquisse de ce à quoi pourrait ressembler ce code,
explicitant ce qui jusqu'à présent était implicite. Un tel code ne peut-être imposé d'autorité. Il devra
être volontairement adopté par les fondateurs ou les propriétaires de projets individuels. Il ne devra
pas, non plus, être complètement rigide, car les contraintes s'exerçant sur la culture sont susceptibles
de changer au cours du temps. Enfin, pour rendre possible l'application d'un tel code, il lui faudra
refléter un large consensus de la tribu des hackeurs.

J'ai commencé à travailler sur un tel code, provisoirement intitulé le «protocole de Malvern», du nom
de la petite ville où je vis. Si l'analyse générale présentée dans cet article conquiert suffisamment de
monde, je rendrai public le protocole de Malvern en tant que modèle de code pour la résolution des
conflits. Les personnes intéressées par la critique ou le développement de ce code, ou souhaitant
m'informer de ce qu'elles estiment bon ou mauvais, sont invitées à me contacter par courrier
électronique.
19. Questions pour aller plus loin
La culture des hackeurs (et moi) comprenons mal les grands projets qui ne suivent pas le modèle du
«dictateur bienveillant». La plupart de ces grands projets échouent. Quelques-uns réussissent de
façon éclatante et deviennent particulièrement importants (Perl, Apache, KDE). Personne ne
comprend vraiment où se situe la différence. Il existe une vague intuition diffuse qui dit que de tels
projets sont sui generis et perdurent ou meurent selon la dynamique du groupe engendrée par chacun
de ses membres propres. Est-ce vrai ou existe-t-il des stratégies reproductibles qu'un groupe puisse
suivre?

On peut remarquer que ceux qui fondent des projets qui fonctionnent bien récoltent plus de prestige
que ceux qui, avec la même somme de travail, corrigent et assistent ces mêmes projets. Est-ce une
estimation rationnelle des efforts fournis comparés, ou est-ce un effet de bord du modèle territorial
inconscient que nous avons évoqué ici ?

20. Bibliographie, notes et remerciements

The adapted Mind: Evolutionary psychology and the generation of culture. J. Barkow, L. Cosmides,
and J. Tooby (Eds.), New York: Oxford University Press, 1992. Une excellente introduction à la
psychologie évolutive. Certains de ces articles parlent des trois types de cultures dont j'ai parlé
(centralisée/échange /don), en suggérant que ces comportements sont profondément ancrés dans le
psychisme humain.

MALACLYPSE THE YOUNGER: Principia Discordia, or How I Found Goddess and What I Did
To Her When I Found Her ; Loompanics, ISBN 1-55950-040-9. Parmi un monceau de bêtises
éclairantes, le « principe de SNAFU » donne une analyse plutôt incisive de la difficulté des pouvoirs
centralisés à gérer de grands ensembles. Il en existe une version HTML:
www.cs.cmu.edu/afs/cs/user/tilt/public_html/principia/

MILLER, WILLIAM IAN: Bloodtaking and Peacemaking : Feud, Law, and Society in Saga Iceland,
Chicago: University of Chicago Press 1990, ISBN 0-226-52680-1. Une étude fascinante de la loi
populaire islandaise, qui permet de mieux comprendre l'origine de la théorie lockéenne de la
propriété et qui décrit différentes étapes ultérieures du processus historique par lesquelles ont transité
ces coutumes pour passer du stade d'accord tacite à celui de loi coutumière, et enfin à celui de loi
écrite.

GOLDHABER, MICHAEL K. : «The Attention Economy and the Net»

(www.well.com/user/mgoldh/). J'ai découvert cet article après ma version 1.7. Il a des défauts
évidents (l'argument de Goldhaber en faveur de l'impossibilité de la mise en oeuvre d'un
raisonnement économique ne résiste pas à une analyse poussée), mais Goldhaber est néanmoins
amusant et perspicace lorsqu'il parle du rôle de la captation d'attention dans un comportement
organisé. Le prestige ou la réputation parmi les pairs dont j'ai parlé plus haut peut être
fructueusement vus comme un cas particulier de cette «attention».
Je suis redevable à Michael Funk (mwfunk@uncc. campus.mci.net) de m'avoir montré combien le
contraste entre la culture des hackeurs et des crackeurs est instructif. Robert Lanphier
(robla@real.com) a beaucoup contribué à la discussion sur les comportements altruistes. Eric Kidd
(eric.kidd@pobox.com) a souligné le rôle de l'humilité dans la prévention contre les cultes de la
personnalité. La partie qui traite des effets généraux a été inspirée par les commentaires de Daniel
Burn (daniel@tsathoggua.lab.usyd. edu.au). Mike Whitaker (mrw@entropic.co.uk) est à l'origine du
passage principal de la partie sur l'acculturation.

21. Historique des versions

Je suis le seul responsable de ce qui est dit dans cet article, de toutes les erreurs ou méprises. J'ai
cependant accueilli favorablement les commentaires et les interventions des lecteurs, et je les ai
utilisés pour améliorer cet article - processus auquel je ne prévois nulle fin prédéfinie.

10 avril 1998: publication de la version 1.2 sur le Web.

12 avril 1998: Version 1.3. Corrections typographiques et réponses aux premiers commentaires du
public. Les quatre premiers ouvrages de la bibliographie. Un contributeur anonyme a remarqué que
la réputation est motivante même lorsque l'artisan n'est pas averti de son existence. J'ai ajouté une
partie intéressante sur le contraste avec les warez d00dz, j'ai allongé la partie des prémisses traitant
du fait que «le logiciel parle de lui-même» et des observations sur la prévention des cultes de la
personnalité. Résultat, la partie «Le problème de l'ego» a grossi et s'est scindée20.

16 avril 1998: Version 1.7. Nouvelle section sur les implications globales, qui traite de l'histoire de la
colonisation de la noosphère et examine le phénomène des «tueurs de concurrence». J'ai ajouté une
autre question à approfondir.

27 avril 1998: Version 1.8. J'ai ajouté Goldhaber à la bibliographie. Cette version est celle qui sera
présentée dans les actes de la «Linux Expo».

26 mai 1998: Version 1.9. J'ai incorporé la distinction entre noosphère et ergosphère de Faré Rideau.
J'ai ajouté l'affirmation de Richard M. Stallman, qui dit ne pas être anti-commercial. Une nouvelle
partie sur l'acculturation et l'académisme (merci à Ross J. Reedstrom, Eran Tromer, Allan McInnes,
et aux autres). Ajouts sur l'humilité («comportement altruiste») venant de Jerry Fass et Marsh Ray.

11 juillet 1998: Version 1.10. J'ai retiré les références à Faré Rideau à propos de la «gloire» à sa
demande.

21 novembre 1998: Version 1.14. Modifications éditoriales mineures, remise à jour de quelques liens.

22. Notes des traducteurs

CRACKER : v. tr. - de l'angl. crack. Action de s'introduire illégalement un système informatique ou
de briser les sécurités d'un logiciel. Où pourrais-je trouver des informations pour cracker ce
logiciel? ou encore Ce site a été cracké.

CRACKEUR : n. m. - de l'angl. cracker. Criminel informatique. Un crackeur s'est introduit dans

notre site cette nuit.

HACK : n. m. - de l'angl. hack. Une invention astucieuse, une solution élégante à un problème.
Aujourd'hui j'ai fait un bon hack pour résoudre mon problème de disque dur.

HACKER : v. tr. - de l'angl. hack. Inventer, bidouiller, bricoler, la plupart du temps dans le domaine
de l'informatique. Pas de problème je vais te hacker une solution vite fait.

HACKEUR : n. m. - de l'angl. hacker. Inventeur, bidouilleur, bricoleur, la plupart du temps dans le

domaine de l'informatique. Ce type est un vrai hackeur!

LOGICIEL LIBRE : n. m. - de l'angl. free software. Se dit d'un logiciel couvert par la licence
publique générale de GNU (liberté au sens des utilisateurs), la licence X, la licence BSD (liberté au
sens des programmeurs), toutes réunies dans la définition de l'Open Source, ou qui remplit les trois
conditions données par Richard Stallman (disponibilité du code source, droit de le modifier et d'en
redistribuer des versions modifiées), ou d'autres critères encore, car ce mot est de plus en plus
galvaudé et récupéré. Le mieux est de préciser ou de se faire préciser exactement dans quel sens le
logiciel dont on traite est «libre».

LOGICIEL OUVERT : n. m. - de l'angl. opensource. Logiciel couvert par la définition de l'Open

Source, c'est-à-dire qui remplit une dizaine de conditions précises, mises au point pour que les
licences classiques de logiciels libres les satisfassent. Nous avons traduit logiciels à sources ouverts,
nous appuyant sur le fait que dans le langage informatique «source», étant un raccourci pour «code
source», s'emploie au masculin. On entendra fréquemment en effet: «Passe-moi ton source!»

23. Remerciements des traducteurs

Un grand merci à : Marie-Aurore Soudant (pour son aide inestimable), Nikky (pour son anglais et sa
patience), Nat Makarevitch (pour son soutien), et à Olivier Blondeau, Florent Latrive et Michel
Valensi pour leur relecture patiente et pertinente à l'occasion de cette publication sur «site papier».

Notes

*.Adresse du texte original : www.tuxedo.org/~esr /writings/homesteading/. Traduit par Emmanuel

Fleury <fleury@lsv.ens-cachan.fr> & Sébastien Blondeel <sbi@linux-france.org> (traduction
disponible sur www.linux-france.org/article/these/noosphere).Version 1.14, du 21 novembre 1998;
traduit au printemps 1999.

1. N.d.t. Emacs et GCC sont deux logiciels qui forment la base de la suite de développement GNU.
Emacs est un éditeur de texte et GCC un compilateur, qui sont toujours la base du monde des
logiciels à sources ouverts sur Internet, et semble devoir le rester un certain temps. (R)

2. N.d.t. Le mot «free» signifie à la fois «libre» et «gratuit». Le nouveau label «open source» évite
cette ambiguïté. [N.d.e. Toutefois Richard Stallman conteste à juste titre la confusion entretenue
entre logiciels libres et open source.Il s'agit bel et bien de deux choses différentes. Voir «An
interview with Richard Stallman», Wizards of OS, Berlin, July 17, 1999, by Geert Lovink,
http://www.nettime.org/nettime.w3archive/199907/msg00075.html.] (R)

3. N.d.t. Modification d'un programme dans le but de corriger des erreurs ou d'introduire de
nouvelles fonctionnalités. (R)

4. N.d.t. L'auteur fait référence au fichier README, (LISEZMOI) présent dans les distributions de
chaque logiciel ouvert, qui contient notamment l'historique des différents propriétaires du projets. (R)

5. N.d.t. Les forums de Usenet sont des espaces de dialogues électroniques thématiques. Il en existe à
l'heure actuelle près d'un million à travers le monde sur des sujets aussi divers que la cuisine
japonaise ou la physique nucléaire dédiés à ce type de logiciels. (R)

6. N.d.a. Le terme «noosphère» est un obscur terme philosophique issu du grec «nous» qui signifie
«pensée», «esprit» ou «âme». Cela se prononce no-o-sfêr' (deux sons en o, l'un long et appuyé,
l'autre court et rapide). Si vous êtes particulièrement tatillon sur l'orthographe, cela devrait
normalement s'écrire avec un tréma sur l'un des «o» - mais ne me demandez pas lequel. [N.d.e. - Le
terme nöosphère a été créé par le père jésuite Pierre Teilhard de Chardin (voir son livre: L'Énergie
humaine, Le Seuil, Paris 1976 ou http://www.trip.com.br/teilhard/noogenese-fr.html). Philip K. Dick
en donne une définition « personnelle » dans Si ce monde vous déplaît..., l'éclat, Paris, 1997, p. 140.]
(R)

7. Voir Bibliographie: Malaclypse the Younger, Principia Discordia, or How I Found Goddess and
What I Did To Her When I Found Her. (R)

8 . N.d.e. Yona Friedman a développé cette idée à travers le concept de « groupe critique » dans son
livre Utopies réalisables, l'éclat, janvier 2000. (R)

9. N.d.t. Cela n'engage que l'auteur. (R)

10. N.d.t. Les crackeurs d00dz (day zero) sont une sous-culture des crackeurs. Leur but est de mettre
gratuitement à la disposition de tous, des logiciels de jeu dont les sécurités ont été forcées, le jour
même de la sortie officielle. (R)

11. N.d.a. J'ai résumé l'histoire du hack sur urlnam. (http://www.tuxedo.org/%7Eesr/writings/hacker-

history/).Le livre qui l'expliquera en détail reste encore à écrire, probablement pas par moi. (R)

12. N.d.t. Écrivain et philosophe américaine d'origine russe, née à Saint-Petersbourg en 1905. Elle est
à l'origine de « l'objectivisme », théorie farouchement libérale et très opposée à celle de l'État-
providence de Roosevelt. (R)

13. N.d.t. Le « mythe de la frontière » est cher aux américains, qui ont conquis leur portion de
continent en allant toujours plus à l'Ouest (conquête de l'Ouest, le far west étant la région éloignée de
la côte de débarquement). Voir supra, J.P.Barlow «Déclaration», et sa critique par R.Barbrook
«Liberté de l'hypermédia». (R)

14. N.d.t. L'auteur fait ici référence au noyau Linux. (R)

15. N.d.e. Les outils de bas niveau sont des logiciels de base pour utiliser un ordinateur. On peut les
opposer aux applications et aux systèmes d'exploitation. (R)

16. N.d.t. File Transfert Protocol (Protocole de transfert de fichiers) Voir Lexique. (R)

17. N.d.t. Groupes de discussion privée par mail qui se rapprochent des forums sur le principe mais
qui sont limités à un nombre restreint d'adhérents pour des raisons techniques. (R)

18. N.d.t. Le plus répandu des logiciels de serveur web de la planète. C'est aussi un logiciel à sources
ouverts. (R)

19.N.d.e. Ce point de vue n'engage, encore une fois, que l'auteur, dont le raisonnement pourtant
aboutit à une conclusion qui pourrait contredire le 'verdict' dont il parle. Nous aurions plutôt
tendance à penser que bien que le verdict de l'histoire n'ait pas encore été prononcé, la sentence est
déjà appliquée par les armes, parce que les juges informationnels ont été soudoyés.Un quart de la
planète est condamné au travail précaire ou à l'exode. Le pourvoi en cassation se perd dans le
labyrinthe idéologique croisé de la fin de l'histoire et de la nouvelle économie. Lénine! Lénine! lama
sabactani! (Psaume XXII, 1). (R)

20. Voir bibliographie: Miller, W. I.: Bloodtaking and Peacemaking : Feud, Law, and Society in Saga
Iceland. (R)

21. N.d.t. Elle a un problème d'ego surdimensionné. (R)

Source Ñ http://www.freescape.eu.org/eclat/3partie/Raymond/raymond.html