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

10. Le contexte social du logiciel dont le code source est ouvert

Cela est bien connu: les meilleures bidouilles commencent en tant que solutions personnelles aux problèmes de tous les jours rencontrés par leur auteur, et elles se répandent parce que ce problème est commun à de nombreuses personnes. Cela nous ramène à la règle numéro 1, reformulée de manière peut-être plus utile:

18. Pour résoudre un problème intéressant, commencez par trouver un problème qui vous intéresse.

Ainsi fut-il de Carl Harris et du vieux popclient, ainsi fut-il de moi et de fetchmail. Mais cela est bien compris depuis longtemps. Ce qui compte, le détail sur lequel les histoires de Linux et de fetchmail semblent nous demander de nous concentrer, est l'étape suivante -- l'évolution du logiciel en présence d'une communauté d'utilisateurs et de co-développeurs importante et active.

Dans ``Le mythe du mois-homme'', Fred Brooks observa qu'on ne peut pas diviser et répartir le temps du programmeur; si un projet a du retard, lui ajouter des développeurs ne fera qu'accroître son retard. Il explique que les coûts de communication et de complexité d'un projet augmentent de manière quadratique avec le nombre de développeurs, alors que le travail réalisé n'augmente que linéairement. Depuis, cela est connu sous le nom de ``loi de Brooks'', et on la considère en général comme un truisme. Mais si seule la loi de Brooks comptait, Linux serait impossible.

Le classique de Gerald Weinberg ``La psychologie de la programmation sur ordinateur'' apporta ce qu'on pourrait considérer après coup comme une correction vitale à Brooks. Dans sa discussion sur la ``programmation non égoïste'', Weinberg observa que dans les boîtes où les programmeurs ne marquent pas le territoire de leur code, et encouragent les autres à y chercher les bogues et les améliorations potentielles, les améliorations sont drastiquement plus rapides qu'ailleurs.

Les termes choisis par Weinberg l'ont peut-être empêché de recevoir toute la considération qu'il méritait -- et l'idée que les bidouilleurs sur Internet puissent être décrits comme ``non égoïstes'' fait sourire. Mais je pense que cet argument semble aujourd'hui plus vrai que jamais.

