1. 1 - Une contradiction liminaire
2. 2 - Les différentes idéologies des hackeurs
3. 3 - Théorie libertine, pratique puritaine
4. 4 - Propriété et logiciels à sources ouverts
5. 5 - Locke et la propriété foncière
6. 6 - Culture du hack, culture du don
7. 7 - Le plaisir du hack
8. 8 - Les multiples facettes de la réputation
9. 9 - Droits de propriété et appâts de la réputation
10. 10 - Le problème de l’ego
11. 11 - La valeur de l’humilité
12. 12 - Conséquences du modèle du jeu des réputations
13. 13 - Propriété de la noosphère et éthologie du territoire
14. 14 - Les causes de conflit s
15. 15 - Structure et propriété des projets libres
16. 16 - Les conflits et leur résolution
17. 17 - Mécanismes d’acculturation et lien avec le modèle académique
18. 18 - Conclusion : de la coutume à la loi coutumière
19. 19 - Questions pour aller plus loin
20. 20 - Bibliographie, notes et remerciements
21. 21 - Historique des versions
22. 22 - Notes des traducteurs
23. 23 - Remerciements des traducteurs

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 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 N.d.t. [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 ».