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

5. Les communs inversés

Ayant observé le modèle dominant d'un oeil sceptique, voyons s'il est possible d'en construire un autre — une explication têtue de ce qui fait que la coopération dans le cadre de projets à sources ouverts soit défendable économiquement.

Cette question mérite qu'on l'examine à différents niveaux. Il nous faut d'abord expliquer le comportement d'individus qui contribuent dans le cadre de projets à sources ouverts ; il nous faut aussi comprendre les forces économiques qui financent la coopération sur des projets à sources ouverts tels que Linux ou Apache.

Ici encore, il nous faudra d'abord démolir un modèle très répandu parmi les foules et qui entrave la compréhension. Sur chacune des tentatives d'explication de comportements coopératifs, plane l'ombre de la Tragédie des communs, de Garret Hardin

N.D.T. : titre original : Tragedy of the Commons.
.

Dans ce texte célèbre, Hardin nous demande d'imaginer un pré, propriété collective d'un village de paysans, qui y font paître leur bétail. Mais les animaux dégradent les communs, en arrachant l'herbe et en laissant des portions boueuses derrière eux, qui ne recouvreront que lentement leur couverture végétale. En l'absence de politique consentie (et appliquée, fût-ce par la force) pour allouer des droits et des limites à chacun, l'intérêt de chacune des parties est d'y mener un maximum de têtes le plus vite possible, pour en extraire toute la valeur avant que les communs ne soient réduits à une mer de boue.

La plupart des gens ont un modèle intuitif du comportement coopératif très semblable à cette fable. En réalité, ce n'est pas une bonne représentation des problèmes économiques des sources ouverts, qui relèvent plus du passager clandestin (sous-provisionnement) que de la congestion des biens publics (sur-utilisation). Néanmoins, c'est cette analogie qui a incité la plupart des objections spontanées qu'on m'a opposées.

