Tous ceux qui observent le monde agité et prolifique des logiciels au source ouvert sur l'Internet depuis un certain temps ont inévitablement remarqué une contradiction intéressante entre ce en quoi les développeurs de logiciels au source ouvert déclarent croire et ce qu'ils font — entre l'idéologie officielle de la culture des logiciels au source ouvert et les pratiques réelles.

Les cultures sont des mécanismes adaptatifs. La culture des logiciels au source ouvert 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.

Les mots placés entre crochets font référence à la bibliographie ou aux notes rassemblées à la fin.

2. Les différentes idéologies des hackeurs [ Haut, § 01,03, 04,05,06,07,08, 09,10,11,12,13, 14,15,16,17,18, 19,20,21, 22,23 ]

L'idéologie de la culture des logiciels au source ouvert 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 au source ouvert (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 de s'y consacrer 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 fanatisme. Le développement de logiciels au source ouvert 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 fanatique zélé pourrait dire « Les logiciels au source ouvert sont ma vie ! J'existe pour créer des programmes utiles et beaux ou pour écrire des documentations et pour les distribuer librement. » Une personne d'une ferveur modérée dirait : « Les logiciels au source ouvert 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 au source ouvert sont parfois corrects. Je joue avec et je respecte les gens qui les font. »

Un autre degré de liberté est l'hostilité aux logiciels commerciaux et/ou aux 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 au source ouvert pour mettre fin à ce mal ! » 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 au source ouvert uniquement parceque 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 au source ouvert. Il est nécessaire d'exhiber 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 fanatique et très anti-commerciale. La « Free Software Foundation » fondée par Richard M. Stallman (RMS) a encourager activement le développement des logiciels au source ouvert depuis le début des années 1980, en fournissant des outils tels que Emacs et GCC, qui sont toujours la base du monde des logiciels au source ouvert sur Internet, et semblent devoir le rester encore un certain temps.

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

