Produire du logiciel libre

8/7/2019 Produire du logiciel libre

1/353

``97612617'' --- 2011/1/2 --- 18:37 --- page i --- #1

Karl Fogel

Produire du logiciel libre

Traduction Fr. : Framalang

Publi sous licence Creative Commons

Paternit-Partage lidentique (3.0)
http://creativecommons.org/licenses/by-sa/3.0/deed.fr


2/353

``97612617'' --- 2011/1/2 --- 18:37 --- page ii --- #2

ii

Copyright 2005, 2006, 2007, 2008, 2009 : Karl Fogel

Copyright 2010 : Framasoft

2010 : traduction Framasoft (projet Framalang)

Mise en page : La Poule ou luf

Couverture : Neocrea

Dpt lgal : dcembre 2010, In Libro Veritas

ISBN : 978-2-35922-034-6
http://www.neocrea.net/http://www.pouleouoeuf.org/


3/353

``97612617'' --- 2011/1/2 --- 18:37 --- page iii --- #3

Avant-propos

Nous sommes heureux de publier cette traduction franaise deProducing Open Source Software. How to Run a Successful FreeSoftware Project, dont le texte original est accessible sur Producin-gOSS.com 1, dans de nombreuses autres langues.

Pour les habitus du genre, la plupart des How To ou comment faire en informatique sont des complments auxmanuels de logiciels. En se focalisant sur des tches spcifiques, unHow to permet de montrer, par la pratique, comment se servir detelle ou telle fonctionnalit dun programme. Ds lors, commentconcevoir quil puisse exister un How to cens renseigner sur une

1. http ://producingoss.com/

i ii
http://producingoss.com/http://producingoss.com/


4/353

``97612617'' --- 2011/1/2 --- 18:37 --- page iv --- #4

iv

activit minemment sociale comme celle qui consiste produire dulogiciel libre par une stratgie de projet communautaire regroupantdes programmeursbnvoles ?

Grce son exprience du dveloppement Open Source, Karl Fo-gel nous livre ici bien davantage quune simple marche suivrepour quun projet voie le jour et ait une chance daboutir. Il sagiten effet de dtailler les lments stratgiques les plus importantscomme la bonne pratique du courrier lectronique et le choix dugestionnaire de versions, mais aussi la manire de rendre cohrentset harmonieux les rapports humains tout en mnageant les suscep-tibilits En somme, dans le dveloppement Open Source peut-treplus quailleurs, et parce quil sagit de trouver un bon quilibreentre coopration et collaboration, les qualits humaines sont aussidcisives que les comptences techniques.

La traduction de cet ouvrage a obi aux mmes principes que ceuxexposs par Karl Fogel. Ce sont les mmes enjeux de motivation etde disponibilit des participants que soulve un tel projet, et quiexpliquent trs certainement sa relative lenteur, puisque les travauxcommencrent au dbut de lanne 2007. Cest en revanche toute laforce des projets libres de Framasoft que de ne pas tre soumis uneexigence de rentabilit impose par des frais dinvestissement ou parles contraintes de la concurrence, si svres dans le monde ditorial.Aussi, quel que soit son rythme, la ralisation dune traduction et

sa publication dans la collection Framabook est toujours voue ausuccs, mais plus ou moins long terme.

Produire du logiciel libre est dabord le rsultat dune convergencefortuite entre deux projets isols, comme cest bien souvent le casdans le monde du libre. Au cours de lanne 2007, Bertrand Floratet tienne Savard avaient commenc traduire louvrage selon lesspcifications donnes par Karl Fogel : un Docbook sous SVN, o lescontributeurs volontaires pouvaient reporter leurs modifications partir du texte en anglais sur le site officiel ProducingOSS.com.Le groupe Framalang, de son ct, avait depuis quelque temps placProducing Open Source Software dans la liste des textes traduiresur le wiki consacr 1, avec un responsable : Olivier Rosseler. Commelexplique Johann Bulteau, tmoin et acteur de la premire heure :

Cest vers le mois de juin 2007 quEva Ma-thieu, de lApril2, et qui travaillait sur Framalang,fit suivre Pierre-Yves Gosset3 un courriel quelle

1. http ://www.framalang.org/2. http ://www.april.org/3. Pierre-Yves Gosset est le Dlgu Gnral (et permanent) de Framasoft.
http://www.april.org/http://www.framalang.org/


5/353

``97612617'' --- 2011/1/2 --- 18:37 --- page v --- #5

v

avait reu par erreur, car les auteurs voulaientcontacter les responsables de Framalang. Pierre-Yves les renvoya donc vers nous.

Ils sagissait dtienne Savard et de Bertrand Flo-rat, les deux traducteurs officiels de ce bouquin.Quand je dis officiels, cest parce quils taient encontact avec lauteur, Karl Fogel, et que leur travailse passait directement sur ProducingOSS.com.

Il y eut moult discussions par courriel afin de sac-corder sur la manire de procder : fork ou coop-ration ? Si coopration, o et comment travailler ?Ce qui tait dj sr en tout cas, cest que Karl Fo-gel tait ravi de voir que son livre allait tre traduiten franais !

On a discut des mthodes de travail. Eux fonc-tionnaient directement sur SVN, avec export en Doc-book. Le problme avec a, cest que nos traducteursne sont pas tous des informaticiens chevronns. Ilsntaient pas l pour et surtout ne savaient pas fairedes commits de leur travail Utiliser ces outils auraitdonc fait perdre une grosse partie des forces vives.Ils lont compris et ils ont finalement dcid de re-joindre notre wiki.

Pour Olivier Rosseler, il sagissait surtout dun dfi. Le groupede traduction Framalang avait pris naissance grce la traductiondu livre Changer pour OpenOffice.org, et la perspective dune nou-velle publication tait fortement motivante. Renouveler loprationsignifiait quun projet permanent de traduction collaborative taitnon seulement viable mais constituait une ressource trs importantepour la diffusion des connaissances sur le logiciel libre. Dautres pro-jets vinrent alors se greffer sur les priorits initiales, commencerpar le projet de traduction de Free as in Freedom, la biographie deRichard Stallman par Sam Williams 1.

Nanmoins, en tant quune des principales portes dentre franco-phone sur le logiciel libre, Framasoft se voyait confort dans le choixdu livre de Karl Fogel, car il reprsentait une chance de diffuser aussi

une mthode pratique de production de logiciel libre, cest--dire unmodle de dveloppement, dconomie et dinnovation encore tropmconnu, au moins en France.

1. Cette biographie, dabord traduite, fut finalement rcrite dans le cadredune collaboration entre Richard Stallman et le projet Framabook, aux di-tions Eyrolles (2010) : Richard Stallman et la Rvolution du logiciel libre. Unebiographie autorise.
http://-/?-


6/353

``97612617'' --- 2011/1/2 --- 18:37 --- page vi --- #6

vi

Selon Olivier Rosseler, la traduction elle-mme a suivi les tapesde dveloppement mentionnes par Karl Fogel :

Curieusement, les propos de Karl Fogel dans sonlivre se sont vrifis tout au long de notre traduction,comme si, maintes reprises, il dcrivait prcis-ment notre collaboration : le besoin lorigine, lesrelations si particulires entre des contributeurs quine sont lis que par le projet, mais qui ont paradoxa-lement des objectifs diffrents, les priodes dactivit

creuses qui alternent avec la frnsie du contributeurpris par les remords davoir dlaiss le projet, lap-proche de la publication et lactivit quelle gnre

Jen retiendrai quun projet libre doit effectivementnatre dun rel besoin. Si personne na vraimentintrt ce que le projet voie le jour, personne nestl pour vraiment en prendre les rnes.

En dernier lieu, cest lquipe Framabook 1 qui se chargea de lamise en uvre de la prsente publication. Les phases de relecture, dereformulation et de chasse aux coquilles furent elles-mmes menes plusieurs en utilisant notre chane ditoriale La Poule ou luf2,que nous tenons vivement remercier ici. Lefficacit de cette ultimetape collaborative fut impressionnante, mais nous naurions pas la

prtention de qualifier ce travail dexemplaire. Cest pourquoi nousavons toujours besoin des rapports de bogues de la part deslecteurs, et pour cela, nhsitez pas vous rendre sur le wiki deFramasoft 3 pour contribuer ce Framabook.

1. http ://www.framabook.org2. http ://www.pouleouoeuf.org/3. http ://wiki.framasoft.org/Contribuer aux Framabooks
http://wiki.framasoft.org/Contribuer_aux_Framabookshttp://wiki.framasoft.org/Contribuer_aux_Framabookshttp://www.pouleouoeuf.org/http://www.framabook.org/


7/353

``97612617'' --- 2011/1/2 --- 18:37 --- page vii --- #7

vii

Remerciements

Framasoft tient remercier Framalang, son quipe de traduction,et plus particulirement, pour la traduction et la relecture initiale :

Johann Bulteau Claude Curgan Daria Bertrand Florat

Gaelix Benjamin Jean (alias Mben) Eva Mathieu R4f Olivier Rosseler tienne Savard Tolosano Tyah

Puis pour la reprise, relecture et mise en page de louvrage avantpublication :

Barbara Bourdelles (alias Garburst) Gilles Coulais (alias Poupoul2) Christophe Jarry

Jean-Bernard Marcon (alias Goofy) Christophe Masutti Julien Reitzel Raymond Rochedieu (alias Papiray) Frdric Urbain

Remerciements galement Simon Descarpentries (alias Siltaar)pour la coordination du projet de publication.

Enfin, Framasoft remercie tout particulirement Christophe Ma-sutti, coordinateur de la collection Framabook.


8/353

``97612617'' --- 2011/1/2 --- 18:37 --- page viii --- #8

viii

Remerciements de lauteur

Ce livre est ddi deux amis qui me sont chers et sans qui rien detout cela naurait t possible : Karen Underhill et Jim Blandy.


9/353

``97612617'' --- 2011/1/2 --- 18:37 --- page ix --- #9

Prface

Pourquoi crire ce livre ?

Dans les soires, les gens ne me regardent plus bizarrement quandje leur dis que je fais du logiciel libre. Ah oui, Open Source, comme

Linux ? me rpondent-ils. Jacquiesce avec empressement. Oui,exactement, cest ce que je fais! Cest agrable de ne plus trecompltement lcart. Dans le pass, la question suivante tait g-nralement assez prvisible : Comment gagnes-tu ta vie en faisanta? . Ma rponse rsumait toute lconomie de lOpen Source :certaines organisations trouvent leur intrt dans lexistence dunlogiciel particulier, mais nont aucunement besoin den vendre des

ix


10/353

``97612617'' --- 2011/1/2 --- 18:37 --- page x --- #10

x

copies, elles veulent juste tre sres que le logiciel continue dexisteret dtre maintenu : en tant quoutil plutt que bien.

