Après avoir observé une contradiction entre l'idéologie
«officielle» définie par les licences de logiciels
à sources ouverts et le comportement réel des hackeurs,
nous examinons les véritables coutumes contrôlant cette
culture. Nous découvrons que cela implique une théorie
des droits de possession sous-jacente, qui est proche de la théorie
de Locke sur la propriété foncière. Nous analysons
la culture hackeur comme une «culture du don» dans laquelle
les participants rivalisent pour le prestige en donnant du temps,
de l'énergie et de la créativité. Nous examinons
ensuite les implications de cette analyse pour la résolution
des conflits dans cette culture et nous développons quelques
idées pour approfondir cette réflexion.
1. Une contradiction liminaire
Tout ceux qui observent le monde agité et formidablement
prolifique des logiciels à sources ouverts sur l'Internet depuis
un certain temps ont inévitablement remarqué une contradiction
intéressante entre ce en quoi les développeurs de logiciels
à sources ouverts déclarent croire et leur manière
de se comporter - entre l'idéologie officielle de la culture
des logiciels à sources ouverts et les pratiques réelles.
Les cultures sont des machines adaptatives. La culture
des logiciels à sources ouverts est une réponse à
un ensemble identifiable de motivations et de contraintes. Comme d'habitude,
l'adaptation d'une culture à ce genre de circonstances se manifeste
à la fois par une idéologie consciente, mais aussi comme
un savoir implicite, inconscient ou semi-conscient. Et, comme c'est
souvent le cas, les adaptations inconscientes sont partiellement en
contradiction avec l'idéologie consciente.
Dans cet article, nous allons faire apparaître
les origines de cette contradiction, et l'utiliser pour découvrir
les coutumes et les contraintes de cette culture. Nous allons en déduire
quelques mécanismes intéressants relatifs à la
culture hackeur et à ses coutumes. Nous conclurons en suggérant
des manières de procéder qui permettent de tirer parti
de la connaissance de cette culture implicite.
2. Les différentes idéologies des hackeurs
L'idéologie de la culture des logiciels à
sources ouverts sur Internet (celle en laquelle croient les hackeurs)
est un sujet déjà assez compliqué en lui-même.
Tous ses membres s'accordent sur le fait que les logiciels à
sources ouverts (c'est-à-dire les logiciels librement redistribuables
et qu'on peut facilement faire évoluer et modifier en fonction
de ses besoins) sont une bonne chose et valent la peine qu'on s'y consacre
de façon significative. Cette position définit efficacement
l'appartenance à cette culture. Pourtant, les raisons pour lesquelles
des individus et différentes sous-cultures adhèrent à
cette croyance sont très variées.
L'un de ces degrés de liberté est le
zélotisme. Le développement de logiciels à sources
ouverts est simplement vu, soit comme un moyen pratique pour atteindre
un but (de bons outils, des gadgets amusants et des jeux intéressants),
soit comme une fin en soi.
Un zélote extrémiste pourrait dire: «Les
logiciels libres sont ma vie! J'existe pour créer des programmes
utiles et beaux ou pour écrire des documentations et pour les
distribuer librement.» Un zélote 'modéré'
dirait: «Les logiciels à sources ouverts sont une bonne
chose, pour laquelle je suis prêt à sacrifier une bonne
partie de mon temps.» Une personne peu attachée à
la cause dirait: «Oui, les logiciels à sources ouverts
sont parfois corrects. Je joue avec et je respecte les gens qui les
font.»
Un autre degré de liberté est l'hostilité
à l'égard des logiciels commerciaux et/ou des compagnies
perçues comme dominant le marché des logiciels.
Quelqu'un de très anti-commercial pourrait dire:
«Les logiciels commerciaux, c'est du vol, de la rétention
d'information! J'écris des logiciels à sources ouverts
pour mettre un terme à ce fléau!» Une personne modérément
anti-commerciale pourra dire: «Les logiciels commerciaux sont
en général acceptables, parce que les programmeurs méritent
d'être payés, mais les compagnies qui se la coulent douce
en vendant de la camelote et en usant de leur poids pour imposer leurs
produits sont mauvaises.» Un pro-commercial dira par exemple:
«Les logiciels commerciaux sont bons, j'utilise /j'écris
des logiciels à sources ouverts uniquement parce que je les trouve
meilleurs.»
Les neuf attitudes qui découlent des combinaisons
de ces catégories sont toutes présentes dans la culture
des logiciels à sources ouverts. Il est nécessaire de
mettre en évidence ces distinctions car cela induit différentes
priorités et différents comportements adaptatifs et coopératifs.
Historiquement, l'organisation la plus connue et la
mieux organisée de la culture hackeur a été à
la fois très zélote et très anti-commerciale. La
Free Software Foundation (FSF) fondée par Richard M. Stallman
(RMS) a encouragé activement le développement des logiciels
à sources ouverts depuis le début des années 1980,
en fournissant des outils tels que Emacs et GCC (1).
Pendant longtemps la FSF était le seul point
de ralliement des développeurs de logiciels à sources
ouverts. Elle a conçu un grand nombre d'outils fondamentaux pour
cette culture. La FSF était aussi le seul sponsor des logiciels
à sources ouverts avec une identité institutionnelle visible
par des observateurs extérieurs à la culture hackeur.
En fait, ses membres ont défini le terme de «free software»
(logiciel libre), en lui donnant délibérément un
nom provocateur (2).
Ainsi, la perception de la culture hackeur, à
la fois de l'extérieur et de l'intérieur, tendait à
être identifiée avec l'attitude de la FSF, à la
fois frénétique et perçue comme anti-commerciale
(Richard M. Stallman, lui-même, dément avoir cette attitude
anti-commerciale, mais son attitude a été interprétée
comme telle par un très grand nombre de gens, dont ses plus fervents
défenseurs). La conduite énergique et explicite de la
FSF pour «luttez contre la rétention des logiciels»
(Stamp Out Software Hoarding!), devint la doctrine des hackeurs
et Richard M. Stallman est devenu le chef de file de cette culture.
Les termes de la licence de la FSF, la «General
Public License» (GPL), traduisent l'attitude de la FSF. Elle
est largement utilisée dans le monde des logiciels à sources
ouverts. Le site Sunsite, en Caroline du Nord, est le plus populaire
des sites d'archives de logiciels dans le monde Linux. En juillet 1997
à peu près la moitié des paquetages de logiciels
de Sunsite utilisaient la licence GPL.
Mais la FSF n'a jamais été seule sur
ce créneau. Il y a toujours eu un autre mouvement au sein de
la culture hackeur, plus calme, moins provocateur, et plus tolérant
en ce qui concerne la vente des logiciels. Les pragmatiques n'étaient
pas tant fidèles à une idéologie qu'à un
ensemble de traditions scientifiques fondées aux débuts
du mouvement des logiciels à sources ouverts, et antérieures
à la FSF. Ces traditions mêlaient, avant tout, la culture
technique d'Unix et l'Internet pré-commercial.
L'attitude typique d'un pragmatiste est seulement modérément
anti-commerciale, et son grief majeur envers le monde des entreprises
n'est pas la rétention des sources en elle-même. C'est
plutôt un ressentiment envers cette culture perverse qui refuse
d'intégrer l'approche plus efficace d'Unix, des standards et
des logiciels à sources ouverts. Si le pragmatique déteste
quelque chose en particulier c'est moins souvent le fait d'être
privé des sources de ses logiciels que le Roi du logiciel du
moment; IBM autrefois, Microsoft aujourd'hui.
Pour le pragmatique, la GPL est un outil important,
mais pas une fin en soi. Son utilité principale n'est pas d'être
une arme contre la rétention d'informations, mais plutôt
un moyen d'encourager la communauté des développeurs au
partage des logiciels et à l'adoption du modèle de programmation
de type «bazar». Le pragmatiste accorde plus de valeur aux
bons outils et aux gadgets qu'il ne déteste le commerce et il
peut utiliser des outils commerciaux de bonne qualité sans se
poser de problème de conscience. En même temps, son expérience
des logiciels à sources ouverts l'a habitué à une
qualité technique que très peu de logiciels fermés
peuvent atteindre.
Pendant de longues années, le point de vue des
pragmatistes était principalement exprimé, au sein de
la culture hackeur, comme un refus obstiné d'adopter la GPL en
particulier ou les idées de la FSF en général.
Dans les années 80 et au début des années 90, cette
attitude tendait à être associée aux fanatiques
de l'Unix de Berkeley, aux utilisateurs de la licence BSD et aux pionniers
qui avaient tenté de constituer un Unix libre à partir
des sources de BSD. Cependant, ces efforts, n'ayant pas mené
à la consitution de communautés «bazar» de
taille conséquente, furent un échec et n'ont produit que
de petits groupes dispersés et inefficaces.
Les pragmatiques ne commencèrent à avoir
du poids qu'avec l'avènement de Linux en 1993-1994. Bien que
Linus Torvalds n'ait jamais souhaité s'opposer à Richard
M. Stallman, il s'est posé en exemple en regardant d'un oeil
bienveillant la croissance de l'industrie commerciale autour de Linux,
approuvant l'utilisation de logiciels commerciaux de bonne qualité
pour des tâches spécifiques, et en raillant gentiment les
éléments les plus puristes et les plus fanatiques de la
culture hackeur.
La croissance rapide de Linux a eu pour conséquence
l'arrivée d'un grand nombre de nouveaux hackeurs dévoués
à Linux et pour lesquels la FSF n'avait qu'un intérêt
historique. Bien que la nouvelle vague de hackeurs Linux décrive
ce système comme «le choix d'une GNUvelle génération
(The choice of a GNU generation), la plupart tendent à
se réclamer de Torvalds plutôt que de Stallman.
De plus en plus, les puristes anti-commerciaux se retrouvèrent
en minorité. Le fait que les choses ont changé ne devint
apparent qu'à l'annonce faite par Netscape en février
1998 de la mise en libre accès des sources de Navigator 5.0,
ce qui a attisé l'intérêt que l'industrie portait
au «logiciel libre». Cette annonce sans précédent
a eu pour conséquence le changement de nom de «logiciel
libre» à «logiciel ouvert», qui s'est produit
avec une facilité qui a surpris tous les acteurs de cette affaire.
Alors que le développement prenait de l'ampleur,
le groupe des pragmatiques commençait lui aussi à se diversifier
au milieu des années 1990. D'autres communautés semi-indépendantes,
conscientes d'elles-mêmes, avec leurs propres chefs charismatiques,
commencèrent à percer au sein de la culture Unix/Internet.
Parmi celles-ci, la plus importante, après celle de Linux, fut
celle de Perl, dirigée par Larry Wall. Plus petites, mais tout
aussi importantes, furent les traditions construites autour des langages
Tcl de John Osterhout et Python de Guido Van Rossum. Ces trois communautés
ont exprimé leur indépendance idéologique en concevant
leurs propres licences de logiciels à sources ouverts, et en
refusant la GPL.
3. Théorie libertine, pratique puritaine
Malgré tout, à travers ces changements,
demeura un large consensus sur ce qu'étaient les «logiciels
libres» ou les «logiciels à sources ouverts».
La preuve la plus éclatante de cette communauté théorique
réside dans l'existence de nombreux dénominateurs qui
unissent les différentes licences de logiciels.
En 1997, ces éléments communs furent
distillés dans le manifeste du logiciel libre de la Debian,
qui est depuis devenu la définition du logiciel ouvert (Open
Source Definition). Dans les lignes directrices définies
par l'OSD (Open Source Definition), une licence de logiciel ouvert
doit protéger un droit inconditionnel de toute partie à
modifier le logiciel ouvert (et à en redistribuer les versions
ainsi modifiées).
Par conséquent, la théorie implicite
de l'OSD (ainsi que celle des licences qui se conforment à l'OSD
telles que la GPL, la licence BSD, et la licence artistique de Perl)
est que n'importe qui peut hacker n'importe quoi. Rien n'empêche
une demi-douzaine de personnes de prendre n'importe quel logiciel ouvert
(tel que GCC, le compilateur C de la FSF), de dupliquer ses sources,
et de le développer dans différentes directions, tout
en clamant haut et fort qu'il s'agit là de la vraie version
du programme.
En pratique, pourtant, de telles «scissions»
n'arrivent quasiment jamais. Les ruptures dans les projets majeurs ont
été rares, et toujours accompagnées d'un changement
de nom et d'un grand nombre de justifications publiques. Il est clair
dans des cas comme la séparation de GNU Emacs/ XEmacs, celle
de GCC/EGCS, ou encore les différents schismes des groupes de
BSD, que les dissidents sentaient qu'ils s'opposaient à une norme
partagée par tous.
En fait, contrairement à la théorie du
consensus selon laquelle tout le monde peut hacker n'importe quoi, la
culture des logiciels à sources ouverts dispose d'un ensemble
de coutumes complexes, mais très largement refoulées,
sur la propriété. Ces coutumes décident de qui
peut modifier un logiciel, des circonstances selon lesquelles il peut
le modifier, et (en particulier) qui a le droit de redistribuer les
versions modifiées à la communauté.
Les tabous d'une culture accentuent grandement ses
règles. C'est pour cela qu'il serait utile pour la suite que
nous en résumions quelques-uns des plus importants.
- Il existe une forte pression sociale contre la
scission de projets. Cela n'arrive pas, sauf si l'on plaide l'absolue
nécessité avec de nombreuses justifications publiques
et un changement de nom du projet.
- Distribuer des modifications d'un projet sans la
coopération des modérateurs est mal vu, sauf dans certains
cas, comme par exemple des corrections mineures pour porter le logiciel
sous une nouvelle architecture.
- Retirer le nom d'une personne de l'histoire d'un
projet, des remerciements ou de la liste des mainteneurs est absolument
impossible sans le consentement explicite de la personne.
Dans le reste de cet article, nous examinerons en détail
tabous et coutumes sur le droit de propriété. Nous ne
nous demanderons pas seulement comment tout cela fonctionne, mais aussi
ce que cela révèle sur la dynamique sociale sous-jacente
et sur ce qui motive la communauté du logiciel ouvert.
4. Propriété et logiciels à sources
ouverts
Que signifie le terme «propriété»
lorsque ce qui est possédé est duplicable à l'infini,
hautement malléable, et que la culture environnante n'est plus
capable de faire appliquer des lois, et n'est plus dans une situation
économique où les ressources sont limitées ?
En fait, dans le cas des logiciels à sources
ouverts, c'est une question à laquelle il est facile de répondre.
Le (ou les) propriétaire(s) d'un projet est celui qui a (ou sont
ceux qui ont) le droit exclusif, et reconnu comme tel par l'ensemble
de la communauté, d'en redistribuer des versions modifiées.
(Nous parlerons de «propriétaire»
au singulier, comme si tous les projets appartenaient à une seule
personne. Cependant, il doit être clair que les projets peuvent
appartenir à des groupes. Nous examinerons les dynamiques internes
de tels groupes plus tard dans cet article.)
Selon les licences ouvertes standard, tous sont égaux
dans le jeu de l'évolution. En pratique, il y a toutefois une
distinction, reconnue par tous, entre les patchs (3)«officiels»,
approuvés et intégrés dans le logiciel par les
mainteneurs publiquement reconnus, et les patchs «pirates»,
proposés par des tiers. Les patchs pirates sont peu fréquents
et, en général, considérés comme peu sûrs.
Il est facile d'établir que la redistribution
publique est un enjeu fondamental. L'usage encourage les gens à
patcher le logiciel pour un usage personnel lorsque c'est nécessaire,
et de ne pas prêter attention aux gens qui redistribuent des versions
modifiées au sein d'un groupe fermé d'utilisateurs ou
de développeurs. C'est uniquement lorsque les modifications sont
diffusées à la communauté en général,
en concurrençant l'original, que la notion de propriété
du projet entre en ligne de compte.
Il existe en général trois manières
de devenir le responsable d'un projet de logiciel ouvert. La première,
la plus évidente, est de le créer. Lorsqu'un projet ne
compte qu'un mainteneur depuis son origine et que ce mainteneur est
toujours actif, l'usage ne permet même pas de remettre en cause
cette autorité.
La deuxième manière de devenir responsable
d'un projet, c'est de se faire confier cette charge par le précédent
propriétaire (on appelle parfois cela «passer le relais»).
Il est évident pour la communauté que les responsables
de projets ont le devoir de choisir un successeur compétent lorsqu'ils
ne veulent ou ne peuvent plus investir le temps nécessaire dans
le développement ou la maintenance du projet.
Il est révélateur que dans le cas de
projets importants, de telles passations de pouvoir sont généralement
annoncées à grand renfort de fanfare. Bien que la communauté
du logiciel ouvert n'ait jamais vraiment remis en cause le choix d'un
successeur par le responsable d'un projet, il est important que, dans
la pratique, le dauphin apparaisse légitime aux yeux de la communauté.
Pour les projets mineurs, il est généralement
suffisant de modifier le nom du propriétaire du projet dans le
fichier d'historique joint à la distribution (4).
On présume que si le propriétaire précédent
n'a pas, en réalité, passé le relais volontairement,
il ou elle pourra reprendre le contrôle de son projet, soutenu
par la communauté, en objectant publiquement dans un délai
raisonnable.
La troisième façon de prendre les rênes
d'un projet est d'avoir des idées de développement, alors
que le responsable précédent a disparu ou perdu tout intérêt
pour ce programme. Si sa succession vous intéresse, il vous faut
le rechercher. S'il reste introuvable, alors vous devez annoncer dans
un endroit approprié (comme les forums de Usenet (5))
que le projet semble orphelin et que, dorénavant, vous envisagez
de prendre les choses en main.
L'usage veut que vous laissiez passer un peu de temps
avant de vous déclarer le nouveau responsable du projet. Si pendant
ce laps de temps, quelqu'un annonce qu'il travaillait déjà
sur ce projet, son annonce l'emporte sur la vôtre. Il est de bon
ton d'annoncer publiquement vos intentions plus d'une fois. Vous vous
légitimerez d'autant plus si vos annonces sont faites dans de
nombreux forums adéquats (forums connexes, listes de diffusions)
et si vous faites preuve de patience en attendant d'éventuelles
réponses. En général, plus vos efforts seront visibles
pour retrouver l'ancien propriétaire ou d'autres prétendants,
plus votre revendication sera légitimée, s'il n'y a pas
de réponse.
Si vous avez passé avec succès toutes
ces étapes devant l'assemblée des utilisateurs du projet
et qu'il n'y a pas d'objection, alors vous pouvez vous proclamer propriétaire
de ce projet orphelin et inscrire votre nom dans le fichier d'historique
du projet. Cependant, cette méthode est moins sûre que
celle du passage de relais, et vous ne pouvez pas vous attendre à
être considéré comme pleinement légitimé,
du moins pas avant d'avoir réalisé d'importantes améliorations
sur le projet, aux yeux de tous.
J'ai observé ces coutumes en action depuis 20
ans, depuis la pré-FSF, dans l'Antiquité des logiciels
à sources ouverts. Elles ont un certain nombre de caractéristiques
très intéressantes. L'une des plus intéressantes
est que la plupart des hackeurs les ont respectées sans en être
pleinement conscients. En effet, ce qui est écrit ici semble
être la première mise au point consciente et raisonnablement
complète jamais faite.
Autre fait intéressant, ces coutumes inconscientes
ont été appliquées avec une cohérence remarquable,
voire surprenante. J'ai observé l'évolution de centaines
de projets de logiciels à sources ouverts, et je peux malgré
tout compter sur les doigts d'une main le nombre de violations significatives
à ces règles.
Un troisième fait intéressant est que
ces coutumes ont toujours évolué dans la même direction.
C'est-à-dire en responsabilisant davantage le public, en l'informant
plus, et en prenant garde de préserver les mérites et
l'historique des projets de façon à établir la
légitimité des propriétaires du moment (entre autres
choses).
Ces particularités suggèrent que ces
coutumes ne sont pas fortuites, mais l'effet d'une organisation spontanée,
implicite, ou d'une finalité (generative pattern) dans
la culture des logiciels à sources ouvertes, essentielle à
son fonctionnement.
L'une des premières remarques qu'on m'ait faite,
portait sur l'enseignement qu'on pouvait tirer du contraste entre la
culture des hackeurs sur Internet et la culture des crackeurs ou pirates
(l'activité des «wArez d00dz» consiste à cracker
des jeux et à pirater des BBS [Bulletin Board Systems]):
toutes deux ont leurs propres finalités. Nous reviendrons sur
ce contraste plus tard.
5. Locke et la propriété foncière
Pour comprendre cette organisation spontanée,
il est utile d'évoquer un cas historique assez semblable, pourtant
très éloigné du domaine habituel des hackeurs.
Comme le sait n'importe quel étudiant en histoire du droit et
en philosophie politique, la théorie de la propriété
dont il est question ici est virtuellement identique aux théories
des lois anglo-américaines de la propriété foncière!
Dans cette théorie, il y a trois façons
d'acquérir la propriété d'une terre.
À la limite du monde connu, là où
les terres n'ont encore jamais appartenu à personne, on les conquiert
en apportant son travail à la terre en friche, en la clôturant
et en défendant son titre de propriété.
Le moyen habituel pour hériter d'une terre dans
une zone colonisée est le transfert de titre, c'est-à-dire
recevoir le titre des mains du propriétaire précédent.
Dans cette théorie, le concept de «chaîne de titres»
est important. La preuve en est qu'on peut toujours remonter cette chaîne
jusqu'au propriétaire originel, qui a conquis le terrain.
Enfin, cette théorie prévoit le cas où
un titre de terrain serait perdu ou abandonné (si par exemple
le propriétaire meurt sans héritier, ou si les registres
nécessaires à l'établissement de cette chaîne
de titres pour des terrains inhabités ont disparu). Une étendue
de terrain laissée en friche peut être réclamée
par une partie adverse - qui s'y installe, l'aménage,
et la défend tout comme dans le cas d'une conquête.
Cette théorie, comme les coutumes des hackeurs,
a évolué de façon organique dans un contexte où
l'autorité centrale était faible ou non existante. Elle
s'est développée sur une période d'un millénaire
à partir des lois tribales scandinaves et allemandes. Étant
donné qu'elle fut systématisée et rationalisée
au début de l'ère moderne par le sociologue anglais John
Locke, on l'appelle parfois théorie «lockéenne»
de la propriété.
Évidemment, des théories similaires ont
eu tendance à apparaître partout où la propriété
avait une grande importance économique ou vitale et où
aucune autorité n'était suffisamment puissante pour centraliser
l'allocation des denrées rares. Cela est encore vrai dans les
cultures des chasseurs-cueilleurs, perçues de façon romantique
comme n'ayant pas de notion de «propriété».
Par exemple, dans la tradition des Bushmen !Kung San du désert
du Kalahari, le territoire de chasse n'appartient à personne.
Mais il y a une propriété des points d'eau et des
sources selon un modèle qui ressemble à la théorie
de Locke.
L'exemple des !Kung San est instructif, parce qu'il
montre que les coutumes décrites par Locke ne surviennent que
là où le bénéfice attendu d'une ressource
dépasse le coût de sa défense. Le territoire de
chasse n'est pas une propriété, car le profit de la chasse
est hautement aléatoire, variable et (bien que très prisé
socialement) pas vraiment nécessaire à la survie quotidienne.
Les points d'eau, au contraire, sont vitaux et suffisamment localisés
pour qu'on en défende l'accès.
La «noosphère» du titre de cet article
est le territoire des idées, l'espace de toutes les pensées
possibles (6). Ce que l'on voit implicitement
dans les coutumes du droit de propriété chez les hackeurs
est une théorie lockéenne de la propriété
sur un sous-ensemble de la noosphère, l'espace de tous les programmes.
La «conquête de la noosphère», est donc entreprise
par tous les fondateurs de nouveaux projets de logiciel ouvert.
Faré Rideau <fare@tunes.org>
fait remarquer à juste titre que les hackeurs n'opéraient
pas exactement dans le domaine des idées pures. Il soutient que
le propre des hackeurs est l'implémentation d'un projet
- la focalisation délibérée sur la partie matérielle
du travail (développement, service, etc.), à laquelle
sont associées la réputation, la confiance, etc. Il affirme
donc que l'espace couvert par les projets des hackeurs, n'est pas
la noosphère, mais une sorte de dual de celle-ci, c'est-à-dire
l'espace des diverses implémentations possibles des projets (pour
faire plaisir aux astrophysiciens, il serait étymologiquement
plus correct d'appeler cet espace dual «l'ergosphère»,
ou encore «la sphère du tangible»).
Mais la distinction entre noosphère et ergosphère
n'est pas cruciale pour le propos de cet article. On peut douter, à
moins d'être un philosophe platonicien, de l'existence d'une quelconque
«noosphère» au sens de Faré. Et la distinction
entre noosphère et ergosphère n'est que d'ordre pratique
pour ceux qui soutiennent la thèse que les idées (ou éléments
de la noosphère) n'appartiennent à personne, alors que
leurs réalisations sous forme de projets ont des propriétaires.
Cela nous mènerait à des questions relevant de la propriété
intellectuelle, et qui dépassent le cadre de cet article.
Néanmoins, pour éviter toute confusion,
il est important de remarquer que ni la noosphère, ni l'ergosphère,
ne représentent l'ensemble des lieux virtuels des médias
électroniques parfois appelés (au grand dam de la plupart
des hackeurs) «cyberespace». La propriété
y est régulée par des règles complètement
différentes, plus proches de celles qui sont utilisées
pour les biens matériels - essentiellement, celui qui possède
le média ou les machines sur lesquelles une partie du «cyberespace»
réside, possède, en conséquence, cette partie du
cyberespace.
La structure lockéenne suggère fortement
que les hackeurs respectent certaines coutumes afin de protéger
le bénéfice qu'ils espèrent retirer de leurs efforts.
Ce bénéfice doit être plus important que l'effort
de création des projets, le travail de maintenance de l'historique
des versions successives, le temps passé à faire des notifications
publiques, et le temps passé à ronger son frein avant
de pouvoir prendre possession d'un projet orphelin.
En outre, le «gain» apporté par
les logiciels à sources ouvertes doit dépasser leur seule
utilisation; il doit aussi être compromis ou dilué par
la scission d'un projet. Si seule l'utilisation du logiciel comptait,
il n'y aurait pas de tabou contre la scission, et le droit de propriété
d'un projet de logiciel ouvert ne ressemblerait en rien à la
propriété foncière. En fait, ce monde alternatif
(où l'usage des logiciels est le seul gain) est celui qui est
induit par les licences de logiciels à sources ouverts existantes.
On peut, d'ores et déjà, éliminer
certains candidats au titre de gain. Comme on ne peut contraindre personne
efficacement via une connexion réseau, la recherche du pouvoir
est impossible. De plus, la culture des logiciels à sources ouverts
n'ayant rien qui ressemble de près ou de loin à de l'argent
ou à une économie de marché, les hackeurs ne peuvent
donc pas rechercher un bien matériel quelconque.
Il existe cependant une façon de s'enrichir
grâce aux logiciels à sources ouverts - et cette méthode
donne de précieux indices quant à ses véritables
motivations. Parfois, la réputation acquise par certains au sein
de la culture hackeur peut se répandre dans le monde réel
et avoir des répercussions financières significatives.
Cela peut ouvrir l'accès à une offre d'emploi plus intéressante,
à un contrat de consultant, ou aiguiser l'intérêt
d'un éditeur.
Ce type d'effet de bord est rare et marginal pour la
plupart des hackeurs, ce qui est insuffisant pour en faire une explication
convaincante, même si on ignore les protestations répétées
des hackeurs clamant qu'ils ne font pas ça pour l'argent, mais
seulement par idéalisme ou par passion.
Pourtant, la médiatisation de cet effet de bord
justifie un examen plus approfondi. Nous verrons plus tard que la compréhension
de la dynamique engendrée par la réputation dans la culture
des logiciels à sources ouverts permet en elle-même
d'expliquer beaucoup de choses.
6. Culture du hack, culture du don
Pour comprendre le rôle de la réputation
dans la culture des logiciels à sources ouverts, il est utile
de considérer tout cela d'un point de vue anthropologique ou
économique plutôt qu'historique, et d'examiner la différence
entre des cultures d'échange et des cultures du don.
Les êtres humains ont un tendance innée
à rivaliser pour leur statut social; c'est un comportement profondément
ancré dans notre histoire. Pendant les 90 % de cette histoire
qui se sont déroulés avant l'invention de l'agriculture,
nos ancêtres vivaient regroupés en petites tribus nomades
de chasseurs-cueilleurs. Les individus des rangs sociaux les plus élevés
avaient accès aux femmes les plus robustes et aux meilleures
parts pendant les repas. Cette course au statut social s'exprime elle-même
de différentes façons, dépendant largement du degré
de pénurie des biens essentiels à la survie.
La plupart des modèles d'organisation des humains
sont dictés par une adaptation aux pénuries et aux désirs.
Chaque modèle porte en lui-même ses différentes
règles de progression sociale.
Le modèle le plus simple est le pouvoir centralisé.
Dans ce système, la répartition des ressources rares est
faite par une autorité centrale et maintenu par la force. Le
pouvoir centralisé n'est efficace qu'à une petite échelle
(7); il devient de plus en plus violent
et inefficace lorsque sa taille augmente (8).
C'est pour cela qu'au-delà de la taille d'une grande famille,
les pouvoirs centralisés sont, presque toujours, des parasites
d'un autre type d'économie, d'un type différent. Dans
ce modèle, le statut social est d'abord déterminé
par l'accès à un pouvoir répressif.
Notre société est principalement dans
une économie d'échanges. C'est une façon
sophistiquée de s'adapter aux pénuries qui, contrairement
au modèle centralisé, s'adapte plutôt bien aux changements
d'échelle. La répartition des ressources rares est faite
de manière décentralisée à travers le commerce
et la coopération volontaire (en fait, c'est l'effet dominant
du désir de compétition que de produire un comportement
de coopération (9)). Dans une
économie fondée sur l'échange, le statut social
est directement déterminé par le contrôle que l'on
a sur les marchandises (pas nécessairement matérielles)
à utiliser ou à commercer.
La plupart des gens ont un modèle mental implicite
pour les deux systèmes décrits précédemment,
et sur la manière dont ils interagissent. Le gouvernement, l'armée,
et le crime organisé (par exemple) sont des pouvoirs centralisés
qui parasitent l'économie d'échange, plus vaste, que nous
appelons le «marché libre». Il existe cependant un
troisième modèle, radicalement différent des autres
et rarement reconnu en tant que tel sauf par les anthropologues: la
culture du don.
Les cultures du don ne sont pas des réponses
à une pénurie, mais à une abondance. Elles surviennent
dans des populations qui ne souffrent pas de carences significatives
en biens de première nécessité. On peut observer
des cultures du don en action dans les cultures aborigènes vivant
dans des éco-zones au climat doux et à la nourriture abondante.
On peut aussi les observer dans certaines strates de notre propre société,
particulièrement dans le monde du spectacle et chez les gens
très riches.
L'abondance rend les ordres imposés par la force
difficiles à justifier et les échanges commerciaux presque
sans objet. Dans une culture du don, le statut social n'est pas déterminé
par ce que vous contrôlez, mais par ce que vous donnez.
D'où les cadeaux des participants à un
réveillon entre amis. Ou les actes de philanthropie raffinés
et souvent ostentatoires d'un multi-millionnaire. Et les longues heures
d'efforts du hackeur pour produire des logiciels à sources ouverts
de bonne qualité.
Si on en fait un telle lecture, il est clair que la
culture des logiciels à sources ouverts est en fait une culture
du don. En son sein, nul ne manque sérieusement de «produits
de première nécessité» - l'espace disque,
la bande passante réseau, la puissance de calcul. Le logiciel
est librement partagé. Cette abondance crée une situation
où la seule évaluation possible de la réussite
dans cette compétition est la réputation que chacun acquiert
auprès de ses pairs.
Cette observation ne suffit pas vraiment, cependant,
à expliquer les caractéristiques que l'on observe dans
la culture hackeur. Les crackeurs d00dz (10)ont
une culture du don qui prospère sur le même média
(électronique) que celui des hackeurs, mais leur comportement
est très différent. Dans leur culture, l'esprit de groupe
est plus fort et plus exclusif que chez les hackeurs. Ils conservent
jalousement leurs secrets plutôt que de les partager; on trouvera
plus fréquemment des groupes de crackeurs qui distribuent des
exécutables sans les sources pour cracker des logiciels que les
astuces pour les réaliser.
Tout cela prouve, au cas où ce n'était
pas évident, qu'il existe plusieurs manières d'envisager
la culture du don. L'histoire et les valeurs jouent un rôle important.
J'ai résumé l'histoire de la culture hackeur dans «Une
brève histoire des hackeurs» (For a brief History of
Hackerdoom) (11); la façon
dont elle a façonné les comportements actuels n'est pas
un mystère. Les hackeurs ont défini leur culture par un
ensemble de choix à propos de la forme que doit prendre leur
compétition. C'est cette forme que nous examinerons dans la suite
de cet article.
7. Le plaisir du hack
En faisant cette analyse du «jeu des réputations»,
mon but n'est pas de dévaluer ou de fermer les yeux sur la satisfaction
purement artistique de mettre au point et de faire fonctionner un bon
logiciel. Nous avons tous l'expérience de ce genre de satisfaction
et nous nous en réjouissons toujours. Ceux pour qui cette sensation
n'est pas une motivation importante ne deviennent jamais des hackeurs
de toutes manières, tout comme ceux qui n'aiment pas la musique
ne deviennent pas compositeurs.
Il nous faut donc probablement rechercher un autre
modèle comportemental des hackeurs, où le plaisir de l'artisan
est la motivation première. Ce modèle de «l'artisan»
aurait à expliquer les coutumes des hackeurs en tant que moyen
d'optimiser à la fois les possibilités de créations
et la qualité des résultats. Cela entre-t-il en conflit
avec le modèle du «jeu des réputations» ou
cela suggère-t-il des résultats différents?
Pas vraiment. En examinant le modèle de «l'artisan»,
on revient aux mêmes problèmes qui contraignent la communauté
des hackeurs à fonctionner au sein d'une culture du don. Comment
peut-on optimiser la qualité en l'absence de métrique
pour cette dernière? En l'absence d'économie de la pénurie,
que reste-t-il en dehors de l'évaluation par les pairs? Il semble
évident qu'en fin de compte, toute culture d'artisan doit se
structurer elle-même à travers un «jeu des réputations»
- et, en fait, c'est exactement cette dynamique que nous pouvons observer
dans de nombreuses cultures d'artisan, depuis le temps des guildes médiévales.
Le modèle de «l'artisan» cède
à la «culture du don» un avantage important: elle
explique bien mieux la contradiction que nous avons exposée au
début de cet article.
Finalement, la motivation de «l'artisan»
n'est peut-être pas aussi éloignée du «jeu
des réputations» que nous aimerions le croire. Imaginez
votre merveilleux programme enfermé dans un tiroir et plus jamais
utilisé. À présent, imaginez qu'il est utilisé
avec efficacité et plaisir par un grand nombre de personnes.
Quel rêve vous satisfait le plus ?
Toutefois, nous garderons un oeil sur le modèle
de l'artisan. Il plaît intuitivement à de nombreux hackeurs,
et il explique suffisamment bien certains aspects des comportements
individuels.
Après la publication de la première version
de cet article, un lecteur m'a écrit: «On ne travaille
peut-être pas pour la gloire, mais c'est la récompense
directe et certaine de tout travail bien exécuté.»
C'est une remarque subtile et importante. Qu'il en soit ou non conscient,
le travail de l'artisan induit sa renommée; ainsi, qu'un hackeur
considère ou non son propre comportement comme un élément
du «jeu des réputations», ce dernier ne l'en façonnera
pas moins.
8. Les multiples facettes de la réputation
Il existe des raisons communes à toutes les
cultures du don qui justifient la recherche d'une bonne réputation
auprès de ses pairs (prestige):
Premièrement, et c'est le plus évident,
jouir d'une bonne réputation auprès de ses pairs est la
récompense la plus appréciable. Pour des raisons dues
à notre évolution, dont on a parlé plus haut, c'est
un fait inscrit au plus profond de notre être. (Nombreux sont
ceux qui subliment la recherche du prestige sous des formes sans rapport
évident à un groupe de pairs, telles que «l'honneur»
«l'intégrité éthique», «la piété»,
etc. Mais cela ne change pas le mécanisme sous-jacent.)
Deuxièmement, le prestige est un bon moyen (et,
dans une pure culture du don, l'unique moyen) d'attirer l'attention
et la coopération des autres. Si quelqu'un est bien connu pour
sa générosité, son intelligence, son honnêteté,
son charisme, ou pour d'autres qualités, il lui devient bien
plus facile de convaincre les autres qu'ils gagneront à s'associer
avec lui.
Troisièmement, si votre économie du don
est en contact ou mélangée avec une économie d'échanges
ou un pouvoir centralisé, votre réputation peut déborder
de votre milieu originel et vous faire atteindre un statut plus élevé.
Au-delà de ces raisons générales,
les caractéristiques particulières de la culture des hackeurs
font que le prestige est encore plus précieux qu'il ne le serait
dans une culture du don du «monde réel».
La principale de ces «conditions particulières»
est que les artefacts qui sont donnés à la communauté
(ou, si on l'interprète différemment, qui représentent
le signe visible de l'énergie et du temps déployés)
sont très complexes. Leur valeur n'est pas aussi évidente
que celle de dons matériels ou de l'argent dans une économie
d'échanges. Il est plus difficile de distinguer objectivement
un don exceptionnel d'un don médiocre. Par conséquent,
la réussite de l'enchère de celui qui brigue un statut
social plus élevé dépend fortement du jugement
critique de ses pairs.
Une autre particularité de la culture des logiciels
à sources ouverts est sa relative pureté. La plupart des
cultures du don sont compromises - soit par des liens avec l'économie
d'échange tels que le commerce de biens de luxe, soit par des
relations avec un pouvoir centralisé telles que des regroupements
en familles ou en clans. Il n'existe rien de tel dans la culture des
logiciels à sources ouverts. En dehors de la réputation
au yeux de ses pairs, il n'y a virtuellement aucun salut.
9. Droits de propriété
et appâts de la réputation
Nous sommes maintenant prêts à faire aboutir
l'analyse précédente en une théorie cohérente
de la coutume de la propriété chez les hackeurs. À
présent, nous comprenons le bénéfice que l'on retire
de la conquête de la noosphère, c'est la réputation
auprès de ses pairs dans la culture du don des hackeurs, avec
les gains indirects et les effets de bord que cela implique.
À partir de là, nous pouvons analyser
les coutumes de la propriété lockéenne des hackeurs
comme un moyen d'optimiser la valeur de la réputation
et d'assurer que la reconnaissance des pairs soit accordée à
ceux qui le méritent et pas aux autres.
Avec cette analyse, les trois tabous dont nous avons
parlé plus haut prennent tout leur sens. La réputation
de quelqu'un peut souffrir injustement si on détourne ou mutile
son travail; ces tabous (et les coutumes qui en découlent) essayent
de prévenir ce genre de situation.
- La scission de projets est mauvaise car elle expose
la réputation des contributeurs du projet d'origine, ce qu'ils
ne peuvent éviter qu'en prenant part simultanément aux
deux projets résultants. (Cela serait généralement
trop confus ou trop difficile pour pouvoir se faire en pratique.)
- La distribution de patchs pirates (ou, pire, de
exécutables pirates) expose les propriétaires à
un risque injuste quant à leur réputation. Même
si le code officiel est parfait, les propriétaires endureront
les critiques des bogues des patchs (mais voir note supra).
- Enlever discrètement le nom de quelqu'un
d'un projet est, dans ce contexte culturel, l'un des plus grands crimes
qui soient.Cela transfère le bénéfice du don
de la victime au voleur.
Ces trois tabous affectent l'ensemble de la communauté
des logiciels à sources ouverts aussi bien que leurs victimes.
Implicitement, ils portent atteinte à l'ensemble de la communauté
car ils rendent moins probable le fait qu'un don ou travail de contributeur
potentiel est récompensé.
Il est important de remarquer que deux de ces trois
tabous peuvent s'expliquer autrement.
D'abord, les hackeurs expliquent souvent leurs appréhensions
face à la scission d'un projet par le temps perdu à faire
tout le travail en double pour chacun des projets fils. Ils peuvent
aussi observer qu'une scission tend à couper l'équipe
de développement en deux groupes, laissant ainsi les deux projets
fils avec moins de cerveaux que le projet père.
Un lecteur a remarqué qu'il est rare, à
long terme, que plus d'un des projets fils survive avec une «part
de marché» suffisamment importante. Cela renforce la motivation
qu'ont les différentes parties de coopérer et d'éviter
une scission. Il est en effet difficile de savoir à l'avance
quel fils sera du mauvais côté de la barrière et
verra tout le travail effectué soit disparaître, soit sombrer
dans l'oubli.
L'aversion pour les patchs pirates est souvent expliquée
par le fait que cela complique considérablement la correction
des bogues, et que cela donne du travail supplémentaire à
des mainteneurs qui ont déjà suffisamment à faire
avec leurs propres erreurs.
Il y a une grande part de vérité dans
ces explications, et elles contribuent certainement à renforcer
la logique lockéenne de propriété. Mais, pour satisfaisantes
qu'elles soient, ces théories n'arrivent pas à expliquer
pourquoi les rares cas où les tabous sont brisés suscitent
autant d'émotions et de luttes territoriales - pas seulement
du fait des parties lésées, mais aussi des observateurs
et des tiers qui réagissent souvent de façon très
sévère. Une inquiétude réfléchie
quant aux ennuis provoqués par la duplication du travail et de
la maintenance ne suffit pas à expliquer les comportements observés.
Et puis, il y a le troisième tabou. Il est difficile
d'envisager une autre explication que le jeu des réputations
pour décrire tout cela. Le fait que l'analyse de ce tabou dépasse
rarement la simple formule: «Ce ne serait pas bien!» est
révélateur en lui-même, comme nous le verrons dans
la section suivante.
10. Le problème de l'ego
Au début de cet article j'ai mentionné
que les fondements inconscients d'une culture sont souvent à
l'opposé de son idéologie consciente. Nous en avons déjà
eu un exemple flagrant dans le fait que les coutumes de propriété
lockéenne ont été amplement suivies bien qu'elles
violent l'esprit des licences standards des logiciels à sources
ouverts.
J'ai observé un autre exemple intéressant
de ce phénomène en discutant de l'analyse du jeu des réputations
avec des hackeurs. Nombre d'entre eux rejetaient l'analyse et se montraient
fortement réticents à admettre que leur comportement puisse
être motivé par leur réputation auprès d'un
pair ou par ce que j'appelais alors imprudemment la «satisfaction
de l'ego».
Cela illustre un point important de la culture hackeur.
Elle se méfie sciemment de la confiance et méprise l'égocentrisme
et les motivations fondées sur l'ego. L'auto-satisfaction a tendance
à être critiquée sans merci, même quand la
communauté pourrait en retirer quelque chose. À tel point
que les aînés de la tribu doivent parler sans ambages et
se déprécier de manière humoristique afin de conserver
leur statut. La manière dont cette attitude s'imbrique au sein
d'une structure dont la motivation principale repose apparemment entièrement
sur l'ego, requiert des explications.
Cela découle certainement du caractère
péjoratif de l'ego dans la culture europeo-américaine.
La matrice culturelle de la plupart des hackeurs leur enseigne que le
désir de l'ego est une motivation mauvaise (ou tout au moins
immature) et que l'ego est, au mieux, une excentricité tolérable
chez les prime donne, et souvent un symptôme de pathologie
mentale. Seules des formes subliminales et déguisées comme
«la réputation auprès des pairs», «l'estime
de soi», «le professionnalisme» ou «la fierté
du travail accompli» en sont généralement acceptables.
Je pourrais écrire un autre essai sur les racines
malsaines de notre héritage culturel, et sur la masse étonnante
d'illusions et de mal que nous nous faisons en croyant (contre toute
évidence psychologique et comportementale) que nous avons véritablement
des motivations non personnelles. Peut-être le ferais-je si Nietzsche
et Ayn Rand (12)ne l'avaient pas
déjà fait (quels qu'aient été leurs échecs
par ailleurs) en démystifiant fort bien «l'altruisme»
comme des sortes d'égocentrismes inconscients et inavoués.
Mais je ne suis pas en train de faire de la morale
philosophique ou psychologique, aussi me contentrai-je d'observer un
moindre mal, causé par la croyance que l'ego est si démoniaque:
cela a rendu émotionnellement difficile pour les hackeurs le
fait de comprendre consciemment la dynamique de leur propre culture!
Mais nous n'en avons pas tout à fait terminé
avec cette enquête. Le tabou frappant les comportements dictés
par l'ego est si intense dans la (sous)culture des hackeurs qu'on peut
le suspecter de remplir une fonction spécifique. En effet, les
tabous concernant l'ego sont de bien moindre importance dans nombres
d'autres cultures du don, telles que les cultures corporatistes (des
gens du spectacle ou des grosses fortunes).
11. La valeur de l'humilité
Ayant établi que le prestige est au centre du
mécanisme de valorisation de la culture hackeur, il nous faut
à présent comprendre pourquoi il semblait si important
que ce fait reste si longtemps dans l'ombre et très peu admis.
Le contraste avec la culture des pirates informatiques
est instructif. Dans cette culture, il est connu et même flagrant
qu'on recherche un certain statut. Les crackeurs recherchent la considération
pour avoir mis en ligne des «warez premier jour» (logiciels
crackés le jour de la sortie du programme original, protégé)
mais restent muets sur leur manière de procéder. Ces magiciens
n'aiment pas donner leurs trucs. C'est pour cela que la base de connaissances
de la culture des crackeurs n'augmente que très lentement, dans
l'ensemble.
Dans la communauté des hackeurs, inversement,
le travail de chacun est ce qu'il publie. C'est une méritocratie
très stricte (le meilleur artisan gagne) et il y a une déontologie
très suivie qui veut qu'il faut laisser parler la qualité.
La meilleure des vantardises est un code qui «marche, tout simplement»,
et dont tout bon programmeur peut voir la bonne facture. Ainsi, la connaissance
de la base culturelle des hackeurs augmente rapidement.
Un tabou contre l'égocentrisme augmente donc
la productivité. Mais c'est un effet de second ordre; ce qui
est directement protégé est ici la qualité de l'information
au sein du système d'évaluation par les pairs. C'est-à-dire
que l'auto-satisfaction et l'intérêt personnel sont supprimés
puisqu'ils pourrait sinon parasiter les signaux vitaux des expériences
en comportements créatifs et coopératifs.
Le médium du don dans la culture hackeur est
intangible, les canaux de communication sont pauvres en ce qui concerne
l'expression des nuances émotionnelles et le face-à-face
entre ses membres plutôt l'exception que la règle. Cela
lui donne une moindre tolérance en bruit que dans la plupart
des autres cultures, et cela explique en grande partie que les aînés
de la tribu se doivent de respecter une certaine humilité en
public.
Ne pas fanfaronner a aussi une utilité fonctionnelle
si l'on veut aspirer à maintenir un projet réussi: il
faut convaincre la communauté que notre jugement est bon, parce
que le travail d'un responsable de projet consiste essentiellement à
évaluer correctement le code des autres. Qui voudrait proposer
son travail à une personne inapte à juger de la qualité
d'un code, ou dont le comportement général tend à
montrer qu'elle essaiera injustement de s'en attribuer seule le mérite
? Les contributeurs potentiels sont à la recherche de gens assez
humbles pour dire, là où les faits objectifs le justifient:
«Oui, cela fonctionne mieux que ma propre version, je le prends»
- et d'en rendre le mérite à l'auteur.
Une autre raison de cette humilité est que dans
le monde des logiciels à sources ouverts, on ne cherche que très
rarement à donner l'impression qu'un projet est «fini».
Cela pourrait mener un contributeur éventuel à penser
que son apport n'est pas nécessaire. Pour maximiser son influence
au sein de la communauté, il faut rester humble quant à
l'état de ses programmes. Si quelqu'un vante son code, mais ajoute:
«Mince alors! Il ne fait pas x, y et z. Il ne doit pas être
aussi bien que ça finalement!», les patchs pour x, y et
z suivront généralement peu après.
Enfin, j'ai personnellement remarqué que le
comportement auto-dépréciateur de certains chefs de file
hackeurs reflète une peur réelle (et pas forcément
injustifiée) de devenir l'objet d'un culte de la personnalité.
Linus Torvalds et Larry Wall apportent tous deux un nombre incalculable
d'exemples clairs de ce genre de comportement. Un jour, lors d'une sortie
avec Larry Wall, j'ai fait une plaisanterie: «Tu es le meilleur
hackeur d'entre nous - tu vas pouvoir choisir le restaurant.»
Il sursauta très nettement. Et pour cause: ne pas distinguer
leurs valeurs respectives de celles de leurs meneurs a détruit
nombre de communautés, un schéma que Linus et lui-même
ne peuvent ignorer. D'un autre côté, beaucoup de hackeurs
adoreraient avoir le problème de Larry, s'ils pouvaient se résoudre
à l'admettre.
12. Conséquences du modèle
du jeu des réputations
L'analyse du jeu des réputations a plus de conséquences
qu'il n'y paraît d'abord. Beaucoup d'entres elles découlent
du fait que l'on retire plus de prestige en ayant fondé un projet
réussi qu'en ayant simplement participé à un projet
existant. Une autre conséquence en est que l'on retire plus de
gloire d'un projet fondamentalement innovant que d'améliorations
incrémentales à un programme qui existe déjà.
D'un autre côté, un logiciel que personne, à part
l'auteur, ne comprend ou n'utilise, n'est pas un bon départ dans
le jeu des réputations, et il est souvent plus aisé d'attirer
l'attention sur soi en contribuant à un projet existant qu'en
créant un nouveau projet. Enfin, il est plus difficile de se
mesurer à un projet qui a déjà le vent en poupe
que de remplir une niche vide.
Ainsi, il existe une distance optimale entre son projet
et ceux des voisins (les projets concurrents les plus similaires). Si
la distance est trop petite, votre projet sera une redite sans valeur
du projet existant (il faudrait plutôt contribuer au projet existant).
Si la distance est trop grande, personne ne sera à même
de comprendre, d'utiliser ou de percevoir le sens de l'effort d'un pair
(là encore, le cadeau sera de faible valeur). Tout cela crée
un plan de conquête de la noosphère qui ressemble à
l'implantation de colons s'aventurant au-delà d'une frontière
dans le monde physique (13). À
tout instant, on s'intéressait à la position de la frontière
séparant les terres colonisées des terres encore sauvages
- pas aléatoirement, mais plutôt comme un agrégat
fractal. Les projets tendent à démarrer là où
ils comblent des trous près de la frontière.
Certains projets à succès deviennent
des «tueurs de concurrence». Personne ne voudra se tenir
près d'eux car se mesurer à une base déjà
établie sera une tâche trop dure. Les gens qui en revanche
feront des efforts distincts finiront plutôt par contribuer à
l'extension de ces projets à succès. L'exemple classique
du «tueur de concurrence» est GNU Emacs. Ses variantes remplissent
la niche écologique des éditeurs entièrement programmables,
à tel point que personne n'a jamais vraiment essayé de
créer un programme très différent dans ce domaine
depuis les années 80. Au lieu de cela les gens écrivent
des modules pour Emacs.
Globalement, ces deux tendances (remplir les vides
et les tueurs de concurrence) ont conduit à des modes dictant
la naissance, en général prévisible, de projets
à travers le temps. Dans les années 70, la majorité
des logiciels à sources ouverts existants étaient des
gadgets et des démos. Dans les années 80, la tendance
allait vers le développement et les outils Internet. Dans les
années 90, elle s'est tournée vers les systèmes
d'exploitation (14). Dans chaque
cas de figure, on s'attaquait à un niveau de plus en plus élevé
de problèmes, alors que les possibilités du précédent
avaient été pratiquement épuisées.
Cette tendance a des conséquences intéressantes
pour un futur proche. Au début de l'année 1998, Linux
ressemble fort à un tueur de concurrence pour la niche des «systèmes
d'exploitation à sources ouverts» - et les gens qui auraient
pu écrire des systèmes d'exploitation concurrents, écrivent
plutôt à présent des pilotes ou des extensions.
Et la plupart des outils de bas niveau (15)dont
les gens ont pu espérer une version ouverte existent déjà.
Que reste-t-il ?
Les applications. À l'approche de l'an 2000,
il semble peu risqué de prédire que l'effort de développement
des logiciels à sources ouverts va peu à peu conquérir
le dernier territoire vierge - notamment avec des logiciels pour les
non-spécialistes. Une prémisse claire en est le développement
de GIMP, l'équivalent de Photoshop pour la manipulation d'images,
qui est la première application ouverte importante avec une GUI
(Graphical User Interface, ou interface homme-machine graphique) digne
de celles qui sont de rigueur dans les applications commerciales de
la dernière décennie. Un autre signe est le remue-ménage
fait autour des projets d'outils d'environnement pour logiciels KDE
et GNOME.
Finalement, l'analyse du jeu des réputations
explique le proverbe, souvent cité, que l'on ne devient pas un
hackeur en s'en donnant le titre - on le devient lorsque d'autres
hackeurs disent de vous que vous êtes un hackeur. Un «hackeur»,
vu sous cet angle, est quelqu'un qui a su prouver (par sa contribution)
qu'il ou elle a un potentiel technique et qu'il ou elle comprend le
fonctionnement du jeu des réputations. Ce jugement est essentiellement
une prise de conscience ou un apprentissage qui ne peut être délivré
que par ceux qui sont déjà bien implantés dans
cette culture.
13. Propriété de la noosphère
et éthologie du territoire
Afin de mieux comprendre les conséquences des
moeurs de propriété, il sera très utile de les
aborder sous un autre angle. En se plaçant du point de vue de
l'éthologie animale, et plus spécifiquement, de l'éthologie
du territoire.
La propriété est une abstraction de la
territorialité animale, qui a évolué de manière
à réduire les comportements violents au sein d'une même
espèce. En marquant son territoire et en respectant celui des
autres, le loup réduit les risques de se retrouver au sein d'un
conflit qui pourrait l'affaiblir ou le tuer et diminuer ses chances
de se reproduire.
Parallèlement, la fonction de la propriété
au sein des communautés humaines est d'abord de prévenir
tout conflit intra-communautaire en définissant des marques qui
séparent clairement un comportement paisible d'un comportement
agressif. Il semble parfois de bon ton de décrire ces marques
comme socialement arbitraires, mais cela est complètement faux.
Quiconque a déjà fait l'expérience d'avoir un chien
qui aboie à l'approche d'un inconnu connaît la continuité
essentielle entre la territorialité animale et la propriété
humaine. Nos cousins domestiques des loups le sentent souvent mieux
que bon nombre de théoriciens politiques.
Clamer sa propriété (ainsi que définir
son territoire) est un acte représentatif, c'est un moyen de
déclarer quelles frontières seront défendues. Appuyer
ce droit à la propriété est un moyen de minimiser
les conflits et de maximiser un comportement coopératif. Cela
reste encore une réalité lorsque le «droit à
la propriété» est plus abstrait qu'un enclos ou
qu'un aboiement de chien, alors même qu'il est réduit à
l'apparition du nom d'un responsable de projet dans un fichier LISEZMOI.
Il s'agit toujours d'une abstraction de la territorialité, et
(comme dans d'autres formes de propriété) nos modèles
instinctifs de propriété sont des modèles territoriaux
qui ont évolué en vue de résoudre les conflits.
Cette analyse éthologique semble de prime abord
très abstraite, et difficile à mettre en relation avec
le comportement réel des hackeurs. Mais elle a d'importantes
conséquences. L'une d'elles est d'expliquer la popularité
des sites Web, et plus spécialement pourquoi les projets de logiciels
à sources ouverts avec un site web semblent beaucoup plus «réels»
et substantiels que ceux qui n'en disposent pas.
Tout bien considéré, cela semble difficile
à expliquer. Comparée aux efforts impliqués par
la création et le maintien d'un programme, même petit,
une page web est facile à maintenir, aussi est-il difficile de
considérer la page web comme la preuve d'un effort substantiel
ou inhabituel.
Les caractéristiques fonctionnelles du Web lui-même
sont encore une explication insuffisante. Les fonctions de communication
d'une page web peuvent être aussi bien, si ce n'est mieux, remplacées
par la combinaison d'un site FTP (16).
Les sites FTP rassemblent un ensemble de fichiers, souvent accessibles
à n'importe qui, d'une liste de diffusion (17)et
d'un forum de discussion. En fait, il est relativement peu fréquent
que les communications courantes concernant un projet se fassent sur
le Web plutôt que sur une liste de diffusion ou un forum de discussion.
Pourquoi les sites Web jouissent-ils donc d'une telle popularité
en tant que localisation d'un projet ?
La métaphore implicite induite dans le terme
de «home page» (littéralement, «document
maison») est un indice important. Puisque fonder un projet de
logiciel ouvert est une revendication territoriale au sein de la noosphère
(et reconnu comme tel par l'usage) ce n'est pas une importante contrainte
psychologique. Un logiciel, après tout, n'a pas de position géographique,
et il peut être duplicable à tout instant. Ceci est assimilable
à notre notion instinctive de «territoire» et de
«propriété», mais seulement après quelques
efforts.
La page d'accueil d'un projet concrétise l'abstraction
de la colonisation de l'espace des programmes possibles en le présentant
comme un territoire conquis au sein du royaume du Web, territorialement
plus organisé. Passer de la noosphère au «cyberespace»
ne nous donne pas tous les moyens de protection du monde réel,
des barrières ou des chiens qui aboient, mais cela ancre la propriété
abstraite de façon plus sûre pour notre notion instinctive
de territoire. Et c'est pour cela que les projets qui bénéficient
d'une page web semblent plus «réels».
Cette analyse éthologique nous encourage aussi
à regarder plus précisément les mécanismes
permettant de gérer les conflits dans la culture des logiciels
à sources ouverts. Cela nous amène à prévoir
que, outre une maximisation des ressorts de la réputation, les
coutumes de propriétés jouent également un rôle
dans l'évitement et la résolution des conflits.
14. Les causes de conflits
Les conflits au sein des logiciels libres peuvent être
classés en quatre grandes catégories:
- Qui prend les décisions importantes du projet?
- Qui doit-on féliciter ou réprimander
et pour quoi ?
- Comment réduire la duplication du travail
et empêcher les versions pirates de compliquer la recherche
des bogues ?
- Quelle est la bonne voie, techniquement parlant
?
Pourtant, si l'on s'arrête sur la question: «Quelle
est la bonne voie?», on constate que celle-ci ne tient pas la
route. Pour de telles questions, soit il existe une solution objective,
acceptée par tous, soit il n'en existe pas. S'il en existe, «eurêka!»,
et tout le monde y gagne. Sinon, cela se réduit à: «Qui
prend les décisions ?».
Par conséquent, les trois problèmes qu'une
théorie de la résolution des conflits doit résoudre
sont (A) sur qui rejeter la responsabilité des choix de conceptions,
(B) comment décider à quel contributeur est attribué
le travail, et (C) comment empêcher le groupe et le logiciel d'exploser
en de multiples branches.
Le rôle des coutumes traitant de la propriété
permettent clairement de résoudre les points (A) et (C). L'usage
affirme que le propriétaire d'un projet prend les décisions
importantes. Nous avions déjà observé le fait que
l'usage exerce aussi une forte pression contre la dilution des projets
par scissions.
Il est instructif de remarquer que ces coutumes ont
un sens même si l'on oublie le jeu des réputations et que
l'on examine la culture des hackeurs avec l'idée d'un pur modèle
de «l'artisan». Dans cette optique, les coutumes s'expliquent
plus par une protection du droit de l'artisan à agir selon sa
vision des choses que pour empêcher l'atténuation de la
motivation dûe à la réputation.
Cependant, le modèle de l'artisan n'est pas
suffisant pour expliquer les coutumes des hackeurs à propos du
point (B), «qui remercie-t-on et pour quoi?» (car dans un
modèle de pur artisan, quelqu'un qui ne s'intéresse pas
au jeu des réputations, ne devrait pas s'en préoccuper).
Pour analyser cela, nous avons besoin de creuser un peu la théorie
lockéenne et d'examiner les conflits et l'application de droits
de propriétés aussi bien à l'intérieur
qu'à l'extérieur des projets.
15. Structure et propriété des projets
libres
Le cas le plus facile est celui dans lequel le projet
n'a qu'un seul propriétaire/mainteneur. Aucun conflit n'est alors
possible. Le propriétaire prend toutes les décisions et
récolte les bénéfices ou les problèmes qu'engendre
son projet. Le seul cas possible de conflit se présente lors
de la succession - qui va devenir le nouveau propriétaire si
le précédent disparaît ou perd son intérêt
pour le projet? La communauté aussi a intérêt, d'après
(C), à éviter les scissions. Ces intérêts
sont exprimés par une règle culturelle qui dit qu'un propriétaire/mainteneur
doit publiquement passer la main à quelqu'un s'il ne peut maintenir
le projet plus longtemps.
Le cas non trivial le plus simple est lorsqu'un projet
a plusieurs co-mainteneurs qui travaillent sous la direction d'un «dictateur
bienveillant». L'usage favorise ce type d'organisation pour les
projets de groupes. L'expérience montre que pour des projets
aussi gros que le noyau Linux ou Emacs cela fonctionne correctement,
et résout le problème du «Qui décide?»
d'une façon qui n'est pas forcément la pire.
Typiquement, une organisation de type «dictateur
bienveillant» est issue d'une organisation de type propriétaire/mainteneur
qui a su attirer des contributeurs. Même si le propriétaire
reste le dictateur, cela introduit un nouveau niveau de dissensions
possibles à propos de la répartition des remerciements
pour les différentes parties du projet.
Dans cette situation, les coutumes obligent le propriétaire/dictateur
à remercier les contributeurs de façon équitable
(à travers, par exemple, une notification appropriée de
leurs noms dans les fichiers LISEZMOI ou dans celui de l'historique
du projet). Selon le modèle de la théorie lockéenne
de la propriété, cela signifie qu'en contribuant à
un projet vous gagnez une part de sa renommée (en bien ou en
mal).
En poussant ce raisonnement plus loin, on constate
qu'en réalité, le dictateur bienveillant ne détient
pas la totalité du projet de façon inconditionnelle. Bien
qu'il ait le droit de faire des choix cruciaux, il propose en effet
aux autres des parts de la renommée de son projet en échange
de leur travail. L'analogie avec le métayage dans les fermes
est presque incontournable, si ce n'est que le nom du contributeur reste
dans les remerciements et qu'il continue à être associé
au projet, même après avoir cessé d'y contribuer.
Quand les projets de type «dictateur bienveillant»
rassemblent plus de participants, deux familles de contributeurs tendent
à se démarquer: les contributeurs ordinaires et les co-développeurs.
Un cheminement typique pour devenir un co-développeur est de
prendre la responsabilité d'un sous-système majeur du
projet. Un autre est de se transformer en «chasseur de bogues»,
en débusquant et en corrigeant un grand nombre de bogues. De
cette façon ou d'une autre, les co-développeurs sont des
contributeurs qui s'investissent de façon substantielle et persistante
dans le projet.
Le rôle de responsable d'un sous-système
est particulièrement important pour notre analyse et mérite
qu'on s'y attarde. Les hackeurs aiment à dire que «l'autorité
vient de la responsabilité». Un co-développeur qui
accepte la responsabilité de la maintenance d'un sous-système
donné obtient en général le contrôle de l'implémentation
de ce sous-système et de ses interactions avec le reste du projet,
et seul le chef de projet (qui joue le rôle d'un architecte) peut
lui faire des remarques. On notera que cette règle délimite
effectivement une propriété suivant le modèle lockéen
à l'intérieur du projet, et qu'elle a exactement le même
rôle de prévention des conflits que les frontières
ceignant habituellement les propriétés.
L'usage veut que le «dictateur» ou le chef
de projet dans un projet avec co-développeurs consulte ceux-ci
lors des décisions-clé. Plus particulièrement encore
lorsque la décision concerne un sous-système «appartenant»
à un co-développeur (c'est-à-dire, qui y a investi
du temps et en a pris la responsabilité). Un chef de projet avisé,
qui sait à quoi sert le découpage interne de son projet,
n'interférera avec, ni n'annulera, les décisions faites
par le propriétaire d'un sous-système.
Certains projets très importants abandonnent
entièrement le modèle du «dictateur bienveillant».
On peut procéder en transformant les co-développeurs en
une commission de votants (comme pour Apache (18)),
ou encore ne faisant tourner le titre de dictateur; dans ce dernier
type d'organisation le pouvoir passe d'un membre à un autre au
sein d'un cercle de co-développeurs aguerris (les développeurs
de Perl se sont organisés ainsi).
De tels arrangements sont généralement
considérés instables et compliqués. Évidemment,
ces difficultés dépendent largement de la productivité
d'une telle commission, de ses décisions ou de son absence de
décision. Ce sont des problèmes dont la communauté
des hackeurs a parfaitement conscience. Je soupçonne cependant
que le malaise des hackeurs vis-à-vis des commissions ou des
organisations à pouvoir tournant vient du fait qu'elles cadrent
mal avec le modèle inconscient de Locke qu'ils utilisent pour
résoudre les cas simples. Il est difficile, dans ces organisations
complexes, de tenir le décompte des propriétés
de chacun en matière de parties contrôlées ou des
gains de réputation. Il est difficile de voir les frontières
internes d'un tel projet, et donc difficile d'éviter les conflits,
à moins que le groupe n'atteigne un niveau exceptionnel d'harmonie
et de confiance réciproque.
16. Les conflits et leur résolution
Nous avons vu qu'au sein des projets la complexité
des rôles tend à croître, d'une part à cause
d'une répartition de l'autorité de conception entre les
membres de l'équipe, d'autre part à cause des droits de
propriété partiels sur des sous-parties du projet. Même
s'il s'agit là d'une façon efficace de distribuer la motivation,
cela diminue aussi l'autorité du chef de projet - cela affaiblit
surtout la position du chef de projet lorsqu'il est nécessaire
de prendre une décision pour étouffer les conflits dans
l'oeuf.
Bien que les arguments techniques de conception du
logiciel semblent être la cause la plus évidente de discorde,
ils sont rarement en cause. Ces problèmes sont généralement
résolus assez facilement par la règle qui dit que l'autorité
vient des responsabilités.
Une autre façon de résoudre les conflits
est de s'en remettre aux seniors - si deux contributeurs ou groupes
de contributeurs se querellent, qu'ils ne peuvent s'entendre de façon
objective, et que personne ne détient le territoire sur lequel
se passe le conflit, alors la partie qui a contribué le plus
activement au projet (c'est-à-dire, la partie qui possède
le plus de droits de propriété du projet) l'emporte.
Ces règles suffisent généralement
à résoudre la majeure partie des querelles. Lorsqu'elles
sont inefficaces, les ordres du chef de projet résolvent généralement
le conflit. Les disputes qui survivent à ces deux filtres sont
rares.
Les conflits semblent ne jamais prendre de l'ampleur,
à moins que ces deux critères («l'autorité
vient des responsabilités» et «les seniors l'emportent»)
ne donnent des directives opposées, et que l'autorité
du chef de projet soit défaillante ou absente. Le cas le plus
évident dans lequel ce genre de choses peut arriver est un conflit
de succession consécutif à la disparition du chef de projet.
J'ai eu l'occasion d'être pris dans l'un de ces conflits. Cela
fut horrible, désagréable, interminable, et ne prit fin
que lorsque toutes les parties furent trop fatiguées pour faire
autre chose que de passer la main à un tiers. Et j'espère
sincèrement ne plus jamais participer à une telle chose.
Finalement, tous ces mécanismes de résolution
de conflits reposent sur la volonté de la communauté des
hackeurs de les faire respecter. Les seuls manières de les appliquer
sont d'incendier et d'occulter - par une condamnation publique de ceux
qui ont enfreint les règles et un refus de coopérer avec
eux après qu'ils l'ont fait.
17. Mécanismes d'acculturation
et lien avec le modèle académique
L'une des premières versions de cet article
a posé la question suivante: comment la communauté informe
et instruit ses membres de ses coutumes? Ces coutumes sont-elles évidentes
ou s'auto-organisent-elles de manière inconsciente, sont-elles
apprises par l'exemple ou par un enseignement explicite ?
Les transmettre par un enseignement explicite est visiblement
rare, ne serait-ce que parce qu'il n'existait aucune description explicite
des normes de cette culture jusqu'à présent.
Bon nombre de règles sont enseignées
par l'exemple. Pour donner un exemple simple, il existe une norme qui
dit que toutes les distributions de logiciels doivent proposer un fichier
LISEZMOI ou LISEZ.MOI qui contient les instructions nécessaires
au parcours de la distribution. Cette convention a été
établie au moins depuis le début des années 80,
mais jusqu'à présent elle n'a jamais été
écrite noir sur blanc. Chacun l'apprend en regardant un grand
nombre de distributions.
D'un autre côté, certaines coutumes des
hackeurs se sont auto-organisées une fois que ces derniers ont
atteint une compréhension basique (et peut-être inconsciente)
du jeu des réputations. La plupart des hackeurs n'ont jamais
entendu parler des trois tabous dont j'ai parlé dans la section
Théorie libertine, pratique puritaine, mais diraient, si
on le leur demandait, qu'ils sont si évidents qu'ils n'ont pas
besoin d'être transmis. Ce phénomène incite à
une analyse plus fine - et peut-être pourrons-nous y trouver une
explication en examinant le processus à partir duquel les hackeurs
acquièrent la connaissance de leur culture.
Un grand nombre de cultures utilisent des règles
cachées (ou plus précisément des «mystères»
au sens religieux ou mystique) comme un mécanisme d'acculturation.
Ce sont des secrets qui ne sont pas révélés aux
étrangers, mais qui doivent être découverts ou déduits
par l'apprenti newbie. Pour être accepté par ses pairs,
il doit démontrer aux autres qu'il comprend à la fois
les «mystères» et qu'il les a appris d'une façon
culturellement correcte.
La culture hackeur utilise de façon massive
et rarement consciente de tels indicateurs ou tests. On peut voir ce
processus se mettre en oeuvre au moins à trois niveaux:
- Mystères de type «mot de passe».
Par exemple, il existe un forum de Usenet appelé alt.sysadmin.recovery,
qui dispose très explicitement d'un tel secret. On ne peut
pas y participer sans le connaître, et cette connaissance est
considérée comme une preuve que l'on correspond au forum.
Ce secret est un puissant tabou pour les habitués du forum.
- La nécessité d'une initiation
à certains mystères techniques. Chacun doit absorber
une copieuse part de connaissance en technique avant de pouvoir offrir
des dons de valeur (i.e. chacun doit connaître au moins l'un
des langages de programmation standard). Ce préalable fonctionne
à grande échelle à la manière dont des
indices cachés fonctionnent à petite échelle,
comme un filtre recherchant des qualités (telles que l'aptitude
à l'abstraction, la persistance, l'adaptation), nécessaires
pour s'intégrer dans la culture.
- Les mystères de contexte social. Chacun
s'implique dans la culture à travers un attachement personnel
à des projets spécifiques. Chaque projet possède
un contenu social propre parmi les hackeurs que les prétendants
contributeurs doivent démonter et comprendre socialement aussi
bien que techniquement pour s'y intégrer (concrètement,
la façon plus courante de faire cela est de lire la page web
ou les archives de la liste de diffusion du projet). C'est à
travers les groupes qui font ces projets que les débutants
apprennent, par l'exemple, le comportement des hackeurs expérimentés.
Dans le processus d'acquisition de ces mystères,
le prétendant hackeur assimile des connaissances contextuelles
qui (après un certain temps) vont rendre les trois tabous et
d'autres coutumes «évidents».
Certains pourraient, incidemment, soutenir le fait
que la structure même de la culture du don des hackeurs est son
propre mystère. On n'est pas considéré comme acculturé
(concrètement, personne ne l'appellera un hackeur) avant d'avoir
démontré un bon niveau de compréhension du jeu
des réputations et de ce qu'il implique: coutumes, tabous et
usages. Mais c'est évident: toutes les cultures exigent une telle
compréhension de la part de ceux qui manifestent la volonté
d'entrer. De plus, la culture hackeur ne manifeste aucune envie de voir
sa logique interne gardée secrète - ou, au moins, personne
ne m'a jamais incendié pour l'avoir révélée!
En commentant cet article, un grand nombre de gens
ont signalé le fait que les coutumes de propriété
des hackeurs semblent intimement liées aux habitudes du monde
universitaire (et pourraient même en dériver directement),
et plus précisément, de celui de la recherche scientifique.
Cette communauté de chercheurs rencontre des problèmes
similaires pour exploiter un territoire aux idées potentiellement
productives, et exhibe des solutions adaptatives très semblables
pour ces problèmes dans le sens où elle utilise aussi
l'approbation des pairs et le jeu des réputations.
Étant donné que de nombreux hackeurs
ont fréquenté l'université (il est fréquent
d'apprendre l'art du hack à la faculté) le fait de dire
que l'université partage certains comportements adaptatifs avec
la culture hackeur est bien plus qu'une simple anecdote dans la compréhension
de la manière dont ces coutumes sont appliquées.
Les parallèles avec la culture du don des hackeurs,
telle que je l'ai caractérisée, abondent à l'université.
Une fois qu'un chercheur a conquis un domaine, il n'a plus à
se soucier de la question de sa survie (en effet, le concept de domaine
remonte probablement à une culture du don plus ancienne, dans
laquelle les «philosophes naturalistes» étaient à
l'origine des riches gentilshommes fortunés avec du temps à
consacrer à la recherche). En l'absence de problèmes de
survie, l'amélioration de la réputation devint la seule
motivation, encourageant le partage des nouvelles idées et la
consultation de journaux et d'autres médias. Ceci est fonctionnel
et objectif car la recherche scientifique, comme la culture hackeur,
repose largement sur l'idée qu'elle se tient sur des «épaules
de géants», et de ne pas devoir redécouvrir les
principes de base encore et encore.
Certains ont poussé le raisonnement jusqu'à
suggérer que les coutumes des hackeurs étaient simplement
un reflet de celles de la communauté scientifique et qu'en fait,
elles étaient pour la plupart acquises auprès de cette
dernière. Cela exagère probablement la réalité,
ne serait-ce que parce que les coutumes des hackeurs semblent déjà
être acquises par de brillants lycéens.
Il y a aussi une autre possibilité intéressante.
Je suspecte l'université et la culture hackeur de partager des
comportements adaptatifs, non parce qu'ils sont reliés génétiquement,
mais parce qu'elles ont toutes deux développé l'une des
organisations sociales les plus efficaces pour ce qu'elles essaient
de faire, étant données les lois de la nature et l'instinct
humain. Le verdict de l'histoire semble être que le capitalisme
et le libre marché est une façon globalement optimale
de coopérer pour engendrer une économie efficace (19).
Peut-être que, d'une manière similaire, le jeu des réputations
de la culture du don est la façon globalement optimale de coopérer
pour créer (et contrôler!) un travail créatif de
qualité.
Si cela est vrai, c'est d'un intérêt bien
plus qu'académique (si vous me le permettez). Vu sous un angle
légèrement différent d'une des spéculations
de «La Cathédrale et le Bazar», cela suggère
finalement que le mode de production industrio-capitaliste du logiciel
était condamné à être dépassé
à partir du moment où le capitalisme a commencé
à créer suffisamment de surplus de richesses, permettant
ainsi à un bon nombre de programmeurs de vivre dans une culture
du don d'après-rareté.
18. Conclusion: de la coutume à la loi coutumière
Nous avons examiné les coutumes qui régulent
la propriété des logiciels à sources ouverts, et
qui les contrôlent. Nous avons montré comment ils sous-tendent
une théorie des droits de propriété analogue à
la théorie lockéenne de la propriété foncière.
Nous avons relié cela à une analyse de la culture hackeur
en tant que «culture du don», dans laquelle les participants
rivalisent pour le prestige en donnant du temps, de l'énergie,
et de la créativité. Nous avons examiné les implications
de cette analyse pour la résolution des conflits dans cette culture.
Logiquement, la question suivante est: «Pourquoi
tout cela est-il important ?». Les hackeurs ont développé
ces coutumes sans analyse consciente, et (jusqu'à présent)
ils les ont également suivies sans analyse consciente. Il n'est
pas immédiatement évident que l'analyse consciente apporte
un quelconque gain en pratique - à moins que nous puissions passer
de la description à la prescription et déduire des manières
d'améliorer le fonctionnement de ces coutumes.
Nous avons trouvé une bonne analogie des coutumes
des hackeurs dans la théorie de la propriété foncière
selon la tradition législative anglo-américaine. Historiquement
(20), les cultures tribales européennes
qui ont inventé cette tradition ont amélioré leur
système de résolution des conflits en passant d'un système
de coutumes désarticulées et semi-conscientes à
un ensemble de lois coutumières mémorisées par
les sages de la tribu - et, finalement, couchées sur papier.
Peut-être qu'avec l'augmentation de notre population,
l'acculturation de tous les nouveaux membres devenant plus difficile,
il est temps pour la culture hackeur de faire quelque chose d'analogue
- c'est-à-dire d'écrire un code de bonne conduite afin
de résoudre les diverses sortes de conflits qui pourraient survenir
dans le cadre de projets de logiciels à sources ouverts, et de
créer une tradition d'arbitrage dans laquelle les aînés
de la communauté pourraient être amenés à
intervenir en tant que médiateurs dans les différends.
L'analyse exposée dans cet article suggère
l'esquisse de ce à quoi pourrait ressembler ce code, explicitant
ce qui jusqu'à présent était implicite. Un tel
code ne peut-être imposé d'autorité. Il devra être
volontairement adopté par les fondateurs ou les propriétaires
de projets individuels. Il ne devra pas, non plus, être complètement
rigide, car les contraintes s'exerçant sur la culture sont susceptibles
de changer au cours du temps. Enfin, pour rendre possible l'application
d'un tel code, il lui faudra refléter un large consensus de la
tribu des hackeurs.
J'ai commencé à travailler sur un tel
code, provisoirement intitulé le «protocole de Malvern»,
du nom de la petite ville où je vis. Si l'analyse générale
présentée dans cet article conquiert suffisamment de monde,
je rendrai public le protocole de Malvern en tant que modèle
de code pour la résolution des conflits. Les personnes intéressées
par la critique ou le développement de ce code, ou souhaitant
m'informer de ce qu'elles estiment bon ou mauvais, sont invitées
à me contacter par courrier électronique.
19. Questions pour aller plus loin
La culture des hackeurs (et moi) comprenons mal les
grands projets qui ne suivent pas le modèle du «dictateur
bienveillant». La plupart de ces grands projets échouent.
Quelques-uns réussissent de façon éclatante et
deviennent particulièrement importants (Perl, Apache, KDE). Personne
ne comprend vraiment où se situe la différence. Il existe
une vague intuition diffuse qui dit que de tels projets sont sui
generis et perdurent ou meurent selon la dynamique du groupe engendrée
par chacun de ses membres propres. Est-ce vrai ou existe-t-il des stratégies
reproductibles qu'un groupe puisse suivre?
On peut remarquer que ceux qui fondent des projets
qui fonctionnent bien récoltent plus de prestige que ceux qui,
avec la même somme de travail, corrigent et assistent ces mêmes
projets. Est-ce une estimation rationnelle des efforts fournis comparés,
ou est-ce un effet de bord du modèle territorial inconscient
que nous avons évoqué ici ?
20. Bibliographie, notes et remerciements
The adapted Mind: Evolutionary psychology and the
generation of culture. J. Barkow, L. Cosmides, and J. Tooby (Eds.),
New York: Oxford University Press, 1992. Une excellente introduction
à la psychologie évolutive. Certains de ces articles parlent
des trois types de cultures dont j'ai parlé (centralisée/échange
/don), en suggérant que ces comportements sont profondément
ancrés dans le psychisme humain.
MALACLYPSE THE YOUNGER: Principia Discordia,
or How I Found Goddess and What I Did To Her When I Found Her ; Loompanics,
ISBN 1-55950-040-9. Parmi un monceau de bêtises éclairantes,
le « principe de SNAFU » donne une analyse plutôt
incisive de la difficulté des pouvoirs centralisés à
gérer de grands ensembles. Il en existe une version HTML: www.cs.cmu.edu/afs/cs/user/tilt/public_html/principia/
MILLER, WILLIAM IAN: Bloodtaking and Peacemaking
: Feud, Law, and Society in Saga Iceland, Chicago: University of
Chicago Press 1990, ISBN 0-226-52680-1. Une étude fascinante
de la loi populaire islandaise, qui permet de mieux comprendre l'origine
de la théorie lockéenne de la propriété
et qui décrit différentes étapes ultérieures
du processus historique par lesquelles ont transité ces coutumes
pour passer du stade d'accord tacite à celui de loi coutumière,
et enfin à celui de loi écrite.
GOLDHABER, MICHAEL K. : «The Attention Economy
and the Net» (www.well.com/user/mgoldh/).
J'ai découvert cet article après ma version 1.7. Il a
des défauts évidents (l'argument de Goldhaber en faveur
de l'impossibilité de la mise en oeuvre d'un raisonnement économique
ne résiste pas à une analyse poussée), mais Goldhaber
est néanmoins amusant et perspicace lorsqu'il parle du rôle
de la captation d'attention dans un comportement organisé. Le
prestige ou la réputation parmi les pairs dont j'ai parlé
plus haut peut être fructueusement vus comme un cas particulier
de cette «attention».
Je suis redevable à Michael Funk (mwfunk@uncc.
campus.mci.net) de m'avoir montré combien le contraste entre
la culture des hackeurs et des crackeurs est instructif. Robert Lanphier
(robla@real.com) a beaucoup contribué à la discussion
sur les comportements altruistes. Eric Kidd (eric.kidd@pobox.com) a
souligné le rôle de l'humilité dans la prévention
contre les cultes de la personnalité. La partie qui traite des
effets généraux a été inspirée par
les commentaires de Daniel Burn (daniel@tsathoggua.lab.usyd. edu.au).
Mike Whitaker (mrw@entropic.co.uk) est à l'origine du passage
principal de la partie sur l'acculturation.
21. Historique des versions
Je suis le seul responsable de ce qui est dit dans
cet article, de toutes les erreurs ou méprises. J'ai cependant
accueilli favorablement les commentaires et les interventions des lecteurs,
et je les ai utilisés pour améliorer cet article - processus
auquel je ne prévois nulle fin prédéfinie.
10 avril 1998: publication de la version 1.2 sur le
Web.
12 avril 1998: Version 1.3. Corrections typographiques
et réponses aux premiers commentaires du public. Les quatre premiers
ouvrages de la bibliographie. Un contributeur anonyme a remarqué
que la réputation est motivante même lorsque l'artisan
n'est pas averti de son existence. J'ai ajouté une partie intéressante
sur le contraste avec les warez d00dz, j'ai allongé la partie
des prémisses traitant du fait que «le logiciel parle de
lui-même» et des observations sur la prévention des
cultes de la personnalité. Résultat, la partie «Le
problème de l'ego» a grossi et s'est scindée20.
16 avril 1998: Version 1.7. Nouvelle section sur les
implications globales, qui traite de l'histoire de la colonisation de
la noosphère et examine le phénomène des «tueurs
de concurrence». J'ai ajouté une autre question à
approfondir.
27 avril 1998: Version 1.8. J'ai ajouté Goldhaber
à la bibliographie. Cette version est celle qui sera présentée
dans les actes de la «Linux Expo».
26 mai 1998: Version 1.9. J'ai incorporé la
distinction entre noosphère et ergosphère de Faré
Rideau. J'ai ajouté l'affirmation de Richard M. Stallman, qui
dit ne pas être anti-commercial. Une nouvelle partie sur l'acculturation
et l'académisme (merci à Ross J. Reedstrom, Eran Tromer,
Allan McInnes, et aux autres). Ajouts sur l'humilité («comportement
altruiste») venant de Jerry Fass et Marsh Ray.
11 juillet 1998: Version 1.10. J'ai retiré les
références à Faré Rideau à propos
de la «gloire» à sa demande.
21 novembre 1998: Version 1.14. Modifications éditoriales
mineures, remise à jour de quelques liens.
22. Notes des traducteurs
CRACKER : v. tr. - de l'angl. crack. Action de
s'introduire illégalement un système informatique ou
de briser les sécurités d'un logiciel. Où
pourrais-je trouver des informations pour cracker ce logiciel? ou
encore Ce site a été cracké.
CRACKEUR : n. m. - de l'angl. cracker. Criminel
informatique. Un crackeur s'est introduit dans notre site cette
nuit.
HACK : n. m. - de l'angl. hack. Une invention
astucieuse, une solution élégante à un problème.
Aujourd'hui j'ai fait un bon hack pour résoudre mon problème
de disque dur.
HACKER : v. tr. - de l'angl. hack. Inventer,
bidouiller, bricoler, la plupart du temps dans le domaine de l'informatique.
Pas de problème je vais te hacker une solution vite fait.
HACKEUR : n. m. - de l'angl. hacker. Inventeur,
bidouilleur, bricoleur, la plupart du temps dans le domaine de l'informatique.
Ce type est un vrai hackeur!
LOGICIEL LIBRE : n. m. - de l'angl. free software.
Se dit d'un logiciel couvert par la licence publique générale
de GNU (liberté au sens des utilisateurs), la licence X, la
licence BSD (liberté au sens des programmeurs), toutes réunies
dans la définition de l'Open Source, ou qui remplit les trois
conditions données par Richard Stallman (disponibilité
du code source, droit de le modifier et d'en redistribuer des versions
modifiées), ou d'autres critères encore, car ce mot
est de plus en plus galvaudé et récupéré.
Le mieux est de préciser ou de se faire préciser exactement
dans quel sens le logiciel dont on traite est «libre».
LOGICIEL OUVERT : n. m. - de l'angl. opensource.
Logiciel couvert par la définition de l'Open Source, c'est-à-dire
qui remplit une dizaine de conditions précises, mises au point
pour que les licences classiques de logiciels libres les satisfassent.
Nous avons traduit logiciels à sources ouverts, nous
appuyant sur le fait que dans le langage informatique «source»,
étant un raccourci pour «code source», s'emploie
au masculin. On entendra fréquemment en effet: «Passe-moi
ton source!»
23. Remerciements des traducteurs
Un grand merci à : Marie-Aurore Soudant (pour
son aide inestimable), Nikky (pour son anglais et sa patience), Nat
Makarevitch (pour son soutien), et à Olivier Blondeau, Florent
Latrive et Michel Valensi pour leur relecture patiente et pertinente
à l'occasion de cette publication sur «site papier».