N.D.T. : le mot "free" signifie à la fois « libre » et « gratuit » en anglais, mais Richard Stallman, fondateur de la FSF, l'a uniquement choisi pour la première de ces deux acceptions. (le nouveau label «  open source », lui, évite cela).

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 (RMS, 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 « Stamp Out Software Hoarding! » (Luttez contre la rétention des logiciels) devint la doctrine des hackeurs et RMS 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 au source ouvert. 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é seul sur ce créneau. Il y a toujours eu un autre mouvement au sein de la culture hackeur, plus calme, moins provocateur, et plus permissif en ce qui concerne la vente des logiciels. Les pragmatistes n'étaient pas tant fidèles à une idéologie qu'à un groupe de traditions scientifiques fondées aux débuts du mouvement des logiciels au source ouvert, 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 au source ouvert. Si le pragmatiste 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 pragmatiste, la GPL est un outils 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 au source ouvert 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 fanas 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'ont pas mené à des communautés bazar de taille conséquente furent un échec et n'ont abouti qu'à de petits groupes dispersés et inefficaces.

Les pragmatistes 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 à RMS, 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 effet de bord 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 « The choice of a GNU generation (NdT : « Le choix d'une GNUvelle génération ») », la plupart tendent à se conformer à Torvalds plutôt qu'à Stallman.

De plus en plus, les anti-commerciaux fanatiques se retrouvèrent en minorité. Le fait que les choses aient 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 au source 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 pragmatistes 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 au source ouvert, et en refusant la GPL.

3. Théorie libertine, pratique puritaine [ Haut, § 01,02,03, 04,05,06,07,08,09, 10,11,12,13,14, 15,16,17,18,19, 20,21,22,23 ]

À travers tous ces changements, malgré tout, demeura un large consensus sur ce qu'étaient les « logiciels libres » et les « logiciels au source ouvert ». La preuve la plus éclatante de cette théorie commune peut être trouvée dans les diverses licences de logiciels au source ouvert, toutes ont des dénominateurs communs cruciaux.

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 au source ouvert (Définition de l'« Open Source »). Dans les lignes directrices définies par l'OSD (Open Source Definition), une licence de logiciel au source ouvert doit protéger un droit inconditionnel de tout parti à modifier (et redistribuer les versions ainsi modifiées) le logiciel au source ouvert.

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 au source 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és 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 lequel tout le monde peut hacker n'importe quoi, la culture des logiciels au source ouvert 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 accentue grandement ses règles. C'est pour cela qu'il serait utile pour la suite que nous en résumions quelques 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 à 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.
• Enlever 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 ce papier, 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 au source ouvert.

4. Propriété et logiciels au source ouvert [ Haut, § 01,02,03,05,06,07,08,09, 10,11,12,13,14, 15,16,17,18,19, 20,21,22,23 ]

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 ni capable de faire appliquer des lois, ni dans une situation économique où les ressources sont limitées ?

En fait, dans le cas des logiciels au source ouvert, c'est une question à laquelle il est facile de répondre. Le(s) propriétaire(s) d'un projet 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 de logiciels au source ouvert standard, tous sont égaux dans le jeu de l'évolution. En pratique, il y a toutefois une distinction, reconnue par tous, entre les patchs

NdT : Modification d'un programme dans le but de corriger des erreurs ou d'introduire de nouvelles fonctionnalités.

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 au source 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 tels passations de pouvoirs sont généralement annoncées en fanfare. Bien que la communauté du logiciel au source ouvert n'ai 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. 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 dédiés à ce type de logiciels) 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 visibles seront vos efforts pour retrouver l'ancien propriétaire ou d'autres prétendants, plus votre revendication, s'il n'y a pas de réponse, sera légitimée.

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 marquer 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 l'avant FSF, l'antiquité des logiciels au source ouvert. 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 conscient. 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 au source ouvert, et je peux malgré tout compter le nombre de violations significatives à ces règles sur les doigts.

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 au source ouvert, 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 « wAr3z 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 [ Haut, § 01,02,03,04,06,07,08,09, 10,11,12,13,14, 15,16,17,18,19, 20,21,22,23 ]

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é que cela implique 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 que l'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 en défendre 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. 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 au source 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 » [N] 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 instances 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ésente l'ensemble des lieux virtuels des médias électroniques parfois appelés (au grand dam de la plupart des hackeurs) « cyber-espace ». 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 lesquels une partie du « cyber-espace » réside, possède, en conséquence, cette partie du cyber-espace.

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 au source ouvert 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 au source 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 au source ouvert 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 même, la culture des logiciels au source ouvert n'ayant rien qui ressemble de loin à de l'argent ou à une économie de marché, les hackeurs ne peuvent donc pas rechercher un quelconque bien matériel.

Il existe cependant une façon de s'enrichir grâce aux logiciels au source ouvert — 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 au mieux 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 au source ouvert permet en elle-même d'expliquer beaucoup de choses.

6. Culture hackeur, culture du don [ Haut, § 01,02,03, 04,05,07,08,09, 10,11,12,13,14, 15,16,17,18,19, 20,21,22,23 ]

Pour comprendre le rôle de la réputation dans la culture des logiciels au source ouvert, il est utile de considérer tout cela dans une optique anthropologique ou économique plutôt qu'historique, et d'examiner la différence entre des cultures d'échange et des cultures du don.

Les être 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 aux 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'à petite échelle [Mal] ; il devient de plus en plus violent et inefficace lorsque sa taille augmente. 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'ajuste 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 c'est en fait l'effet dominant du désir de compétition que de produire un comportement de coopération). 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 au source ouvert de bonne qualité.

Si on en fait un telle lecture, il est clair que la culture des logiciels au source ouvert 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 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 [HH] ; 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 le reste de cet article.

7. Le plaisir du hack [ Haut, § 01,02,03,04,05,06,08,09,10,11,12,13,14,15,16,17,18,19,20,21, 22 ]

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 de maximiser à 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 comme une culture du don. Comment peut-on maximiser 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 que lui 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 certains aspects des comportements individuels suffisamment bien.

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 [ Haut, § 01,02,03,04,05,06,07,09, 10,11,12,13,14, 15,16,17,18,19, 20,21,22,23 ]

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 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 original et vous faire atteindre dans le deuxième 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 qui brigue un statut social plus élevé dépend fortement du jugement critique de ses pairs.

Une autre particularité de la culture des logiciels au source ouvert est sa relative pureté. La plupart des cultures du don sont compromises — soit par des liens avec l'économie d'échange tel 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 au source ouvert. En dehors de la réputation au yeux de ses pairs, il n'y a virtuellement aucun salut.

9. Droits de propriété et motivation de la réputation
[ Haut, § 01,02,03,04,05,06,07,08,10,11,12,13,14,15,16,17,18,19,20,21,22,23 ]

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 bords que cela implique.

À partir de là, nous pouvons analyser les coutumes de la propriété Lockéenne des hackeurs comme un moyen de maximiser 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 binaires pirates) expose les propriétaires à un injuste risque sur leur réputation. Même si le code officiel est parfait, les propriétaires endureront les critiques des bogues des patchs (mais voir [RP]).
• Enlever discrètement le nom de quelqu'un d'un projet est, dans ce contexte culturel, l'un des plus grands crimes qui existent. 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 au source ouvert 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 soit 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 coté 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 ce tabou soit rarement analysé plus profondément que « 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 [ Haut, § 01,02,03,04,05,06,07,08,09,11,12,13,14,15,16,17,18,19,20,21,22,23 ]

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 malgré le fait qu'elles violent l'esprit des licences standard.

J'ai observé un autre exemple intéressant de ce phénomène en discutant 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 basé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 europo-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 prima donna, 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 Raud ne l'avaient pas déjà fait en démystifiant fort bien (quels qu'aient été leurs échecs par ailleurs) « l'altruisme » sous 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 contenté-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 qui leur serait 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é [ Haut, § 01,02,03,04,05,06,07,08,09,10,12,13,14,15,16,17,18,19,20,21,22,23 ]

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

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

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

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

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

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

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

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

12. Conséquences du modèle du jeu des réputations
[ Haut, § 01,02,03,04,05,06,07,08,09,10,11,13,14,15,16,17,18,19,20,21,22,23 ]

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 juste 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

N.D.T. : le « mythe de la frontière » est cher aux états-uniens, 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). À tout instant, on s'intéressait à la position de la frontière séparant les terres colonisées des terres encore sauvages.

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 dans ce domaine depuis les années 80. À la place les gens écrivent des modes 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édictible, de projets à travers le temps. Dans les années 70, la majorité des logiciels au source ouvert existants étaient des gadgets et des démos. Dans les années 80, la tendance allait vers le développement et les outils Internet

N.D.T. : l'auteur oublie le projet GNU, initié par Richard Stallman en 1983, qui est un système d'exploitation, ainsi que le début des systèmes BSD libres sur ordinateur personnel.

Cette tendance a des conséquences intéressantes pour un futur proche. Au début de l'année 1998, Linux ressemble beaucoup à un tueur de concurrence pour la niche des « systèmes d'exploitation ouverts » — les gens qui autrement auraient pu écrire des systèmes d'exploitations concurrents, écrivent à présent des pilotes ou des extensions à la place. Et la plupart des outils de bas niveau dont les gens ont pu espérer une version au source ouvert 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 au source ouvert va peu à peu conquérir le dernier territoire vierge — notamment avec des logiciels pour les non spécialistes. Une prémisse clair en est le développement de GIMP, l'équivalent de Photoshop pour la manipulation d'images, qui est la première application au source ouvert 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 vous appellent un hackeur. Un « hackeur », vu sous cet angle, est quelqu'un qui a su prouver (par 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 ancrés dans cette culture.

13. Propriété de la Noosphère et éthologie du territoire
[ Haut, § 01,02,03,04,05,06,07,08,09,10,11,12,14,15,16,17,18,19,20,21,22,23 ]

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 ses 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 performant, 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 comporte d'importantes conséquences. L'une d'elles est d'expliquer la popularité des site Web, et plus spécialement pourquoi les projets de logiciels au source ouvert 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, d'une liste de diffusion, 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 au source 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 à tout instant duplicable. 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 « cyber-espace » 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 ont 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 au source ouvert. 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
[ Haut, § 01,02,03,04,05,06,07,08,09,10,11,12,13,15,16,17,18,19,20,21,22,23 ]

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 des droits de l'artisan à faire selon sa vision des choses que pour empêcher de fatiguer les ressorts de la réputation.

Le modèle de l'artisan n'est, cependant, 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 Haut, § 01,02,03,04,05,06,07,08,09,10,11,12,13,14,16,17,18,19,20,21,22,23 ]

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 de toutes les possibilités.

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 leur nom dans les fichiers de 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 que le « dictateur bienveillant » ne détient pas, en réalité, 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, sauf que le nom du contributeur reste dans les remerciements et qu'il continue à être associé au projet, même après avoir arrêté 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 remarque que cette règle délimite effectivement une propriété suivant le modèle Lockéen à l'intérieur du projet, et 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 clef. 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 ». Une façon de procéder est de transformer les co-développeurs en une commission de votants (comme pour Apache). Une autre façon est de faire tourner le titre de dictateur, dans ce 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 [ Haut, § 01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,17,18,19,20,21,22,23 ]

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, 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'aient fait.

17. Mécanismes d'acculturation et lien avec le modèle académique
[ Haut, § 01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,18,19,20,21,22,23 ]

L'une des premières versions de ce papier 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 à un niveau du subconscient, sont-ils 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 l'exemple d'un cas 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 depuis au moins 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é, certains 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 inhabituellement 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 poster 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érequis fonctionne à grande échelle à la manière dont des indices cachés fonctionnent à petite échelle, comme un filtre recherchant des qualités (telles que la capacité à l'abstraction, la persistence, 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 context 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 ce papier, 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 fac) 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. 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 d'un angle légèrement différent qu'une des spéculations de La cathédrale et le bazar , cela suggère que, finalement, 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
[ Haut, § 01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,18,19,20,21,22,23 ]