Ces derniers temps pourtant, la question ne portait pas toujourssur largent. Le ct conomique de lOpen Source 1 nest plus simystrieux et beaucoup de non-programmeurs comprennent, ou dumoins ne sont pas surpris, que certains y soient employs pleintemps. Par contre, la question entendue de plus en plus souventtait : Ah! Comment a marche?

Je navais pas de rponse satisfaisante toute prte et, plus jes-

sayais den donner une, plus je ralisais quel point le sujet estcomplexe. Mener un projet de logiciel libre nest pas exactementcomme diriger une entreprise (imaginez devoir constamment discu-ter de la nature du produit avec un groupe de volontaires que vousne rencontrerez jamais pour la plupart !). Pour diffrentes raisons,ce nest pas non plus comme diriger une association but non lu-cratif traditionnelle ou un gouvernement. Il y a des ressemblancesentre tous ces types dorganisations, mais je suis lentement arriv la conclusion que le logiciel libre est sui generis. Il peut tre compar de nombreuses choses, sans pouvoir tre assimil aucune. En fait,mme lhypothse selon laquelle un projet de logiciel libre peut tre dirig est douteuse. Un tel projet peut tre dmarr et influencpar les personnes impliques, souvent mme trs fortement. Maisson capital ne peut tre considr comme la proprit dun seul, et,

tant quil y aura des volontaires, quelque part et peu importe o,nul ne pourra dcider unilatralement de larrter. Chacun possdeun pouvoir infini et personne ne possde le moindre pouvoir : le toutproduisant une dynamique intressante.

Voil pourquoi jai voulu crire ce livre. Les projets de logicielslibres ont donn naissance une culture distincte, une philosophieo la libert de crer un logiciel ralisant ce que lon veut est ladoctrine centrale. Pourtant, il rsulte de cette libert non pas unedispersion des individus, chacun allant dans sa propre direction avecle code, mais une collaboration enthousiaste. En effet, cette capacitest lune des facults la plus hautement estime dans le monde dulibre. Diriger de tels projets signifie sengager dans une sorte de co-opration hypertrophie o lhabilet dune personne non seulement travailler avec les autres, mais aussi proposer de nouvelles m-thodes de travail en commun, peut aboutir des avances tangiblesdu logiciel. Ce livre tente dexpliquer comment rendre ceci possible.Il nest en aucun cas exhaustif, mais peut tre considr comme unebase de dpart.

1. Les termes Open Source et libre sont essentiellement des synonymesdans ce contexte : jen parle davantage dans la section intitule Libre contreOpen Source dans lIntroduction.


11/353

``97612617'' --- 2011/1/2 --- 18:37 --- page xi --- #11

xi

Produire du bon logiciel libre est en soi un but valable, et jespreque les lecteurs qui viennent chercher des moyens de latteindre se-ront satisfaits de ce quils trouveront ici. Bien au-del, jespre trans-mettre un peu du grand plaisir que lon peut prendre travailleravec une quipe motive de dveloppeurs Open Source et interagiravec les utilisateurs de manire directe, comme le monde du librenous y invite de faon gniale. Prendre part un projet de logiciellibre russi est amusant et cest bien ce qui, au bout du compte,permet au systme entier de fonctionner.

qui sadresse ce livre ?

Ce livre sadresse aux dveloppeurs de logiciels et aux respon-sables envisageant de lancer un projet Open Source, ou layant djcommenc, et qui se demandent que faire ensuite. Il devrait gale-ment tre utile ceux qui souhaitent simplement simpliquer dansun projet Open Source sans lavoir jamais fait auparavant.

Nul besoin dtre programmeur, mais le lecteur devrait connatreles concepts basiques dingnierie logicielle tels que code source, com-pilateur et correctif.

Une exprience pralable du logiciel Open Source, en tant quu-

tilisateur ou dveloppeur, nest pas ncessaire. Ceux qui ont djtravaill au sein dun projet de logiciel libre trouveront certainesparties du livre videntes et pourront les passer. tant donn le largeventail possible dexpriences des lecteurs, jai essay de nommerclairement les diffrentes sections et de prciser celles qui peuventtre ignores par les familiers du sujet.

Sources

Une grande partie de la matire premire de ce livre provientde cinq ans dexprience sur le projet Subversion 1, un programmeOpen Source de gestion de versions, crit partir de rien, et crpour remplacer CVS, lui-mme une rfrence en la matire dans lacommunaut Open Source. Le projet fut lanc, au dbut des annes2000, par mon employeur CollabNet 2 lequel comprit, heureusementds le dpart, comment le faire fonctionner de manire collectiveet rpartie. De nombreux dveloppeurs bnvoles y adhrrent trs

1. http ://subversion.tigris.org/2. http ://www.collab.net/
http://www.collab.net/http://subversion.tigris.org/


12/353

``97612617'' --- 2011/1/2 --- 18:37 --- page xii --- #12

xii

tt. Aujourdhui, le projet en compte une cinquantaine dont peusont employs par CollabNet.

De bien des manires, Subversion est un exemple classique de pro-jet Open Source et je men suis finalement inspir plus que je ne lepensais au dbut, en partie parce que ctait pratique pour moi.Chaque fois que javais besoin dun exemple pour illustrer un ph-nomne particulier, cest une exprience issue de Subversion qui mevenait lesprit. Mais aussi pour une question de vrification : quoi-quengag, divers degrs, dans dautres projets de logiciels libreset malgr mes entretiens avec des amis et connaissances impliqusdans bien dautres encore, jai ralis rapidement, tout en crivanten vue dune publication, que tous les faits doivent tre vrifis. Jene voulais pas faire de dclarations propos dvnements se pro-duisant dans dautres projets en me basant simplement sur ce que jepouvais lire dans les archives de leurs listes de diffusion publique. Siquelquun le faisait avec Subversion, je men rends bien compte, ilse tromperait la moiti du temps. Donc quand jai pris exemple surdautres projets avec lesquels je nai pas eu dexprience directe, jaitoujours essay de vrifier mes informations auprs dune personneimplique, en qui je pouvais avoir confiance, afin quelle mexpliquece qui sest vraiment pass.

Jai travaill sur Subversion pendant les cinq dernires annes,mais je suis impliqu dans le logiciel libre depuis douze ans. Voici

dautres projets ayant influenc ce livre : Le projet dditeur de texte GNU Emacs de la Free Software

Foundation, pour lequel je maintiens quelques paquets. Concurrent Versions System (CVS), sur lequel jai beaucoup

travaill en 1994-1995 avec Jim Blandy mais auquel je participeseulement par intermittence depuis.

Lensemble des projets Open Source connus sous le nom dA-pache Software Foundation et plus spcialement lApache Por-table Runtime (APR) et lApache HTTP Server.

OpenOffice.org, la base de donnes de Berkeley de Sleepycatet la base de donnes MySQL : je nai pas t personnellementimpliqu dans ces projets mais je les ai observs et, dans certainscas, jai pu parler avec des personnes en faisant partie.

Le GNU Debugger (GDB) (idem). Le projet Debian (idem).

videmment, cette liste nest pas exhaustive. Comme la plupartdes programmeurs Open Source, je garde un il sur de nombreuxprojets diffrents, juste pour avoir une ide gnrale de ce qui sepasse. Je ne vais pas tous les mentionner ici, mais certains sont citsdans le livre quand je lai jug appropri.


13/353

``97612617'' --- 2011/1/2 --- 18:37 --- page xiii --- #13

xiii

Remerciements

crire ce livre ma pris quatre fois plus de temps que je ne lepensais et, quel que soit le sujet, javais souvent limpression demarcher avec une pe de Damocls suspendue au-dessus de matte. Sans laide de nombreuses personnes, jaurais t incapable dele finir en gardant tous mes esprits.

Andy Oram, chez OReilly, a t pour moi lditeur idal. En plusde trs bien connatre le sujet (il a suggr un grand nombre des

thmes), il a le don rare de savoir ce que quelquun veut dire et depouvoir laider le dire correctement. Travailler avec lui a t unhonneur. Merci aussi Chuck Toporek pour avoir immdiatementpropos ce projet Andy.

Brian Fitzpatrick a relu tout mon travail mesure que jcrivais,ce qui a non seulement amlior le livre mais ma aussi permis depoursuivre lcriture quand jaurais souhait me trouver nimporteo plutt que devant mon ordinateur. Ben Collins-Sussman et MikePilato ont aussi gard un il sur lavancement du travail et taienttoujours heureux de discuter, parfois longuement, quel que soit lesujet que jessayais de traiter cette semaine-l. Ils remarquaient ga-lement quand javais tendance me relcher et me taquinaient sincessaire. Merci les gars !

Biella Coleman rdigeait galement un mmoire en mme tempsque jcrivais ce livre. Elle sait ce que signifie sasseoir et crire tousles jours : elle fut pour moi aussi bien un exemple quune oreillecompatissante. Elle possde aussi le regard fascinant de lanthropo-logue sur le mouvement du logiciel libre, me fournissant la foisdes ides et des rfrences que je pouvais utiliser. Alex Golub (unautre anthropologue, avec un pied dans le monde du logiciel libre,qui lui aussi terminait son mmoire au mme moment) ma apportun soutien exceptionnel ds le dbut, ce qui ma beaucoup aid.

Micah Anderson na, dune certaine manire, jamais sembl tropstress par son propre contrat ddition, ce qui fut source de motiva-tion mais me rendait maladivement jaloux. Il a toutefois toujours tprsent par son amiti, sa conversation et (au moins une occasion)son aide technique. Merci Micah !

Jon Trowbridge et Sander Striker mont apport chacun leurs en-couragements et une aide prcieuse. Leur grande exprience du logi-ciel libre ma fourni la matire que je naurais pu trouver nulle partailleurs.

Merci Greg Stein, non seulement pour son amiti et ses encou-ragements arrivs point nomm, mais aussi pour avoir montr au


14/353

``97612617'' --- 2011/1/2 --- 18:37 --- page xiv --- #14

xiv

projet Subversion quel point une inspection rgulire du code estimportante pour le dveloppement dune communaut de program-meurs. Je remercie galement Brian Behlendorf qui a fait entreravec tact dans nos esprits limportance des discussions publiques :jespre que ce principe se reflte dans ce livre.

Merci Benjamin Mako Hill et Seth Schoen pour les nom-breuses discussions propos du logiciel libre et de sa politique, Zack Urlocker et Louis Suarez-Potts pour avoir trouv quelques mi-nutes dans leur emploi du temps surcharg afin de maccorder uneinterview, Shane de la liste Slashcode pour mavoir permis de citerson article et Haggen So pour sa comparaison des sites dhberge-ment qui ma normment aid.

