La cathedrale et le bazar

of 24/24
Auteur: Eric    S.    Raymond    ( [email protected] ) Traduction: Sébastien    Blondeel   Date: 1998/08/11 20:27:29 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. 1. La cathédrale et le bazar Linux est subversif. Qui aurait imaginé, il y a seulement cinq ans, qu'un système d'exploitation de classe internationale prendrait forme comme par magie à partir de bidouilles 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 ? Certainement pas moi. Quand, début 1993, Linux est apparu pour la première fois sur mon écran radar, cela faisait déjà dix ans que j'étais impliqué dans le développement sous Unix et dans la programmation de logiciels dont le code source est ouvert. Au milieu des années 1980, j'étais l'un des premiers contributeurs à GNU. J'avais distribué sur le réseau une bonne quantité de logiciels dont le code source est ouvert (nethack, les modes VC et GUD pour Emacs, xlife, et d'autres),
  • date post

    15-May-2015
  • Category

    Technology

  • view

    333
  • download

    0

Embed Size (px)

description

Auteur: Eric S.Raymond( [email protected]) Traduction: Sébastien Blondeel Date: 1998/08/11 20:27:29

Transcript of La cathedrale et le bazar

  • 1. Auteur: EricS.Raymond ([email protected]) Traduction:Sbastien Blondeel Date: 1998/08/11 20:27:29J'analyse le succs d'un projet de logiciel dont le code source est ouvert, NdT traduction de open-source software, terme par lequel l'auteur a dlibrment remplac le terme prcdent free software (logiciel libre). ``Ouvert'' signifie ici la fois public et susceptible d'tre comment et corrig par ceux qui s'y intresseront suffisamment. fetchmail (``va chercher le courrier''), qui a t lanc dlibrment pour tester certaines thories surprenantes du gnie logiciel suggres par l'histoire de Linux. Je discute ces thories en termes de deux styles de dveloppement fondamentalement diffrents, le modle ``cathdrale'' de la majorit du monde commercial, opposer au modle ``bazar'' du monde de Linux. Je montre que ces modles drivent d'hypothses opposes sur la nature de la tche consistant dboguer un logiciel. Enfin, je m'efforce de dmontrer, partir de l'exprience apporte par Linux, qu'``tant donns suffisamment d'observateurs, tous les bogues sautent aux yeux'', je suggre des analogies productives avec d'autres systmes auto-correcteurs par agents gostes, et je conclus en rflchissant aux implications de ces ides sur l'avenir du logiciel.1.Lacathdraleetlebazar Linux est subversif. Qui aurait imagin, il y a seulement cinq ans, qu'un systme d'exploitation de classe internationale prendrait forme comme par magie partir de bidouilles 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 mcaniques diverses, et de les rparer ou de les amliorer. 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 ngatif. Un bidouilleur construit des choses parfois trs belles et trs compliques, alors qu'un pirate cherche dtruire. faites pendant le temps libre de plusieurs milliers de dveloppeurs dissmins de par le monde, et relis seulement par les les liens tnus de l'Internet ? Certainement pas moi. Quand, dbut 1993, Linux est apparu pour la premire fois sur mon cran radar, cela faisait dj dix ans que j'tais impliqu dans le dveloppement sous Unix et dans la programmation de logiciels dont le code source est ouvert. Au milieu des annes 1980, j'tais l'un des premiers contributeurs GNU. J'avais distribu sur le rseau une bonne quantit de logiciels dont le code source est ouvert (nethack, les modes VC et GUD pour Emacs, xlife, et d'autres),