La tragédie des communs ne prédit que trois résultats possibles. Le premier est une mer de boue. Le deuxième est qu'un acteur disposant d'un pouvoir coercitif ne fasse appliquer une politique d'allocation au nom du village (c'est la solution communiste). Le dernier est que les communs soient divisés et que les membres du village n'en clôturent des portions qu'ils pourront défendre et gérer correctement (c'est la solution des droits de propriété).

Quand, par réflexe, les gens appliquent ce modèle à la coopération dans le cadre de projets à sources ouverts, ils s'attendent à ce qu'elle soit instable et possède une demi-vie courte. Puisqu'il n'existe aucune manière évidente d'appliquer une politique d'allocation au temps des programmeurs sur l'Internet, ce modèle conduit tout droit à la prédiction que les communs vont être séparés, que diverses portions de logiciels seront rendues propriétaires, et que la quantité de travaux réinjectés dans le pot commun décroîtra rapidement.

En fait, les faits empiriques sont clairs, et c'est la tendance contraire qui a lieu. Le spectre et le modèle des développements à sources ouverts (mesurés, par exemple, en termes de soumissions sur Metalab ou en annonces sur freshmeat.net chaque jour) croît continûment. Il est clair qu'on assiste à un phénomène dont le modèle de la « Tragédie des communs » échoue à rendre compte.

Une partie de la réponse tient certainement au fait qu'utiliser du logiciel n'en décroît en rien la valeur. En fait, le fait qu'un logiciel à sources ouverts soit largement utilisé tend à en augmenter la valeur, puisque les utilisateurs contribuent par leurs propres corrections et ajouts (par des patches au code). Dans ces communs inversés, l'herbe repousse plus haut quand elle est broutée.

La réponse tient aussi dans le fait que la valeur supposée, sur le marché, de petits correctifs à une base commune de sources est difficile à capturer. Supposons que j'écrive un correctif pour un bogue irritant, et supposons que de nombreuses personnes comprennent que ce travail a une valeur économique ; comment puis-je la collecter de tous ces gens ? Les systèmes conventionnels de paiement ont des surcoûts suffisamment élevés pour rendre impraticables les micro-paiements qui seraient sinon appropriés.

On divaguera moins encore si on signale que cette valeur n'est pas seulement difficile à capturer, elle est même, dans le cas général, difficile à déterminer. Soit l'expérience de pensée suivante : supposons que l'Internet soit équipé du système de micro-paiements idéal en théorie — sûr, accessible à tous, sans surcoûts. Supposons maintenant que vous ayez écrit un patch intitulé « Divers correctifs pour le noyau Linux ». Comment un acheteur potentiel, n'ayant pas encore vu votre travail, peut savoir ce qu'il est raisonnable d'en proposer ?

Nous nous trouvons en présence de l'image à travers une maison aux miroirs de foire du « problème de calcul » de F.A. Hayek — il faudrait un sur-être, à la fois capable d'évaluer la valeur fonctionnelle des correctifs et habilité à positionner les prix en fonction, pour lubrifier le commerce.

Malheureusement, il y a rupture de stock sur les sur-êtres, aussi l'auteur du correctif, T. Codeur-Lambda a deux possibilités : garder le correctif par devers lui, ou en faire gracieusement bénéficier les autres. La première possibilité ne lui apporte rien. Le second choix ne lui apportera peut-être rien, mais il peut aussi encourager d'autres à donner des correctifs qui résoudront certains des problèmes de T. Codeur-Lambda à l'avenir. Le second choix, apparemment altruiste, est en fait optimalement égoïste au sens de la théorie des jeux.

En analysant ce type de coopération, il est important de remarquer que même en présence d'un problème de passager clandestin (il se peut que le travail se fasse mal en l'absence d'argent ou de compensations équivalentes), il ne grandit pas avec le nombre d'utilisateurs finals. La complexité et les surcoûts en communication d'un projet à sources ouverts ne dépend pratiquement que du nombre de développeurs impliqués ; disposer d'un plus grand nombre d'utilisateurs finals, qui n'iront jamais inspecter le code source, ne coûte rien, dans la pratique. Cela peut augmenter le nombre de questions idiotes sur les listes de diffusion du projet, mais on peut faciliter anticiper cela en maintenant une foire aux questions (FAQ) et en ignorant avec insouciance ceux qui posent des questions sans l'avoir consultée (et en fait, ces deux pratiques sont typiques).

Les véritables problèmes de passagers clandestins dans le logiciel à sources ouverts dépendent plus des coûts de friction lors de la soumission de correctifs que de quoi que ce soit d'autre. Un contributeur potentiel peu averti du jeu culturel des réputations (voir [HtN] ) peut, en l'absence de compensation financière, penser « Cela n'est pas la peine de soumettre ce correctif car il me faudra nettoyer le patch, écrire une entrée dans le fichier Changelog, et signer les papiers légaux de la FSF... ». C'est pour cette raison que le nombre de contributeurs (et, au second ordre, la réussite) des projets est fortement liée et inversement proportionnelle au nombre de sas que chaque projet impose à chaque utilisateur de traverser avant de l'autoriser à contribuer. De tels coûts de frictions peuvent être politiques ou mécaniques. Corrélés, ils peuvent expliquer pourquoi la culture Linux, amorphe et lâche, a attiré à elle une énergie coopérative de plusieurs ordres de grandeur supérieure aux efforts plus sévèrement organisés et plus centralisés des projets *BSD, et pourquoi la montée de Linux a fait de l'ombre à la Free Software Foundation.

Tout cela est bel et bon. Mais c'est une explication a posteriori de ce que T. Codeur-Lambda doit faire de son correctif une fois qu'il en dispose. Il faut aussi donner une explication économique au fait que T. C-L a eu les moyens pour écrire ce correctif, plutôt que de devoir travailler sur un programme à sources fermés qui aurait pu lui octroyer un revenu sous la forme de prix d'acquisition. Quels modèles économiques créent des niches dans lesquelles le développement à sources ouverts peut prospérer ?


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