Merci Alla Dekhtyar, Polina et Sonya pour leurs encouragementspatients et sans faille. Je suis ravi de ne plus avoir courter (ouplutt, essayer en vain dcourter) nos soires pour aller travaillersur Le Livre .

Merci Jack Repenning pour son amiti, sa conversation et son en-ttement refuser daccepter une analyse simple mais fausse quandune autre plus complexe mais juste existe. Jespre quune partie desa longue exprience dans le dveloppement et lindustrie du logiciela dteint sur ce livre.

CollabNet sest montr exceptionnellement gnreux en me per-

mettant dadapter mon agenda pour crire ce livre, sans se plaindrequand cela me prit plus de temps que prvu. Je ne connais pas tousles rouages dune telle dcision mais je suppose que Sandhya Klute,et par la suite Mahesh Murthy, y sont pour quelque chose. Je lesremercie tous les deux.

Toute lquipe de dveloppement Subversion a t une sourcedinspiration au cours de ces cinq dernires annes et cest auprsde ses membres que jai appris lessentiel de ce qui est expliqu dansce livre. Je ne les remercierai pas nominativement, car ils sont tropnombreux, mais jimplore chaque lecteur qui croise un committerde Subversion de lui offrir un verre. Cest ce que je compte fairemoi-mme.

Jai souvent pest auprs de Rachel Scollon propos de ltat de

ce livre. Elle a toujours t prte mcouter et, dune certainemanire, a russi faire paratre mes problmes moins graves quilsne ltaient avant nos conversations. Cela ma beaucoup aid, merci.

Merci (encore) Noel Taylor, qui a certainement d se demanderpourquoi je voulais crire un autre livre, sachant quel point jemtais plaint la fois prcdente, mais dont lamiti et la conduitemont aid prserver, dans mon existence, la musique et un cercle


15/353

``97612617'' --- 2011/1/2 --- 18:37 --- page xv --- #15

xv

fraternel, mme pendant les priodes les plus charges. Merci aussi Matthew Dean et Dorothea Samtleben, amis et compagnons mu-sicaux que jai longtemps fait souffrir et qui se sont montrs trscomprhensifs quand les excuses que je donnais pour ne pas rptersaccumulaient. Megan Jennings ma toujours soutenu et a montrun rel intrt pour le sujet malgr son inexprience dans le do-maine, un vrai nergisant pour un crivain qui doute. Merci monamie!

Jai eu quatre relecteurs comptents et persvrants pour ce livre :Yoav Shapira, Andrew Stellman, Davanum Srinivas et Ben Hyde. Sijavais pu ajouter toutes leurs excellentes suggestions, ce livre seraitencore meilleur. Des contraintes de temps mont forc faire deschoix mais les amliorations sont quand mme visibles. Toutes leserreurs qui subsistent sont entirement les miennes.

Mes parents, Frances et Henry, mont apport comme toujours unmagnifique soutien, et comme ce livre est moins technique que leprcdent, jespre quils le trouveront un peu plus lisible.

Pour finir, jaimerais remercier les ddicataires : Karen Underhillet Jim Blandy. Lamiti et la comprhension de Karen reprsententtout pour moi, non seulement pendant lcriture de ce livre maisaussi au cours des sept dernires annes. Je naurais simplement paspu finir sans son aide. De mme, Jim, vritable ami et matre hackerqui, le premier, ma fait dcouvrir les logiciels libres tel loiseauenseignant lavion comment voler.

Note

Les penses et opinions exprimes dans ce livre sont les miennes.Elles ne reprsentent pas ncessairement les ides de CollabNet nidu projet Subversion.


16/353

``97612617'' --- 2011/1/2 --- 18:37 --- page xvi --- #16


17/353

``97612617'' --- 2011/1/2 --- 18:37 --- page xvii --- #17

Table des matires

Avant-propos iii

Prface viii

1 Introduction 1

2 Bien dmarrer 192.1 Commencez avec ce que vous avez . . . . . . 222.2 Choisir une licence et lappliquer . . . . . . . 382.3 Donner le ton . . . . . . . . . . . . . . . . . . 412.4 Annoncer . . . . . . . . . . . . . . . . . . . . . 51

xvii


18/353


19/353

``97612617'' --- 2011/1/2 --- 18:37 --- page xix --- #19

Table des matires xix

8 Encadrer les volontaires 2358.1 Tirer le meilleur des volontaires . . . . . . . . 2378.2 Partager les tches . . . . . . . . . . . . . . . 2538.3 Transitions . . . . . . . . . . . . . . . . . . . 2628.4 Committers . . . . . . . . . . . . . . . . . . . 2668.5 Remerciements . . . . . . . . . . . . . . . . . 2718.6 Les fourches . . . . . . . . . . . . . . . . . . . 273

9 Licences, droits d'auteur et brevets 2799.1 Terminologie . . . . . . . . . . . . . . . . . . 280

9.2 Les aspects des licences . . . . . . . . . . . . 2849.3 La GPL et la compatibilit de licence . . . . . 2859.4 Le choix dune licence . . . . . . . . . . . . . 2879.5 Attribution des droits dauteur et proprit . 2939.6 La double licence . . . . . . . . . . . . . . . . 2969.7 Brevets . . . . . . . . . . . . . . . . . . . . . . 2989.8 Plus de rfrences . . . . . . . . . . . . . . . . 301

A Solutions libres de gestion de versions 303

B Systmes libres de suivi de bogues 309

C Pourquoi se soucier de la couleur de l'abri vlos 315

D Exemples d'instructions pour les rapports de bogues321

E Copyright 325


20/353

``97612617'' --- 2011/1/2 --- 18:37 --- page xx --- #20


21/353

``97612617'' --- 2011/1/2 --- 18:37 --- page 1 --- #21

Chapitre

1Introduction

La plupart des projets de logiciels libres chouent.

Nous avons tendance ne pas trop remarquer les checs. Seuls lessuccs attirent notre attention, et le nombre total 1 de projets de lo-giciels libres est si important que leur visibilit reste forte malgr untaux de russite relativement faible. De mme, nous nentendons pasparler des checs car linsuccs est un non-vnement. Le moment

prcis o un projet cesse dtre viable nexiste pas : les gens sencartent et finissent par labandonner. Il se peut qu un momentdonn un dernier changement soit apport au projet mais lauteur,

1. SourceForge.net est un site dhbergement populaire qui accueillait 79 225projets enregistrs la mi-avril 2004. On est bien sr trs loin de la quantittotale de projets de logiciels libres sur Internet : il sagit seulement ici de ceuxqui ont choisi dutiliser SourceForge.

1


22/353

``97612617'' --- 2011/1/2 --- 18:37 --- page 2 --- #22

2 Introduction

cet instant, ne sait pas quil sagit du dernier. Comment dterminerla mort dun projet ? Quand on ny a plus travaill activement de-puis six mois ? Quand le nombre de ses utilisateurs cesse de crotre,sans avoir dpass celui des dveloppeurs? Et que dire dun pro-jet abandonn parce que ses dveloppeurs, se rendant compte quilsreproduisaient un travail existant, se dcident rejoindre un autreprojet pour lamliorer en y intgrant une grande partie de leurs tra-vaux prcdents ? Le premier projet est-il mort ou a-t-il simplementchang dadresse?

En raison de cette complexit, il est impossible de dterminer pr-cisment le taux dchec. Mais le constat qui ressort de plus dunedcennie dans lOpen Source, de quelques participations Sour-ceForge.net et dun peu de googlage est le suivant : ce tauxest extrmement lev, probablement de lordre de 90% 95%. Illest encore plus si lon y inclut les projets survivants mais qui fonc-tionnent mal : certes ils produisent des applications utilisables, maisil est pnible dy travailler, ou bien il est impossible dy progressercomme on pourrait le souhaiter.

Lobjectif de cet ouvrage est dviter lchec. Il passe en revuenon seulement les bonnes pratiques, mais aussi les mauvaises, afinque chacun puisse dtecter et corriger les problmes rapidement.Mon plus grand souhait est quaprs sa lecture, on puisse disposerdun rpertoire de techniques pour, dune part, viter les piges les

plus courants du dveloppement Open Source, et dautre part, grerla croissance et la maintenance dun projet russi. Le succs nestpas un jeu somme nulle et il ne sagit pas ici de victoire ni dedomination de la concurrence. En ralit, une part importante dudveloppement dun projet Open Source consiste travailler sansheurt avec les autres projets apparents. long terme, chaque rus-site contribue au bien-tre du logiciel libre , dans son ensembleet partout dans le monde.

Il serait tentant de dire que les projets de logiciels libres et lesprojets caractre propritaire chouent pour les mmes raisons.Le libre na pas le monopole des agendas farfelus, des spcificationsfloues, de la mauvaise gestion des ressources humaines, des phasesde conception insuffisantes et autres nuisances bien connues de lin-

dustrie du logiciel. La somme dcrits traitant de ce sujet est djconsidrable, je ne mtendrai donc pas davantage. Jessaierai pluttde dcrire les problmes spcifiques au logiciel libre. Quand un projetscroule cest souvent parce que les dveloppeurs (ou les directeurs)nont pas su valuer les problmes propres au dveloppement dunlogiciel Open Source, alors mme quils taient rods aux difficultsmieux connues du dveloppement code ferm.


23/353

``97612617'' --- 2011/1/2 --- 18:37 --- page 3 --- #23

3

Mesurez vos attentes vis--vis de lOpen Source, ne tombez pasdans le pige dune trop grande ambition. Une licence ouverte nemet pas immdiatement des lgions de dveloppeurs au service devotre projet, et ouvrir le code dun projet en difficult nest pas unremde tous les maux. En fait, cest plutt le contraire : ouvrir unprojet peut ajouter une nouvelle srie de complications et cote pluscher court terme que le garder ferm. Ouvrir veut dire remanier lecode pour le rendre comprhensible par quelquun de compltementtranger au projet, mettre en place un espace Web de dveloppe-ment, des listes de diffusion et, souvent, crire pour la premire fois

la documentation. Tout ceci reprsente beaucoup de travail. Biensr, si des dveloppeurs intresss se prsentent, il faudra les int-grer, rpondre leurs questions, tout cela peut prendre un certaintemps avant que vous ne perceviez les bnfices de leur prsence.Comme la dit Jamie Zawinski en parlant des priodes troubles dudbut du projet Mozilla :

LOpen Source fonctionne, mais ce nest vrai-ment pas la panace. La morale de cette histoire cestquon ne peut pas prendre un projet moribond et letraiter la poudre de perlimpinpin Open Source pour que tout se mette marcher comme par magie.Le dveloppement logiciel cest difficile. Les solutionsne sont pas si simples. 1

