Préface
Pourquoi écrire ce livre?
Dans les soirées, les gens ne me regardent plus bizarrement quand
je leur dis que je fais du logiciel libre. « Ah oui, Open Source, comme
Linux ? » me répondent-ils. J'acquiesce avec empressement. « Oui,
exactement, c'est ce que je fais ! » C'est agréable de ne plus être
complètement à l'écart. Dans le passé, la question suivante était
généralement assez prévisible : « Comment gagnes-tu ta vie en faisant
ça ? ». Ma réponse résumait toute l'économie de l'Open Source :
certaines organisations trouvent leur intérêt dans l'existence d'un
logiciel particulier, mais n'ont aucunement besoin d'en vendre des
copies, elles veulent juste être sûres que le logiciel continue à
exister et à être maintenu : en tant qu'outil plutôt que bien.
Ces derniers temps pourtant, la question suivante ne traitait pas
toujours d'argent. Le côté économique de l'Open Source
Les termes « Open Source » et « libre » sont essentiellement des
synonymes dans ce contexte: j'en parle plus dans la section intitulée
dans le
.
n'est plus si mystérieux et beaucoup de non-programmeurs comprennent, ou
du moins ne sont pas surpris, que certains y soient employés à plein
temps. Par contre, la question entendue de plus en plus souvent était :
« Ah ! Comment ça marche ? »
Je n'avais pas de réponse satisfaisante toute prête et, plus
j'essayais d'en donner une, plus je réalisais à quel point ce sujet est
complexe. Mener un projet de logiciel libre n'est pas exactement comme
diriger une entreprise (imaginez devoir constamment discuter de la
nature du produit avec un groupe de volontaires que vous ne rencontrerez
jamais pour la plupart !). Pour différentes raisons, ce n'est pas non
plus comme diriger une association à but non lucratif traditionnelle ou
un gouvernement. Il y a des ressemblances entre tous ces types
d'organisations, 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, même l'hypothèse selon laquelle un projet de logiciel
libre peut être « dirigé » est limite. Un tel projet peut être
démarré et influencé par les personnes impliquées,
souvent même très fortement. Mais son capital ne peut être considéré
comme la propriété d'une seule et unique personne et, tant qu'il y aura
des individus, quelque part, peu importe où, désirant continuer le
projet, nul ne pourra décider unilatéralement de l'arrêter. Chacun
possède un pouvoir infini, personne ne possède le moindre pouvoir : le
tout produisant une dynamique intéressante.
Voilà pourquoi j'ai voulu écrire ce livre. Les projets de
logiciels libres ont donné naissance à une culture distincte, une
philosophie où la liberté de créer un logiciel réalisant ce que l'on
veut est la doctrine centrale. Pourtant, il résulte de cette liberté non
pas une dispersion des individus, chacun allant dans sa propre direction
avec le code, mais une collaboration enthousiaste. En effet, la capacité
de collaborer est l'une des facultés les plus hautement estimées dans le
monde du libre. Diriger de tels projets signifie s'engager dans une
sorte de coopération hypertrophiée où l'habilité d'une personne non
seulement à travailler avec les autres, mais aussi à proposer de
nouvelles manières de travailler ensemble, peut aboutir à des avancées
tangibles du logiciel. Ce livre tente d'expliquer comment rendre ceci
possible. Il n'est en aucun cas exhaustif, mais c'est au moins un début.
Produire un bon logiciel libre est un but louable en soit, et
j'espère que les lecteurs qui sont venus à la recherche de manières d'y
parvenir vont être satisfaits de ce qu'ils vont trouver ici. Mais au
delà de cela, j'espère également vous transmettre le réel plaisir de
travailler avec une équipe motivée de développeurs de logiciel libre, et
celui d'interagir avec les usagers de la manière merveilleusement
directe que l' Open Source encourage.
Participer à une projet de logiciel libre qui a du succès est
amusant, et ultimement c'est ce qui permet à tout
ce système de fonctionner.
Produire du bon logiciel libre est en soi un but valable, et
j'espère que les lecteurs qui viennent chercher des moyens de
l'atteindre seront satisfaits de ce qu'ils trouveront ici. Bien au-delà,
j'espère transmettre un peu du pur plaisir que l'on peut prendre à
travailler avec une équipe de développeurs Open Source motivée et à
interagir avec les utilisateurs de cette manière merveilleusement
directe encouragée par le monde du libre. Prendre part à un projet de
logiciel libre réussi est amusant et c'est bien ce
qui, au bout du compte, permet au système entier de fonctionner.
À qui s'adresse ce livre ?
Ce livre s'adresse aux développeurs de logiciels et aux
responsables envisageant de lancer, ou ayant déjà commencé, un projet
Open Source, et se demandant que faire maintenant. Il devrait également
être utile aux gens souhaitant simplement s'impliquer dans un projet
Open Source sans l'avoir jamais fait auparavant.
Nul besoin d'être programmeur, mais le lecteur devrait connaître
les concepts basiques d'ingénierie logicielle tels que code source,
compilateur et correctif.
Une expérience préalable avec le logiciel Open Source, en tant
qu'utilisateur ou développeur, n'est pas nécessaire. Ceux qui ont déjà
travaillé au sein d'un projet de logiciel libre trouveront certaines
parties du livre évidentes et pourront passer ces sections. Étant donné
le large éventail possible d'expériences des lecteurs, j'ai essayé de
nommer clairement les différentes parties et de préciser celles pouvant
être ignorées par les familiers du sujet.
Sources
Une grande partie de la matière première de ce livre provient de
cinq ans d'expérience à travailler sur le projet Subversion (). Subversion est un programme
Open Source de gestion de versions, écrit à partir de rien, et créé
pour remplacer CVS comme gestionnaire de versions de référence de la
communauté Open Source. Le projet fut lancé, au début des années 2000,
par mon employeur CollabNet (),
lequel comprit, heureusement dès le départ, comment le faire fonctionner
de manière collective et répartie. De nombreux développeurs bénévoles y
adhérèrent très tôt. Aujourd'hui, le projet en compte une cinquantaine
dont peu sont employés par CollabNet.
De bien des manières, Subversion est un exemple classique de
projet Open Source et je m'en suis finalement inspiré plus que je ne le
pensais au début, en partie parce que c'était plus pratique. Chaque fois
que j'avais besoin d'un exemple pour illustrer un phénomène particulier,
c'est une expérience issue de Subversion qui me venait à l'esprit. Mais
aussi pour une question de vérification : quoiqu'engagé, à divers degrés,
dans d'autres projets de logiciels libres et malgré mes entretiens avec
des amis et connaissances impliqués dans bien d'autres encore, on réalise
rapidement en écrivant en vue d'une publication que tous les faits
doivent être vérifiés. Je ne voulais pas faire de déclarations à propos
d'évènements se produisant dans d'autres projets en me basant simplement
sur ce que je pouvais lire dans les archives de leur liste de diffusion
publique. Si quelqu'un le faisait avec Subversion, je m'en rends bien
compte, il se tromperait la moitié du temps. Donc quand je m'inspire ou
que je prends exemple sur d'autres projets avec lesquels je n'ai pas eu
d'expérience directe, j'ai toujours essayé de vérifier mes informations
auprès de quelqu'un d'impliqué, quelqu'un en qui je pouvais faire
confiance pour qu'il m'explique ce qui s'est vraiment passé.
J'ai travaillé sur Subversion pendant les cinq dernières années,
mais je suis impliqué dans le logiciel libre depuis douze ans. Voici
d'autres projets ayant influencés ce livre :
Le projet d'éditeur de texte GNU Emacs de la Free
Software Foundation, pour lequel je maintiens quelques paquets.
Concurrent Versions System (CVS), sur lequel j'ai
beaucoup travaillé en 1994–1995 avec Jim Blandy mais auquel je
participe seulement par intermittence depuis.
L'ensemble des projets Open Source connus sous le nom
d'Apache Software Foundation et plus spécialement l'Apache Portable
Runtime (APR) et l'Apache HTTP Server.
OpenOffice.org, la base de données de Berkeley de
Sleepycat et la base de données MySQL: je n'ai pas été personnellement
impliqué dans ces projets mais je les ai observés et, dans certains
cas, j'ai pu parler avec des personnes en faisant partie.
Le GNU Debugger (GDB) (idem).
Le projet Debian (idem).
Évidemment, cette liste n'est pas exhaustive. Comme la plupart des
programmeurs Open Source, je garde un œil sur de nombreux projets
différents, juste pour avoir une idée générale de ce qui se passe.
Je ne vais pas tous les mentionner ici, mais certains sont cités dans
le livre quand je l'ai jugé approprié.
Remerciements
Écrire ce livre m'a pris quatre fois plus de temps que je ne le
pensais et, quel que soit le sujet, j'avais souvent l'impression de
marcher avec une épée de Damoclès suspendue au-dessus de ma tête. Sans
l'aide de nombreuses personnes, j'aurais été incapable de le finir en
gardant toute ma tête.
Andy Oram, chez O'Reilly, a été pour moi l'éditeur idéal. En plus
de très bien connaître le sujet (il a suggéré un grand nombre des
thèmes), il a le don rare de savoir ce que quelqu'un veut dire et de
pouvoir l'aider à le dire correctement. Travailler avec lui a été un
honneur. Merci aussi à Chuck Toporek pour avoir immédiatement proposé ce
projet à Andy.
Brian Fitzpatrick a relu tout mon travail à mesure que j'écrivais,
ce qui a non seulement amélioré le livre mais m'a aussi permis de
poursuivre l'écriture quand j'aurais souhaité me trouver n'importe où
plutôt que devant mon ordinateur. Ben Collins-Sussman et Mike Pilato ont
aussi gardé un œil sur l'avancement du travail et étaient toujours
heureux de discuter, parfois longuement, quel que soit le sujet que
j'essayais de traiter cette semaine-là. Ils remarquaient également quand
j'avais tendance à me relâcher et me taquinaient si nécessaire. Merci
les gars !
Biella Coleman rédigeait également un mémoire en même temps que
j'écrivais ce livre. Elle sait ce que signifie s'asseoir et écrire tous
les jours : elle fut pour moi aussi bien un exemple qu'une oreille
compatissante. Elle possède également le regard fascinant de
l'anthropologue sur le mouvement du logiciel libre, me fournissant à la
fois des idées et des références que je pouvais utiliser. Alex Golub (un
autre anthropologue, avec un pied dans le monde du logiciel libre, qui
lui aussi terminait son mémoire au même moment) m'a apporté un soutien
exceptionnel dès le début, ce qui m'a beaucoup aidé.
Micah Anderson n'a, d'une certaine manière, jamais semblé trop
stressé par son propre contrat d'écriture, ce qui fut source de
motivation mais me rendait maladivement jaloux. Il a toutefois toujours
été présent par son amitié, sa conversation et (au moins à une occasion)
son aide technique. Merci Micah !
Jon Trowbridge et Sander Striker m'ont apporté chacun leurs
encouragements et une aide précieuse. Leur grande expérience du logiciel
libre m'a fourni la matière que je n'aurais pu trouver nulle part
ailleurs.
Merci à Greg Stein, non seulement pour son amitié et ses
encouragements arrivés à point nommé, mais aussi pour avoir montré au
projet Subversion à quel point une inspection régulière du code est
importante pour le développement d'une communauté de programmeurs. Je
remercie également Brian Behlendorf qui a fait entrer avec tact dans nos
esprits l'importance des discussions publiques : j'espère que ce
principe se reflète dans ce livre.
Merci à Benjamin « Mako » Hill et Seth Schoen pour les nombreuses
discussions à propos du logiciel libre et de sa politique, à Zack
Urlocker et Louis Suarez-Potts pour avoir trouvé quelques minutes dans
leur emploi du temps surchargé afin de m'accorder une interview, à Shane
de la liste Slashcode pour m'avoir permis de citer son article et à
Haggen So pour sa comparaison des sites d'hébergement qui m'a énormément
aidé.
Merci à Alla Dekhtyar, Polina et Sonya pour leur encouragement
patient et sans faille. Je suis ravi de ne plus avoir à écourter (ou
plutôt, essayer en vain d'écourter) nos soirées pour aller travailler
sur « Le Livre ».
Merci à Jack Repenning pour son amitié, sa conversation et son
entêtement à refuser d'accepter une analyse simple mais fausse quand une
autre plus complexe mais juste existe. J'espère qu'une partie de sa
longue expérience dans le développement et l'industrie du logiciel a
déteint sur ce livre.
CollabNet s'est montré exceptionnellement généreux en me
permettant d'adapter mon agenda pour écrire ce livre, sans se plaindre
quand cela me prit plus de temps que prévu. Je ne connais pas tous les
rouages d'une telle décision mais je suppose que Sandhya Klute, et par
la suite Mahesh Murthy, y sont pour quelque chose. Je les remercie tous
les deux.
Toute l'équipe de développement Subversion a été une source
d'inspiration au cours de ces cinq dernières années et c'est auprès d'eux
que j'ai appris l'essentiel de ce qui est expliqué dans ce livre. Je ne
les remercierai pas nominativement, car ils sont trop nombreux, mais
j'implore chaque lecteur qui croise un committer de Subversion de lui
offrir un verre. C'est ce que je compte faire moi-même.
J'ai souvent pesté auprès de Rachel Scollon à propos de l'état de
ce livre. Elle a toujours été prête à m'écouter et, d'une certaine
manière, a réussi à faire paraître mes problèmes moins graves qu'ils ne
l'étaient avant nos conversations. Cela m'a beaucoup aidé, merci.
Merci (encore) à Noel Taylor, qui a certainement dû se demander
pourquoi je voulais écrire un autre livre, sachant à quel point je
m'étais plaint la fois précédente, mais dont l'amitié et la conduite de
Golosá m'ont aidé à préserver, dans mon existence, la musique et
un cercle fraternel, même pendant les périodes les plus chargées. Merci
aussi à Matthew Dean et Dorothea Samtleben, amis et compagnons musicaux
que j'ai longtemps fait souffrir et qui se sont montrés très
compréhensifs quand les excuses que je donnais pour ne pas répéter
s'accumulaient. Megan Jennings m'a toujours soutenu et a montré un réel
intérêt pour le sujet malgré son inexpérience dans le domaine, un vrai
énergisant pour un écrivain qui doute. Merci mon amie !
J'ai eu quatre relecteurs compétents et persévérants pour ce
livre : Yoav Shapira, Andrew Stellman, Davanum Srinivas et Ben Hyde. Si
j'avais pu ajouter toutes leurs excellentes suggestions, ce livre serait
encore meilleur. Des contraintes de temps m'ont forcé à faire des choix
mais les améliorations sont quand même visibles. Toutes les erreurs qui
subsistent sont entièrement les miennes.
Mes parents, Frances et Henry, m'ont apporté comme toujours un
magnifique soutien, et comme ce livre est moins technique que le
précédent, j'espère qu'ils le trouveront un peu plus lisible.
Pour finir, j'aimerais remercier les dédicataires : Karen
Underhill et Jim Blandy. L'amitié et la compréhension de Karen
représentent tout pour moi, non seulement pendant l'écriture de ce livre
mais aussi au cours des sept dernières années. Je n'aurais simplement
pas pu finir sans son aide. De même, Jim, véritable ami et maître hacker
qui, le premier, m'a fait découvrir les logiciels libres tel l'oiseau
enseignant à l'avion comment voler.
Note
Les pensées et opinions exprimées dans ce livre sont les miennes.
Elles ne représentent pas nécessairement les idées de CollabNet ni du
projet Subversion.