POSS Chap 0

En soirée, 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 est-ce que tu gagnes 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 de certains logiciels, mais elles n'ont pas besoin d'en vendre des copies, elles veulent juste être certaines que le logiciel continue à exister et à être maintenu, c'est plus un outil qu'un bien.

Ces derniers temps pourtant, la question qui suit n'a plus toujours trait à l'argent. Le côté économique de l'Open Source [1] 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 que j'entends de plus en plus souvent est : « Ah ! Comment est-ce que ç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 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 de diriger une association à but non lucratif traditionnelle ou un gouvernement. Il y a des ressemblances avec 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, mais ne peut être assimilé à aucune. En effet, même l'hypothèse selon laquelle un projet de logiciel libre peut être « dirigé » est limite. Un projet logiciel libre peut être démarré et peut être influencé par les personnes impliquées, souvent même très fortement. Mais son capital ne peut pas être réduit à la propriété d'une unique personne et aussi longtemps qu'il y aura des individus quelque part, peu importe où, désirant continuer le projet, on ne pourra pas décider unilatéralement de l'arrêter. Chacun possède un pouvoir infini ; personne ne possède le moindre pouvoir. Tout cela produit une dynamique intéressante.

Voilà pourquoi j'ai voulu écrire ce livre. Les projets logiciels libres ont donné naissance à une culture distincte, une ethnie pour laquelle la liberté de créer un logiciel, qui peut réaliser ce que l'on veut, est la doctrine centrale ; et pourtant le résultat de cette liberté n'est pas la 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 capacités les plus hautement estimées dans le monde du libre. Diriger ces projets signifie s'engager dans une sorte de coopération hypertrophiée où la capacité 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 de décrire les techniques rendant ceci possible. Il n'est en aucun cas exhaustif, mais c'est au moins un début.

Produire du bon logiciel libre est en soi-même 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. Mais au-delà de ça, 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 merveilleuse manière que le monde du libre encourage. Prendre part à un projet logiciel libre réussi est amusant et ultimement c'est ce qui permet à tout ce système de fonctionner.

Ce livre est fait pour les développeurs de logiciels et les managers qui envisagent de lancer un projet Open Source ou qui ont déjà commencé et qui se demandent ce qu'ils doivent faire maintenant. Il devrait également être utile aux gens qui veulent simplement s'impliquer dans un projet Open Source mais ne l'ont jamais fait jusqu'ici.

Le lecteur n'a pas besoin d'être programmeur, mais il devrait connaître les concepts et termes de base de l'ingénierie logicielle tels que code source, compilateur et patch.

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 logiciel libre trouveront certaines parties du livre évidentes et pourront passer ces sections. Parce qu'il peut y avoir de gros écarts d'expérience entre les lecteurs, j'ai essayé de donner des titres explicites aux différentes parties et de préciser quand une partie peut être sautée par les lecteurs 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 (http://subversion.tigris.org/). Subversion est un programme de Gestion de Configuration Logicielle (GCL) Open Source, écrit à partir de zéro, et créé pour remplacer CVS comme gestionnaire de configuration logicielle de référence de la communauté Open Source. Le projet a été lancé par mon employeur, CollabNet (http://wwww.collab.net/), au début des années 2000 et, heureusement, dès le départ Collabnet a compris comment faire fonctionner ce projet de manière collective et répartie. Beaucoup des développeurs bénévoles y ont adhéré très tôt ; aujourd'hui le projet en compte une cinquantaine, parmi lesquels seulement quelques uns 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 c'était aussi une question de vérification. Bien que je sois engagé dans d'autres projets logiciels libres à différents degrés et que je parle à des amis et autres relations engagés dans bien d'autres encore, on réalise rapidement que lorsqu'on écrit pour publier, 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 sur la simple base de ce que je pouvais lire dans les archives de leur liste de diffusion publique. Si quelqu'un faisait cela avec Subversion, je m'en rends bien compte, il se tromperait la moitié du temps. Donc quand je m'inspire ou prends exemple sur d'autres projets avec lesquels je n'ai pas eu d'expérience directe, j'ai toujours essayé de parler en premier lieu avec un informateur de chez eux, quelqu'un en qui j'ai confiance pour m'expliquer 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 j'ai seulement participé 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 la plupart du temps, peu importe le sujet, j'avais l'impression de marcher avec une épée de Damoclès suspendue au-dessus de ma tête. Sans l'aide de nombreuses personnes je n'aurais pas été capable de le finir en gardant toute ma tête.

Andy Oram, mon éditeur 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 d'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 je préférais 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, quelque soit le sujet que j'essayais de traiter cette semaine-là. Ils remarquaient également quand j'avais tendance à me relâcher et me taquinaient quand c'était nécessaire. Merci les gars !

Biella Coleman écrivait également son mémoire en même temps que j'écrivais mon livre. Elle sait ce que signifie s'asseoir et écrire tous les jours et elle a été pour moi aussi bien un exemple qu'une oreille compatissante. Elle possède également le regard fascinant de l'anthropologiste sur le mouvement du logiciel libre, me fournissant à la fois des idées et des références que je pouvais utiliser dans mon livre. Alex Golub, un autre anthropologiste avec un pied dans le monde du logiciel libre, qui lui aussi terminait son mémoire à ce moment là, 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 a été grandement inspirant 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 véritable aide. 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 d'avoir 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é du temps dans leur emploi du temps surchargé pour 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ée.

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 emploi du temps pour écrire ce livre et ne s'est pas plaint quand cela m'a pris plus de temps que prévu au départ. 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 rencontre un commiter 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 a, d'une certaine manière, réussi à faire paraître mes problèmes moins graves. 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 dernière fois, mais dont l'amitié et le leadership de Golosá ont aidé à garder la musique et un bon cercle de gens proches dans ma vie, 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, pas seulement pendant l'écriture de ce livre mais pour les sept dernières années. Je ne pense pas que j'aurai fini sans son aide. De même, Jim, véritable ami et un hacker de chez hacker qui, le premier, m'a fait découvrir les logiciels libres, un peu comme si un oiseau apprenait à voler à un avion.

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.

[1] Les termes « Open Source » et « libre » sont essentiellement des synonymes dans ce contexte ; j'en parle plus dans la section intitulée «  « Libre » contre « Open Source » » dans le Chapitre 1, Introduction.