Lsiner sur la prsentation et la cration de paquets en remet-tant cela plus tard, une fois le projet sur les rails, est une erreur.La prsentation et la cration de paquets comportent un nombreimportant de tches visant en faciliter lapproche. Pour rendrele projet accueillant aux nophytes, il faut crire la documentationdveloppeur et utilisateur, crer pour le projet un site Web infor-mant les curieux, automatiser autant que possible la compilationet linstallation du logiciel, etc. Beaucoup de programmeurs consi-drent malheureusement ce travail comme secondaire par rapportau code lui-mme. Et ceci pour plusieurs raisons. Premirement,cest leurs yeux une perte de temps car ils nen tirent pas direc-tement les bnfices contrairement aux personnes moins familiresavec le projet. Aprs tout, les gens qui dveloppent le projet nontpas vraiment besoin quon leur prpare des paquets. Ils savent djcomment installer, administrer et utiliser le logiciel quils ont crit.Deuximement, les comptences requises pour la prsentation et lacration de paquets sont souvent compltement diffrentes de celles

1. Voir Jamie Zawinski, Resignation and Postmortem , 1999. Article ac-cessible http ://www.jwz.org/gruntle/nomo.html.
http://-/?-


24/353

``97612617'' --- 2011/1/2 --- 18:37 --- page 4 --- #24

4 Introduction

ncessaires lcriture du code. Les gens ont tendance se concen-trer sur ce quils connaissent le mieux, mme sils peuvent rendreun meilleur service au projet en consacrant un peu de temps auxchoses qui leur conviennent moins. Le chapitre 2 examine en dtailles questions de prsentation et de cration de paquets. Il expliquepourquoi il est essentiel den faire une priorit ds le lancement duprojet.

Vient ensuite lide fausse que lOpen Source na gure besoin degestion de projet et quinversement les techniques de direction uti-lises pour les dveloppements en interne fonctionneront galementpour le projet Open Source. Le management dans un projet OpenSource nest pas toujours trs visible, mais dans les projets russisil est toujours prsent en coulisse dune manire ou dune autre.Inutile de pousser la rflexion trs loin pour sen rendre compte.Un projet Open Source consiste en un assemblage fortuit de pro-grammeurs, catgorie dj rpute pour son indpendance desprit,qui ne se sont trs probablement jamais rencontrs et qui peuventparticiper en ayant chacun des objectifs personnels diffrents. Il estfacile dimaginer ce que deviendrait un tel groupe sans manage-ment. moins dun miracle, il scroulerait ou claterait trs vite.Les choses ne vont pas marcher delles-mmes, que nous le voulionsou non. Mais le management, aussi actif soit-il, est le plus souventinformel, subtil et voil. La seule chose qui maintienne un groupe

de dveloppeurs ensemble est la croyance commune quils peuventfaire plus collectivement quindividuellement. Dans ce cadre, le ma-nagement a pour but principal de faire en sorte quils continuent le croire, en tablissant des formes de communication, en sassurantque des dveloppeurs utiles ne sont pas marginaliss en raisons decaractristiques personnelles et, de manire gnrale, en faisant ensorte que le projet reste un espace o les dveloppeurs ont envie derevenir. Les techniques spcifiques pour russir cela sont abordesdans le reste de louvrage.

Enfin, il y a une catgorie gnrique de problmes quon pour-rait appeler checs de navigation culturelle . Il y a dix ou mmecinq ans, il aurait t prmatur de parler dune culture mondialedu logiciel libre : plus maintenant. Une culture reconnaissable amerg lentement et bien quelle ne soit pas monolithique (elle estautant sujette la dissidence et aux factions que nimporte quelleculture gographiquement dfinie), elle est base sur un noyau fon-damentalement solide. La plupart des projets Open Source russisaffichent quelques-unes sinon toutes les caractristiques de ce noyau.Ils rcompensent certains types de comportements et en punissentdautres, ils crent une atmosphre qui encourage la participationnon planifie (parfois au dtriment de la coordination centralise),


25/353

``97612617'' --- 2011/1/2 --- 18:37 --- page 5 --- #25

5

ils possdent leur propre conception de la politesse et de la brutalitpouvant diffrer foncirement de celle qui prvaut par ailleurs. Et,chose primordiale, les participants de longue date ont gnralementintrioris ces critres au point dtre plus ou moins unanimes surles comportements attendus. Les projets qui chouent gnralementscartent de manire significative de ce noyau, mme involontaire-ment, et nont pas de dfinition commune du comportement raison-nable par dfaut. Ainsi, quand les problmes surgissent, la situationpeut se dtriorer rapidement, les participants ne disposant pas dunstock de rflexes culturels tablis auxquels recourir pour rsoudre les

diffrends.Cet ouvrage est un guide pratique et non une tude anthropolo-

gique ou historique. Cependant, une relle connaissance de la culturedu logiciel libre est une base essentielle pour profiter de tout conseilpratique. Une personne qui apprhende cette culture peut parcourir,en long et en large, le monde de lOpen Source, rencontrer maintesvariantes locales des coutumes et des dialectes, tout en tant capablede participer partout avec aisance et efficacit. En revanche, pourqui ne la comprend pas, le processus dorganisation ou de participa-tion un projet sera difficile et plein de surprises. Le nombre de per-sonnes qui dveloppent des logiciels libres ne cessant de crotre rapi-dement, cette dernire catgorie ne dsemplit pas. Cest en grandepartie une culture de nouveaux migrants, et a continuera ltre

pendant un certain temps. Si vous pensez tre lun deux, la sectionsuivante vous fournira larrire-plan des discussions que vous enten-drez plus tard, aussi bien dans ce livre que sur Internet (dautrepart, si vous travaillez dans le monde du libre depuis un moment,vous en savez peut-tre dj pas mal sur son histoire. Dans ce cas,nhsitez pas sauter la prochaine section).

Historique

Le partage des logiciels est aussi ancien que les logiciels eux-mmes. Aux premiers temps des ordinateurs, les fabricants, sentantque les bnfices conomiques se trouvaient principalement dans laproduction de matriel, ne prtrent gure attention aux logicielset leurs atouts financiers. Un grand nombre dacheteurs de ces pre-mires machines taient des scientifiques ou des techniciens capablesde modifier et damliorer eux-mmes les logiciels livrs avec les ma-chines. Parfois les clients distribuaient leurs correctifs non seulementaux fabricants, mais aussi aux propritaires de machines semblables.Les fabricants tolraient, voire encourageaient cette pratique : pour


26/353

``97612617'' --- 2011/1/2 --- 18:37 --- page 6 --- #26

6 Introduction

eux, lamlioration des logiciels, peu importe la source, rendait leursmachines plus attrayantes aux yeux dautres acheteurs potentiels.

Bien que cette priode ressemblt, sous de nombreux aspects, la culture des logiciels libres daujourdhui, elle en dviait sur deuxpoints importants. Premirement la standardisation du matriel n-tait pas vraiment lordre du jour. Ctait une poque dinnovationflorissante pour la fabrication dordinateurs, mais face la diversitdes architectures, la compatibilit ntait pas une priorit. Ainsi, leslogiciels crits pour une machine ne fonctionnaient pas, en gnral,sur une autre. Les programmeurs avaient tendance se spciali-ser dans une architecture ou dans une famille darchitectures (alorsquaujourdhui, ils auraient plutt tendance se spcialiser dansun langage de programmation, ou une famille de langages, sachantpertinemment que leur savoir sera transfrable sur nimporte quelsystme auquel ils se trouveraient confronts). Comme leur exper-tise tendait tre spcifique un type dordinateur, laccumulationdes savoirs avait pour effet de le rendre plus attractif leurs yeuxet ceux de leurs collgues. Ctait alors dans lintrt du construc-teur de voir les codes et connaissances spcifiques sa machine serpandre le plus possible.

Deuximement, Internet alors nexistait pas. Bien que les restric-tions lgales vis vis du partage fussent moins fortes quaujourdhui,elles taient plus nombreuses sur le plan technique. Les moyens pour

transporter les donnes dun endroit un autre taient peu pra-tiques et encombrants, compars aujourdhui. Il existait des petitsrseaux locaux, pratiques pour partager des informations entre em-ploys du mme laboratoire de recherche ou de la mme entreprise.Mais certaines barrires restaient surmonter si lon voulait par-tager avec le monde entier tout en saffranchissant des contraintesgographiques. Ces difficults ont t surmontes dans de nombreuxcas. Parfois des groupes entraient en contact les uns avec les autresindpendamment, en senvoyant des disquettes ou des cassettes parcourrier. Parfois les fabricants eux-mmes centralisaient les correc-tifs. Un point positif tait quune grande partie des premiers d-veloppeurs travaillaient au sein duniversits o la publication desconnaissances dune personne est attendue. Mais les ralits phy-siques de lchange de donnes entranaient un temps de latence,un retard proportionnel la distance (physique ou organisation-nelle) que le logiciel avait parcourir. Le partage souple et grandechelle, comme nous le connaissons aujourdhui, tait impossiblealors.


27/353

``97612617'' --- 2011/1/2 --- 18:37 --- page 7 --- #27

7

Lavnement des logiciels propritaires et des logicielslibres

mesure que lindustrie mrissait, plusieurs changements lis sesont produits. La jungle des normes matrielles a progressivementpermis lmergence de quelques laurats grce une meilleure tech-nologie, une meilleure stratgie voire la combinaison des deux. Enmme temps, et pas entirement par hasard, le dveloppement delangages de programmation dits de haut niveau signifiait que lonpouvait crire un programme une seule fois, dans un langage, et levoir automatiquement traduit (compil) afin de fonctionner sur dif-frents types dordinateurs. Les constructeurs de matriel nont pasmanqu den voir les implications : un client pouvait, ds ce moment,entreprendre un travail considrable dingnierie logicielle sans sen-chaner ncessairement une architecture particulire. Ceci, coupl une diminution des carts de performances entre les diffrents or-dinateurs (les conceptions les moins performantes tant vinces),faisait quun fabriquant qui misait tout sur le matriel pouvait sat-tendre voir baisser ses marges dans un futur proche. La puissancebrute des ordinateurs ntait plus suffisante pour crer un avantagedcisif, la concurrence sest alors dplace sur le terrain des logiciels.Vendre des logiciels, ou au moins leur donner la mme importancequau matriel, devenait la nouvelle stratgie gagnante.

Cela signifiait, pour les fabricants, faire respecter le droit dauteursur leur code de manire plus stricte. Si les utilisateurs continuaient partager et modifier le code de manire libre entre eux, ils pour-raient reproduire certaines des amliorations dsormais vendues entant que valeur ajoute par le fournisseur. Pire encore, le codepartag pourrait arriver entre les mains des concurrents. Lironie estque tout ceci se passait lpoque o Internet commenait pointerson nez. Alors mme que les obstacles tombaient, la mue du mar-ch des ordinateurs rendit le partage de logiciels conomiquementindsirable, au moins du point de vue de nimporte quelle entre-prise. Les fournisseurs ont renforc leurs positions, soit en refusantaux utilisateurs laccs au code faisant fonctionner leurs machines,soit en imposant des accords de confidentialit rendant tout partageimpossible.

