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. 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. 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é. É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. 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.