Nous avons examiné les coutumes qui régulent la propriété et contrôlent les logiciels au source ouvert. 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, peut-être, 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 [Miller], 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 au source ouvert, 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

N.D.T. : comme ceux qu'on trouve dans fufe, par exemple.

J'ai commencé a 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 ce papier 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 [ Haut, § 01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,19,20,21,22,23 ]

La culture des hackeurs (et moi) comprenons mal les grands projets qui ne suivent pas le modèle des dictateurs-bienveillants. La plupart de ces grands projets échoue. 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 leurs 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 invoqué ici ?

20. Bibliographie, notes et remerciements
[ Haut, § 01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,21,22,23 ]

[Miller] Miller, William Ian ; Bloodtaking and Peacemaking : Feud, Law, and Society in Saga Iceland; 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.

[Mal] 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.

[BCT] J. Barkow, L. Cosmides, and J. Tooby (Eds.) ; The adapted mind: Evolutionary psychology and the generation of culture. New York : Oxford University Press, 1992. Une excellente introduction à la psychologie évolutive. Certains de ces papiers 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.

[MHG] Goldhaber, Michael K. ; "The Attention Economy and the Net". J'ai découvert ce papier 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 ».

[HH] J'ai résumé l'histoire du hack sur http://www.linux-france.org/article/these/hackers_history/fr-a_brief_history_of_hackerdom.html. Le livre qui l'expliquera en détail reste encore à écrire, probablement pas par moi.

