La cathédrale et le bazar(The Cathedral and the Bazaar)Auteur : Eric Steven Raymond (esr@thyrsus.com)Traducteur : Sébastien Blondeel (sbi@linux-france.org)$Date: 1998/08/11 20:27:29 $
Résumé J'analyse le succès d'un projet de logiciel dont le code source est ouvert, NdT : traduction de open-source software, terme par lequel l'auteur a délibérément remplacé le terme précédent free software (logiciel libre). « Ouvert » signifie ici à la fois public et susceptible d'être commenté et corrigé par ceux qui s'y intéresseront suffisamment. fetchmail (« va chercher le courrier »), qui a été lancé délibérément pour tester certaines théories surprenantes du génie logiciel suggérées par l'histoire de Linux. Je discute ces théories en termes de deux styles de développement fondamentalement différents, le modèle « cathédrale » de la majorité du monde commercial, à opposer au modèle « bazar » du monde de Linux. Je montre que ces modèles dérivent d'hypothèses opposées sur la nature de la tâche consistant à déboguer un logiciel. Enfin, je m'efforce de démontrer, à partir de l'expérience apportée par Linux, qu'« Étant donnés suffisamment d'observateurs, tous les bogues sautent aux yeux », je suggère des analogies productives avec d'autres systèmes auto-correcteurs par agents égoïstes, et je conclus en réfléchissant aux implications de ces idées sur l'avenir du logiciel. Table des matières
NdT : Aux termes to hack, hacker, Eric S. Raymond a consacré un article complet. Il s'agit de l'action de comprendre comment les choses fonctionnent, de vouloir savoir ce qui se cache dans les mécaniques diverses, et de les réparer ou de les améliorer. En aucun cas, ce terme ne doit être confondu, sous cette plume, avec les pirates de l'informatique, ou crackers. J'ai choisi de traduire ce terme par « bidouille », et je vous demande de ne pas y attacher d'a priori négatif. Un bidouilleur construit des choses parfois très belles et très compliquées, alors qu'un pirate cherche à détruire. faites pendant le temps libre de plusieurs milliers de développeurs disséminés de par le monde, et reliés seulement par les les liens ténus de l'Internet ? Depuis 1993, j'étais aux commandes du service technique d'un modeste fournisseur de services Internet proposant un accès libre, appelé Chester County Interlink (CCIL) et situé dans le West Chester, en Pennsylvanie (je suis l'un des co-fondateurs de CCIL et j'ai écrit notre unique logiciel de « bulletin-board system » (BBS, systèmes de discussions entre utilisateurs) multi-utilisateurs — vous pouvez vérifier cela en accédant par telnet à locke.ccil.org. Aujourd'hui, ce service supporte presque trois mille utilisateurs sur trente lignes.) Ce travail m'a permis d'accéder au réseau 24 heures sur 24, à travers la ligne de 56K de CCIL — en réalité, c'était presque une nécessité ! De cette manière, je m'étais habitué au courrier électronique instantané par
l'Internet. Pour des raisons compliquées, il était difficile de faire
fonctionner SLIP entre ma machine située à mon domicile
( Indiquer simplement à sendmail de faire suivre le courrier n'aurait pas
fonctionné, parce que ma machine personnelle n'est pas sur le réseau en
permanence et ne dispose pas d'une adresse IP statique. J'avais besoin d'un
programme qui étende une main tentaculaire à travers ma connexion SLIP, et me
rapporte mon courrier afin de le distribuer de manière locale. Je savais que de
telles choses existaient, et que la plupart d'entre elles utilisait un simple
protocole d'application (application protocol) appelé POP (Post Office Protocol,
protocole du bureau de poste). Et bien sûr, le système d'exploitation BSD/OS de
J'avais besoin d'un client POP3. Alors je suis allé sur le réseau et j'en ai trouvé un. En fait, j'en ai trouvé trois ou quatre. J'ai utilisé pop-perl pendant un moment, mais il lui manquait une fonctionnalité qui semblait évidente, la possibilité de bidouiller les adresses sur le mail rapporté afin que les réponses fonctionnent correctement. Le problème était le suivant: un dénommé `joe' sur C'était typiquement le genre de choses que l'ordinateur devait faire à ma place. Mais aucun des clients POP existants ne savait comment faire ! Et ceci nous amène à la première leçon :
Ceci est peut-être une évidence (il est bien connu, et depuis longtemps, que « Nécessité est mère d'Invention ») mais trop souvent on voit des développeurs de logiciels passer leurs journées à se morfondre à produire des programmes dont ils n'ont pas besoin et qu'ils n'aiment pas. Ce n'est pas le cas dans le monde Linux — ce qui peut expliquer pourquoi la plupart des programmes issus de la communauté Linux sont de si bonne facture. Alors, me suis-je précipité frénétiquement dans le codage d'un client POP3 tout nouveau tout beau, qui soutienne la comparaison avec ceux qui existent déjà ? Jamais de la vie ! J'ai examiné avec beaucoup d'attention les utilitaires POP que j'avais à ma disposition, en me demandant « lequel de ces programmes est le plus proche de ce que je cherche ? ». Parce que :
N'ayant pas la prétention de me compter parmi les grands programmeurs, j'essaie seulement de les imiter. Une caractéristique importante des grands programmeurs est la paresse constructive. Ils savent qu'on n'obtient pas 20/20 pour les efforts fournis, mais pour le résultat obtenu, et qu'il est pratiquement toujours plus facile de partir d'une bonne solution partielle que de rien du tout. Linus Torvalds, par exemple, n'a pas essayé d'écrire Linux en partant d'une page blanche. Au contraire, il a commencé par réutiliser le code et les idées de Minix, un minuscule système d'exploitation ressemblant à Unix tournant sur les 386. La totalité du code de Minix a été abandonnée ou réécrite complètement depuis — mais tant qu'il était là, ce code a servi de tuteur à l'enfant qui deviendrait Linux. Dans le même esprit, je me suis mis en quête d'un utilitaire POP raisonnablement bien écrit, afin de l'utiliser comme base pour mon développement. La tradition de partage du code source du monde Unix a toujours favorisé la réutilisation de code (c'est pourquoi le projet GNU a choisi Unix comme système d'exploitation de travail, malgré de sérieuses réserves quant au système d'exploitation lui-même). Le monde Linux a pratiquement emmené cette tradition jusqu'à sa limite technologique; il dispose de téraoctets (millions de millions d'octets) de codes sources ouverts généralement disponibles. De telle sorte que passer du temps à chercher le « presqu'assez bon » de quelqu'un d'autre a plus de chances de donner de bons résultats dans le monde Linux que nulle part ailleurs. Et pour moi, cela a marché. Avec ceux que j'avais déjà trouvés, ma deuxième recherche aboutit à un total de neuf candidats — fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail et upop. Je me suis d'abord concentré sur le `fetchpop' de Seung-Hong Oh. J'y ai ajouté ma fonctionnalité de réécriture des entêtes, et j'ai fait un certain nombre d'améliorations que l'auteur a acceptées dans sa version 1.9. Quelques semaines plus tard, cependant, je suis tombé sur le code de `popclient' par Carl Harris, et j'ai rencontré un problème. Fetchpop contenait des idées bonnes et originales (comme son mode démon), mais il ne pouvait gérer que POP3 et il était programmé d'une manière quelque peu amateur (Seung-Hong est un programmeur brillant mais inexpérimenté, et ces deux caractéristiques apparaissaient dans son travail). Le code de Carl était meilleur, assez professionnel et solide, mais son programme ne proposait pas certaines fonctionnalités de fetchpop, importantes et plutôt difficiles à coder (en particulier, celles que j'avais programmées moi-même). Continuer, ou basculer ? Si je basculais, cela revenait à abandonner le travail que j'avais déjà réalisé, en échange d'une meilleure base de développement. Une raison pragmatique me poussant à changer était la présence d'un support pour plusieurs protocoles. POP3 est le protocole de bureau de poste NdT : traduction littérale de POP le plus communément utilisé, mais ce n'est pas le seul. Fetchpop et ses semblables n'étaient pas compatibles avec les protocoles POP2, RPOP, ou APOP, et j'envisageais déjà vaguement d'ajouter IMAP (Internet Message Access Protocol, protocole d'accès aux messages par Internet, le protocole de bureau de poste le plus récent et le plus puissant), rien que pour le plaisir. Mais j'avais une raison plus théorique de penser que changer serait une bonne idée malgré tout, une raison que j'avais apprise bien avant Linux.
NdT : « Le mythe du mois-homme », traduction de Frédéric Mora, ITP, ISBN 2-84180-081-4, est un livre où il explique que l'ensemble des croyances relatives à l'unité de mesure « mois-homme » est un mythe. Ou, dit autrement, on ne comprend souvent vraiment bien un problème qu'après avoir implanté une première solution. La deuxième fois, on en sait parfois assez pour le résoudre correctement. Ainsi, si vous voulez faire du bon travail, soyez prêt à recommencer au moins une fois.. Bien (me suis-je dit), les modifications à fetchpop furent un coup d'essai. J'ai donc basculé. Après avoir envoyé à Carl Harris mon premier lot de modifications apportées à popclient, le 25 juin 1996, j'ai découvert qu'il avait pratiquement perdu tout intérêt pour popclient depuis quelque temps. Le code était un peu poussiéreux, et de petits bogues y subsistaient. J'avais de nombreuses modifications à apporter, et nous nous sommes rapidement mis d'accord pour que je reprenne le programme. Avant même que je m'en rende compte, le projet avait monté d'un cran. Je n'envisageais plus d'apporter des modifications mineures à un client POP existant. Je m'engageais à maintenir un client POP dans son intégralité, et je savais que certaines des idées qui germaient dans mon cerveau m'amèneraient probablement à effectuer des modifications majeures. Dans une culture du logiciel qui encourage le partage du code, il est naturel pour un projet d'évoluer ainsi. J'étais en train d'expérimenter le fait suivant:
Mais l'attitude de Carl Harris était encore plus importante. Il comprit que
Sans même avoir à en discuter, Carl et moi savions que nous poursuivions un objectif commun: chercher la meilleure solution. La seule question d'importance pour chacun de nous était de nous assurer que le programme serait en de bonnes mains avec moi. Une fois que j'en apportai la preuve, il me fit place nette avec bonne volonté. J'espère agir de même quand mon tour viendra. En fait, ma bidouille personnelle qui a rencontré le plus de succès, avant fetchmail, fut probablement le mode VC pour Emacs, issu d'une collaboration par courrier électronique à la Linux avec trois autres personnes, et je n'ai toujours rencontré que l'une d'entre elles (Richard Stallman, l'auteur d'Emacs et le fondateur de la FSF) à ce jour. C'était une interface sous Emacs pour SCCS, RCS et plus tard pour CVS, qui fournissait toutes les opérations de contrôle de version avec un seul bouton. Il était parti d'un mode sccs.el très rudimentaire et tout petit, écrit par quelqu'un d'autre. Et le développement de VC fut réussi parce que, à la différence d'Emacs lui-même, le code Lisp pour Emacs pouvait traverser très rapidement les cycles de mise à jour/test/amélioration. La plus importante de ces archives, l'archive elisp de l'État de l'Ohio, était en avance sur son temps et avait déjà deviné l'esprit et la plupart des spécificités des archives Linux actuelles. Mais bien peu d'entre nous réfléchissaient vraiment beaucoup sur ce que nous faisions ou sur les problèmes liés au développement de style cathédrale adoptés par la FSF que l'existence même de cette archive pouvait suggérer. J'ai vraiment tenté, une fois, vers 1992, de faire passer de manière formelle, un bon morceau du code d'Ohio dans la bibliothèque Lisp officielle d'Emacs. Je n'ai rencontré que des guerres d'opinions et je suis rentré bredouille dans les grandes longueurs. Mais un an plus tard, alors que Linux devenait de plus en plus apparent, il était clair que quelque chose de différent, de plus sain, était en train de se produire. La politique de développement ouvert de Linus était l'antithèse même du modèle des cathédrales. Les archives de sunsite et de tsx-11 bourgeonnaient, de multiples distributions étaient mises à l'eau. Et tout cela était rythmé par une fréquence de mise à jour du coeur même du système jusqu'alors inégalée. Linus traitait ses utilisateurs comme des développeurs de la manière la plus efficace:
La grande innovation de Linus ne fut pas tant de faire cela (c'était une tradition du monde Unix depuis un bon moment, en tout cas sous une forme proche), que de donner à cette idée un niveau d'intensité correspondant à la complexité de ce qu'il développait. En ces temps reculés (autour de 1991), il lui arrivait de mettre à jour son noyau plusieurs fois par jour ! Comme il cultivait sa base de co-développeurs et recherchait des collaborations sur Internet plus que quiconque jusque là, cela a marché. Mais comment cela a-t-il marché ? Et, était-ce quelque chose que je pouvais dupliquer, ou cela reposait-il uniquement sur quelque trait de génie propre à Linus Torvalds ? Je ne le pensais pas. Je vous l'accorde, Linus est un bidouilleur sacrément bon (combien parmi nous pourraient mettre au point l'intégralité du noyau d'un système d'exploitation prêt à être mis en production ?). Mais Linux ne constituait pas vraiment un réel progrès conceptuel. Linus n'est pas (en tout cas, pas encore) un génie de l'innovation dans la conception comme peuvent l'être Richard Stallman ou James Gosling (de NeWS et Java). Au contraire, Linus est à mes yeux un génie de l'ingéniérie, doué d'un sixième sens qui lui permet d'éviter les bogues et les impasses de développement et surtout d'un authentique talent pour trouver le chemin de moindre effort reliant A à B. En effet, la conception de Linux dans son intégralité est imprégnée de cette qualité et reflète l'approche conservatrice et simplificatrice qu'a Linus de la conception. Ainsi, si la rapidité des mises à jour et l'extraction de la substantifique moelle de l'Internet en tant que moyen de communication n'étaient pas des hasards, mais faisaient partie intégrante du côté visionnaire génial de Linus vers le chemin le plus facile à suivre, qu'est-ce donc qu'il maximisait ? Qu'est-ce donc qu'il tirait de toute cette machinerie ? Posée de cette manière, la question contient sa propre réponse. Linus stimulait et récompensait ses utilisateurs/bidouilleurs en permanence — il les stimulait par la perspective auto-gratifiante de prendre part à l'action, et il les récompensait par la vue constante (et même quotidienne) des améliorations de leur travail. Linus cherchait directement à maximiser le nombre de personnes-heures jetées dans la bataille du débogage et du développement, au prix éventuel d'une certaine instabilité dans le code et de l'extinction de sa base d'utilisateurs si un quelconque bogue sérieux se révélait insurmontable. Linus se comportait comme s'il croyait en quelque chose comme:
Ou, moins formellement, « Étant donnés suffisamment d'observateurs, tous les bogues sautent aux yeux. » C'est ce que j'appelle: « La Loi de Linus ». Ma première formulation de cette loi était que chaque problème « semblera clair comme de l'eau de roche à quelqu'un ». Linus a objecté qu'il n'était pas nécessaire, et que d'ailleurs ce n'était pas le cas en général, que la personne qui comprenne un problème soit la personne qui l'ait d'abord identifié. « Quelqu'un trouve le problème, » dit-il, « et c'est quelqu'un d'autrequi le comprend. Je pousserai le bouchon jusqu'à dire que le plus difficile est de trouver le problème. » Mais le principal est que ces deux événements se produisent en général vite. C'est là, je pense, la différence fondamentale sous-jacente aux styles de la cathédrale et du bazar. Dans la programmation du point de vue de la cathédrale, les bogues et les problèmes de développement représentent des phénomènes difficiles, ennuyeux, insidieux, profonds. Il faut à une poignée de passionnés des mois d'observations minutieuses avant de bien vouloir se laisser convaincre que tous les bogues ont été éliminés. D'où les longs intervalles séparant les mises à jour, et l'inévitable déception quand on se rend compte que la mise à jour tant attendue n'est pas parfaite. Dans le point de vue bazar, d'un autre côté, vous supposez qu'en général, les bogues sont un phénomène de surface — ou, en tout cas, qu'ils sautent rapidement aux yeux lorsqu'un millier de co-développeurs avides se précipitent sur toute nouvelle mise à jour. C'est pourquoi vous mettez à jour souvent afin de disposer de plus de corrections, et un effet de bord bénéfique est que vous avez moins à perdre si de temps en temps, un gros bogue vous échappe. Et voilà. C'est tout. Si la « Loi de Linus » est fausse, alors tout système aussi complexe que le noyau Linux, subissant les bidouilles simultanées d'autant de mains que ce fut le cas du noyau Linux, aurait dû à un certain moment s'effondrer sous le poids des interactions néfastes et imprévues, sous le poids de bogues « profonds » non découverts. D'un autre côté, si elle est juste, elle suffit à expliquer l'absence relative de bogues dans Linux. Et peut-être bien, après tout, que cela ne devrait pas être aussi surprenant. Il y a des années que les sociologues ont découvert que l'opinion moyenne d'un grand nombre d'observateurs (tous aussi experts, ou tous aussi ignorants) est d'un indicateur beaucoup plus fiable que l'opinion de l'un des observateurs, choisi au hasard. Ils ont appelé ce phénomène l'« effet de (l'oracle de) Delphes ». Il apparaît que Linus a fait la preuve que cela s'applique même au débogage d'un système d'exploitation — que l'effet de Delphes peut apprivoiser la complexité du développement même au niveau de complexité atteint par le noyau d'un système d'exploitation. Je dois à Jeff Dutky <dutky@wam.umd.edu> la remarque qu'on peut reformuler la Loi de Linus sous la forme « On peut paralléliser le débogage ». Jeff fait remarquer que, même si le débogage requiert que les débogueurs communiquent avec un développeur chargé de la coordination, une réelle coordination entre débogueurs n'étant pas indispensable. Ainsi, le débogage n'est pas la proie de cette augmentation quadratique de la complexité et des coûts d'organisation qui rend problématique l'ajout de nouveaux développeurs. En pratique, le monde Linux n'est quasiment pas affecté par la perte théorique d'efficacité qui découle du fait que plusieurs débogueurs travaillent sur la même chose au même moment. L'une des conséquences de la politique du « distribuez tôt, mettez à jour souvent » est de minimiser les pertes de ce type en propageant au plus vite les corrections qui sont revenues au coordinateur. Brooks a même fait une observation annexe proche de celle de Jeff: « Le coût total de maintenance d'un programme largement utilisé est typiquement de 40 pour cent ou plus de son coût de développement. De façon surprenante, ce coût dépend énormément du nombre d'utilisateurs. Un plus grand nombre d'utilisateurs trouve un plus grand nombre de bogues. » (l'emphase est de mon fait). Plus d'utilisateurs trouvent plus de bogues parce que l'ajout de nouveaux utilisateurs introduit de nouvelles manières de pousser le programme dans ses derniers retranchements. Cet effet est amplifié quand les utilisateurs se trouvent être des co-développeurs. Chacun d'entre eux a une approche personnelle de la traque des bogues, en utilisant une perception du problème, des outils d'analyse, un angle d'attaque qui lui sont propres. L'« effet de Delphes » semble précisément fonctionner grâce à cette variabilité. Dans le contexte spécifique du débogage, la diversité tend aussi à réduire la duplication des efforts. Ainsi, introduire de nouveaux bêta-testeurs ne va sans doute pas réduire la complexité du bogue le plus « profond » du point de vue du développeur, mais cela augmente la probabilité que la trousse à outils d'un bêta-testeur sera adaptée au problème de telle sorte que le bogue saute aux yeux de cette personne. Mais Linus assure ses arrières. Au cas où il y aurait des bogues sérieux, les versions du noyau Linux sont numérotées de telle sorte que des utilisateurs potentiels peuvent faire le choix d'utiliser la dernière version désignée comme étant « stable », ou de surfer à la pointe de la technique courant le risque que quelques bogues accompagnent les nouvelles fonctionnalités. Cette tactique n'est pas encore formellement imitée par la plupart des bidouilleurs Linux, mais c'est sans doute un tort; le fait d'avoir une alternative rend les deux choix séduisants.
J'ai en partie accepté d'ajouter le multidrop parce qu'on me le réclamait à grands cris, mais surtout parce que je pensais qu'il m'aiderait à traquer les bogues subsistant dans le code 'single-drop' (mono-destinataire) en me forçant à gérer les adresses dans toute leur généralité. C'est ce qui s'est passé. Il me fallut extrêmement longtemps pour gérer la syntaxe du RFC 822, NdT : les RFC sont des protocoles décidés en commun sur Internet. Ce sont les initiales de Request For Comments, littéralement « (nous) réclamons des commentaires (sur ce qui suit) ». non qu'il contienne des choses extrêmement compliquées, mais que dans son ensemble il fait intervenir un enchevêtrement de détails un peu tordus. Mais l'adressage multidrop s'avéra également être une excellente décision de conception. Voici comment je m'en rendis compte :
L'utilisation inattendue d'un fetchmail multi-destinataires est la gestion de listes de courrier électronique où la liste est conservée et où le développement des alias est fait du côté client de la connexion SLIP/PPP. Cela signifie qu'on peut modérer une liste de courrier électronique à partir d'une machine personnelle, via un compte chez un fournisseur de services pour Internet NdT : ISP, parfois FAI sans devoir accéder sans cesse aux fichiers d'alias du fournisseur. Une autre amélioration importante exigée par mes bêta-testeurs, fut la possibilité d'utiliser le format MIME en 8 bits. Cela fut assez simple à faire, parce que j'avais pris soin de laisser mon code compatible 8 bits. Non que je prévoyais ce souhait des utilisateurs, mais plutôt en accord avec une autre règle :
Si je n'avais pas obéi à cette règle, le support du MIME en 8 bits aurait été difficile à implanter et instable. En l'état, il me suffit de lire le RFC 1652 et d'ajouter un petit peu de logique triviale pour la génération des en-têtes. Quelques utilisateurs européens m'ont ennuyé jusqu'à ce que j'ajoute une option pour limiter le nombre de messages transférés à chaque session (pour qu'ils puissent contrôler le prix de la communication téléphonique, sur leur onéreux réseau). J'ai mis du temps à m'y résoudre, et aujourd'hui encore je n'en suis pas très content. Mais quand vous êtes au service du monde entier, il vous faut écouter vos consommateurs — le fait qu'ils ne vous paient pas en monnaie sonnante et trébuchante ne change rien à l'affaire.
Quand vous initiez un travail de développement en communauté, il vous faut être capable de présenter une promesse plausible. Votre programme ne doit pas nécessairement fonctionner très bien. Il peut être grossier, bogué, incomplet, et mal documenté. Mais il ne doit pas manquer de convaincre des co-développeurs potentiels qu'il peut évoluer en quelque chose de vraiment bien dans un futur pas trop lointain. Linux et fetchmail furent tous deux rendus publics avec des conceptions simples, fortes et séduisantes. Nombreux sont ceux qui, après avoir réfléchi au modèle du bazar tel que je l'ai présenté ici, ont très correctement considéré que cela était critique, et en ont rapidement conclu qu'il était indispensable que le chef de projet fasse preuve au plus haut point d'astuce et d'intuition dans la conception. Mais Linus se fonda sur la conception d'Unix. Ma conception provenait initialement du vieux programme popclient (bien que beaucoup de choses aient changé à terme, proportionnellement bien plus que dans Linux). Alors faut-il que le chef/coordinateur d'un effort commun mené dans le style bazar ait un talent exceptionnel pour la conception, ou peut-il se contenter d'exalter le talent des autres ? Je pense qu'il n'est pas critique que le coordinateur soit capable de produire des conceptions exceptionnellement brillantes. En revanche, il est absolument critique que le coordinateur soit capable de reconnaître les bonnes idées de conception des autres. Les projets Linux et fetchmail en sont tous deux la preuve. Linus, bien qu'il ne soit pas (comme nous l'avons vu précédemment) un concepteur spectaculairement original, a démontré une puissante capacité à reconnaître une bonne conception et à l'intégrer au noyau Linux. Et j'ai déjà décrit comment l'idée la plus puissante dans la conception de fetchmail (faire suivre le courrier vers le port SMTP) me fut soufflée par quelqu'un d'autre. Les premières personnes auxquelles j'ai présenté cet article m'ont complimenté en me suggérant que je suis prompt à sous-évaluer dans la conception des projets menés dans le style bazar, leur originalité — principalement parce que j'en suis pas mal pourvu moi-même, ce qui me conduit à considérer cela comme acquis. Il peut y avoir un fond de vérité là dedans; la conception (à l'opposé de la programmation ou du débogage) est certainement mon point fort. Mais le problème avec l'intelligence et l'originalité dans la conception de logiciels, c'est que ça devient une habitude — presque par réflexe, vous commencez à faire dans l'esthétique et le compliqué alors qu'il faudrait rester simple et robuste. Certains de mes projets n'ont jamais abouti à cause de cette erreur, mais ce ne fut pas le cas pour fetchmail. Aussi suis-je convaincu que le projet fetchmail a réussi en partie parce que j'ai refoulé ma tendance à donner dans la subtilité; cela contredit (au moins) l'idée que l'originalité dans la conception est essentielle dans des projets réussis menés dans le style bazar. Et pensez à Linux. Imaginez que Linus ait tenté de mettre en pratique des innovations fondamentales dans la conception de systèmes d'exploitation au cours du développement; est-il probable que le noyau qui en résulterait soit aussi stable et populaire que celui que nous connaissons ? Il faut, bien sûr, une certaine habileté dans la conception et le codage, mais je pense que quiconque envisage sérieusement de lancer un projet dans le style en possède déjà le minimum nécessaire. Les lois du marché de la réputation interne au monde du logiciel dont le code source est ouvert exercent des pressions subtiles décourageant ceux qui pensent mettre à contribution d'autres développeurs alors qu'ils n'ont pas eux-mêmes la compétence d'assurer le suivi. Jusqu'à présent tout cela semble avoir très bien marché. Il existe une autre qualité qui n'est pas normalement associée au développement logiciel, mais je pense qu'elle est aussi importante qu'une bonne intelligence de la conception pour les projets de style bazar — et elle est peut-être bien plus importante. Le chef, ou coordinateur, d'un projet dans le style bazar doit être bon en relations humaines et avoir un bon contact. Cela devrait être évident. Pour construire une communauté de développement, il vous faut séduire les gens, les intéresser à ce que vous faites, et les encourager pour les petits bout du travail qu'ils réalisent. De bonnes compétences techniques sont essentielles, mais elles sont loin de suffire. La personnalité que vous projetez compte aussi. Cela n'est pas une coïncidence que Linus soit un chic type qu'on apprécie volontiers et qu'on a envie d'aider. Cela n'est pas fortuit non plus que je sois un extraverti énergique qui aime animer les foules et qui se comporte et réagit comme un comique de théâtre. Pour que le modèle du bazar fonctionne, une petite touche de charme et de charisme aide énormément.
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 :
« 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 :
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. Un grand nombre de personnes m'ont aidé, au travers de conversations, à améliorer cet article. Je remercie tout particulièrement Jeff Dutky <dutky@wam.umd.edu> qui m'a suggéré la formule « le débogage est parallélisable », et qui m'a aidé à tirer l'analyse qui en découle. Merci aussi à Nancy Lebovitz <nancyl@universe.digex.net> qui m'a suggéré que je suivais l'exemple de Weinberg en citant Kropotkine. J'ai reçu aussi des critiques utiles de la part de Joan Eslinger <wombat@kilimanjaro.engr.sgi.com> et de Marty Franz <marty@net-link.net> de la liste de General Technics. Je remercie les membres du PLUG, le groupe d'utilisateurs de Linux de Philadelphie (jeu de mot signifiant aussi « branché »), pour avoir joué le rôle du premier public critique de cet article. Enfin, les commentaires de Linus Torvalds me furent utiles, et son soutien des premières heures m'encouragea beaucoup. J'ai cité plusieurs extraits du classique de P. Brooks The Mythical Man-Month (Le mythe du mois-homme) parce que, sous bien des aspects, ses conclusions doivent encore être affinées. Je recommande chaleureusement l'édition faite par la société Addison-Wesley (ISBN 0-201-83595-9) à l'occasion du vingt-cinquième anniversaire de ce livre, qui ajoute son article de 1986 intitulé « No Silver Bullet » (pas de balle en argent). Cette nouvelle édition est préfacée par une inestimable rétrospective des 20 dernières années dans laquelle Brooks reconnaît les quelques affirmations de son texte original qui n'ont pas résisté à l'épreuve du temps. J'ai lu la rétrospective pour la première fois après avoir écrit la quasi totalité du présent article, et j'ai été surpris de constater que Brooks attribue des pratiques de type bazar à Microsoft ! De Gerald M. Weinberg, The Psychology Of Computer Programming (la psychologie de la programmation des ordinateurs) (New York, Van Nostrand Reinhold 1971) introduisit le concept assez maladroitement appelé de « programmation non égoïste ». Bien que n'étant pas le premier à se rendre compte de la futilité du « principe de commandement », il fut probablement le premier à reconnaître cet aspect et à argumenter sur ce dernier par rapport au développement logiciel. Richard P. Gabriel, en contemplant la culture Unix de l'avant-Linux, argumenta à contrecoeur en faveur de la supériorité d'un modèle de type bazar primitif dans son article de 1989 Lisp: Good News, Bad News, and How To Win Big (Lisp: bonnes nouvelles, mauvaises nouvelles, et comment gagner gros). Bien qu'il ait mal vieilli sous certains aspects, cet essai est toujours adulé à juste titre dans les cercles de fans de Lisp (dont je fais partie). Un correspondant m'a rappelé que la section intitulée « Worse Is Better » (le pire est l'ami du mieux) peut presque se lire comme une anticipation de Linux. On peut trouver ce papier sur la Toile (WWW) à l'adresse http://www.naggum.no/worse-is-better.html. Peopleware: Productive Projects and Teams (ressources humaines : projets et équipes productifs) de De Marco et Lister's (New York; Dorset House, 1987; ISBN 0-932633-05-6) est un joyau méconnu, et j'ai été enchanté de voir Fred Brooks le citer dans sa rétrospective. Bien que la matière directement applicable au monde Linux ou au monde du logiciel dont le code source est ouvert en général soit rare, les auteurs ont de bonnes intuitions sur les prérequis nécessaires au travail créatif qui intéresseront quiconque envisage d'importer les vertus du modèle du bazar dans un contexte commercial. Enfin, je dois admettre que j'ai failli appeler cet article « La cathédrale et l'agora », du mot grec désignant un marché ouvert ou un lieu public de rencontres. Les articles fondateurs « agoric systems » (systèmes agoriques), de Mark Miller et Eric Drexler, en décrivant les propriétés émergentes d'écosystèmes informatiques similaires au libre marché, m'ont aidé à avoir les idées plus claires sur des phénomènes analogues dans la culture du logiciel dont le code source est ouvert quand Linux m'a mis le nez dedans, cinq ans plus tard. On peut trouver ces papiers sur la Toile à l'adresse http://www.agorics.com/agorpapers.html. Ça fait tout drôle de réaliser qu'on participe à l'Histoire... Le 22 janvier 1998, environ sept mois après ma première publication de cet article, Netscape Communications, Inc. a rendu public son projet de donner libre accès au code source de Netscape Communicator. Je n'avais pas la moindre idée que cela se produirait avant qu'ils ne l'annoncent. Eric Hahn, vice-président et responsable en chef de la technologie à Netscape, m'a envoyé un courrier électronique peu après en me disant: « Au nom de tout le monde à Netscape, je souhaite vous remercier pour nous avoir, le premier, aidés à comprendre tout cela. Votre réflexion et vos écrits ont été des inspirations cruciales dans la prise de cette décision. » La semaine suivante, à l'invitation de Netscape, je me suis rendu dans la « Silicon Valley » NdT : c'est l'endroit, près de San Francisco, où sont concentrées de nombreuses entreprises qui travaillent sur l'électronique des ordinateurs et sur les ordinateurs eux-mêmes. pour suivre une conférence de stratégie d'un jour (le 4 février 1998) en compagnie de certains de leurs cadres et de leurs techniciens les plus importants. Nous avons mis au point la stratégie de mise à disposition du code source de Netscape ainsi que la licence sous laquelle il serait rendu public, et nous avons fait quelques projets dont nous espérons qu'ils auront, à terme, un impact très étendu et très positif sur la communauté du logiciel dont le code source est ouvert. Au moment où j'écris ces lignes, il est un peu trop tôt pour donner plus de détails; mais vous en prendrez connaissance dans les semaines à venir. Netscape est sur le point de nous proposer une expérience à grande échelle, une expérience dans des conditions réelles du modèle du bazar dans une optique commerciale. La culture du logiciel dont le code source est ouvert affronte maintenant un danger; si le projet de Netscape ne donne pas satisfaction, cela risque de jeter tant de discrédit sur le concept de logiciel dont le code source est ouvert qu'il faudra attendre dix ans de plus pour que des sociétés commerciales s'y intéressent. D'un autre côté, c'est également une opportunité spectaculaire. Les réactions à chaud à cet événement, à Wall Street (la bourse de New York) comme ailleurs, ont été circonspectes mais positives. On nous donne aussi l'opportunité de faire nos preuves. Si, grâce à cette décision, Netscape regagne des parts de marché de façon substantielle, cela risque de provoquer une révolution dans l'industrie du logiciel, une révolution qui aurait dû prendre part il y a si longtemps. L'année qui vient devrait être très instructive et très intéressante. $Id: cathedral-bazaar.sgml,v 1.40 1998/08/11 20:27:29 esr Exp $ J'ai lu la version 1.16 au Linux Kongress le 21 mai 1997. J'ai ajouté la bibliographie dans la version 1.20 le 7 juillet 1997. J'ai ajouté l'anecdote concernant la conférence sur Perl le 18 novembre 1997 dans la version 1.27. J'ai changé « logiciel libre » en « logiciel dont le code source est ouvert » le 9 février 1998 dans la version 1.29. J'ai ajouté « Épilogue: Netscape embrasse la méthode du bazar ! » le 10 février 1998 dans la version 1.31. J'ai ôté le commentaire de Paul Eggert concernant l'opposition entre le modèle du bazar et la GPL à la suite d'arguments pertinents émis par RMS le 28 juillet 1998. Les autres numéros de versions correspondent à des corrections éditoriales et de structuration du document mineures. Sébastien Blondeel <sbi@linux-france.org> est responsable de la traduction en français. Il sera heureux de recueillir vos commentaires et vos remarques sur les choix qu'il a faits. Ce document aussi est « ouvert » ! Merci à Mark Hoebeke <mh@bambou.jouy.inra.fr> et à Julien Vayssiere <Julien.Vayssiere@sophia.inria.fr> pour leurs relectures et conseils éclairés. |