Rsistance consciente

Alors que le monde du libre change de code saffaiblissait, lidedune riposte germait dans lesprit dau moins un programmeur : Ri-chard Stallman. Ce dernier travaillait au laboratoire dintelligenceartificielle au MIT (Massachusetts Institute of Technology) dans les


28/353

``97612617'' --- 2011/1/2 --- 18:37 --- page 8 --- #28

8 Introduction

annes 1970 et au dbut des annes 1980, durant une priode quisest rvle tre lge dor du partage de code 1. Le laboratoire avaitune forte thique de hacker 2 selon laquelle on ntait pas seule-ment encourag partager les amliorations apportes au systme,ctait ce qui tait attendu de soi. Comme Stallman crivit plustard :

Nous nappelions pas nos logiciels logicielslibres parce que ce terme nexistait pas, maiscest bien ce quils taient. Si des gens dune

autre universit ou dune entreprise voulaient uti-liser nos programmes, nous leur en donnions volon-tiers la permission. Si vous voyiez quelquun utili-ser un programme intressant que vous ne connais-siez pas, vous pouviez toujours lui en demander lecode source, pour pouvoir le lire, le modifier ou enemprunter une partie pour faire un nouveau pro-gramme. 3

Cette communaut utopique sest effondre autour de Stallmanpeu aprs 1980, quand le laboratoire a finalement t rattrap parles changements qui sopraient dans le reste de lindustrie. Unestart-up dbaucha de nombreux programmeurs du service pour d-velopper un systme dexploitation proche de celui sur lequel ils

travaillaient, mais dsormais sous licence exclusive. Au mme mo-ment, le laboratoire faisait lacquisition de nouveaux quipementslivrs avec un systme dexploitation propritaire.

Stallman voyait trs bien o cette tendance les conduisait :

Les ordinateurs modernes de cette poque,comme le VAX ou le 68020 avaient leur propre sys-tme dexploitation, mais ni lun ni lautre ntaitlibre, vous deviez signer un accord de confidentia-lit, mme pour en obtenir une copie fonctionnelle.

Ce qui signifiait que la premire dmarche fairepour utiliser un ordinateur tait de promettre de nepas aider son voisin. Une communaut cooprative