2. encore largement utiliss de nos jours. Je pensais savoir comment tout cela fonctionnait. Linux a remis en cause une grande partie de ce que je croyais savoir. J'avais prch l'vangile selon Unix sur l'utilisation de petits outils, le prototypage rapide et la programmation volutive, depuis des annes. Mais je pensais aussi qu'il existait une certaine complexit critique au del de laquelle une approche plus centralise, plus a priori, tait ncessaire. Je pensais que les logiciels les plus importants (comme les systmes d'exploitation et les trs gros outils comme Emacs) devaient tre conus comme des cathdrales, soigneusement labors par des sorciers isols ou des petits groupes de mages travaillant l'cart du monde, sans qu'aucune version bta ne voie le jour avant que son heure ne soit venue. Le style de dveloppement de Linus Torvalds - distribuez vite et souvent, dlguez tout ce que vous pouvez dlguer, soyez ouvert jusqu' la promiscuit - est venu comme une surprise. l'oppos de la construction de cathdrales, silencieuse et pleine de vnration, la communaut Linux paraissait plutt ressembler un bazar, grouillant de rituels et d'approches diffrentes (trs justement symbolis par les sites d'archives de Linux, qui acceptaient des contributions de n'importe qui) partir duquel un systme stable et cohrent ne pourrait apparemment merger que par une succession de miracles. Le fait que ce style du bazar semblait fonctionner, et bien fonctionner, fut un choc supplmentaire. Alors que j'apprenais m'y retrouver, je travaillais dur, non seulement sur des projets particuliers, mais encore essayer de comprendre pourquoi le monde Linux, au lieu de se disloquer dans la confusion la plus totale, paraissait au contraire avancer pas de gant, une vitesse inimaginable pour les btisseurs de cathdrales. Vers le milieu de 1996, je pensais commencer comprendre. Le hasard m'a donn un moyen incomparable de mettre ma thorie l'preuve, sous la forme d'un projet dont le code source est ouvert et que je pourrais consciemment faire voluer dans le style du bazar. Ce que je fis -- et je rencontrai un franc succs. Dans le reste de cet article, je conterai l'histoire de ce projet, et je l'utiliserai pour proposer des aphorismes relatifs au dveloppement efficace de logiciels dont le code source est public. Je n'ai pas appris toutes ces choses dans le monde Linux, mais nous verrons de quelle manire le monde Linux les place au devant de la scne. Si je ne me trompe pas, elles vous aideront comprendre exactement ce qui fait de la communaut Linux une telle manne de bons logiciels - et devenir plus productif vous-mme.2.Lecourrierdoitpasser! Depuis 1993, j'tais aux commandes du service technique d'un modeste fournisseur de services Internet proposant un accs 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, systmes de discussions entre utilisateurs) multi-utilisateurs -- vous pouvez vrifier cela en accdant par telnet locke.ccil.org. Aujourd'hui, ce service supporte presque trois mille utilisateurs sur trente lignes.) Ce travail m'a permis d'accder au rseau 24 heures sur 24, travers la ligne de 56K de CCIL -- en ralit, c'tait presque une ncessit ! 3. De cette manire, je m'tais habitu au courrier lectronique instantan par l'Internet. Pour des raisons compliques, il tait difficile de faire fonctionner SLIP entre ma machine situe mon domicile (snark.thyrsus.com) et CCIL. Quand j'ai enfin russi, j'ai trouv que me connecter rgulirement locke pour vrifier que je n'avais pas de courrier lectronique tait ennuyeux. Je souhaitais que mon courrier me parvienne sur snark de telle sorte que je sois averti ds son arrive et que je puisse le traiter l'aide de mes outils locaux. Indiquer simplement sendmail de faire suivre le courrier n'aurait pas fonctionn, parce que ma machine personnelle n'est pas sur le rseau 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 manire 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 sr, le systme d'exploitation BSD/OS de locke, incluait un serveur POP3. J'avais besoin d'un client POP3. Alors je suis all sur le rseau 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 rponses fonctionnent correctement. Le problme tait le suivant: un dnomm `joe' sur locke m'envoyait du courrier. Si je rapportais le courrier sur snark et tentais d'y rpondre, mon programme de courrier essayait en toute bonne foi de le faire parvenir un `joe' sur snark, qui n'existait pas. diter les adresses de retour la main pour leur ajouter `@ccil.org' est rapidement devenu assez pnible. 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 amne la premire leon: 1. Tout bon logiciel commence par gratter un dveloppeur l o a le dmange. Ceci est peut-tre une vidence (il est bien connu, et depuis longtemps, que ``Ncessit est mre d'Invention'') mais trop souvent on voit des dveloppeurs de logiciels passer leurs journes 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 prcipit frntiquement dans le codage d'un client POP3 tout nouveau tout beau, qui soutienne la comparaison avec ceux qui existent dj ? 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 2. Les bons programmeurs savent quoi crire. Les grands programmeurs savent quoi rcrire (et rutiliser). N'ayant pas la prtention de me compter parmi les grands programmeurs, j'essaie seulement de les imiter. Une caractristique importante des grands programmeurs est la paresse constructive. Ils savent qu'on n'obtient pas 20/20 pour les efforts fournis, mais pour le rsultat 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 4. contraire, il a commenc par rutiliser le code et les ides de Minix, un minuscule systme d'exploitation ressemblant Unix tournant sur les 386. La totalit du code de Minix a t abandonne ou rcrite compltement depuis -- mais tant qu'il tait l, ce code a servi de tuteur l'enfant qui deviendrait Linux. Dans le mme esprit, je me suis mis en qute d'un utilitaire POP raisonnablement bien crit, afin de l'utiliser comme base pour mon dveloppement. La tradition de partage du code source du monde Unix a toujours favoris la rutilisation de code (c'est pourquoi le projet GNU a choisi Unix comme systme d'exploitation de travail, malgr de srieuses rserves quant au systme d'exploitation lui-mme). Le monde Linux a pratiquement emmen cette tradition jusqu' sa limite technologique; il dispose de traoctets (millions de millions d'octets) de codes sources ouverts gnralement 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 rsultats dans le monde Linux que nulle part ailleurs. Et pour moi, cela a march. Avec ceux que j'avais dj trouvs, ma deuxime 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 rcriture des enttes, et j'ai fait un certain nombre d'amliorations que l'auteur a acceptes 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 problme. Fetchpop contenait des ides bonnes et originales (comme son mode dmon), mais il ne pouvait grer que POP3 et il tait programm d'une manire quelque peu amateur (Seung-Hong est un programmeur brillant mais inexpriment, et ces deux caractristiques apparaissaient dans son travail). Le code de Carl tait meilleur, assez professionnel et solide, mais son programme ne proposait pas certaines fonctionnalits de fetchpop, importantes et plutt difficiles coder (en particulier, celles que j'avais programmes moi-mme). Continuer, ou basculer ? Si je basculais, cela revenait abandonner le travail que j'avais dj ralis, en change d'une meilleure base de dveloppement. Une raison pragmatique me poussant changer tait la prsence d'un support pour plusieurs protocoles. POP3 est le protocole de bureau de poste NdT traduction littrale de POP le plus communment 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 dj vaguement d'ajouter IMAP (Internet Message Access Protocol, protocole d'accs aux messages par Internet, le protocole de bureau de poste le plus rcent et le plus puissant), rien que pour le plaisir. Mais j'avais une raison plus thorique de penser que changer serait une bonne ide malgr tout, une raison que j'avais apprise bien avant Linux. 3. ``Prvoyez d'en jeter un, car de toute manire, vous le ferez.'' (Fred Brooks, ``The Mythical ManMonth'', chapitre 11) ``Le mythe du mois-homme'', traduction de Frdric Mora, ITP, ISBN 2-84180-081-4, 5. 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 problme qu'aprs avoir implant une premire solution. La deuxime fois, on en sait parfois assez pour le rsoudre correctement. Ainsi, si vous voulez faire du bon travail, soyez prt recommencer au moins une fois. Bien (me suis-je dit), les modifications fetchpop furent un coup d'essai. J'ai donc bascul. Aprs avoir envoy Carl Harris mon premier lot de modifications apportes popclient, le 25 juin 1996, j'ai dcouvert qu'il avait pratiquement perdu tout intrt pour popclient depuis quelque temps. Le code tait un peu poussireux, 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 mme 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 intgralit, et je savais que certaines des ides qui germaient dans mon cerveau m'amneraient 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'exprimenter le fait suivant: 4. Si vous avez la bonne attitude, les problmes intressants viendront vous. Mais l'attitude de Carl Harris tait encore plus importante. Il comprit que 5. Quand un programme ne vous intresse plus, votre dernier devoir son gard est de le confier un successeur comptent. Sans mme 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'espre agir de mme quand mon tour viendra.3.Del'importanced'avoirdesutilisateurs C'est ainsi que j'hritai de popclient. De mme, et c'est tout aussi important, c'est ainsi que j'hritai de l'ensemble des utilisateurs de popclient. Il est merveilleux de disposer d'utilisateurs, et pas seulement parce qu'ils vous rappellent que vous remplissez un besoin et que vous avez fait une bonne chose. duqus de faon approprie, ils peuvent devenir vos co-dveloppeurs. Le fait que beaucoup d'utilisateurs sont galement des bidouilleurs est une autre force de la tradition Unix, et c'est une caractristique que Linux a pousse avec bonheur dans ses derniers retranchements. De plus, la libre disponibilit du code source en fait des bidouilleurs efficaces. Ceci peut se rvler incroyablement utile pour rduire le temps de dbogage. Avec un peu d'encouragement (ils n'en rclament pas beaucoup), vos utilisateurs diagnostiqueront les problmes, suggreront des corrections, et vous aideront amliorer le code bien plus rapidement que vous n'auriez pu le faire, si vous tiez laiss vous mme. 6. 6. Traiter vos utilisateurs en tant que co-dveloppeurs est le chemin le moins sem d'embches vers une amlioration rapide du code et un dbogage efficace. Il est facile de sous-estimer la puissance de ce phnomne. En fait, la quasi-totalit d'entre nous, appartenant au monde du logiciel dont le code source est ouvert, sous-estimions effroyablement la facilit avec laquelle il s'adapterait l'augmentation du nombre d'utilisateurs et de la complexit des systmes, jusqu' ce que Linus Torvalds ne nous dmontre le contraire. En ralit, je pense que la bidouille la plus ingnieuse de Linus, et celle qui a eu le plus de consquences, n'a pas t la construction du noyau de Linux en lui-mme, mais plutt son invention du modle de dveloppement de Linux. Un jour o j'exprimais cette opinion en sa prsence, il souria et rpta tranquillement cette pense qu'il a si souvent exprime: ``Je suis tout simplement une personne trs paresseuse, qui aime se faire remercier pour le travail effectu par d'autres.'' Paresseux comme un renard. Ou, comme Robert Heinlein aurait pu le dire, trop paresseux pour pouvoir chouer. Rtrospectivement, on peut voir dans le dveloppement des bibliothques Lisp et des archives de code Lisp pour GNU Emacs un prcdent aux mthodes et au succs de Linux. Au contraire du coeur d'Emacs, construit en C la manire des cathdrales, et au contraire de la plupart des autres outils proposs par la FSF (Free Software Foundation, Fondation pour le Logiciel Libre), l'volution de l'ensemble du code Lisp a t trs fluide et trs dirige par les utilisateurs. On a souvent rcrit les ides et les prototypes des modes trois ou quatre fois avant d'atteindre une forme finale stable. Et les exemples de collaborations occasionnelles rendues possibles par l'Internet, la manire de Linux, ne manquent pas. En fait, ma bidouille personnelle qui a rencontr le plus de succs, 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 oprations de contrle de version avec un seul bouton. Il tait parti d'un mode sccs.el trs rudimentaire et tout petit, crit par quelqu'un d'autre. Et le dveloppement de VC fut russi parce que, la diffrence d'Emacs lui-mme, le code Lisp pour Emacs pouvait traverser trs rapidement les cycles de mise jour/test/amlioration.4.Distribueztt,mettezjoursouvent Un lment essentiel du systme de dveloppement de Linux est la mise jour rapide et frquente des nouvelles versions. La plupart des dveloppeurs (moi y compris) pensait que ce n'tait pas une bonne mthode pour des projets de taille non triviale, parce que des versions prmatures sont quasiment, par dfinition, des versions bogues, et qu'il n'est pas dans votre intrt d'abuser de la patience des utilisateurs. C'est cette croyance qui a consolid l'attachement gnral au style de dveloppement de type cathdrale. Si l'objectif premier tait de prsenter aux utilisateurs une version aussi dpouille de bogues que possible, alors vous ne faisiez une mise jour que tous les six mois (voire moins souvent encore), et vous travailliez d'arrache-pied au dbogage entre les mises jour. C'est de cette manire qu'a t mis au point le coeur d'Emacs, crit en C. Ce ne fut pas le cas, en pratique, de la 7. bibliothque Lisp -- parce qu'il existait des archives Lisp ``vivantes'' hors de porte de la FSF, et o on pouvait trouver de nouvelles versions de code de dveloppement indpendamment du cycle de mises jour d'Emacs. La plus importante de ces archives, l'archive elisp de l'tat de l'Ohio, tait en avance sur son temps et avait dj devin l'esprit et la plupart des spcificits des archives Linux actuelles. Mais bien peu d'entre nous rflchissaient vraiment beaucoup sur ce que nous faisions ou sur les problmes lis au dveloppement de style cathdrale adopts par la FSF que l'existence mme de cette archive pouvait suggrer. J'ai vraiment tent, une fois, vers 1992, de faire passer de manire formelle, un bon morceau du code d'Ohio dans la bibliothque 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 diffrent, de plus sain, tait en train de se produire. La politique de dveloppement ouvert de Linus tait l'antithse mme du modle des cathdrales. Les archives de sunsite et de tsx-11 bourgeonnaient, de multiples distributions taient mises l'eau. Et tout cela tait rythm par une frquence de mise jour du coeur mme du systme jusqu'alors ingale. Linus traitait ses utilisateurs comme des dveloppeurs de la manire la plus efficace: 7. Distribuez tt. Mettez jour souvent. Et soyez l'coute de vos clients. 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 ide un niveau d'intensit correspondant la complexit de ce qu'il dveloppait. En ces temps reculs (autour de 1991), il lui arrivait de mettre jour son noyau plusieurs fois par jour ! Comme il cultivait sa base de co-dveloppeurs 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 gnie propre Linus Torvalds ? Je ne le pensais pas. Je vous l'accorde, Linus est un bidouilleur sacrment bon (combien parmi nous pourraient mettre au point l'intgralit du noyau d'un systme d'exploitation prt tre mis en production ?). Mais Linux ne constituait pas vraiment un rel progrs conceptuel. Linus n'est pas (en tout cas, pas encore) un gnie 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 gnie de l'ingnirie, dou d'un sixime sens qui lui permet d'viter les bogues et les impasses de dveloppement et surtout d'un authentique talent pour trouver le chemin de moindre effort reliant A B. En effet, la conception de Linux dans son intgralit est imprgne de cette qualit et reflte 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 intgrante du ct visionnaire gnial 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 ? Pose de cette manire, la question contient sa propre rponse. Linus stimulait et rcompensait ses utilisateurs/bidouilleurs en permanence -- il les stimulait par la perspective auto-gratifiante de 8. prendre part l'action, et il les rcompensait par la vue constante (et mme quotidienne) des amliorations de leur travail. Linus cherchait directement maximiser le nombre de personnes-heures jetes dans la bataille du dbogage et du dveloppement, au prix ventuel d'une certaine instabilit dans le code et de l'extinction de sa base d'utilisateurs si un quelconque bogue srieux se rvlait insurmontable. Linus se comportait comme s'il croyait en quelque chose comme: 8. tant donn un ensemble de bta-testeurs et de co-dveloppeurs suffisamment grand, chaque problme sera rapidement isol, et sa solution semblera vidente quelqu'un. Ou, moins formellement, ``tant donns suffisamment d'observateurs, tous les bogues sautent aux yeux.'' C'est ce que j'appelle: ``La Loi de Linus''. Ma premire formulation de cette loi tait que chaque problme ``semblera clair comme de l'eau de roche quelqu'un''. Linus a object qu'il n'tait pas ncessaire, et que d'ailleurs ce n'tait pas le cas en gnral, que la personne qui comprenne un problme soit la personne qui l'ait d'abord identifi. ``Quelqu'un trouve le problme,'' dit-il, ``et c'est quelqu'un d'autre qui le comprend. Je pousserai le bouchon jusqu' dire que le plus difficile est de trouver le problme.'' Mais le principal est que ces deux vnements se produisent en gnral vite. C'est l, je pense, la diffrence fondamentale sous-jacente aux styles de la cathdrale et du bazar. Dans la programmation du point de vue de la cathdrale, les bogues et les problmes de dveloppement reprsentent des phnomnes difficiles, ennuyeux, insidieux, profonds. Il faut une poigne de passionns des mois d'observations minutieuses avant de bien vouloir se laisser convaincre que tous les bogues ont t limins. D'o les longs intervalles sparant les mises jour, et l'invitable dception quand on se rend compte que la mise jour tant attendue n'est pas parfaite. Dans le point de vue bazar, d'un autre ct, vous supposez qu'en gnral, les bogues sont un phnomne de surface -- ou, en tout cas, qu'ils sautent rapidement aux yeux lorsqu'un millier de codveloppeurs avides se prcipitent sur toute nouvelle mise jour. C'est pourquoi vous mettez jour souvent afin de disposer de plus de corrections, et un effet de bord bnfique 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 systme aussi complexe que le noyau Linux, subissant les bidouilles simultanes d'autant de mains que ce fut le cas du noyau Linux, aurait d un certain moment s'effondrer sous le poids des interactions nfastes et imprvues, sous le poids de bogues ``profonds'' non dcouverts. D'un autre ct, si elle est juste, elle suffit expliquer l'absence relative de bogues dans Linux. Et peut-tre bien, aprs tout, que cela ne devrait pas tre aussi surprenant. Il y a des annes que les sociologues ont dcouvert 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 phnomne l'``effet de (l'oracle de) Delphes''. Il apparat que Linus a fait la preuve que cela s'applique mme au dbogage d'un systme d'exploitation -- que l'effet de Delphes peut apprivoiser la complexit du dveloppement mme au niveau de complexit atteint par le noyau d'un systme d'exploitation. Je dois Jeff Dutky la remarque qu'on peut reformuler la Loi de Linus 9. sous la forme ``On peut parallliser le dbogage''. Jeff fait remarquer que, mme si le dbogage requiert que les dbogueurs communiquent avec un dveloppeur charg de la coordination, une relle coordination entre dbogueurs n'tant pas indispensable. Ainsi, le dbogage n'est pas la proie de cette augmentation quadratique de la complexit et des cots d'organisation qui rend problmatique l'ajout de nouveaux dveloppeurs. En pratique, le monde Linux n'est quasiment pas affect par la perte thorique d'efficacit qui dcoule du fait que plusieurs dbogueurs travaillent sur la mme chose au mme moment. L'une des consquences de la politique du ``distribuez tt, 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 mme fait une observation annexe proche de celle de Jeff: ``Le cot total de maintenance d'un programme largement utilis est typiquement de 40 pour cent ou plus de son cot de dveloppement. De faon surprenante, ce cot dpend normment 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 manires de pousser le programme dans ses derniers retranchements. Cet effet est amplifi quand les utilisateurs se trouvent tre des co-dveloppeurs. Chacun d'entre eux a une approche personnelle de la traque des bogues, en utilisant une perception du problme, des outils d'analyse, un angle d'attaque qui lui sont propres. L'``effet de Delphes'' semble prcisment fonctionner grce cette variabilit. Dans le contexte spcifique du dbogage, la diversit tend aussi rduire la duplication des efforts. Ainsi, introduire de nouveaux bta-testeurs ne va sans doute pas rduire la complexit du bogue le plus ``profond'' du point de vue du dveloppeur, mais cela augmente la probabilit que la trousse outils d'un bta-testeur sera adapte au problme de telle sorte que le bogue saute aux yeux de cette personne. Mais Linus assure ses arrires. Au cas o il y aurait des bogues srieux, les versions du noyau Linux sont numrotes de telle sorte que des utilisateurs potentiels peuvent faire le choix d'utiliser la dernire version dsigne comme tant ``stable'', ou de surfer la pointe de la technique courant le risque que quelques bogues accompagnent les nouvelles fonctionnalits. Cette tactique n'est pas encore formellement imite par la plupart des bidouilleurs Linux, mais c'est sans doute un tort; le fait d'avoir une alternative rend les deux choix sduisants.5.Delachenilleaupapillon Aprs avoir tudi le comportement de Linus et formul une thorie expliquant les raisons de son succs, je dcidai volontairement de mettre cette thorie en pratique sur mon nouveau projet (quoique bien moins complexe et bien moins ambitieux). Mais la premire chose que je fis fut de rorganiser et de simplifier popclient en profondeur. L'implantation de Carl Harris tait trs correcte, mais elle trahissait cette complexit inutile qui caractrise de nombreux programmeurs C. Il pensait que le code primait sur les structures de donnes, qui le servaient. Le rsultat tait un code assez esthtique, mais une conception improvise 10. des structures de donnes, assez laides (en tout cas aux yeux d'un vieux baroudeur du Lisp comme moi). J'avais malgr tout autre chose en tte que simplement amliorer le code et les structures de donnes. Mon but tait de transformer popclient en quelque chose que je comprenne entirement. Ce n'est pas drle de devoir corriger des bogues dans un programme que vous comprenez mal. Pendant environ un mois, je me contentai de suivre les consquences de la conception simpliste de Carl. Le premier changement significatif que je fis fut d'introduire le support pour IMAP. Je le fis en rorganisant les pilotes de protocoles sous la forme d'un pilote gnrique et de trois tables de mthodes (pour POP2, POP3, et IMAP). Cela, et les modifications antrieures, illustre un principe gnral qu'il est bon pour les programmeurs de garder l'esprit, en particulier dans des langages comme le C qui ne permettent pas de procder un typage dynamique de manire naturelle: 9. Il vaut mieux avoir des structures de donnes intelligentes et un code stupide que le contraire. Si on prend le chapitre 9 de Fred Brooks: ``Montre-moi ton code, dissimule tes structures de donnes, je continuerai tre mystifi. Montre-moi tes structures de donnes et je n'aurai sans doute pas besoin de voir ton code, il me semblera vident.'' En fait, il parlait d'``organigrammes'' et de ``descriptions de donnes''. Mais si on traduit cela en termes d'aujourd'hui, aprs trente ans d'volution culturelle et technologique, cela revient pratiquement au mme. C'est ce moment (dbut septembre 1996, six semaines aprs avoir commenc) que j'ai commenc penser procder un changement de nom -- aprs tout, il ne s'agissait plus l uniquement d'un client POP. Mais j'hsitai, puisque rien dans ma conception n'tait vraiment neuf. Il fallait encore que mon programme dveloppe une identit propre. Cela s'est produit de manire radicale quand fetchmail apprit faire suivre le courrier rapport sur le port SMTP. J'y viendrai bientt. Il me faut d'abord signaler ceci: j'ai dit plus haut que j'avais dcid d'utiliser ce projet pour mettre en pratique ma thorie sur les raisons du succs de Linus Torvalds. Comment ai-je procd, vous direz-vous ? Comme suit: 1. J'ai distribu tt et mis jour souvent (au moins tous les dix jours; pendant les priodes de dveloppement effrn, une fois par jour). 2. J'ai agrandi ma liste de bta-testeurs en y ajoutant tout ceux qui me contactaient et me parlaient de fetchmail. 3. chaque mise jour, j'envoyais un petit palabre sur la liste bta, encourageant les gens participer. 4. Et j'ai cout mes bta-testeurs, en les sondant sur les choix de conception et en les caressant dans le sens du poil chaque fois qu'ils m'envoyaient leur avis ou des corrections. Le rsultat de ces mesures lmentaires ne se fit pas attendre. La plupart des dveloppeurs tueraient pre et mre pour avoir des notifications de bogues de la qualit de celles que je reus ds le dbut du projet, et la plupart du temps, elles taient accompagnes de bonnes solutions. J'ai reu des critiques rflchies, du courrier d'admirateurs, des suggestions intelligentes proposant de nouvelles fonctionnalits. Ce qui nous donne: 10. Si vous traitez vos bta-testeurs comme ce que vous avez de plus cher au monde, ils ragiront en 11. devenant effectivement ce que vous avez de plus cher au monde. Une mesure intressante du succs de fetchmail est l'impressionnante taille de la liste bta du projet, les amis de fetchmail. Au moment ou j'cris ces lignes, elle compte 249 membres et elle grandit de deux ou trois membres chaque semaine. En fait, alors que je relis maintenant ces lignes en mai 1997, la liste commence diminuer (elle a atteint son heure de gloire, la taille de 300 membres) pour une raison intressante. Plusieurs personnes m'ont demand de rsilier leur inscription parce que fetchmail fonctionne si bien pour eux qu'ils n'prouvent plus le besoin de suivre les discussions de la liste ! Cela fait sans doute partie du cycle de vie d'un projet dans le style bazar, lorsqu'il est parvenu a maturit.6.Etpopclientdevintfetchmail Le projet prit un virage radical le jour o Harry Hochheiser m'envoya un premier jet de son code destin faire suivre le courrier sur le port SMTP de la machine faisant tourner le client. J'ai ralis pratiquement tout de suite qu'une implantation fiable de cette fonctionnalit rendrait pratiquement obsoltes tous les autres modes de distribution du courrier. Cela faisait plusieurs semaines que je peaufinais fetchmail, pas pas, tout en trouvant mon interface fonctionnelle mais un peu pataude -- inlgante et truffe de trop nombreuses options exigus qui sortaient de toutes parts. J'tais particulirement turlupin par les options proposant de dposer le courrier rcupr dans un fichier bote aux lettres ou sur la sortie standard, sans trop savoir pourquoi. Je compris, quand l'ide de faire suivre le courrier sur le port SMTP traversa mon esprit, que popclient cherchait trop en faire. Il avait t conu pour jouer la fois le rle de la Poste (MTA, agent de transport du courrier) et du facteur (MDA, agent de distribution du courrier). En choisissant la solution SMTP, il n'aurait plus s'occuper de tout ce qui est MDA et pourrait se concentrer sur le ct MTA, en passant le relais d'autres programmes pour la distribution en local, tout comme sendmail le fait. Pourquoi s'encombrer de toute la complexit inhrente la configuration d'un facteur, pourquoi verrouiller un fichier bote aux lettres, y ajouter du courrier, alors que le port 25 nous tendait les bras de faon pratiquement assure sur toute plate-forme proposant TCP/IP depuis toujours ? Surtout que choisir cette solution garantit au courrier rcupr sa ressemblance avec du courrier normalement envoy par son vritable auteur via SMTP, et que c'est exactement ce que nous cherchions. Il y a plusieurs morales cette histoire. Tout d'abord, l'ide de faire suivre le courrier vers le port SMTP fut le plus grand profit que je tirai de la tentative consciente de copier les mthodes de Linus. C'est un utilisateur qui m'a souffl cette ide formidable -- et je n'ai eu qu' en comprendre les consquences. 11. Il est presque aussi important de savoir reconnatre les bonnes ides de vos utilisateurs que d'avoir de bonnes ides vous-mme. C'est mme prfrable, parfois. De manire surprenante, vous comprendrez vite que si vous tes parfaitement honnte quant ce 12. que vous devez aux autres, tout en restant en retrait, on finira par considrer que c'est vous qui avez tout crit tout seul et que vous restez modeste par humilit. On sait tous comment cela a bien fonctionn pour Linus ! (Quand j'ai prsent cet article la confrence sur Perl en aot 1997, Larry Wall, l'inventeur de Perl, tait assis au premier rang. Alors que j'abordai le paragraphe prcdent il cria, d'un ton enthousiaste et fervent: NdT Larry se moquait gentiment de lui-mme; il frquente des groupes chrtiens qui font des runions assez pittoresques. ``Oui, dis-le leur, mon frre !'', dclenchant un rire gnralis. Tout le monde dans l'assistance savait comment cela avait bien fonctionn pour l'inventeur de Perl, galement.) Aprs quelques semaines de travail sur le projet dans cet esprit-l, je commenai tre flicit par des gens qui n'taient pas mes utilisateurs, mais qui avaient entendu parler du projet. J'ai archiv certains de ces courriers; je les consulterai de nouveau si un jour je me demande avec angoisse si ma vie a t utile quelque chose :-). Mais on doit retenir deux autres leons essentielles, apolitiques, valables pour toutes sortes de conceptions de procds nouveaux. 12. Bien souvent, les solutions les plus innovantes, les plus frappantes, apparaissent lorsque vous ralisez que votre approche du problme tait mauvaise. J'avais tent de rsoudre le mauvais problme en m'acharnant dvelopper popclient comme un MTA/MDA combins, m'encombrant d'un tas de modes de distribution exotiques en local. Il fallait repenser la conception de fetchmail du tout au tout, se contenter d'en faire un MTA, un maillon de la chane du courrier gr par SMTP sur l'Internet. Quand vous vous heurtez un mur au cours du dveloppement d'un projet -- quand vous avez du mal rflchir au-del de la prochaine gnration de corrections -- c'est souvent le bon moment pour vous demander, non pas si vous apportez la bonne rponse, mais plutt si vous posez la bonne question. Il se peut qu'il faille recadrer le problme. Je le recadrai. Clairement, il me fallait maintenant (1) bidouiller pour ajouter la possibilit de faire suivre le courrier vers le port SMTP dans le pilote gnrique, (2) en faire le mode par dfaut, et (3), finalement, abandonner tous les autres modes de livraison, en particulier les options de livraison dans un fichier ou sur la sortie standard. J'ai eu des scrupules franchir la troisime tape pendant un moment, craignant le courroux de mes utilisateurs fidles, utilisant les autres modes de distribution. En thorie, il leur suffisait de mettre en place des fichiers .forward ou leur quivalent dans un autre systme que sendmail pour obtenir exactement les mmes effets. Dans la pratique, il se pouvait que la transition soit difficile. Mais quand je le fis, finalement, les avantages furent normes. Les parties les plus alambiques du code propre au pilote disparurent. La configuration devenait simplissime -- plus de baratin sur la manire de grer le MDA et la bote aux lettres de l'utilisateur, plus d'ennuis quant savoir si le systme d'exploitation sous-jacent permettait de verrouiller des fichiers. Il faut galement noter que l'unique manire de perdre son courrier disparut par la mme occasion. 13. Si vous demandiez la distribution du courrier vers un fichier et que le disque tait plein, votre courrier tait perdu. Cela ne peut pas se produire en faisant suivre le courrier vers le port SMTP, parce que la machine distante ne vous dira pas que tout va bien si elle ne peut effectivement distribuer le message, ou tout du moins le mettre de ct pour plus tard. De plus, les performances de mon programme s'en trouvaient amliores (mais pas au point de le remarquer au cours d'une seule session). Un autre bnfice non ngligeable de ce changement de cap fut la simplification drastique de la documentation (la page de man). Plus tard, il me fallut revenir un mode de distribution (MDA) en local spcifi par l'utilisateur, de manire me permettre de grer certaines situations obscures lies au SLIP dynamique. Mais j'ai trouv une faon de faire bien plus simple. La morale ? N'hsitez pas jeter aux orties des fonctionnalits dpasses quand vous le pouvez sans perdre en efficacit. Antoine de Saint-Exupry (qui, lorsqu'il n'crivait pas des classiques pour enfants, pilotait et construisait des avions), a dit: 13. ``La perfection est atteinte non quand il ne reste rien ajouter, mais quand il ne reste rien enlever.'' C'est quand votre code devient meilleur et plus simple, que vous savez qu'il est bon. Et au passage, la conception de fetchmail dveloppa sa propre identit, diffrente de son anctre popclient. Le temps tait venu pour un changement de nom. La nouvelle conception du nouveau programme ressemblait beaucoup plus une rplique de sendmail qu' l'ancien popclient; tous deux sont des MTAs, mais alors que sendmail envoie puis distribue, le nouveau popclient rcupre avant de distribuer. Deux mois aprs le dmarrage du projet, j'en changeai le nom en fetchmail.7.Fetchmailgrandit Me voici donc avec une conception propre et novatrice, un code dont je savais qu'il fonctionnait bien puisque je l'utilisais tous les jours, et une liste bta bourgeonnante. Je me rendis peu peu compte que je n'tais plus engag dans une bidouille personnelle et triviale que d'autres pourraient ventuellement trouver utile. J'tais le responsable d'un programme rellement utile tout bidouilleur possdant une babasse sous Unix et une connexion par SLIP/PPP. Quand j'y eus inject la fonctionnalit de SMTP, il surpassa tellement ses concurrents qu'il se mua en un ``programme de rfrence'', un de ces programmes classiques qui remplissent si bien leur rle qu'il limine toute comptition parce qu'on en oublie compltement les autres solutions, au lieu de simplement les laisser de ct. Je ne pense pas qu'on puisse vraiment viser ou planifier un tel but. On y est attir par des ides de conception si puissantes qu'aprs coup les rsultats paraissent tout naturels, invitables, prdestins. La seule manire de tomber sur ce genre d'ides est d'avoir beaucoup d'ides -- ou d'avoir assez de discernement pour reconnatre les bonnes ides des autres, mme si elles vous mnent plus loin que vous ne pensiez aller. Andrew Tanenbaum eut l'ide originale de construire un Unix simple en natif pour le 386, afin de l'utiliser comme outil pour l'enseignement. Linus Torvalds a pouss le concept de Minix bien plus 14. loin sans doute que ce qu'Andrew avait en tte -- et il le transforma en quelque chose de merveilleux. De la mme manire (mais pas la mme chelle), j'avais pris quelques ides de Carl Harris et de Harry Hochheiser et je les avais exploites fond. Aucun de nous n'est 'original' de la manire, romantique, dont les gens imaginent le gnie. Mais la majeure partie des sciences, de l'ingnirie et du dveloppement logiciel n'est pas le fruit du gnie l'tat pur, malgr ce que peuvent laisser croire les mythes des bidouilleurs. Les rsultats furent peu prs une excitation identique -- en fait, le genre de choses dont tous les bidouilleurs rvent ! Et ils signifiaient simplement qu'il me faudrait tre encore plus exigeant avec moi-mme. Pour rendre fetchmail aussi bon que j'entrevoyais qu'il pouvait l'tre, il ne faudrait plus me contenter d'crire du code rpondant mes propres besoins, il me faudrait prendre en compte les dsirs et les souhaits des autres pour des fonctionnalits que je n'utiliserais pas. Tout en gardant le programme simple et robuste. Le premier ajout que j'crivis aprs cela, et il fut de taille, fut la possibilit de distribuer du courrier dans des 'immeubles' (multidrop) -- rcuprer du courrier partir d'une bote aux lettres correspondant une adresse commune, dans laquelle s'taient accumuls des plis, et redistribuer chacun d'entre eux dans les botes personnelles de leur vritable destinataire. J'ai en partie accept d'ajouter le multidrop parce qu'on me le rclamait grands cris, mais surtout parce que je pensais qu'il m'aiderait traquer les bogues subsistant dans le code 'single-drop' (monodestinataire) en me forant grer les adresses dans toute leur gnralit. C'est ce qui s'est pass. Il me fallut extrmement longtemps pour grer la syntaxe du RFC 822 NdT les RFC sont des protocoles dcids en commun sur Internet. Ce sont les initiales de Request For Comments, littralement ``(nous) rclamons des commentaires (sur ce qui suit)''. , non qu'il contienne des choses extrmement compliques, mais que dans son ensemble il fait intervenir un enchevtrement de dtails un peu tordus. Mais l'adressage multidrop s'avra galement tre une excellente dcision de conception. Voici comment je m'en rendis compte: 14. Tout outil doit tre utile par rapport aux utilisations qu'il a t prvu d'en faire. Mais on reconnat un outil vraiment excellent au fait qu'il se prte des usages totalement insouponns. L'utilisation inattendue d'un fetchmail multi-destinataires est la gestion de listes de courrier lectronique o la liste est conserve et o le dveloppement des alias est fait du ct client de la connexion SLIP/PPP. Cela signifie qu'on peut modrer 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 accder sans cesse aux fichiers d'alias du fournisseur. Une autre amlioration importante exige par mes bta-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 prvoyais ce souhait des utilisateurs, mais plutt en accord avec une 15. autre rgle: 15. Quand vous crivez un logiciel jouant le rle d'une passerelle quelconque, prenez soin de perturber le moins possible le flot de donnes -- et ne perdez *jamais* d'lments d'information, moins que la machine destinataire vous y oblige ! Si je n'avais pas obi cette rgle, 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 gnration des en-ttes. Quelques utilisateurs europens m'ont ennuy jusqu' ce que j'ajoute une option pour limiter le nombre de messages transfrs chaque session (pour qu'ils puissent contrler le prix de la communication tlphonique, sur leur onreux rseau). J'ai mis du temps m'y rsoudre, et aujourd'hui encore je n'en suis pas trs 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 trbuchante ne change rien l'affaire.8.Quelquesenseignementssupplmentairestirsdefetchmail Avant de retourner des sujets plus gnraux du gnie logiciel, il nous reste mditer sur quelques leons supplmentaires tires de l'exprience de fetchmail. La syntaxe du fichier rc spcifie quelques mots cls ``parasites'' optionnels, compltement ignors par l'analyseur syntaxique. Ils permettent l'utilisation d'une syntaxe proche de la langue anglaise, nettement plus lisible que les traditionnels, et spartiates, couples mot cl-valeur qu'on peut lire quand on ne garde que l'indispensable. L'ide m'est venue tard un soir, alors que je remarquais combien ces dclarations du fichier rc commenaient prendre l'allure d'un mini-langage impratif. (C'est aussi la raison pour laquelle j'ai remplac le mot cl `server' (serveur), originalement prsent dans popclient, par `poll' (vrification de la prsence d'activit)). Il m'a sembl que rendre ce mini-langage plus proche de l'anglais en rendrait l'utilisation plus aise. Il me faut prciser que, bien que farouche partisan de l'cole de conception ``faites-en un langage'', illustre par des outils comme Emacs, HTML et de nombreux moteurs de bases de donnes, je ne suis pas, d'habitude, un admirateur des syntaxes `` l'anglaise''. De manire traditionnelle, les programmeurs ont eu tendance favoriser des syntaxes de contrle trs prcises et compactes, sans redondance. Il s'agit d'un hritage culturel du temps o les ressources informatiques cotaient cher, et o il fallait donc rendre les tapes d'analyse syntaxique aussi courtes et simples que possible. La langue anglaise, pour moiti redondante, semblait alors un modle trs peu appropri. Ce n'est pas la raison pour laquelle je dnonce la non utilisation de syntaxes naturelles; je n'en fais mention ici que pour mieux la dmolir. Maintenant que les ressources informatiques sont plthore, l'austrit ne doit pas tre une fin en soi. De nos jours, il est plus important qu'un langage soit facilement comprhensible par les humains plutt que par les ordinateurs. Il existe, en revanche, de bonnes raisons pour se mfier. L'une d'entre elles est le cot en complexit 16. de la phase d'analyse syntaxique -- vous n'avez certainement pas envie d'en faire une source non ngligeable de bogues. Vous n'avez pas envie non plus que la complexit de votre langage droute l'utilisateur. Une autre raison est que les tentatives de rendre la syntaxe d'un langage similaire l'anglais, aboutissent le plus souvent un telle dformation de cet ``anglais'' que cette ressemblance superficielle au langage naturel provoque autant de confusion que ne l'aurait fait une syntaxe traditionnelle. (C'est le cas de nombreux langages prtendument de quatrime gnration et des langages de requtes dans des bases de donnes commerciales.) La syntaxe permettant de contrler fetchmail vite ces deux cueils parce que le domaine du langage est trs restreint. Il n'est en rien un langage gnraliste; il se contente de dire des choses simples, de telle sorte qu'il est difficile de se tromper en transposant mentalement un minuscule sous-ensemble de l'anglais au langage de contrle en lui-mme. Je pense qu'il y a ici matire une leon plus gnrale: 16. Quand votre langage est loin d'tre Turing quivalent NdT c'est le cas par exemple des langages de programmation , un peu de ``sucre syntaxique'' ne peut qu'aider. Une autre leon concerne la scurit par hermtisme (utilisant par exemple des mots de passes secrets). Certains utilisateurs de fetchmail m'ont demand de modifier le logiciel de manire stocker des mots de passe chiffrs dans le fichier rc, de telle sorte que les petits malins ne puissent les lire directement. Je ne l'ai pas fait, parce que cela n'apporte aucune protection supplmentaire. Quiconque a obtenu le droit de lire votre fichier rc pourra lancer fetchmail sous votre identit de toutes manires -- et s'il en a aprs votre mot de passe, il pourra toujours extraire du code de fetchmail le dcodeur ncessaire pour le dchiffrer. Tout ce qu'un chiffrement de mots de passe dans le fichier .fetchmailrc aurait apport, c'est un sentiment de scurit infond ceux qui connaissent mal les problmes de scurit. La rgle gnrale est ici: 17. Un systme de scurit n'est pas plus sr que le secret (la cl) qui le garde. Gare aux pseudo secrets !9.Prrequisncessairesaustylebazar Les premiers relecteurs et les premiers publics auprs desquels cet article a t test ont pos de manire rgulire la question des prrequis ncessaires la russite d'un dveloppement dans le style bazar, en incluant dans cette question aussi bien les qualifications du chef de projet que l'tat du code au moment o il est rendu public et tente de rallier autour de lui une communaut de codveloppeurs. Il est assez vident qu'il n'est pas possible de commencer coder dans le style bazar ds le dbut. On peut tester, dboguer et amliorer un programme dans le style bazar, mais il sera trs difficile de faire dmarrer un projet dans le mode bazar. Linus ne l'a pas tent, moi non plus. Il faut que votre communaut naissante de dveloppeurs ait quelque chose qui tourne, qu'on puisse tester, avec quoi 17. elle puisse jouer. Quand vous initiez un travail de dveloppement en communaut, il vous faut tre capable de prsenter une promesse plausible. Votre programme ne doit pas ncessairement fonctionner trs bien. Il peut tre grossier, bogu, incomplet, et mal document. Mais il ne doit pas manquer de convaincre des co-dveloppeurs 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 sduisantes. Nombreux sont ceux qui, aprs avoir rflchi au modle du bazar tel que je l'ai prsent ici, ont trs correctement considr 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 reconnatre les bonnes ides 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 prcdemment) un concepteur spectaculairement original, a dmontr une puissante capacit reconnatre une bonne conception et l'intgrer au noyau Linux. Et j'ai dj dcrit comment l'ide la plus puissante dans la conception de fetchmail (faire suivre le courrier vers le port SMTP) me fut souffle par quelqu'un d'autre. Les premires personnes auxquelles j'ai prsent cet article m'ont compliment en me suggrant que je suis prompt sous-valuer dans la conception des projets mens dans le style bazar, leur originalit -- principalement parce que j'en suis pas mal pourvu moi-mme, ce qui me conduit considrer cela comme acquis. Il peut y avoir un fond de vrit l dedans; la conception ( l'oppos de la programmation ou du dbogage) est certainement mon point fort. Mais le problme avec l'intelligence et l'originalit dans la conception de logiciels, c'est que a devient une habitude -- presque par rflexe, vous commencez faire dans l'esthtique 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 russi en partie parce que j'ai refoul ma tendance donner dans la subtilit; cela contredit (au moins) l'ide que l'originalit dans la conception est essentielle dans des projets russis mens dans le style bazar. Et pensez Linux. Imaginez que Linus ait tent de mettre en pratique des innovations fondamentales dans la conception de systmes d'exploitation au cours du dveloppement; est-il probable que le noyau qui en rsulterait soit aussi stable et populaire que celui que nous connaissons ? Il faut, bien sr, une certaine habilet dans la conception et le codage, mais je pense que quiconque 18. envisage srieusement de lancer un projet dans le style en possde dj le minimum ncessaire. Les lois du march de la rputation interne au monde du logiciel dont le code source est ouvert exercent des pressions subtiles dcourageant ceux qui pensent mettre contribution d'autres dveloppeurs alors qu'ils n'ont pas eux-mmes la comptence d'assurer le suivi. Jusqu' prsent tout cela semble avoir trs bien march. Il existe une autre qualit qui n'est pas normalement associe au dveloppement 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 dveloppement, il vous faut sduire les gens, les intresser ce que vous faites, et les encourager pour les petits bout du travail qu'ils ralisent. De bonnes comptences techniques sont essentielles, mais elles sont loin de suffire. La personnalit que vous projetez compte aussi. Cela n'est pas une concidence que Linus soit un chic type qu'on apprcie 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 ragit comme un comique de thtre. Pour que le modle du bazar fonctionne, une petite touche de charme et de charisme aide normment.10.Lecontextesocialdulogicieldontlecodesourceestouvert Cela est bien connu: les meilleures bidouilles commencent en tant que solutions personnelles aux problmes de tous les jours rencontrs par leur auteur, et elles se rpandent parce que ce problme est commun de nombreuses personnes. Cela nous ramne la rgle numro 1, reformule de manire peut-tre plus utile: 18. Pour rsoudre un problme intressant, commencez par trouver un problme qui vous intresse. 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 dtail sur lequel les histoires de Linux et de fetchmail semblent nous demander de nous concentrer, est l'tape suivante -- l'volution du logiciel en prsence d'une communaut d'utilisateurs et de co-dveloppeurs importante et active. Dans ``Le mythe du mois-homme'', Fred Brooks observa qu'on ne peut pas diviser et rpartir le temps du programmeur; si un projet a du retard, lui ajouter des dveloppeurs ne fera qu'accrotre son retard. Il explique que les cots de communication et de complexit d'un projet augmentent de manire quadratique avec le nombre de dveloppeurs, alors que le travail ralis n'augmente que linairement. Depuis, cela est connu sous le nom de ``loi de Brooks'', et on la considre en gnral 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 considrer aprs coup comme une correction vitale Brooks. Dans sa discussion sur la ``programmation non goste'', Weinberg observa que dans les botes o les programmeurs ne marquent pas le territoire de leur code, et encouragent les autres y chercher les bogues et les amliorations potentielles, les amliorations sont drastiquement plus rapides qu'ailleurs. Les termes choisis par Weinberg l'ont peut-tre empch de recevoir toute la considration qu'il 19. mritait -- et l'ide que les bidouilleurs sur Internet puissent tre dcrits comme ``non gostes'' fait sourire. Mais je pense que cet argument semble aujourd'hui plus vrai que jamais. L'histoire d'Unix aurait d nous prparer ce que nous dcouvrons avec Linux (et ce que j'ai expriment une chelle plus modeste en copiant dlibrment les mthodes 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 rflexion de communauts entires. Le dveloppeur qui n'utilise que son propre cerveau dans un projet ferm ne tiendra pas la route face au dveloppeur qui sait comment crer un contexte ouvert, susceptible d'voluer, dans lequel la traque des bogues et les amliorations sont effectues 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 lgales des diverses licences, secrets de fabrication, et autres intrts commerciaux. Un autre (mieux compris plus tard) tait que l'Internet n'tait pas encore assez mr. Avant que les cots d'accs Internet ne chutent, il existait quelques communauts gographiquement compactes dont la culture encourageait la programmation ``non goste'' la Weinberg, et un dveloppeur pouvait facilement attirer tout un tas de co-dveloppeurs et autres touche--tout dous. 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 lgendaires qui sont rests puissants. Linux fut le premier projet qui fit un effort conscient et abouti pour utiliser le monde entier comme rservoir de talent. Je ne pense pas que cela soit une concidence que la priode de gestation de Linux ait concid 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'intrt gnral accord Internet et que l'industrie des fournisseurs d'accs explosrent. Linus fut le premier comprendre comment jouer selon les nouvelles rgles qu'un Internet omniprsent rendait possibles. Mme s'il fallait qu'Internet ne cote pas cher pour que le modle Linux se dveloppe, je ne pense pas que cela soit suffisant. Il y avait un autre facteur vital: le dveloppement d'un style de direction de projet et d'un ensemble de coutumes de coopration qui permettaient aux dveloppeurs d'attirer des co-dveloppeurs et de rentabiliser au maximum ce nouveau mdia. Quel est donc ce style de direction, quelles sont donc ces coutumes ? Ils ne peuvent pas tre fonds sur des rapports de force -- mme si c'tait le cas, la direction par coercition ne produirait pas les rsultats qu'on peut observer. Weinberg cite fort propos l'autobiographie de Pyotr Alexeyvitch Kropotkine, anarchiste russe du XIXe sicle, ``Mmoires d'un rvolutionnaire'': ``lev dans une famille possdant des serfs, j'entrai dans la vie active, comme tous les jeunes gens de mon poque, avec une confiance aveugle dans la ncessit de commander, d'ordonner, de brimer, de punir et ainsi de suite. Mais quand, assez tt, je dus diriger d'importantes affaires et ctoyer des hommes libres, et quand chaque erreur pouvait tre immdiatement lourde de consquences, je commenai apprcier la diffrence 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 dfil militaire, mais ne vaut rien dans la vie courante, o on ne peut atteindre son but que grce l'effort soutenu de nombreuses volonts travaillant dans le mme sens.'' 20. ``L'effort soutenu de nombreuses volonts travaillant dans le mme 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 oprer et se mesurer les uns aux autres de manire efficace, les bidouilleurs qui cherchent prendre la tte d'un projet de collaboration commune doivent apprendre recruter et insuffler de l'nergie dans les communauts d'intrts convergents la manire vaguement suggre par le ``principe de bonne intelligence'' de Kropotkine. Ils doivent apprendre utiliser la loi de Linus. Plus haut, je me rfrais ``l'effet de Delphes'' comme une possible explication de la loi de Linus. Mais on ne peut s'empcher de penser des analogies trs puissantes avec des systmes adaptatifs en biologie et en conomie. Le monde Linux sous de nombreux aspects, se comporte comme un march libre ou un cosystme, un ensemble d'agents gostes qui tentent de maximiser une utilit, ce qui au passage produit un ordre spontan, auto-correcteur, plus labor et plus efficace que toute planification centralise 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 rputation 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'gosme pour l'altruiste). Les cultures volontaires qui fonctionnent ainsi ne sont pas si rares; j'ai dj 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 rputation s'accroisse auprs des autres fans) est le principal moteur qui propulse les activits volontaires. Linus, en se positionnant avec succs comme gardien des cls d'un projet o le dveloppement est surtout fait par les autres, et en y injectant de l'intrt 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 mthode de Linus comme un moyen de crer de manire efficace, un march de l'``egoboo'' -- relier les gosmes individuels des bidouilleurs aussi fermement que possible, dans le but de raliser des tches impossibles sans une coopration soutenue. Avec le projet fetchmail, j'ai montr ( une chelle plus modeste, je vous l'accorde) qu'on peut dupliquer ses mthodes avec de bons rsultats. Peut-tre mme l'ai-je fait un peu plus consciemment et plus systmatiquement que lui. Nombreux sont ceux (en particulier ceux dont les opinions politiques les font se mfier des marchs libres) qui s'attendraient ce que la culture d'gostes sans autre matre qu'eux mmes soit fragmente, territoriale, source de gchis, pleine de petits secrets, et hostile. Mais cette ide est clairement mise en dfaut par (pour ne donner qu'un seul exemple) l'poustouflante varit, qualit et profondeur de la documentation relative Linux. Il est pourtant lgendaire que les programmeurs dtestent 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 gnrer des comportements vertueux, serviables, mieux que les services documentaires largement subventionns des producteurs de logiciels commerciaux. 21. 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-dveloppeur fort peut utiliser l'Internet pour tirer parti du fait d'avoir normment de co-dveloppeurs sans que le projet ne s'effondre en un capharnam chaotique. C'est pourquoi je propose la contrepartie suivante la loi de Brooks: 19: Pour peu que le coordinateur du dveloppement 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 invitable qu'il y ait plus de choses dans plusieurs ttes 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 cathdrales pour se consacrer entirement au bazar. Cela ne veut pas dire que les coups de gnie individuels ne compteront plus; je pense plutt que l'tat de l'art du logiciel dont le code source est ouvert appartiendra ceux qui commencent par un projet individuel gnial, et qui l'amplifieront travers la construction efficace de communauts d'intrt volontaires. Et peut-tre mme qu'il n'est pas question ici que de l'avenir du logiciel dont le code source est ouvert. Aucun dveloppeur qui fonctionne avec un code source ferm ne peut mobiliser autant de talent que celui que la communaut Linux peut consacrer un problme donn. Bien rares mme sont ceux qui auraient eu les moyens de rmunrer 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 cooprer, non pas parce qu'il est moralement mal de ``clturer'' le logiciel (en supposant que vous soyez d'accord avec la deuxime 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 communauts de logiciel libre, qui peuvent mettre sur le problme un temps humain cumul plus important de plusieurs ordres de grandeurs.11.Remerciements Un grand nombre de personnes m'ont aid, au travers de conversations, amliorer cet article. Je remercie tout particulirement Jeff Dutky qui m'a suggr la formule ``le dbogage est paralllisable'', et qui m'a aid tirer l'analyse qui en dcoule. Merci aussi Nancy Lebovitz qui m'a suggr que je suivais l'exemple de Weinberg en citant Kropotkine. J'ai reu aussi des critiques utiles de la part de Joan Eslinger et de Marty Franz 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 rle du premier public critique de cet article. Enfin, les commentaires de Linus Torvalds me furent utiles, et son soutien des premires heures m'encouragea beaucoup.12.Pourallerplusloin J'ai cit plusieurs extraits du classique de P. Brooks The Mythical Man-Month (Le mythe du moishomme) parce que, sous bien des aspects, ses conclusions doivent encore tre affines. Je 22. recommande chaleureusement l'dition faite par la socit Addison-Wesley (ISBN 0-201-83595-9) l'occasion du vingt-cinquime anniversaire de ce livre, qui ajoute son article de 1986 intitul ``No Silver Bullet'' (pas de balle en argent). Cette nouvelle dition est prface par une inestimable rtrospective des 20 dernires annes dans laquelle Brooks reconnat les quelques affirmations de son texte original qui n'ont pas rsist l'preuve du temps. J'ai lu la rtrospective pour la premire fois aprs avoir crit la quasi totalit du prsent 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 goste''. Bien que n'tant pas le premier se rendre compte de la futilit du ``principe de commandement'', il fut probablement le premier reconnatre cet aspect et argumenter sur ce dernier par rapport au dveloppement logiciel. Richard P. Gabriel, en contemplant la culture Unix de l'avant-Linux, argumenta contrecoeur en faveur de la supriorit d'un modle 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 intitule ``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/worseis-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 mconnu, et j'ai t enchant de voir Fred Brooks le citer dans sa rtrospective. Bien que la matire directement applicable au monde Linux ou au monde du logiciel dont le code source est ouvert en gnral soit rare, les auteurs ont de bonnes intuitions sur les prrequis ncessaires au travail cratif qui intresseront quiconque envisage d'importer les vertus du modle du bazar dans un contexte commercial. Enfin, je dois admettre que j'ai failli appeler cet article ``La cathdrale et l'agora'', du mot grec dsignant un march ouvert ou un lieu public de rencontres. Les articles fondateurs ``agoric systems'' (systmes agoriques), de Mark Miller et Eric Drexler, en dcrivant les proprits mergentes d'cosystmes informatiques similaires au libre march, m'ont aid avoir les ides plus claires sur des phnomnes 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.13.pilogue:Netscapeembrasselamthodedubazar! a fait tout drle de raliser qu'on participe l'Histoire... Le 22 janvier 1998, environ sept mois aprs ma premire publication de cet article, Netscape Communications, Inc. a rendu public son projet de donner libre accs au code source de Netscape 23. Communicator. Je n'avais pas la moindre ide que cela se produirait avant qu'ils ne l'annoncent. Eric Hahn, vice-prsident et responsable en chef de la technologie Netscape, m'a envoy un courrier lectronique peu aprs en me disant: ``Au nom de tout le monde Netscape, je souhaite vous remercier pour nous avoir, le premier, aids comprendre tout cela. Votre rflexion et vos crits ont t des inspirations cruciales dans la prise de cette dcision.'' La semaine suivante, l'invitation de Netscape, je me suis rendu dans la ``Silicon Valley'' NdT c'est l'endroit, prs de San Francisco, o sont concentres de nombreuses entreprises qui travaillent sur l'lectronique des ordinateurs et sur les ordinateurs euxmmes. pour suivre une confrence de stratgie d'un jour (le 4 fvrier 1998) en compagnie de certains de leurs cadres et de leurs techniciens les plus importants. Nous avons mis au point la stratgie 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 esprons qu'ils auront, terme, un impact trs tendu et trs positif sur la communaut du logiciel dont le code source est ouvert. Au moment o j'cris ces lignes, il est un peu trop tt pour donner plus de dtails; mais vous en prendrez connaissance dans les semaines venir. Netscape est sur le point de nous proposer une exprience grande chelle, une exprience dans des conditions relles du modle 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 discrdit sur le concept de logiciel dont le code source est ouvert qu'il faudra attendre dix ans de plus pour que des socits commerciales s'y intressent. D'un autre ct, c'est galement une opportunit spectaculaire. Les ractions chaud cet vnement, 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, grce cette dcision, Netscape regagne des parts de march de faon substantielle, cela risque de provoquer une rvolution dans l'industrie du logiciel, une rvolution qui aurait d prendre part il y a si longtemps. L'anne qui vient devrait tre trs instructive et trs intressante.14.Historiquedesversionsetdesmodifications $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 confrence 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 fvrier 1998 dans la version 1.29. J'ai ajout ``pilogue: Netscape embrasse la mthode du bazar !'' le 10 fvrier 1998 dans la version 1.31. 24. J'ai t le commentaire de Paul Eggert concernant l'opposition entre le modle du bazar et la GPL la suite d'arguments pertinents mis par RMS le 28 juillet 1998. Les autres numros de versions correspondent des corrections ditoriales et de structuration du document mineures. Sbastien Blondeel est responsable de la traduction en franais. 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 et Julien Vayssiere pour leurs relectures et conseils clairs.