Auteur : Eric S. Raymond ( esr@thyrsus.com) Traducteur : Sébastien ...
la cathédrale et le bazar
(
the cathedral and the bazaar)
auteur :
eric s. raymond
(
esr@thyrsus.com)
traducteur :
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), encore largement utilisés 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 prêché l'évangile selon unix sur l'utilisation de petits outils,
le prototypage rapide et la programmation évolutive, depuis des années.
mais je pensais aussi qu'il existait une certaine complexité critique au
delà de laquelle une approche plus centralisée, plus a priori, était
nécessaire. je pensais que les logiciels les plus importants (comme les
systèmes d'exploitation et les très gros outils comme emacs) devaient être
conçus comme des cathédrales, soigneusement élaborés par des sorciers isolés
ou des petits groupes de mages travaillant à l'écart du monde,
sans qu'aucune version bêta ne voie le jour avant que son heure ne soit venue.
le style de développement de linus torvalds - distribuez vite et
souvent, déléguez tout ce que vous pouvez déléguer, soyez ouvert jusqu'à la
promiscuité - est venu comme une surprise. À l'opposé de la construction de
cathédrales, silencieuse et pleine de vénération, la communauté linux
paraissait plutôt ressembler à un bazar, grouillant de rituels et d'approches
différentes (très justement symbolisé par les sites
d'archives de linux, qui acceptaient des contributions de n'importe
qui) à partir duquel un système stable et cohérent 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 supplémentaire. 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
géant, à une vitesse inimaginable pour les bâtisseurs
de cathédrales.
vers le milieu de 1996, je pensais commencer à comprendre. le hasard m'a
donné un moyen incomparable de mettre ma théorie à 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
succès.
dans le reste de cet article, je conterai l'histoire de ce projet, et je
l'utiliserai pour proposer des aphorismes relatifs au développement
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 manière le monde linux les place au
devant de la scène. 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-même.
2. le courrier doit passer !
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
(snark.thyrsus.com) et ccil. quand j'ai enfin réussi, j'ai trouvé que me
connecter régulièrement à locke pour vérifier 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 dès son
arrivée 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 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 locke, incluait un serveur pop3.
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 locke m'envoyait du
courrier. si je rapportais le courrier sur snark et tentais d'y répondre,
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 pénible.
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:
1. tout bon logiciel commence par gratter un développeur là où ça le
démange.
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
2. les bons programmeurs savent quoi écrire.
les grands programmeurs savent quoi réécrire (et réutiliser).
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.
3. ``prévoyez d'en jeter un, car de toute manière, vous le ferez.''
(fred brooks, ``the mythical man-month'', chapitre 11)
``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:
4. si vous avez la bonne attitude, les problèmes intéressants viendront
à vous.
mais l'attitude de carl harris était encore plus importante. il comprit que
5. quand un programme ne vous intéresse plus, votre dernier devoir à
son égard est de le confier à un successeur compétent.
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.
3. de l'importance d'avoir des utilisateurs
c'est ainsi que j'héritai de popclient.
de même, et c'est tout aussi important, c'est ainsi que j'héritai 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.
Éduqués de façon appropriée, ils peuvent devenir vos co-développeurs.
le fait que beaucoup d'utilisateurs sont également des bidouilleurs
est une autre force de la tradition unix, et c'est une
caractéristique que linux a poussée avec bonheur dans ses derniers
retranchements. de plus, la libre disponibilité du code source en fait des
bidouilleurs efficaces.
ceci peut se révéler incroyablement utile pour réduire le temps
de débogage. avec un peu d'encouragement (ils n'en réclament pas
beaucoup),
vos utilisateurs diagnostiqueront les problèmes, suggéreront des
corrections, et vous aideront à améliorer le code bien plus rapidement que
vous n'auriez pu le faire, si vous étiez laissé à vous même.
6. traiter vos utilisateurs en tant que co-développeurs est le chemin
le moins semé d'embûches vers une amélioration rapide du code et un
débogage efficace.
il est facile de sous-estimer la puissance de ce phénomène. 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 systèmes, jusqu'à ce que linus
torvalds ne nous démontre le contraire.
en réalité, je pense que la bidouille la plus ingénieuse de linus, et
celle qui a eu le plus de conséquences, n'a pas été la construction du
noyau de linux en lui-même, mais plutôt son invention du modèle de
développement de linux. un jour où j'exprimais cette opinion en sa
présence, il souria et répéta tranquillement cette pensée qu'il
a si souvent exprimée: ``je suis tout simplement une personne très
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.
rétrospectivement, on peut voir dans le développement des
bibliothèques lisp et des archives de code lisp pour gnu emacs un
précédent aux méthodes et au succès de linux. au contraire du coeur
d'emacs, construit en c à la manière des cathédrales, et au contraire
de la plupart des autres outils proposés par la fsf (free software
foundation, fondation pour le logiciel libre), l'évolution de
l'ensemble du code lisp a été très fluide et très dirigée par les
utilisateurs. on a souvent réécrit les idées 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 manière de linux, ne manquent pas.
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.
4. distribuez tôt, mettez à jour souvent
un élément essentiel du système de développement de linux est la mise à
jour rapide et fréquente des nouvelles versions.
la plupart des développeurs (moi y compris) pensait que ce n'était pas
une bonne méthode pour des projets de taille non triviale, parce
que des versions prématurées sont quasiment, par définition, des versions
boguées, et qu'il n'est pas dans votre intérêt d'abuser de la patience
des utilisateurs.
c'est cette croyance qui a consolidé l'attachement général au style de
développement de type cathédrale. si l'objectif premier était de
présenter aux utilisateurs une version aussi dépouillée 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
débogage entre les mises à jour. c'est de cette manière qu'a été mis
au point le coeur d'emacs, écrit en c. ce ne fut pas le cas, en
pratique, de la bibliothèque lisp -- parce qu'il existait des archives
lisp ``vivantes'' hors de portée de la fsf, et où on pouvait trouver
de nouvelles versions de code de développement indépendamment 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 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:
7. distribuez tôt. 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 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:
8. Étant donné un ensemble de bêta-testeurs et de co-développeurs
suffisamment grand, chaque problème sera rapidement isolé, et sa
solution semblera évidente à quelqu'un.
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'autre qui 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.
5. de la chenille au papillon
après avoir étudié le comportement de linus et formulé une théorie
expliquant les raisons de son succès, je décidai volontairement de
mettre cette théorie en pratique sur mon nouveau projet (quoique bien
moins complexe et bien moins ambitieux).
mais la première chose que je fis fut de réorganiser et de simplifier
popclient en profondeur. l'implantation de carl harris était très
correcte, mais elle trahissait cette complexité inutile qui
caractérise de nombreux programmeurs c. il pensait que le code primait
sur les structures de données, qui le servaient. le résultat était un
code assez esthétique, mais une conception improvisée des structures
de données, assez laides (en tout cas aux yeux d'un vieux baroudeur du
lisp comme moi).
j'avais malgré tout autre chose en tête que simplement améliorer le
code et les structures de données. mon but était de transformer
popclient en quelque chose que je comprenne entièrement. ce n'est pas drôle de
devoir corriger des bogues dans un programme que vous comprenez mal.
pendant environ un mois, je me contentai de suivre les conséquences
de la conception simpliste de carl. le premier changement significatif
que je fis fut d'introduire le support pour imap. je le fis en
réorganisant les pilotes de protocoles sous la forme d'un pilote
générique et de trois tables de méthodes (pour pop2, pop3, et
imap). cela, et les modifications antérieures, illustre un principe
général qu'il est bon pour les programmeurs de garder à l'esprit, en
particulier dans des langages comme le c qui ne permettent pas de
procéder à un typage dynamique de manière naturelle:
9. il vaut mieux avoir
des structures de données 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 données, je
continuerai à être mystifié. montre-moi tes structures de
données 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 données''. mais si on traduit cela
en termes d'aujourd'hui, après trente ans d'évolution culturelle et
technologique, cela revient pratiquement au même.
c'est à ce moment (début septembre 1996, six semaines après avoir
commencé) que j'ai commencé à penser à procéder à un changement de nom
-- après tout, il ne s'agissait plus là uniquement d'un client
pop. mais j'hésitai, puisque rien dans ma conception n'était vraiment
neuf. il fallait encore que mon programme développe une identité
propre.
cela s'est produit de manière radicale quand fetchmail apprit à faire
suivre le courrier rapporté sur le port smtp. j'y viendrai bientôt.
il me faut d'abord signaler ceci: j'ai dit plus haut que j'avais décidé
d'utiliser ce projet pour mettre en pratique ma théorie sur les raisons du
succès de linus torvalds. comment ai-je procédé, vous direz-vous ? comme suit:
j'ai distribué tôt et mis à jour souvent (au moins tous les dix
jours; pendant
les périodes de développement effréné, une fois par jour).
j'ai agrandi ma liste de bêta-testeurs en y ajoutant tout ceux qui me
contactaient et me parlaient de fetchmail.
À chaque mise à jour, j'envoyais un petit palabre sur la liste bêta,
encourageant les gens à participer.
et j'ai écouté mes bêta-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 résultat de ces mesures élémentaires ne se fit pas attendre. la
plupart des développeurs tueraient père et mère pour avoir des
notifications de bogues de la qualité de celles que je reçus dès le
début du projet, et la plupart du temps, elles étaient accompagnées de bonnes
solutions. j'ai reçu des critiques réfléchies, du courrier
d'admirateurs, des suggestions intelligentes proposant de nouvelles
fonctionnalités. ce qui nous donne:
10. si vous traitez vos bêta-testeurs comme ce que vous avez de plus
cher au monde, ils réagiront en devenant effectivement ce que vous
avez de plus cher au monde.
une mesure intéressante du succès de fetchmail est l'impressionnante taille
de la liste bêta 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 intéressante. plusieurs personnes m'ont
demandé de résilier 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. et popclient devint fetchmail
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 réalisé
pratiquement tout de suite qu'une implantation fiable de cette
fonctionnalité rendrait pratiquement obsolètes 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
-- inélégante et truffée de trop nombreuses options exiguës qui
sortaient de toutes parts. j'étais particulièrement turlupiné par les
options proposant de déposer le courrier récupéré dans un fichier
boîte aux lettres ou sur la sortie standard, sans trop savoir
pourquoi.
je compris, quand l'idée de faire suivre le courrier sur le port smtp
traversa mon esprit, que popclient cherchait à trop en faire. il avait
été conçu pour jouer à la fois le rôle 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 côté
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é inhérente à la
configuration d'un facteur, pourquoi verrouiller un fichier boîte aux
lettres, y ajouter du courrier, alors que le port 25 nous tendait les
bras de façon pratiquement assurée sur toute plate-forme proposant
tcp/ip depuis toujours ? surtout que choisir cette solution garantit
au courrier récupéré sa ressemblance avec du courrier normalement
envoyé par son véritable auteur via smtp, et que c'est exactement ce
que nous cherchions.
il y a plusieurs morales à cette histoire. tout d'abord, l'idée de faire
suivre le courrier vers le port smtp fut le plus grand profit que je tirai
de la tentative consciente de copier les méthodes de linus. c'est un
utilisateur qui m'a soufflé cette idée formidable -- et je n'ai eu qu'à en
comprendre les conséquences.
11. il est presque aussi important de savoir reconnaître les bonnes
idées de vos utilisateurs que d'avoir de bonnes idées vous-même.
c'est même préférable, parfois.
de manière surprenante, vous comprendrez vite que si vous êtes
parfaitement honnête quant à ce que vous devez aux autres, tout en
restant en retrait, on finira par considérer 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 présenté cet article à la conférence sur perl en août
1997, larry wall, l'inventeur de perl, était assis au premier
rang. alors que j'abordai le paragraphe précédent il cria, d'un ton
enthousiaste et fervent:
ndt larry se moquait gentiment de lui-même; il fréquente des groupes
chrétiens qui font des réunions assez pittoresques.
``oui, dis-le leur, mon frère !'', déclenchant un rire généralisé.
tout le monde dans l'assistance savait comment cela avait bien fonctionné
pour l'inventeur de perl, également.)
après quelques semaines de travail sur le projet dans cet esprit-là,
je commençai à être félicité 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 leçons essentielles, apolitiques,
valables pour toutes sortes de conceptions de procédés nouveaux.
12. bien souvent, les solutions les plus innovantes, les plus
frappantes, apparaissent lorsque vous réalisez que votre approche du
problème était mauvaise.
j'avais tenté de résoudre le mauvais problème en m'acharnant à
développer popclient comme un mta/mda combinés, 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 chaîne du courrier géré par smtp sur l'internet.
quand vous vous heurtez à un mur au cours du développement d'un projet
-- quand vous avez du mal à réfléchir au-delà de la prochaine
génération de corrections -- c'est souvent le bon moment pour vous
demander, non pas si vous apportez la bonne réponse, mais plutôt si
vous posez la bonne question. il se peut qu'il faille recadrer le
problème.
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 générique, (2) en faire le mode par défaut, 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 troisième étape pendant un moment,
craignant le courroux de mes utilisateurs fidèles, utilisant les
autres modes de distribution. en théorie, il leur suffisait de mettre
en place des fichiers .forward ou leur équivalent dans un autre
système que sendmail pour obtenir exactement les mêmes 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 alambiquées du code propre au pilote disparurent. la
configuration devenait simplissime -- plus de baratin sur la manière
de gérer le mda et la boîte aux lettres de l'utilisateur, plus
d'ennuis quant à savoir si le système d'exploitation sous-jacent
permettait de verrouiller des fichiers.
il faut également noter que l'unique manière de perdre son courrier
disparut par la même occasion. 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 côté pour plus tard.
de plus, les performances de mon programme s'en trouvaient améliorées
(mais pas au point de le remarquer au cours d'une seule session). un
autre bénéfice non négligeable 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 spécifié par l'utilisateur, de manière à me permettre de gérer
certaines situations obscures liées au slip dynamique. mais j'ai
trouvé une façon de faire bien plus simple.
la morale ? n'hésitez pas à jeter aux orties des fonctionnalités
dépassées quand vous le pouvez sans perdre en efficacité. antoine de
saint-exupéry (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 développa sa propre identité, différente de son ancêtre
popclient.
le temps était venu pour un changement de nom. la nouvelle conception
du nouveau programme ressemblait beaucoup plus à une réplique de sendmail
qu'à l'ancien popclient; tous deux sont des mtas, mais alors que
sendmail envoie puis distribue, le nouveau popclient récupère avant de
distribuer. deux mois après le démarrage du projet, j'en changeai le
nom en fetchmail.
7. fetchmail grandit
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 bêta 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 réellement utile à tout bidouilleur
possédant 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 référence'', un de
ces programmes classiques qui remplissent si bien leur rôle qu'il
élimine toute compétition parce qu'on en oublie complètement les
autres solutions, au lieu de simplement les laisser de côté.
je ne pense pas qu'on puisse vraiment viser ou planifier un tel
but. on y est attiré par des idées de conception si puissantes
qu'après coup les résultats paraissent tout naturels, inévitables,
prédestinés. la seule manière de tomber sur ce genre d'idées est
d'avoir beaucoup d'idées -- ou d'avoir assez de discernement pour
reconnaître les bonnes idées des autres, même si elles vous mènent plus
loin que vous ne pensiez aller.
andrew tanenbaum eut l'idée 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
loin sans doute que ce qu'andrew avait en tête -- et il le transforma
en quelque chose de merveilleux. de la même manière (mais pas à la
même échelle), j'avais pris quelques idées de carl harris et de harry
hochheiser et je les avais exploitées à fond. aucun de nous n'est
'original' de la manière, romantique, dont les gens imaginent le
génie. mais la majeure partie des sciences, de l'ingéniérie et du
développement logiciel n'est pas le fruit du génie à l'état pur,
malgré ce que peuvent laisser croire les mythes des bidouilleurs.
les résultats furent à peu près une excitation identique -- en fait, le
genre de choses dont tous les bidouilleurs rêvent ! et ils signifiaient
simplement qu'il me faudrait être encore plus exigeant avec moi-même. pour
rendre fetchmail aussi bon que j'entrevoyais qu'il pouvait l'être, il ne
faudrait plus me contenter d'écrire du code répondant à mes propres
besoins, il me faudrait prendre en compte les désirs et les souhaits des
autres pour des fonctionnalités que je n'utiliserais pas. tout en gardant le
programme simple et robuste.
le premier ajout que j'écrivis après cela, et il fut de taille, fut la
possibilité de distribuer du courrier dans des 'immeubles' (multidrop) --
récupérer du courrier à partir d'une boîte aux lettres correspondant à une
adresse commune, dans laquelle s'étaient accumulés des plis, et
redistribuer chacun d'entre eux dans les boîtes personnelles de leur
véritable destinataire.
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 822ndt 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:
14. tout outil doit être utile par rapport aux utilisations qu'il a été
prévu d'en faire. mais on reconnaît un outil vraiment excellent
au fait qu'il se prête à des usages totalement insoupçonnés.
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:
15. quand vous écrivez un logiciel jouant le rôle d'une passerelle
quelconque, prenez soin de perturber le moins possible le flot de
données -- et ne perdez *jamais* d'éléments d'information, à
moins que la machine destinataire vous y oblige !
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.
8. quelques enseignements supplémentaires tirés de fetchmail
avant de retourner à des sujets plus généraux du génie logiciel, il
nous reste à méditer sur quelques leçons supplémentaires tirées de
l'expérience de fetchmail.
la syntaxe du fichier rc spécifie quelques mots clés ``parasites''
optionnels, complètement ignorés 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'idée m'est venue tard un soir, alors que je remarquais combien ces
déclarations du fichier rc commençaient à prendre l'allure d'un
mini-langage impératif. (c'est aussi la raison pour laquelle j'ai
remplacé le mot clé `server' (serveur), originalement présent dans
popclient, par `poll' (vérification de la présence d'activité)).
il m'a semblé que rendre ce mini-langage plus proche de l'anglais en
rendrait l'utilisation plus aisée. il me faut préciser que, bien que
farouche
partisan de l'école de conception ``faites-en un langage'', illustrée par
des outils comme emacs, html et de nombreux moteurs de bases de données,
je ne suis pas, d'habitude, un admirateur des syntaxes ``à l'anglaise''.
de manière traditionnelle, les programmeurs ont eu tendance à
favoriser des syntaxes de
contrôle très précises et compactes, sans redondance. il s'agit d'un
héritage culturel du temps
où les ressources informatiques coûtaient 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 modèle très
peu approprié.
ce n'est pas la raison pour laquelle je dénonce la
non utilisation
de syntaxes naturelles; je n'en
fais mention ici que pour mieux la démolir. maintenant que les
ressources informatiques sont pléthore, l'austérité ne doit pas être
une fin
en soi. de nos jours, il est plus important qu'un langage soit
facilement compréhensible par les humains plutôt que par les
ordinateurs.
il existe, en revanche, de bonnes raisons pour se méfier. l'une d'entre elles
est le coût en complexité de la phase d'analyse syntaxique -- vous n'avez
certainement pas envie d'en faire une source non négligeable de bogues.
vous n'avez pas envie non plus que la complexité de votre langage
déroute 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 déformation 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 prétendument de
quatrième génération et des langages de requêtes dans des bases de données
commerciales.)
la syntaxe permettant de contrôler fetchmail évite ces deux écueils parce
que le domaine du langage est très restreint. il n'est en rien un langage
généraliste; 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 contrôle
en lui-même. je pense qu'il y a ici matière à une leçon plus générale:
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 leçon concerne la sécurité par hermétisme (utilisant par
exemple des mots de passes secrets).
certains utilisateurs de fetchmail m'ont demandé de modifier le logiciel de
manière à stocker des mots de passe chiffrés 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
supplémentaire. quiconque a obtenu le droit de lire votre fichier rc pourra
lancer fetchmail sous votre identité de toutes manières -- et s'il en a après
votre mot de passe, il pourra toujours extraire du code de fetchmail
le décodeur nécessaire pour le déchiffrer.
tout ce qu'un chiffrement de mots de passe dans le fichier .fetchmailrc
aurait apporté, c'est un sentiment de sécurité infondé à ceux qui
connaissent mal les problèmes de sécurité. la règle générale est ici:
17. un système de sécurité n'est pas plus sûr que le secret (la clé)
qui le garde. gare aux pseudo secrets !
9. prérequis nécessaires au style bazar
les premiers relecteurs et les premiers publics auprès desquels cet
article a été testé ont
posé de manière régulière la question des prérequis nécessaires à la
réussite
d'un développement 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 co-développeurs.
il est assez évident qu'il n'est pas possible de commencer à coder
dans le style bazar dès le début. on peut tester, déboguer et
améliorer un programme dans le style bazar, mais il sera très
difficile de faire démarrer un projet dans le mode
bazar. linus ne l'a pas tenté, moi non plus. il faut que votre
communauté naissante de développeurs ait quelque chose qui tourne,
qu'on puisse tester, avec quoi elle puisse jouer.
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.
10. le contexte social du logiciel dont le code source est ouvert
cela est bien connu: les meilleures bidouilles commencent en tant que
solutions personnelles aux problèmes de tous les jours rencontrés par leur
auteur, et elles se répandent parce que ce problème est commun à de
nombreuses personnes. cela nous ramène à la règle numéro 1, reformulée
de manière peut-être plus utile:
18. pour résoudre un problème intéressant, commencez par trouver un
problème qui vous intéresse.
ainsi fut-il de carl harris et du vieux popclient, ainsi fut-il de moi et de
fetchmail. mais cela est bien compris depuis longtemps. ce qui compte, le
détail sur lequel les histoires de linux et de fetchmail semblent nous
demander de nous concentrer, est l'étape suivante -- l'évolution du
logiciel en présence d'une communauté d'utilisateurs et de co-développeurs
importante et active.
dans ``le mythe du mois-homme'', fred brooks observa qu'on ne peut pas
diviser et répartir le temps du programmeur; si un projet a du retard, lui
ajouter des développeurs ne fera qu'accroître son retard.
il explique que les coûts de communication et de complexité d'un projet
augmentent de manière quadratique avec le nombre de développeurs, alors que
le travail réalisé n'augmente que linéairement.
depuis, cela est connu sous le nom de ``loi de brooks'', et on la considère
en général comme un truisme. mais si seule la loi de brooks comptait, linux
serait impossible.
le classique de gerald weinberg ``la psychologie
de la programmation sur ordinateur'' apporta ce qu'on pourrait considérer
après coup comme une correction vitale à brooks.
dans sa discussion sur la ``programmation non égoïste'', weinberg observa que
dans les boîtes où les programmeurs ne marquent pas le territoire de leur
code, et encouragent les autres à y chercher les bogues et les
améliorations potentielles, les améliorations sont drastiquement plus
rapides qu'ailleurs.
les termes choisis par weinberg l'ont peut-être empêché de recevoir toute
la considération qu'il méritait -- et l'idée que les bidouilleurs sur
internet puissent être décrits comme ``non égoïstes'' fait sourire. mais je
pense que cet argument semble aujourd'hui plus vrai que jamais.
l'histoire d'unix aurait dû nous préparer à ce que nous découvrons avec
linux (et à ce que j'ai expérimenté à une échelle plus modeste en
copiant délibérément les méthodes de linus): alors que l'acte de
programmation est essentiellement solitaire, les plus grandes bidouilles
proviennent de la mise à contribution de l'attention et de la puissance de
réflexion de communautés entières.
le développeur qui n'utilise que son propre cerveau dans un projet fermé ne
tiendra pas la route face au développeur qui sait comment créer un contexte
ouvert, susceptible d'évoluer, dans lequel la traque des bogues et les
améliorations sont effectuées par des centaines de gens.
mais le monde traditionnel d'unix n'a pas poussé cette approche dans ses
derniers retranchements pour plusieurs raisons. l'un d'entre eux
concernait les contraintes légales des diverses licences, secrets de
fabrication,
et autres intérêts commerciaux. un autre (mieux compris plus tard)
était que l'internet n'était pas encore assez mûr.
avant que les coûts d'accès à internet ne chutent, il existait quelques
communautés géographiquement compactes dont la culture encourageait la
programmation ``non égoïste'' à la weinberg, et un développeur pouvait
facilement attirer tout un tas de co-développeurs et autres touche-à-tout
doués. les laboratoires bell, le laboratoire d'intelligence artificielle de
l'institut de technologie du massachusetts (mit), l'université de californie à
berkeley, devinrent les foyers d'innovations légendaires qui sont restés
puissants.
linux fut le premier projet qui fit un effort conscient et abouti pour
utiliser le monde entier comme réservoir de talent. je ne
pense pas que cela soit une coïncidence que la période de gestation de
linux ait coïncidé avec la naissance du world wide web, ni que linux
ait quitté le stade de la petite enfance en 1993-1994, au moment où
l'intérêt général accordé à internet et que l'industrie des
fournisseurs d'accès explosèrent. linus fut le premier à
comprendre comment jouer selon les nouvelles règles qu'un internet
omniprésent rendait possibles.
même s'il fallait qu'internet ne coûte pas cher pour que le modèle linux se
développe, je ne pense pas que cela soit suffisant. il y avait un autre facteur
vital: le développement d'un style de direction de projet et d'un ensemble de
coutumes de coopération qui permettaient aux développeurs d'attirer des
co-développeurs et de rentabiliser au maximum ce nouveau média.
quel est donc ce style de direction, quelles sont donc ces coutumes ? ils ne
peuvent pas être fondés sur des rapports de force -- même
si c'était le cas, la direction par coercition ne produirait pas les
résultats qu'on peut observer. weinberg cite fort à propos l'autobiographie de
pyotr alexeyvitch
kropotkine, anarchiste russe du xixe siècle, ``mémoires d'un
révolutionnaire'':
``Élevé dans une famille possédant des serfs, j'entrai dans la vie active,
comme tous les jeunes gens de mon époque, avec une confiance aveugle dans la
nécessité de commander, d'ordonner, de brimer,
de punir et ainsi de suite. mais quand, assez tôt, je dus diriger
d'importantes affaires et côtoyer des hommes
libres,
et quand chaque erreur pouvait être immédiatement lourde de conséquences,
je commençai à apprécier la différence entre agir selon les principes
du commandement et de la discipline et agir selon le principe de la
bonne intelligence.
le premier fonctionne admirablement dans un défilé militaire, mais ne
vaut rien dans la vie courante, où on ne peut atteindre son but que grâce à
l'effort soutenu de nombreuses volontés travaillant dans le même sens.''
``l'effort soutenu de nombreuses volontés travaillant dans le même sens'',
c'est exactement ce qu'un projet comme linux demande -- et le ``principe de
commandement'' est en effet impossible à appliquer aux volontaires de ce
paradis de l'anarchie que nous appelons internet. pour opérer et se
mesurer les uns aux autres de manière efficace,
les bidouilleurs qui cherchent à prendre la tête d'un projet de
collaboration commune doivent apprendre à recruter et à insuffler de
l'énergie dans les communautés d'intérêts convergents à la manière vaguement
suggérée par le ``principe de bonne intelligence'' de kropotkine. ils
doivent apprendre à utiliser la loi de linus.
plus haut, je me référais à ``l'effet de delphes'' comme une possible
explication de la loi de linus. mais on ne peut s'empêcher de penser à des
analogies très puissantes avec des systèmes adaptatifs en biologie et en
économie. le monde linux sous de nombreux aspects, se comporte comme un
marché libre ou un écosystème, un ensemble d'agents égoïstes qui tentent
de maximiser une utilité, ce qui au passage produit un ordre
spontané, auto-correcteur, plus élaboré et plus efficace que toute
planification centralisée n'aurait pu l'être.
c'est ici qu'il faut chercher le ``principe de bonne intelligence''.
la ``fonction d'utilité'' que les bidouilleurs linux maximisent n'est pas
classiquement économique, c'est l'intangible de leur propre satisfaction
personnelle et leur réputation au sein des autres bidouilleurs. (on peut
être tenté de penser que leur motivation est ``altruiste'', mais c'est
compter sans le fait que l'altruisme est en soi
une forme d'égoïsme pour l'altruiste). les cultures volontaires qui
fonctionnent ainsi ne sont pas si rares; j'ai déjà participé à des projets
semblables dans les fanzines de science-fiction, qui au contraire du monde
de la bidouille, reconnaissent explicitement que l'``egoboo'' (le fait que sa
réputation s'accroisse auprès des autres fans) est le principal moteur qui
propulse les activités volontaires.
linus, en se positionnant avec succès comme gardien des clés d'un projet où
le développement est surtout fait par les autres, et en y injectant de
l'intérêt jusqu'à ce qu'il devienne auto-suffisant
a montré une intelligence profonde du ``principe
de bonne intelligence'' de kropotkine.
cette vision quasi-économique du monde de linux nous permet de comprendre
comment cette bonne intelligence est mise en oeuvre.
on peut analyser la méthode de linus comme un moyen de créer de manière
efficace, un marché de l'``egoboo'' -- relier les égoïsmes individuels
des bidouilleurs aussi fermement que possible, dans le but de
réaliser des tâches impossibles sans une coopération soutenue. avec
le projet fetchmail, j'ai montré (à une échelle plus modeste, je vous
l'accorde) qu'on peut dupliquer ses méthodes avec de bons résultats.
peut-être même l'ai-je fait un peu
plus consciemment et plus systématiquement que lui.
nombreux sont ceux (en particulier ceux dont les opinions politiques les
font se méfier des marchés libres) qui s'attendraient à ce que la
culture d'égoïstes sans autre maître qu'eux mêmes soit fragmentée,
territoriale, source de gâchis, pleine de petits secrets, et hostile.
mais cette idée est clairement mise en défaut par (pour ne donner qu'un
seul exemple) l'époustouflante variété, qualité et profondeur de la
documentation relative à linux. il est pourtant légendaire que les
programmeurs détestent écrire des documentations; comment se
fait-il, alors, que les bidouilleurs de linux en produisent tant ?
il est évident que le marché libre d'egoboo de linux fonctionne mieux
que tout autre pour générer des comportements vertueux, serviables,
mieux que les services documentaires largement subventionnés des
producteurs de logiciels commerciaux.
les projets fetchmail et du noyau de linux montrent tous deux qu'en
flattant à bon escient l'ego de beaucoup d'autres bidouilleurs, un
coordinateur-développeur fort peut utiliser l'internet pour tirer parti
du fait d'avoir énormément de co-développeurs sans que le projet ne
s'effondre en un capharnaüm chaotique. c'est pourquoi je propose la
contrepartie suivante à la loi de brooks:
19: pour peu que le coordinateur du développement dispose d'un moyen
de communication au moins aussi bon que l'internet, et pour peu
qu'il sache comment mener ses troupes sans coercition, il est
inévitable qu'il y ait plus de choses dans plusieurs têtes que
dans une seule.
je pense qu'à l'avenir, le logiciel dont le code source est ouvert
sera de plus en plus entre les
mains de gens qui savent jouer au jeu de linus, des gens qui abandonnent
les cathédrales pour se consacrer entièrement au bazar. cela ne veut pas
dire que les coups de génie individuels ne compteront plus; je pense
plutôt que l'état de l'art
du logiciel dont le code source est ouvert appartiendra à ceux qui
commencent par un projet individuel génial, et qui l'amplifieront à
travers la construction efficace de communautés d'intérêt volontaires.
et peut-être même qu'il n'est pas question ici que de l'avenir du
logiciel dont le code source est ouvert. aucun développeur
qui fonctionne avec un code source fermé
ne peut mobiliser autant de talent que celui que la
communauté linux peut consacrer à un problème donné. bien rares même
sont ceux qui auraient eu les moyens de rémunérer les deux cents et
quelques contributeurs à fetchmail !
peut-être qu'à terme, la culture du logiciel dont le code source est
ouvert triomphera, non pas
parce qu'il est moralement bon de coopérer, non pas parce qu'il est
moralement mal de ``clôturer'' le logiciel (en supposant que vous
soyez d'accord avec la deuxième assertion; ni linus ni moi ne le sommes),
mais simplement parce que le monde dont le code source est fermé
ne peut pas gagner une
course aux armements évolutive contre des communautés de logiciel
libre, qui peuvent mettre sur le problème un temps humain cumulé plus
important de plusieurs ordres de grandeurs.
11. remerciements
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.
12. pour aller plus loin
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.
13. Épilogue: netscape embrasse la méthode du bazar !
Ç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.
14. historique des versions et des modifications
$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.
Acceuil
suivante
Auteur : Eric S. Raymond ( esr@thyrsus.com) Traducteur : Sébastien ... Auteur : Eric S. Raymond ( esr@thyrsus.com) Traducteur : Sébastien ... Prestataires de Madagascar : le bazar be vente en detail et gros ... www.bhv.fr - Tout pour trouver son bonheur Bazar Avenue - Electroménager - Cuisine : Magimix, Kitchenaid ... LE MAG - Le Bazar Parisien - Tous nos conseils pour shopper autrement Le Bazar Parisien - Concept store on line - Découvrez une ... Le Bazar du Bizarre Le Bazar du Bizarre Le Bazar : Discothèques Marseille - Actualité - Artisanat maroc - bazar maroc - artisanat marocain - babouches ... Game Bazar Network [ counter-strike, half-life, day of defeat ... Bazar - Wikipédia La Cathédrale et le Bazar - Wikipédia bigbazar.info : 5000 logiciels à télécharger gratuitement Big Bazar : cliparts à télécharger gratuitement Le Petit Bazar Cartographique Le Web Bazar !!! Roadbooks, Liens, Calendrier, Essais, Motos... !!! LudikBazar, Jeux de rôle introuvables à petit prix jeux gratuits en ligne (jeux en ligne), Tous les jeux vidéo en ... Electric Bazar Cie / Retire tes Doigts - Rock'n'roll Roumain y ... Bienvenue au P'tit BaZaR!! Bienvenue dans La BoîTe à BaZaR SPIDER DATABASE, bibliographical part Babali - les plus bas prix : 1er bazar en ligne Le Grand bazar du Transsibérien ALPHA BAZAR : Programmation créative en vrac par ALPHA STUDIO Bazar, Fatras et Grand Fourre-Tout Accueil du BFGFT Le Grand Bazar - Comparatif des prix sur Kelkoo Belgique Bazar Maximal Video Bazar Maximal Quelbazar, l'oeil du Syklop - En vrac d'un papa lausannois ... Au bazar des NAC - Association de protection et Refuge pour les ... Mon Bazar à Moi / Stickers décoratifs pour meubles et objets Bazar Be - croissance.com Le baZar de Milou BAZAR CHIC!!!!!! Boot''s Bazar - Gowest - Bottes - santiag - boots - Miss Bazar