1. NdT : voir ce propos R. Stallman, S. Williams et C. Masutti, RichardStallman et la rvolution du logiciel libre. Une biographie autorise, Paris, Ey-rolles Framasoft, 2010 (http ://framabook.org/stallman.html).

2. Stallman utilise le mot hacker pour dsigner une personne qui aimeprogrammer et qui adore faire le malin avec a mais pas quelquun quisintroduit dans les ordinateurs comme le voudrait le nouveau sens.

3. Tir de Richard Stallman, The Gnu project (http ://www.gnu.org/gnu-/thegnuproject.html).
http://www.gnu.org/gnu/thegnuproject.htmlhttp://-/?-


29/353

``97612617'' --- 2011/1/2 --- 18:37 --- page 9 --- #29

9

tait proscrite. La rgle mise en place par les cra-teurs des logiciels propritaires tait : Si vous par-tagez avec votre voisin vous tes un pirate. Si vousdsirez des changements, suppliez nous de les fai-re.

Mais Stallman ntait pas un hacker comme les autres et sa person-nalit le poussa sopposer cette tendance. Plutt que de continuer travailler dans un laboratoire dcim ou de trouver un emploi deprogrammeur dans lune de ces nouvelles compagnies o les fruits

de son travail seraient enferms dans une bote, il a dmissionnpour lancer le projet GNU et la Free Software Foundation (FSF).Le but du projet GNU 1 tait de dvelopper un systme dexploi-tation pour ordinateur, compltement libre et ouvert, ainsi quunensemble dapplications logicielles dans lequel les utilisateurs ne se-raient jamais empchs dhacker ou de partager leurs modifications.Il entreprenait en fait de recrer ce qui avait t dtruit au labora-toire dintelligence artificielle mais lchelle mondiale et sans lespoints faibles lorigine de la destruction de lesprit du laboratoire.

En plus de travailler sur le nouveau systme dexploitation, Stall-man conut une licence dont les termes garantissent que son coderestera libre tout jamais. La GNU General Public License (GPL)est une pirouette lgale bien pense : elle dit que le code peut trecopi ou modifi sans restriction et que les copies ou le travail driv(cest--dire les versions modifies) doivent tre distribues sous lamme licence que loriginal, sans y ajouter de restrictions. En fait,elle utilise les lois du droit dauteur pour produire leffet oppos ducopyright traditionnel : plutt que de limiter la diffusion du logi-ciel, elle empche quiconque, mme lauteur, de la restreindre. PourStallman a valait mieux que de simplement placer son code dansle domaine public. En appartenant au domaine public, nimportequelle copie aurait pu tre incorpore dans un programme propri-taire (ce qui sest pass avec du code publi sous des licences troppermissives). Mme si cette incorporation ne diminue en rien la dis-ponibilit continue du code originel, elle aurait signifi que les effortsde Stallman auraient pu profiter lennemi : le logiciel propritaire.La GPL peut tre vue comme une forme de protection pour le logi-

ciel libre car elle empche les logiciels non-libres de profiter du codesous licence GPL. La GPL et ses relations avec dautres licences delogiciels libres sont prsentes en dtails dans le chapitre 9.

Avec laide de nombreux dveloppeurs, certains dentre eux parta-geant lidologie de Stallman et dautres voulant simplement voir un

1. GNU est lacronyme de GNU is Not Unix et GNU dans cetteextension signifie la mme chose (NdT : il sagit dun acronyme rcursif).


30/353

``97612617'' --- 2011/1/2 --- 18:37 --- page 10 --- #30

10 Introduction

maximum de code libre disponible, le projet GNU commena pro-duire des quivalents libres pour beaucoup dlments importantsdun systme dexploitation. Grce la standardisation du mat-riel informatique et des logiciels, il tait devenu possible dutiliserles quivalents GNU sur des systmes non-libres, et beaucoup lontfait. Lditeur de texte GNU (Emacs) et le compilateur C (GCC)en particulier ont rencontr un succs important, rassemblant, nonpour lidologie quils vhiculaient mais simplement pour leurs m-rites techniques, une grande communaut dutilisateurs loyaux. lore de 1990, GNU avait produit lessentiel dun systme dexploi-tation libre lexception du noyau (la partie sur laquelle dmarrela machine et qui est en charge de la gestion de la mmoire, desdisques et des autres ressources systmes).

Malheureusement le projet GNU avait fait le choix dune concep-tion de noyau qui sest rvle plus difficile mettre en uvre queprvu. Le retard qui sensuivit empcha la Free Software Founda-tion de sortir le premier systme dexploitation libre. La dernirepice a finalement t mise en place par Linus Torvalds, un tudianten informatique finlandais qui, avec laide de volontaires du mondeentier, avait compil un noyau libre de conception plus classique.Il le nomma Linux, lequel, une fois combin aux programmes GNUexistants, donna un systme dexploitation entirement libre. Pourla premire fois vous pouviez allumer votre ordinateur et travailler

sans utiliser un seul logiciel propritaire1

.La plupart des logiciels de ce nouveau systme dexploitation n-

taient pas produits par le projet GNU. En fait, GNU ntait mmepas le seul groupe travaillant llaboration dun systme dexploi-tation libre (par exemple, le code qui deviendra NetBSD et FreeBSDtait dj en dveloppement cette poque). Mais limportance dela Free Software Foundation ntait pas seulement dans le code critpar ses membres : il sagissait aussi dun discours idologique. Enmettant en avant le logiciel libre comme une cause part entire,plutt quune commodit, ils lui ont donn une dimension politiquedifficile ignorer par les programmeurs. Mme ceux en dsaccordavec la FSF ont d prendre en compte cette question, parfois pourrevendiquer une position diffrente. Lefficacit du message de laFSF tient au fait quil est li au code, grce la GPL et dautres

1. Techniquement, Linux ntait pas le premier. Un systme dexploitationlibre pour les ordinateurs compatibles IBM, appel 386BSD, est sorti peu avantLinux. Cependant, il tait bien plus compliqu de faire marcher 386BSD. Linuxa cr des remous non seulement parce quil tait libre mais aussi parce quilavait vraiment une bonne chance de faire marcher lordinateur sur lequel vouslaviez install.


31/353

``97612617'' --- 2011/1/2 --- 18:37 --- page 11 --- #31

11

textes. Alors que le code se rpand partout, le message se diffusegalement.

Rsistance accidentelle

Bien que le champ naissant du logiciel libre ait t trs dyna-mique, peu dactivits furent aussi clairement idologiques que leprojet GNU de Stallman. Lun des plus importants tait le projetBerkeley Software Distribution (BSD), une r-implmentation gra-duelle du systme dexploitation Unix (qui jusqu la fin des annes1970 fut un projet de recherche vaguement propritaire chez AT&T)par des programmeurs de lUniversit de Californie de Berkeley. Legroupe BSD ne prit pas ouvertement position sur la ncessit desprogrammeurs de sunir et de partager, mais ils mirent en pratiquecette ide avec style et enthousiasme en coordonnant un gros effortde dveloppement coopratif grce auquel les lignes de commandedes utilitaires Unix, les librairies de code et finalement le noyau dusystme dexploitation lui-mme furent r-crits entirement, princi-palement par des volontaires. Le projet BSD devint un exemple im-portant de dveloppement non-idologique de logiciel libre et servitgalement de terrain dentranement de nombreux dveloppeursqui continueront par la suite tre actifs dans le monde de lOpenSource.

Un autre nid de dveloppement coopratif fut le systme X Win-dow, un environnement graphique, libre et transparent au rseau,dvelopp au MIT au milieu des annes 1980 en partenariat avec desvendeurs de matriel ayant un intrt commun pouvoir proposer leurs clients un systme graphique. Loin de sopposer aux logicielspropritaires, la licence X permettait dlibrment lajout dexten-sions propritaires au cur libre du systme, chaque membre duconsortium souhaitant pouvoir amliorer la distribution X de baseet, par ce moyen, obtenir un avantage concurrentiel sur les autres.X Window 1 en lui mme tait un logiciel libre, mais essentiellementpar volont de placer les concurrents sur un mme pied dgalit,et non pas comme un dsir quelconque de mettre un terme l-hgmonie des logiciels propritaires. Devanant le projet GNU dequelques annes, TeX, le systme libre de traitement de texte de Do-

nald Knuth permettant la cration de documents de grande qualit,en est un autre exemple. Il fut publi sous une licence permettant quiconque de modifier et de distribuer le code mais qui interdisaitde nommer le rsultat TeX sil navait pas pass une srie detests de compatibilit stricts (cest l un exemple de licence libre

1. Ils prfrent quil soit appel le Systme X Window , mais en pratiqueon lappelle X Window parce que les trois mots sont trop encombrants.


32/353

``97612617'' --- 2011/1/2 --- 18:37 --- page 12 --- #32

12 Introduction

de protection de marque dpose que nous approfondirons dansle chapitre 9). Knuth nexprimait aucun avis, dune faon ou duneautre, sur la question de lopposition des logiciels libres aux logi-ciels propritaires : il cherchait simplement un meilleur traitementde texte pour achever son vritable but, un livre sur la programma-tion informatique, et ne voyait aucune raison de ne pas offrir sonsystme au monde une fois celui-ci prt.

Sans faire une liste de tous les projets et de toutes les licences,on peut dire qu la fin des annes 1980, il existait de nombreuxlogiciels disponibles sous une grande varit de licences. La diver-sit des licences refltait une diversit quivalente des motivations.Mme certains des programmeurs choisissant la GNU GPL ntaientpas aussi dtermins idologiquement que le projet GNU lui-mme.Et sils apprciaient de travailler sur des logiciels libres, nombredentre eux ne considraient pas les logiciels propritaires commeun mal social. Quelques uns ressentaient un besoin moral de dbar-rasser le monde des logiciels panneaux daffichage (appellationde Stallman pour les logiciels propritaires), mais dautres taientplutt motivs par lmulation technique ou le plaisir de travailleravec des collaborateurs partageant leurs ides, voire par le simpledsir humain de gloire. Pourtant, ces diverses motivations nintera-gissaient pas gnralement de manire destructive. Cest en partied au fait que les logiciels, contrairement dautres uvres cra-

tives comme la prose ou les arts visuels, doivent russir des testssemi-objectifs pour tre considrs comme des succs : ils doiventfonctionner et ne pas comporter trop de bogues. Cela donne auxparticipants du projet une base commune, une raison et un cadrepour travailler ensemble sans se proccuper des qualifications autresque techniques.

Les dveloppeurs avaient une autre raison de rester unis : il sestavr que le code produit par le monde des logiciels libres taitde trs bonne qualit. Dans certains cas, ces programmes taientdun point de vue technique nettement suprieurs leurs quivalentsnon-libres, dans dautres cas ils taient au moins comparables, etbien sr, toujours meilleur march. Alors que seulement quelquespersonnes auraient pu tre motives pour produire des logiciels libressur des bases strictement philosophiques, beaucoup ltaient du fait

des meilleurs rsultats obtenus. De plus, il y avait toujours un certainpourcentage dutilisateurs prts donner de leur temps et de leurscomptences afin daider maintenir et amliorer le logiciel.

Cette tendance produire du bon code ntait certainement pasuniverselle, mais cela se renouvelait une frquence croissante dansles projets de logiciels libres du monde entier. Les entreprises tri-butaires de logiciels commencrent progressivement le remarquer.


33/353

``97612617'' --- 2011/1/2 --- 18:37 --- page 13 --- #33

13

Beaucoup dentre elles dcouvrirent quelles utilisaient dj, sans lesavoir, des logiciels libres pour leurs oprations quotidiennes (les di-rigeants ne sont pas toujours au courant des choix de leur service in-formatique). Les socits entreprirent de simpliquer davantage dansles projets de logiciels libres en mettant disposition du temps etdes quipements, voire mme en finanant le dveloppement. De telsinvestissements pouvaient, dans les meilleurs scnarios, se montrertrs lucratifs par un coefficient de retour consquent. Le comman-ditaire ne paie quun nombre rduit de programmeurs experts pourse consacrer plein temps au projet, mais rcolte les fruits de la

collaboration de chacun, y compris du travail des bnvoles et desdveloppeurs pays par dautres socits.

Libre contre Open Source

Alors que le monde de lentreprise prtait de plus en plus attentionaux logiciels libres, les programmeurs se trouvrent confronts denouveaux problmes de reprsentation. Lun dentre eux tait le mot free lui-mme. Entendant pour la premire fois free software ,nombre de personnes pensaient, tort, que cela signifiait logicielgratuit . Sil est vrai que tous les logiciels libres ne cotent rien 1,tous les logiciels gratuits ne sont pas libres. Par exemple, durant la

bataille des navigateurs dans les annes 90 et dans la course auxparts de march quils se livraient, Netscape et Microsoft offraientleurs navigateurs Web gratuitement. Aucun des deux ntait libredans le sens des logiciels libres . Vous ne pouviez pas obtenirle code source et, mme si vous y parveniez, vous naviez pas ledroit de le modifier ni de le redistribuer 2. Vous pouviez tout justetlcharger un excutable et le lancer. Les navigateurs ntaient pasplus libres que les logiciels sous film plastique achets en magasin :tout au plus taient-ils diffuss prix infrieur.

La confusion sur le mot free est entirement due lambi-valence malheureuse du terme en anglais. La plupart des autreslangues font une distinction entre la notion de prix et de libert (ladiffrence entre gratuit et libre est vidente dans une langue romanepar exemple). Mais langlais tant de facto la langue dchange sur

1. On peut faire payer quelque chose en change de copies dun logiciel libre,mais comme on ne peut pas empcher lacheteur de le redistribuer gratuitement,le prix tend immdiatement vers zro.

2. Finalement, le code source de Netscape Navigator a t publi sousune licence libre, en 1998, et devint la base du navigateur Web Firefox. Voirhttp ://www.mozilla.org.
http://www.mozilla.org/


34/353

``97612617'' --- 2011/1/2 --- 18:37 --- page 14 --- #34

14 Introduction

Internet, le problme spcifique cette langue concerne, un cer-tain degr, tout le monde. Lincomprhension lie au mot free taittelle que les programmeurs de logiciels libres ont fini par crer uneformule en rponse : Cest free (libre) comme dans freedom (li-bert), pensez free speech(libert de parole), pas free beer (biregratuite) . Reste que devoir lexpliquer sans cesse est fatigant. Denombreux programmeurs ressentaient, juste titre, que lambigutdu mot free rendait plus difficile la comprhension par le public dece type de logiciels.

Cependant, le problme apparaissait plus profond que cela. Lemot libre tait vecteur dune connotation morale indniable : sila libert tait une fin en soi, peu importait que les logiciels libressoient galement meilleurs ou plus profitables certaines socitsdans certaines circonstances. Ce ntaient l que les effets secon-daires bienvenus dune motivation qui, au fond, ntait ni techniqueni commerciale mais morale. En outre, lide de Libre comme danslibert imposait une flagrante contradiction aux socits souhai-tant soutenir certains logiciels libres dans un domaine particulier deleurs activits, mais voulant continuer commercialiser des logicielspropritaires dans dautres branches.

Ces dilemmes touchrent une communaut dj promise unecrise didentit. Les programmeurs qui crivent des logiciels libresnont jamais russi se mettre daccord sur le but final, sil existe,

du mouvement des logiciels libres. Mme dire que les opinions vontdun extrme lautre serait trompeur, car cela implique une visionlinaire au lieu de la dispersion multidimensionnelle existante. Ce-pendant, on peut dfinir deux grands courants de pense, si vous ac-ceptez de passer outre les dtails pour le moment. Lun des groupespartage la pense de Stallman que la libert de partager et modifierest la plus importante, et quen consquence, si vous cessez de parlerde libert, vous abandonnez lide principale. Pour dautres, cest lelogiciel qui compte et ils ne se voient pas dire que les logiciels pro-pritaires sont par dfinition mauvais. Certains programmeurs delogiciels libres, mais pas tous, pensent que lauteur (ou lemployeurdans le cas de travail rmunr) devrait avoir le droit de contrlerles termes de la distribution et quaucun jugement moral ne devraitt rattach au choix de termes particuliers.

Pendant longtemps personne na vraiment eu prter attention ces diffrences ou leurs interfrences, mais le succs grandissantdes logiciels libres dans le monde de lentreprise a rendu cette ques-tion invitable. En 1998, le terme Open Source a t invent, entant qualternative libre , par une coalition de programmeurs


35/353

``97612617'' --- 2011/1/2 --- 18:37 --- page 15 --- #35

15

devenue par la suite The Open Source Initiative (OSI 1). Pour lOSInon seulement le terme logiciel libre tait droutant, mais le mot libre ntait que le symptme dun problme plus gnral : lemouvement avait besoin dune stratgie de commercialisation poursadapter au monde de lentreprise, et les discours sur les avantagesmoraux et sociaux du partage ne pntreraient pas les conseils dad-ministration des entreprises. Selon eux :

LOpen Source Initiative est un programme decommercialisation des logiciels libres. Cest un ar-

gumentaire en faveur des logiciels libres qui sap-puie sur une solide base pragmatique plutt que surune idologie dvote. La substance gagnante na paschang, lattitude et le symbolisme perdants, eux, ontchangs.

Le point qui doit tre expos la plupart des tech-niciens nest pas le concept de lOpen Source, mais lenom. Pourquoi ne pas lappeler, comme nous lavonstoujours fait, logiciel libre ?

Une raison simple est que le terme logiciel li-bre peut facilement prter confusion et mener auconflit.

Mais la vraie motivation de ce changement denom est conomique. Nous essayons maintenant de

vendre notre concept au monde de lentreprise. Nousavons un produit comptitif, mais notre positionne-ment, dans le pass, tait trs mauvais. Le termelogiciel libre na pas t compris correctement parles hommes daffaires qui ont pris le dsir de partagepour de lanti-capitalisme, ou pire encore, pour duvol.

Les dcideurs des principales grandes entreprisesnachteront jamais un logiciel libre. Mais si nousprenons les mmes ides, les mmes licences de lo-giciel libre et que lon remplace le nom par OpenSource ? Alors ils achteront. Certains hackers ontdu mal y croire, mais cest parce que ce sont destechniciens qui pensent aux choses concrtes, pal-pables et qui ne comprennent pas limportance delimage quand vous vendez quelque chose.

Dans le monde des affaires, lapparence est uneralit. Lapparence que nous voulons abattre lesbarricades et travailler avec le monde des affaires

1. La page Web de lOSI est : http ://www.opensource.org.
http://www.opensource.org/


36/353

``97612617'' --- 2011/1/2 --- 18:37 --- page 16 --- #36

16 Introduction

compte au moins autant que la ralit de notre com-portement, nos convictions et nos logiciels. 1

La pointe de liceberg de la polmique apparat dans ce texte.Il mentionne nos convictions mais vite intelligemment de ci-ter prcisment quelles sont ces convictions. Pour certains, a peuttre la conviction que le code dvelopp selon un processus ouvertsera meilleur, pour dautres a peut-tre la conviction que toutes lesinformations devraient tre partages. Lusage du mot vol fait(srement) rfrence la copie illgale, dont beaucoup se dfendent :

ce nest pas un vol si personne nest dpossd de son bien. On re-trouve aussi le raccourci facile, mais injuste, entre logiciels libres etanti-capitalisme, sans dbattre du bien fond de cette accusation.

Rien de tout cela ne signifie que le site de lOSI est incompletou trompeur. Il ne lest pas. Au contraire, cest la vitrine de cequi manquait au mouvement du logiciel libre daprs lOSI : unebonne stratgie commerciale o bon veut dire : viable dans lemonde des affaires . LOpen Source Initiative a offert beaucoupde gens exactement ce quils cherchaient : un vocabulaire pour parlerdes logiciels libres avec un plan de dveloppement et une stratgiecommerciale, plutt quune croisade idologique.

Lapparition de lOpen Source Initiative a transform lhorizon deslogiciels libres. Elle a reconnu une dichotomie longtemps inavoue

et, par l mme, a forc le mouvement reconnatre quil avait au-tant une politique interne quexterne. On voit aujourdhui que lesdeux groupes ont d trouver un terrain dentente puisque la plupartdes projets font participer des programmeurs des deux camps aussibien que dautres nentrant pas clairement dans lune ou lautre descatgories. Cela ne veut pas dire que les gens ne parlent jamaisde motivations idologiques ; on fait parfois rfrence aux manque-ments la morale de hacker traditionnelle par exemple. Maisil est rare de voir un dveloppeur de lun des deux mondes douterouvertement des motivations profondes de ses collgues. La contri-bution transcende le participant. Si quelquun produit du bon code,personne ne lui demande sil le fait pour des raisons morales, ouparce que son employeur le paie pour cela, ou parce quil toffe sonCurriculum Vitae ou quoi que ce soit dautre. Lvaluation et les cri-

tiques de la contribution se font sur des critres techniques. Mmedes organisations ouvertement politiques comme le projet Debiandont le but est doffrir un environnement 100% libre (cest--dire libre comme dans libert ) sont plutt ouvertes lintgration

1. Daprs le site http ://www.opensource.org/. Ou plutt une de ses versionsanciennes lOSI a apparemment t ces pages depuis lors, bien quelles soienttoujours visibles sur http ://web.archive.org/.
http://-/?-http://www.opensource.org/


37/353

``97612617'' --- 2011/1/2 --- 18:37 --- page 17 --- #37

17

de code non-libre et la coopration avec des programmeurs qui nepartagent pas exactement les mmes buts.

La situation actuelle

Quand vous dirigez un projet de logiciel libre, vous navez pas be-soin de discuter de lourds problmes philosophiques tous les jours.Les programmeurs nont pas cur de convertir les autres par-ticipants leurs opinions diverses (ceux qui le font se retrouvent

rapidement incapables de travailler sur un projet). Mais vous de-vez savoir que la question libre contre Open Source existe,au moins pour viter de dire des choses inamicales certains desparticipants, mais aussi parce que comprendre les motivations desdveloppeurs est la meilleure manire, la seule manire en un certainsens, de diriger un projet.

Le logiciel libre est une culture par choix. Pour y naviguer avecsuccs, vous devez comprendre pourquoi les gens ont fait le choix dyparticiper en premier lieu. Les manires coercitives ne fonctionnentpas. Si les gens ne sont pas heureux au cur dun projet, ils vontsimplement sen carter pour en rejoindre un autre. Le logiciel libreest remarquable, mme au sein des communauts de volontaires,par la lgret de linvestissement. La plupart des gens engags

nont jamais vraiment rencontrs dautres participants face face,et donnent simplement un peu de leur temps quand ils en ressententlenvie. Les moyens usuels, par lesquels les humains tablissent desliens entre eux et forment des groupes qui durent, sont restreints leur plus simple expression : des mots crits transmis par des filslectriques. cause de cela, la formation dun groupe soud et d-vou peut prendre du temps. Inversement, un projet peut facilementperdre un volontaire potentiel dans les cinq premires minutes deprsentation. Si un projet ne fait pas bonne impression, les nouveauxvenus lui donnent rarement une seconde chance.

La brivet, ou plutt la brivet potentielle, des relations estpeut-tre lobstacle le plus intimidant au commencement dun nou-veau projet. Quest ce qui persuadera tous ces gens de rester groupssuffisamment longtemps pour produire quelque chose dutile? La r-

ponse cette question est suffisamment complexe pour tre le sujetdu reste de ce livre, mais si elle devait tre exprime en une seulephrase, ce serait :

Les gens doivent sentir que leur relation unprojet, et leur influence sur celui-ci, est directementproportionnelle leurs contributions.


38/353

``97612617'' --- 2011/1/2 --- 18:37 --- page 18 --- #38

18 Introduction

Aucune catgorie de dveloppeurs, ou de dveloppeurs potentiels,ne devrait se sentir mise lcart ou tre discrimine pour des rai-sons non-techniques. Les projets ports par une socit et/ou desdveloppeurs salaris doivent y faire particulirement attention, lechapitre 5 aborde ce sujet plus en dtail. Bien sr, cela ne veut pasdire que, si vous ne bnficiez pas du financement dune socit,vous navez vous soucier de rien. Largent nest que lun des nom-breux facteurs pouvant influencer le succs dun projet. Il y a aussiles questions de choix du langage, de la licence, du processus de d-veloppement, du type prcis dinfrastructure mettre en place, de

la manire efficace de rendre publique la base du projet et bien plusencore. Commencer un projet du bon pied est le sujet du prochainchapitre.


39/353

``97612617'' --- 2011/1/2 --- 18:37 --- page 19 --- #39

Chapitre

2Bien dmarrer

Eric Raymond, dans un article maintenant clbre sur les proces-sus Open Source intitul La Cathdrale et le Bazaar 1 dcritles tapes classiques du lancement dun projet de logiciel libre. Il ycrit :

Tout bon logiciel commence par gratter un dve-loppeur l o a le dmange.

Remarquez que Raymond ne dit pas que les projets Open Sourcedmarrent seulement quand quelques individus ont une dmangeai-son. Il dit plutt que tout bonlogiciel est dabord la rponse quap-porte un programmeur un problme qui lirrite personnellement.

1. http ://catb.org/esr/writings/homesteading/

19
http://catb.org/esr/writings/homesteading/


40/353

``97612617'' --- 2011/1/2 --- 18:37 --- page 20 --- #40

20 Bien dmarrer

Cest exactement ce qui se passe dans le monde du logiciel libre : lesbesoins personnels sont les motivations les plus frquentes pour com-mencer un projet. Cest aujourdhui encore la motivation de base dela plupart des projets libres, mais moins quen 1997 quand Raymondcrivait ces lignes. Aujourdhui nous voyons des entreprises, y com-pris but tout fait lucratif, qui lancent de vastes projets OpenSource gestion centralise en partant de zro. Le programmeurisol, crivant des bouts de code pour rsoudre un problme localprcis et qui se rend compte que le rsultat obtenu peut tre large-ment tendu, est encore la base de nombreux nouveaux logiciels

libres, mais dautres modles ont merg.Lide de Raymond demeure trs pertinente. Il faut que les cra-

teurs du programme aient un rel intrt le voir aboutir car ilslutilisent eux-mmes : cest une condition essentielle. Si le logicielne fait pas ce quil est cens faire, la personne ou lorganisation com-manditaire ne seront pas satisfaites dans leur travail au quotidien.Prenons lexemple du projet OpenAdapter 1, lanc par la banquedinvestissement Dresdner Kleinwort Wasserstein. Il sagit dune in-frastructure Open Source pour lintgration de systmes dinforma-tions financires disparates : on peut difficilement dire que ce projetrponde au besoin particulier dun quelconque dveloppeur maisplutt celui dune institution. Mais cest bien la rponse concrte une insatisfaction de linstitution et de ses partenaires. En cons-

quence, si le programme faillit sa mission, ils le sauront. Cetteconfiguration produit de bons logiciels parce que la boucle de rtro-action est efficace. Le programme nest pas crit pour tre vendu un client quelconque afin quil puisse rsoudre son problme. Cestnous qui lcrivons pour rsoudre notre propre problme et pour par-tager ensuite la solution avec tous, un peu comme si le problme taitune maladie et le logiciel le mdicament dont la diffusion pourraitradiquer lpidmie.

Ce chapitre traite de llaboration et de la publication dun nou-veau projet de logiciel libre, mais de nombreuses recommandationssembleraient familires aux organisations mdicales qui diffusent desmdicaments. Les buts paraissent trs similaires : vous voulez expli-quer de manire simple ce que le mdicament fait, le mettre entreles mains des personnes concernes et vous assurer que ceux qui lereoivent savent bien lutiliser ; dans le cas des logiciels, vous voulezaussi inciter certains destinataires rejoindre la recherche en courspour amliorer le mdicament.

La distribution du logiciel libre comporte deux facettes : elle doittrouver des utilisateurs dune part et des dveloppeurs de lautre.

1. https ://www.openadapter.org/
https://www.openadapter.org/


41/353

``97612617'' --- 2011/1/2 --- 18:37 --- page 21 --- #41

21

Ces deux besoins ne sont pas forcment antagonistes mme silsrendent la prsentation initiale du projet plus complique. Certainesinformations sont utiles aux deux publics, dautres le sont unique-ment lun ou lautre. Les deux types dinformations devraientrpondre au principe de prsentation adapte, ce qui signifie que ledegr de dtail prsent chacun devrait correspondre directement la somme de temps et defforts consentis par le lecteur. Un effortplus important devrait toujours tre rcompens sa juste valeur.Quand le retour sur investissement nest pas satisfaisant, les genspeuvent rapidement perdre la foi et arrter de sinvestir.

Le corollaire en est que les apparences comptent vraiment. Les pro-grammeurs, en particulier, sont souvent sceptiques ce sujet. Leuramour pour le fond plutt que pour la forme est presque une sourcede fiert professionnelle. Ce nest pas un hasard si tant de program-meurs montrent de lantipathie envers le marketing et les relationspubliques, ou si les graphistes de mtier sont souvent horrifis parce que les dveloppeurs peuvent produire.

Cest dommage car il existe des situations la prsentation dunprojet en est une o la forme fait partie du tout. Par exemple,lune des premires choses que retient un visiteur propos dunprojet est laspect de son site Web. Cette information est absorbeavant que le vrai contenu du site ne soit compris, avant que le textene soit lu ou que le visiteur ne clique sur les liens. Mme si cela peut

tre injuste, les gens ne peuvent sempcher de se forger une premireimpression. Lapparence du site montre lapplication apporte laprsentation du projet. Les humains ont des antennes trs sensiblespour dtecter le souci du dtail. La plupart dentre nous peuventdire en un coup dil si un site Web a t assembl la va-vite ousil a t mrement rflchi. Cest la premire information que votreprojet montre et limpression quelle cre psera, par association,sur le reste du projet.

En consquence, alors que ce chapitre du livre porte sur le contenu la base de votre projet, souvenez-vous que son apparence comptegalement. tant donn que le site Web sadresse deux types devisiteurs, les utilisateurs et les dveloppeurs, une attention particu-lire doit tre apporte sa clart et sa concision. Bien que a ne

soit pas le meilleur endroit pour traiter de la conception dune pageWeb, un principe est suffisamment important pour tre mentionnici, particulirement quand le site sadresse plusieurs publics (quipeuvent se confondre) : les gens devraient avoir une vague ide dela direction dun lien avant de cliquer dessus. Par exemple, il de-vrait tre vident que les liens vers la documentation utilisateur nerenvoient pas la documentation dveloppeur. Diriger un projet


42/353

``97612617'' --- 2011/1/2 --- 18:37 --- page 22 --- #42

22 Bien dmarrer

consiste la fois fournir des informations mais aussi rassurer.La simple prsence de certaines offres standard, lendroit attendu,rassure les utilisateurs et les dveloppeurs qui dcident sils vont ounon simpliquer. Cela montre que le projet a une ligne de conduitedfinie, quil a anticip les questions des visiteurs, et quil a faitleffort dy rpondre de manire simple. Quand le projet tmoignedune prparation soigne, cest comme sil envoyait un message : Vous nallez pas perdre votre temps en nous rejoignant , ce quiest exactement ce que les gens veulent entendre.

Regardez dabord autour de vous

Avant de commencer un projet Open Source, faites bien attention :

Regardez toujours autour de vous afin de savoir sil nexiste pasdj un projet correspondant ce que vous souhaitez. Il y a debonnes chances que, quel que soit le problme rsoudre, quelquunait dj pris linitiative avant vous. Si le problme a t rsolu etson code rendu public, sous une licence libre, vous navez aucuneraison de rinventer la roue. Il y a bien sr des exceptions : si vousvoulez dbuter un projet des fins dexprience pdagogique, uncode pr-existant ne vous aidera pas, ou encore : le projet que vousavez en tte est si spcialis que vous savez quil y a peu de chance

quun autre lait dj fait. Il ny a, en gnral, aucune raison dene pas effectuer de recherche, le gain peut tre norme. Si les mo-teurs de recherche sur Internet ne retournent aucune rponse, tentezvotre chance sur freshmeat.net 1 (un site rassemblant les nouvelles propos de projets Open Source dont je parlerai plus longuementpar la suite), sur sourceforge.net 2 et dans le rpertoire des logicielslibres 3 de la Free Software Foundation. Mme si vous ne trouvezpas exactement votre bonheur, vous pourriez dcouvrir un projetsen approchant suffisamment pour quil soit plus logique dy ajou-ter une fonctionnalit en le rejoignant que de commencer partirde rien et par vous-mme.

2.1 Commencez avec ce que vous avez

Vous avez cherch mais navez rien trouv correspondant votrebesoin, vous tes donc dcid commencer un nouveau projet.

1. http ://freshmeat.net/2. http ://www.sourceforge.net/3. http ://directory.fsf.org/
http://directory.fsf.org/http://directory.fsf.org/http://www.sourceforge.net/http://freshmeat.net/


43/353

``97612617'' --- 2011/1/2 --- 18:37 --- page 23 --- #43

2.1 Commencez avec ce que vous avez 23

Que faire maintenant?

La partie la plus difficile du lancement dun projet de logiciel libreest la transposition dune vision personnelle en une vision publique.Vous, ou votre organisation, savez parfaitement ce que vous voulez,mais expliquer ce but de manire comprhensible au monde entierreprsente un travail important. Il est essentiel cependant de prendrele temps de le faire. Vous et les autres membres fondateurs devezdcider dune dfinition prcise du projet (cest--dire, dcider de seslimites, de ce quil ne ralisera pas aussi bien que de ce quil fera) etcrire une dclaration dobjectif (ou mission). Cette partie nest, engnral, pas trop complique bien quelle puisse rvler des non-ditset mme des dsaccords propos de la nature du projet, ce qui estune bonne chose : mieux vaut rsoudre ces problmes maintenantque plus tard. Ltape suivante est de prparer la prsentation duprojet au public ; une vritable corve.

Ce qui rend cette tape si laborieuse est quil sagit ici principa-lement dorganiser et de documenter des choses que tout le mondeconnat dj, tout le monde signifiant ici ceux qui ont dj timpliqus dans un projet. Par consquent, pour les gens soccupantde cette tche, il ny a pas de gain immdiat. Ils nont pas besoin defichier Lisez moi dcrivant le projet, ni des fiches techniques oude la documentation utilisateur. Ils nont pas besoin dune arbores-cence du code tablie avec attention selon des standards officieux

mais largement utiliss pour la distribution du code de logiciels. Peuimporte comment le code source est organis, ils sy retrouveront,ils y sont dj habitus, et si le code fonctionne, ils savent lutiliser.Peu importe aussi pour eux si les bases architecturales du projetrestent non documentes, ils en sont dj familiers.

Les nouveaux arrivants, dun autre ct, ont besoin de ces in-formations. Heureusement, ils nont pas besoin de tout, tout desuite. Il nest pas ncessaire de donner accs toutes les sourcespossibles avant de rendre le projet public. Dans un monde parfait,peut-tre, chaque nouveau projet Open Source commencerait avecun modle de document exhaustif, un manuel utilisateur complet(avec des avertissements pour les fonctionnalits prvues mais pasencore implmentes), un beau code bien assembl et portable, ca-

pable de fonctionner sur nimporte quelle plateforme, etc. En ralit,soccuper de tous ces dtails prendrait un temps considrable et se-rait rdhibitoire : de toute faon, cest un travail pour lequel on peutesprer recevoir de laide des volontaires une fois le projet sur lesrails.

Il est ncessaire cependant de sinvestir suffisamment dans la pr-sentation afin que les dbutants puissent surmonter les premiers


44/353

``97612617'' --- 2011/1/2 --- 18:37 --- page 24 --- #44

24 Bien dmarrer

obstacles dus leur manque dhabitude. Il faut le voir comme lepremier pas pour lancer le projet du bon pied en lui apportant unesorte dnergie dactivation minimale. Certains appellent ce seuillnergie dhacktivation: lnergie quun dbutant doit fournir avantde recevoir quelque chose en retour. Plus le niveau requis dnergiedhacktivation est bas, mieux a vaut. Votre premire tche seradabaisser cette nergie dhacktivation un niveau encourageant lesgens sengager.

Chacune des sections suivantes dcrit un aspect important ducommencement dun nouveau projet. Elles sont plus ou moins pr-sentes dans lordre dapparition pour un nouveau visiteur, mmesi, bien sr, votre ordonnancement peut tre diffrent. Vous pouvezvous en servir comme dune liste de contrle. Quand vous commen-cez un projet, suivez cette liste et assurez-vous que chaque point esttrait, ou au moins que vous naurez pas de problmes quant auxconsquences possibles si vous dcidez den carter un.

2.1.1 Choisissez un bon nom

Mettez-vous la place de quelquun venant de dcouvrir votreprojet, peut-tre en le trouvant par hasard lors dune recherche delogiciel. La premire chose quil verra est le nom du projet.

Un bon nom ne fera pas automatiquement de votre projet unsuccs et un mauvais ne le condamnera pas (enfin, un trs mauvaisnom peut le faire, mais nous partons de lhypothse que personne icine tente intentionnellement de faire chouer son projet). Quoi quilen soit, un mauvais nom peut ralentir ladoption du projet parce queles gens ne le prennent pas au srieux, ou simplement parce quilsont du mal le retenir.

Un bon nom doit avoir les caractristiques suivantes :

Il donne une ide de lobjectif du projet, ou prsente au moinsclairement son domaine : ainsi, celui qui connat le nom et lateneur du projet laura plus facilement lesprit par la suite.

Il est simple mmoriser. Ici, on ne peut ignorer que langlaisest devenu le langage par dfaut sur Internet : simple m-

moriser signifie simple mmoriser pour quelquun parlantanglais . Un jeu de mots dpendant de la prononciation dulocuteur dans cette langue, par exemple, sera obscur pour lesnombreux lecteurs dont langlais nest pas la langue maternelle.Si le jeu de mot est particulirement bien trouv et facile mmoriser, cela peut tout de mme fonctionner : gardez simple-ment lesprit quen voyant le nom, beaucoup ne lentendront


45/353

``97612617'' --- 2011/1/2 --- 18:37 --- page 25 --- #45

2.1 Commencez avec ce que vous avez 25

pas mentalement comme une personne de langue maternelle an-glaise.

Il nest pas le mme que celui dun autre projet et ne sapprochedaucune marque dpose. Ce ne sont que des bonnes manireset du bon sens lgal. Vous ne voulez pas crer une confusiondidentit. Il est dj assez difficile de suivre tout ce qui est dis-ponible sur le Net sans sencombrer de problmes dhomonymie.Les sites mentionns prcdemment dans lintroduction vous se-ront dune grande aide pour savoir si un projet a dj adoptle nom auquel vous pensiez. Une recherche gratuite de marques

dposes est galement possible sur les sites nameprotect.org 1et uspto.org 2.

il est disponible comme nom de domaine en .com, .net ou .orgsi possible. Vous devriez en choisir un, vraisemblablement en.org, comme site officiel de prsentation du projet : les deuxautres devraient renvoyer ce premier site et ne sont l quepour viter une confusion didentit autour du nom du projet.Mme si vous avez lintention de lhberger sur un autre site(voir la section Forges ), vous pouvez toujours enregistrer desnoms de domaines particuliers pour le projet et les faire renvoyervers le site dhbergement. Cela aide beaucoup les utilisateursdavoir une adresse simple et facilement mmorisable.

2.1.2 Dfinissez clairement vos objectifs

Une fois le site du projet trouv, les gens chercheront une des-cription rapide de sa teneur, votre dclaration dintention, afin depouvoir dcider rapidement (dans les 30 secondes) sils souhaitenten savoir plus ou pas. Cette description devrait avoir une place dechoix sur la premire page, de pfrence juste en-dessous du nomdu projet.

Votre dclaration doit tre concrte, restreinte et surtout concise.En voici un bon exemple tir du site openoffice.org 3 :

Pour crer, en tant que communaut, la suite bu-reautique internationale dominante qui fonctionnera

sur toutes les plateformes principales et qui don-nera accs toutes les fonctionnalits et toutes lesdonnes au travers dAPI bases sur des composantslibres et des formats de fichier bass sur XML.

1. ht

Documents

Produire du logiciel libre