L'histoire d'Unix aurait dû nous préparer à ce que nous découvrons avec Linux (et à ce que j'ai expérimenté à une échelle plus modeste en copiant délibérément les méthodes de Linus): alors que l'acte de programmation est essentiellement solitaire, les plus grandes bidouilles proviennent de la mise à contribution de l'attention et de la puissance de réflexion de communautés entières. Le développeur qui n'utilise que son propre cerveau dans un projet fermé ne tiendra pas la route face au développeur qui sait comment créer un contexte ouvert, susceptible d'évoluer, dans lequel la traque des bogues et les améliorations sont effectuées par des centaines de gens.

Mais le monde traditionnel d'Unix n'a pas poussé cette approche dans ses derniers retranchements pour plusieurs raisons. L'un d'entre eux concernait les contraintes légales des diverses licences, secrets de fabrication, et autres intérêts commerciaux. Un autre (mieux compris plus tard) était que l'Internet n'était pas encore assez mûr.

Avant que les coûts d'accès à Internet ne chutent, il existait quelques communautés géographiquement compactes dont la culture encourageait la programmation ``non égoïste'' à la Weinberg, et un développeur pouvait facilement attirer tout un tas de co-développeurs et autres touche-à-tout doués. Les laboratoires Bell, le laboratoire d'intelligence artificielle de l'institut de technologie du Massachusetts (MIT), l'université de Californie à Berkeley, devinrent les foyers d'innovations légendaires qui sont restés puissants.

Linux fut le premier projet qui fit un effort conscient et abouti pour utiliser le monde entier comme réservoir de talent. Je ne pense pas que cela soit une coïncidence que la période de gestation de Linux ait coïncidé avec la naissance du World Wide Web, ni que Linux ait quitté le stade de la petite enfance en 1993-1994, au moment où l'intérêt général accordé à Internet et que l'industrie des fournisseurs d'accès explosèrent. Linus fut le premier à comprendre comment jouer selon les nouvelles règles qu'un Internet omniprésent rendait possibles.

Même s'il fallait qu'Internet ne coûte pas cher pour que le modèle Linux se développe, je ne pense pas que cela soit suffisant. Il y avait un autre facteur vital: le développement d'un style de direction de projet et d'un ensemble de coutumes de coopération qui permettaient aux développeurs d'attirer des co-développeurs et de rentabiliser au maximum ce nouveau média.

Quel est donc ce style de direction, quelles sont donc ces coutumes ? Ils ne peuvent pas être fondés sur des rapports de force -- même si c'était le cas, la direction par coercition ne produirait pas les résultats qu'on peut observer. Weinberg cite fort à propos l'autobiographie de Pyotr Alexeyvitch Kropotkine, anarchiste russe du XIXe siècle, ``Mémoires d'un révolutionnaire'':

``Élevé dans une famille possédant des serfs, j'entrai dans la vie active, comme tous les jeunes gens de mon époque, avec une confiance aveugle dans la nécessité de commander, d'ordonner, de brimer, de punir et ainsi de suite. Mais quand, assez tôt, je dus diriger d'importantes affaires et côtoyer des hommes libres, et quand chaque erreur pouvait être immédiatement lourde de conséquences, je commençai à apprécier la différence entre agir selon les principes du commandement et de la discipline et agir selon le principe de la bonne intelligence. Le premier fonctionne admirablement dans un défilé militaire, mais ne vaut rien dans la vie courante, où on ne peut atteindre son but que grâce à l'effort soutenu de nombreuses volontés travaillant dans le même sens.''

``L'effort soutenu de nombreuses volontés travaillant dans le même sens'', c'est exactement ce qu'un projet comme Linux demande -- et le ``principe de commandement'' est en effet impossible à appliquer aux volontaires de ce paradis de l'anarchie que nous appelons Internet. Pour opérer et se mesurer les uns aux autres de manière efficace, les bidouilleurs qui cherchent à prendre la tête d'un projet de collaboration commune doivent apprendre à recruter et à insuffler de l'énergie dans les communautés d'intérêts convergents à la manière vaguement suggérée par le ``principe de bonne intelligence'' de Kropotkine. Ils doivent apprendre à utiliser la loi de Linus.

Plus haut, je me référais à ``l'effet de Delphes'' comme une possible explication de la loi de Linus. Mais on ne peut s'empêcher de penser à des analogies très puissantes avec des systèmes adaptatifs en biologie et en économie. Le monde Linux sous de nombreux aspects, se comporte comme un marché libre ou un écosystème, un ensemble d'agents égoïstes qui tentent de maximiser une utilité, ce qui au passage produit un ordre spontané, auto-correcteur, plus élaboré et plus efficace que toute planification centralisée n'aurait pu l'être. C'est ici qu'il faut chercher le ``principe de bonne intelligence''.

La ``fonction d'utilité'' que les bidouilleurs Linux maximisent n'est pas classiquement économique, c'est l'intangible de leur propre satisfaction personnelle et leur réputation au sein des autres bidouilleurs. (On peut être tenté de penser que leur motivation est ``altruiste'', mais c'est compter sans le fait que l'altruisme est en soi une forme d'égoïsme pour l'altruiste). Les cultures volontaires qui fonctionnent ainsi ne sont pas si rares; j'ai déjà participé à des projets semblables dans les fanzines de science-fiction, qui au contraire du monde de la bidouille, reconnaissent explicitement que l'``egoboo'' (le fait que sa réputation s'accroisse auprès des autres fans) est le principal moteur qui propulse les activités volontaires.

Linus, en se positionnant avec succès comme gardien des clés d'un projet où le développement est surtout fait par les autres, et en y injectant de l'intérêt jusqu'à ce qu'il devienne auto-suffisant a montré une intelligence profonde du ``principe de bonne intelligence'' de Kropotkine. Cette vision quasi-économique du monde de Linux nous permet de comprendre comment cette bonne intelligence est mise en oeuvre.

On peut analyser la méthode de Linus comme un moyen de créer de manière efficace, un marché de l'``egoboo'' -- relier les égoïsmes individuels des bidouilleurs aussi fermement que possible, dans le but de réaliser des tâches impossibles sans une coopération soutenue. Avec le projet fetchmail, j'ai montré (à une échelle plus modeste, je vous l'accorde) qu'on peut dupliquer ses méthodes avec de bons résultats. Peut-être même l'ai-je fait un peu plus consciemment et plus systématiquement que lui.

Nombreux sont ceux (en particulier ceux dont les opinions politiques les font se méfier des marchés libres) qui s'attendraient à ce que la culture d'égoïstes sans autre maître qu'eux mêmes soit fragmentée, territoriale, source de gâchis, pleine de petits secrets, et hostile. Mais cette idée est clairement mise en défaut par (pour ne donner qu'un seul exemple) l'époustouflante variété, qualité et profondeur de la documentation relative à Linux. Il est pourtant légendaire que les programmeurs détestent écrire des documentations; comment se fait-il, alors, que les bidouilleurs de Linux en produisent tant ? Il est évident que le marché libre d'egoboo de Linux fonctionne mieux que tout autre pour générer des comportements vertueux, serviables, mieux que les services documentaires largement subventionnés des producteurs de logiciels commerciaux.

Les projets fetchmail et du noyau de Linux montrent tous deux qu'en flattant à bon escient l'ego de beaucoup d'autres bidouilleurs, un coordinateur-développeur fort peut utiliser l'Internet pour tirer parti du fait d'avoir énormément de co-développeurs sans que le projet ne s'effondre en un capharnaüm chaotique. C'est pourquoi je propose la contrepartie suivante à la loi de Brooks:

19: Pour peu que le coordinateur du développement dispose d'un moyen de communication au moins aussi bon que l'Internet, et pour peu qu'il sache comment mener ses troupes sans coercition, il est inévitable qu'il y ait plus de choses dans plusieurs têtes que dans une seule.

Je pense qu'à l'avenir, le logiciel dont le code source est ouvert sera de plus en plus entre les mains de gens qui savent jouer au jeu de Linus, des gens qui abandonnent les cathédrales pour se consacrer entièrement au bazar. Cela ne veut pas dire que les coups de génie individuels ne compteront plus; je pense plutôt que l'état de l'art du logiciel dont le code source est ouvert appartiendra à ceux qui commencent par un projet individuel génial, et qui l'amplifieront à travers la construction efficace de communautés d'intérêt volontaires.

Et peut-être même qu'il n'est pas question ici que de l'avenir du logiciel dont le code source est ouvert. Aucun développeur qui fonctionne avec un code source fermé ne peut mobiliser autant de talent que celui que la communauté Linux peut consacrer à un problème donné. Bien rares même sont ceux qui auraient eu les moyens de rémunérer les deux cents et quelques contributeurs à fetchmail !

Peut-être qu'à terme, la culture du logiciel dont le code source est ouvert triomphera, non pas parce qu'il est moralement bon de coopérer, non pas parce qu'il est moralement mal de ``clôturer'' le logiciel (en supposant que vous soyez d'accord avec la deuxième assertion; ni Linus ni moi ne le sommes), mais simplement parce que le monde dont le code source est fermé ne peut pas gagner une course aux armements évolutive contre des communautés de logiciel libre, qui peuvent mettre sur le problème un temps humain cumulé plus important de plusieurs ordres de grandeurs.


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