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

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

Nous avons examiné les coutumes qui régulent la propriété des, 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.
de la tribu des hackeurs.

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.


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