[N] 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-sfere (deux sons en [o], l'un long et appuyé, l'autre court et rapide). Si vous êtes particulièrement tâtillon sur l'orthographe, cela devrait normalement s'écrire avec un tréma sur l'un des « o » — mais ne me demandez pas lequel.

[RP] Il existe quelques subtilités à propos des patchs incontrôlés. On peut les classer en deux catégories, les « amis » et les « nuisibles ». Un patch « ami » est conçu pour être intégré aux sources du projet sous le contrôle des mainteneurs (que cette intégration se fasse ou pas). Un patch « nuisible » essaye de détourner le projet dans une direction que les mainteneurs désapprouvent. Certains projets (notamment celui du noyau Linux lui-même) sont plutôt permissifs à propos des patchs amis et en encouragent même des distributions indépendantes en les considérant comme une phase de leur bêta-test. D'un autre côté, un patch nuisible représente une volonté de concurrence avec le projet original et c'est un problème grave. Devoir maintenir un grand nombre de patchs nuisibles tend à conduire un projet à la scission.

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 [ Haut, § 01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,22,23 ]

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ée

N.D.T. : elle a un problème d'ego surdimensionné

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 RMS, 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). Un peu plus 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 du traducteur [ Haut, § 01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,23 ]

bitouiller bitouiller v. tr. — Touiller des bits.

cracker 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 crackeur n. m. — de l'angl. cracker. Criminel informatique. Un crackeur s'est introduit dans notre site cette nuit.

hack 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 hacker v. tr. — de l'angl. hack. Inventer, bitouiller, bricoler, la plupart du temps dans le domaine de l'informatique. Pas de problème je vais te hacker une solution vite fait.

hackeur hackeur n. m. — de l'angl. hacker. Inventeur, bitouilleur, bricoleur, la plupart du temps dans le domaine de l'informatique. Ce type est un vrai hackeur !

FSW 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 ».

OSS logiciel au source 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.

23. Remerciements du traducteur [ Haut, §01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21,22 ]

Un grand merci à :

• Marie-Aurore Soudant pour son aide pour les sections :
  Le problème de l'ego, La valeur de l'humilité, Conséquences du modèle du jeu des réputations,
  Propriété de la Noosphère et éthologie du territoire.
• Nikky pour son anglais et ses réponses à mes questions.
• Nat Makarévitch pour m'avoir encouragé à persévérer et pour sa relecture patiente et avisée.
• Et bien sûr à Ducat Enragé pour m'avoir mis dans le bain du petit monde de la traduction française. :- )