De Framalang Wiki.

Chapitre 4 : Infrastructure sociale et politique

Sommaire

1 Chapitre 5 : L'argent

Chapitre 5 : L'argent

Ce chapitre aborde la question du financement d'un projet de logiciel libre. Il ne concerne pas uniquement les développeurs payés pour travailler sur des projets de logiciel libre, mais aussi leurs responsables, lesquels doivent comprendre les règles sociales régissant le cadre du développement. Dans les sections suivantes, nous ferons l'hypothèse que le destinataire (« vous ») est, soit développeur rémunéré, soit dirigeant. Les conseils dispensés aux deux modèles seront souvent identiques, dans le cas contraire, le poste concerné sera mis en évidence par le contexte.

Le financement du développement d'un logiciel libre par une entreprise n'est pas un phénomène nouveau. Depuis toujours, nombreux sont les développements subventionnés de manière officieuse. Lorsqu'un administrateur système écrit un outil d'analyse du réseau pour l'aider dans son travail, puis, une fois en ligne, reçoit des corrections de bogues ou des contributions d'autres administrateurs systèmes, il s'agit bien de la création d'un consortium officieux. Les entreprises qui rémunèrent ces administrateurs réseaux et leurs fournissent bureaux et bande passante en deviennent les mécènes involontaires. Elles profitent, bien sûr, de cet investissement, quoiqu'elles ne le sachent pas officiellement en premier lieu.

La différence, aujourd'hui, est que ces collaborations se formalisent. Les entreprises ont pris conscience des avantages des logiciels Open Source et commencent à s'impliquer plus directement dans leur développement. De même, les développeurs en sont arrivés à espérer que les projets vraiment importants attirent au moins des donations voire, si possible, des partenaires sur le long terme. Alors que la présence d'argent n'a rien changé aux principes de base du développement de logiciels libres, elle a profondément modifié l'échelle des occurrences, tant en terme d'effectifs que de temps par développeur. Cela eut également une incidence sur l'organisation des projets, et sur les interactions entre les groupes impliqués. Les questions ne portent pas simplement sur la manière de dépenser l'argent, ou sur les moyens de mesurer le retour sur investissement. Elles touchent aussi à l'organisation et aux procédures : comment des organisations hiérarchisées d'entreprises et semi-décentralisées de communautés du logiciel libre peuvent-elles travailler ensemble pour un meilleur profit ? S'accorderont elles, d'ailleurs, sur le sens même de « meilleur profit » ?

Un soutien financier est, en général, bien accueilli par les communautés de développement Open Source. Il peut réduire la vulnérabilité du projet face aux Forces du Chaos qui emportent tant de projets avant qu'ils ne décollent vraiment, et ainsi donc, rendre les gens plus enclins à donner une chance au logiciel. Ils ont alors le sentiment d'investir leur temps dans quelque chose qui sera toujours présent dans six mois. Après tout, la crédibilité est particulièrement contagieuse. Quand IBM, par exemple, soutient un projet Open Source, les gens se disent que le projet n'aura pas le droit d'échouer. La confiance, inspirée par ce parrainage, se traduira en inspiration, un supplément de motivation qui peut entraîner la prophétie à se réaliser d'elle-même.

Quoiqu'il en soit, le financement implique, également, une idée de contrôle. Manipulé sans attention, l'argent peut entraîner une scission entre développeurs rémunérés et bénévoles. Si ces derniers ont la sensation que c'est finalement l'argent qui décide de la conception ou des nouvelles fonctionnalités, ils partiront pour un projet paraissant plus proche d'une méritocratie que d'un travail à titre gracieux au bénéfice d'autres personnes. Ils ne s'en plaindront pas forcément ouvertement dans les listes de diffusion. Vous remarquerez plutôt le nombre des contributions externes diminuer à mesure que les volontaires cesseront d'essayer vainement de se voir accorder une certaine crédibilité. Le bourdonnement de l'activité à petite échelle continuera, sous forme de rapports de bogues ou de petits correctifs occasionnels. Mais, vous ne verrez plus de grande contribution au code, ni de participation extérieure dans les discussions portant sur la conception. Les gens ressentent ce que l'on attend d'eux, et répondent (ou pas) à ces attentes.

L'argent n'est pas sans pouvoir pour autant. Vous pouvez acheter votre influence, mais pas de manière directe. Dans un échange commercial classique, vous donnez de l'argent en échange de ce que vous désirez. Si vous avez besoin d'une fonctionnalité supplémentaire, vous signez un contrat, payez votre part, et elle sera ajoutée. Dans un projet Open Source, ce n'est pas si simple. Vous pouvez signer un contrat avec quelques développeurs, mais ils se mystifieraient (et vous aussi) s'ils garantissaient que le travail, que vous avez payé, sera accepté par la communauté de développement, simplement parce que vous l'avez payé. Le travail ne peut être accepté que pour son propre mérite, et s'il correspond aux projets qu'a la communauté pour le logiciel. Vous pouvez avoir votre mot à dire dans ces projets, mais vous n'êtes pas le seul.

Vous n'achetez pas de l'influence, vous achetez une voix au sein du projet. Les programmeurs en sont le meilleur exemple. Si de bons programmeurs recrutés parviennent, avec le temps, à se faire respecter par la communauté, ils pourront influencer le projet à l'instar des autres membres. Ils auront le droit de vote et, s'ils sont nombreux, feront une alliance. Respectés dans le projet, leur influence dépassera leurs simples votes. Les développeurs rémunérés n'ont aucune raison de cacher leurs motivations, non plus. Après tout, quiconque veut une modification du logiciel, le veut pour une raison. La motivation de votre entreprise est aussi légitime que toute autre. Il faut juste savoir que le poids accordé aux objectifs de votre entreprise sera déterminé par le statut de ses représentants au sein du projet, pas par sa taille ou son modèle économique.

Les différentes participations

Les projets Open Source peuvent être financés pour de nombreuses raisons. Les points de cette liste ne s'excluent pas mutuellement, souvent la décision de soutenir financièrement un projet résultera de plusieurs de ces motivations, voire même de toutes :

Partager la charge

Des organismes distincts aux besoins logiciels communs se retrouvent souvent à reproduire les travaux, soit en écrivant un code proche et redondant en interne, soit en achetant des produits similaires à des vendeurs privés. Quand ils comprennent la situation, les structures peuvent fusionner leurs ressources et créer (ou rejoindre) un projet Open Source sur-mesure satisfaisant leurs besoins. Les avantages sont évidents : coûts de développement partagés et gains accrus pour tout le monde. Ce scénario, plus logique pour des organisations à but non lucratif de prime abord, peut se révéler payant, même pour les entreprises commerciales.

Exemples : http://www.openadapter.org/, http://www.koha.org/.

Accroître les services

Lorsqu'une entreprise vend des services dépendants de programmes Open Source particuliers, il est naturellement dans l'intérêt de cette compagnie de s'assurer que ces programmes soient activement maintenus.

Exemple : Le soutien de CollabNet au site http://subversion.tigris.org/ (note : c'est mon travail, mais c'est aussi un parfait exemple de ce modèle).

Renforcer l'offre matériel

La valeur des ordinateurs et de leur composants est directement liée au nombre de logiciels disponibles. Les vendeurs de matériel (pas uniquement les vendeurs de machines complètes, mais aussi les fabricants de périphériques et de micropuces) se sont aperçus que la présence de logiciels libres de qualité fonctionnant sur leur matériel est importante aux yeux des clients.

Affaiblir un produit concurrent

Parfois, les entreprises apportent leur soutien à un projet Open Source particulier, dans le but d'affaiblir le produit d'un concurrent, Open Source ou pas. Grignoter des parts de marché d'un concurrent, n'est, en général, pas la seule raison pour s'investir dans un projet Open Source, mais cela peut compter.

Exemple : http://www.openoffice.org/ (non, ce n'est pas la seule raison d'exister d'OpenOffice, mais le logiciel est au moins en partie une réponse à Microsoft Office).

Commercialisation

Associer son entreprise à une application Open Source populaire peut simplement être bon pour l'image de la société.

Double licence

Grâce à une double-licence, vous pouvez proposer du logiciel, sous une licence privée classique, aux clients souhaitant le revendre au sein d'applications brevetées, mais aussi sous une licence libre, à ceux désirant l'utiliser comme logiciel Open Source (voir la section « La double licence » au Chapitre 9, Licences, droits d'auteurs et brevets). Si la communauté de développeurs Open Source est active, le logiciel bénéficie, à grande échelle, du développement et de la correction de bogues, mais la société perçoit toujours les redevances lui permettant de financer quelques programmeurs à temps plein.

Deux exemples bien connus sont MySQL, les fabricants du logiciel de base de donnée du même nom, et Sleepycat qui s'occupe des distributions et du support de la Berkeley Database. Ce n'est pas une coïncidence si ces deux compagnies sont spécialisées dans les bases de données. Les logiciels de base de données sont plus souvent intégrés à d'autres applications que vendus directement aux utilisateurs, le modèle à licence double leur correspond donc très bien.

Les dons

Un programme très utilisé peut parfois recevoir des dons importants, de particuliers ou d'entreprises, en affichant simplement un bouton de donation en ligne, quelques fois en vendant des objets portant son logo comme des tasses à café, des T-shirts, des tapis de souris, etc. Attention : si votre projet accepte les dons, planifiez l'utilisation de cet argent avant qu'il n'arrive, et affichez vos prévisions sur le site Web du projet. Les discussions sur la manière d'allouer l'argent ont tendance à être plus tranquilles quand elles ont lieu avant qu'il n'y ait effectivement de l'argent à dépenser. De toute façon, en cas de désaccords importants, mieux s'en rendre compte quand tout n'est encore que théorique.

Le modèle économique d'un donateur n'est pas le seul facteur entrant en ligne de compte dans ses relations avec la communauté Open Source. L'historique de leur rapports précédents est tout aussi important : est-ce l'entreprise à l'initiative du projet ou se joint-elle au développement pré-existant ? Dans les deux cas, le donateur devra mériter sa crédibilité, bien évidemment, le deuxième lui vaudra plus d'efforts. L'organisme se doit d'avoir des buts précis pour le projet. L'entreprise essaie-t-elle de conserver une position dominante, d'être une simple voix parmi d'autres au sein de la communauté, ou, de guider mais sans forcément gouverner les décisions du projet ? Ou bien veut-elle simplement assurer ses intérêts et elle finance quelques committers pour réparer les bogues rencontrés par ses clients et apporter des modifications dans la distribution publique sans faire de vague ?

Gardez ces questions à l'esprit en lisant les conseils suivants. Ils sont faits pour être appliqués à tout investissement dans l'organisation d'un projet de logiciel libre, par contre, chaque projet étant un environnement humain, deux situations ne seront jamais identiques. Il faudra aussi vous fier à votre instinct. Cependant, en suivant ces conseils, vous devriez augmenter les probabilités d'un fonctionnement conforme à vos désirs.

Recrutez pour le long terme

Si vous dirigez des programmeurs dans un projet Open Source, faites en sorte qu'ils participent au projet suffisamment longtemps afin qu'ils puissent acquérir l'expertise technique et politique nécessaire, deux ans au minimum. Évidemment, que le code source soit ouvert ou non, une rotation rapide des programmeurs n'est profitable à aucun projet. L'obligation d'apprendre tous les rouages, à chaque nouvel arrivant, serait dissuasive quelque soit l'environnement. Mais le handicap est encore plus fort pour les projets Open Source puisque les développeurs quittant le projet emmènent avec eux non seulement leur connaissance du code, mais aussi leur statut dans la communauté et les relations humaines qu'ils ont tissées.

La crédibilité acquise ne peut être transférée. Pour prendre l'exemple le plus évident, un nouveau développeur ne peut pas hériter de l'accès de commit du développeur sortant (voir la section « L'argent ne fait pas tout » plus loin dans ce chapitre), donc, le nouveau développeur, n'ayant pas encore l'accès de commit, devra proposer des correctifs jusqu'à son obtention. Mais l'accès de commit n'est que la manifestation la plus visible de la perte d'influence. Un développeur de longue date connaît toutes les discussions traitées et rabâchées sur les listes de discussion. Un nouveau développeur, ne connaissant pas toutes ces conversations, pourrait tenter de raviver un problème une nouvelle fois, affectant ainsi la crédibilité de votre organisation : les autres se diront « ne peuvent-ils donc pas s'en souvenir ? ». Un développeur novice ne connaîtra pas la hiérarchie interne du projet, et sera incapable d'influencer l'orientation du projet aussi rapidement et souplement qu'une personne présente depuis longtemps.

Formez les nouveaux venus au moyen d'un programme de recrutement supervisé. Le développeur inexpérimenté devrait être en contact direct avec la communauté de développement public dès le départ, en commençant par des corrections de bogues et des tâches de nettoyage afin qu'il puisse apprendre les bases du code et se faire une réputation dans la communauté. Mais évitez de provoquer de longues discussions enflammées sur la conception du programme. Au cours du processus, un développeur expérimenté (ou plusieurs) devrait être disponible pour répondre à ses questions, il devrait aussi lire toutes les contributions faites par le nouvel arrivant à la liste de développement, même si elles se rapportent à des discussions habituellement ignorées par le développeur exercé. Cela aidera le groupe à repérer les récifs potentiels avant l'échouement du novice. Encouragements et indications privés peuvent aussi aider grandement, notamment si le nouvel arrivant n'a pas l'habitude de voir son travail minutieusement inspecté par ses pairs.

Quand CollabNet engage un nouveau développeur pour travailler dans Subversion, nous choisissons ensemble quelques bogues, que le nouveau venu puisse s'y faire les dents. Nous discutons du contour technique des solutions, ensuite, nous assignons au minimum un développeur expérimenté à la vérification (publique) du correctif que le nouveau développeur publiera (publiquement). En règle générale, nous ne regardons même pas le correctif avant que la principale liste de développeurs ne le voit, alors que nous pourrions le faire en cas de nécessité. Il est primordial que le développeur passe par le processus de révision public, il apprend la base du code tout en s'habituant à recevoir des critiques de personnes complètement inconnues. Nous essayons aussi de coordonner nos réponses afin que nos impressions soient visibles dès la publication du correctif. Ainsi, les premières inspections lues sur la liste sont les nôtres, ce qui peut aider à donner la tonalité des révisions suivantes. Nous montrons ainsi, à tout le monde, que cette nouvelle personne doit être prise au sérieux. Si chacun voit que nous prenons le temps de faire des commentaires détaillés, avec des explications exhaustives et des références aux archives si nécessaire, ils comprendront que la personne est dans une phase de formation, certainement synonyme d'investissement sur le long terme. Cela peut les inciter à de bonnes dispositions envers ce développeur, au moins jusqu'à consacrer du temps supplémentaire à répondre aux questions et inspecter les correctifs.

Montrez vous unis

Vos développeurs feront leur possible pour s'exprimer, sur les forums publics de développement, en tant que participants individuels plutôt que sous forme d'une force corporative massive. Ce n'est pas qu'une présence corporative imposante possède une connotation négative (enfin, peut-être existe-t-elle, mais ce n'est pas le sujet de ce livre). C'est plutôt parce que les projets Open Source ne sont structurellement équipés que pour traiter avec des entités individuelles. Un participant individuel peut discuter, proposer des correctifs, gagner en crédibilité, voter, etc. Une entreprise ne le peut pas.

De plus, en décentralisant le projet, vous évitez la concentration de l'opposition. Laissez vos développeurs argumenter entre eux dans les listes de diffusion. Encouragez les à revoir leur code mutuellement, aussi souvent que possible et publiquement, comme ils le feraient pour toute autre personne. Découragez les à voter en groupe, car s'ils le font, d'autres pourraient commencer à penser, juste par principe, qu'ils devraient, eux aussi, s'organiser pour garder un certain poids.

Il y a une différence entre être vraiment décentralisé et s'efforcer à paraître décentralisé. Selon les circonstances, il peut s'avérer utile que vos développeurs agissent de concert, ils devraient donc être préparés à s'unir en coulisse si nécessaire. Par exemple, quand vous faites une proposition, l'intervention de quelques personnes, exprimant leur consentement, peut aider en donnant l'impression qu'un consensus s'installe. Les autres auront alors l'impression que la proposition gagne de la vitesse, et que, faire part de leur objection casserait cet élan. En conséquence, les gens ne protesterons qu'à juste raison. Il n'y a aucun mal à orchestrer un accord de cette manière, tant que les objections sont prises au sérieux. Les expressions publiques d'un accord privé ne sont pas moins sincères parce qu'il fut conclu par avance, et ne sont dommageables qu'utilisées afin d'étouffer les arguments contraires. Leur but est tout simplement d'inhiber cette catégorie de personnes qui ne contredit que pour la forme, voir la section nommée « Plus un sujet est facile plus les discussions sont longues » dans le Chapitre 6, Communication pour en savoir plus à ce propos.

Ne cachez pas vos motivations

Annoncez les buts de votre organisation en toute transparence, sans révéler de secrets commerciaux. Si vous voulez que le projet incorpore une certaine fonctionnalité parce que, par exemple, vos clients la réclame à corps et à cris, annoncez le clairement sur les listes de diffusion. Si les clients souhaitent rester anonymes, comme c'est parfois le cas, demandez leur au moins si vous pouvez les citer comme exemples sans les nommer. La communauté de développeurs acceptera d'autant mieux vos propositions qu'ils en connaissent les raisons.

Cela va à l'encontre de l'idée instinctive, si facile à acquérir, si difficile à chasser, que la connaissance est un pouvoir, et qu'en jouant carte sur table, vous vous mettez en position de faiblesse. Mais cette idée instinctive est fausse ici. En défendant publiquement les fonctionnalités (ou correctifs de bogues ou quoique ce soit d'autre), vous avez déjà dévoilé votre jeu. La question en suspens est de savoir si vous arriverez à mener la communauté à partager vos objectifs. Si vous dites simplement ce que vous désirez, mais sans fournir d'exemple, votre défense est faible, les gens commenceront à soupçonner des motivations cachées. Par contre en donnant des exemples concrets, montrant pourquoi la fonctionnalité proposée est importante, vous pouvez spectaculairement influer sur le débat.

Pour comprendre cela, pensez à la situation inverse. Trop souvent, les débats à propos de nouvelles fonctionnalités ou de nouvelles orientations sont longs et fatigants. Les arguments avancés se résument en général à « Moi je veux ceci ou cela », ou encore, à cette phrase extrêmement populaire « D'après mes années d'expérience en tant qu'architecte logiciel, ceci ou cela est important pour les utilisateurs / n'est qu'une fonction inutile qui ne plaira à personne. » Comme prévu, l'absence de données concrètes n'aident ni à raccourcir, ni à tempérer de tels débats. Au contraire, cela les éloignent toujours plus de la question centrale : la satisfaction de l'utilisateur. Sans la force d'un contrepoids, il est très probable finalement que le résultat ne soit pas déterminé par celui ayant montré le plus de logique, de ténacité ou d'expérience.

En tant qu'entreprise possédant un grand nombre de données clients, vous avez la possibilité d'exercer cette force pour faire contrepoids. Vous êtes le fil conducteur transmettant les informations qui, autrement, n'atteindraient pas la communauté de développeurs. Utiliser ces informations pour appuyer vos souhaits n'est en rien embarrassant. La plupart des développeurs n'ont pas, individuellement, une grande expérience de l'utilisation qui est faite du logiciel qu'ils écrivent. Chaque développeur utilise le logiciel d'une manière qui lui est propre, vous apportez à la communauté de développement public une vraie bouffée d'oxygène. Tant que vous y mettez les formes, ils l'accueilleront avec enthousiasme, et cela propulsera les choses dans la direction que vous souhaitez.

Tout réside, évidemment, dans la manière de présenter les choses. Vous n'obtiendrez jamais rien en insistant uniquement parce que vous représentez un grand nombre d'utilisateurs, et que, parce qu'ils ont besoin d'une fonctionnalité particulière (ou pensent en avoir besoin), votre solution devrait être ajoutée. Vous devriez, de préférence, concentrer vos premiers messages sur le problème, plutôt que sur une solution particulière. Décrivez avec force de détails les difficultés que rencontrent vos clients, donnez autant d'analyses et de solutions viables que possible. Quand les gens commencent à spéculer sur l'efficacité de plusieurs solutions, vous pouvez continuer à dérouler vos données pour appuyer ou réfuter ce qu'ils disent. Vous avez peut-être déjà une solution depuis le début, mais ne la mettez pas tout de suite en avant. Ce n'est pas une tromperie, c'est simplement l'attitude standard du « courtier honnête ». Après tout, votre véritable but est de régler le problème, une solution n'est qu'un moyen d'arriver à cette fin. Si la solution que vous privilégiez est effectivement meilleure, d'autres développeurs finiront par le remarquer d'eux-même et, s'y rangeront de leur propre volonté, ce qui vaut bien mieux que de les intimider pour qu'ils l'ajoutent (la probabilité qu'ils proposent une meilleure solution n'est pas nulle non plus).

Cela ne veut pas dire que vous ne pouvez jamais prendre position pour une solution particulière. Mais vous devez avoir la patience de voir l'analyse, déjà menée personnellement, être répétée sur les listes de développement publiques. Ne répondez pas « Oui, on y a déjà réfléchi, mais ça ne marche pas pour les raisons A, B et C. À bien y réfléchir, la seule solution pour régler ce problème est... ». Ce n'est pas tant l'arrogance qui pourrait transparaître, que l'impression d'y avoir déjà consacré en coulisse une quantité inconnue (qu'on présumera importante) de ressources d'analyse qui pose problème. Les gens auront l'impression que des travaux majeurs ont déjà été réalisés, que peut-être des décisions ont été prises, et ce, sans concertation du public : c'est bien la meilleure voie vers la rancœur.

Naturellement, vous connaissez la quantité d'efforts dévoués en interne, et ce savoir est, d'une certaine manière, un désavantage. Vos développeurs se retrouvent dans un état d'esprit légèrement différent de celui des autres participants de la liste de diffusion. De fait, cela réduit leur habilité à appréhender les choses du point de vue des personnes n'ayant pas encore beaucoup réfléchi au problème. Vous réduirez ce fossé en réussissant à rallier tout le monde à votre vision le plus tôt possible. Cette logique s'applique, non seulement à des problèmes techniques isolés, mais aussi à la tâche plus générale consistant à exposer aussi clairement que possible vos objectifs. L'inconnu fait toujours plus peur que le connu. Si les gens comprennent pourquoi vous voulez ce que vous voulez, ils se sentiront plus à l'aise pour vous parler, même si c'est pour exprimer leur désaccord. S'ils ne peuvent pas cerner ce qui vous motive, ils s'imagineront le pire, au moins de temps en temps.

Évidemment, vous serez incapable de tout rendre public vous-même, et les gens n'attendent pas que vous le fassiez. Toutes les entreprises ont leur secrets, celles à but lucratif en ont peut-être plus, mais les organisations à but non-lucratif en ont aussi. Si vous devez défendre une certaine orientation, mais que vous ne pouvez rien dévoiler sur le pourquoi, donnez les meilleurs arguments que vous avez malgré ce handicap, et acceptez le fait que vous n'aurez peut-être pas autant d'influence que vous le souhaiteriez dans la discussion. C'est l'un des compromis à faire pour avoir une communauté de développement absente du registre des salaires.

L'argent ne fait pas tout

Si vous êtes un développeur payé au sein d'un projet, définissez rapidement ce que l'argent peut acheter, ou pas. Cela ne veut pas dire que vous devez envoyer deux messages par jour sur les listes de diffusion pour réaffirmer votre nature noble et incorruptible. Non, vous devez essentiellement montrer que vous êtes conscient que des tensions peuvent survenir à cause de l'argent. Inutile de vous lancer dans le projet en supposant que ces tensions existent, mais faites savoir clairement que vous êtes prêt à désamorcer ces situations si elles venaient à se présenter.

Le projet Subversion me fournit un très bon exemple. Subversion a été lancé en 2000 par CollabNet, donateur principal du projet depuis sa création et employeur de plusieurs développeurs (note : je n'en fais pas partie). Peu après le début du projet, nous avons engagé un autre développeur, Mike Pilato, pour se joindre à notre effort. À ce moment là, l'écriture du code avait déjà commencé. Bien que Subversion n'en fût encore qu'à ses balbutiements, il possédait déjà une communauté de développeurs respectant un ensemble de règles de base.

L'arrivée de Mike a soulevé une question intéressante. Subversion avait déjà une règle pour l'attribution, à un nouveau développeur, de l'accès de commit. Il commence par proposer des correctifs à la liste de développement. Lorsqu'il a fait ses preuves et que les autres committers voient que le nouvel arrivant sait ce qu'il fait, quelqu'un propose qu'il valide ses changements lui-même (cette proposition est privée, comme décrit dans la section « Committers »). En supposant que tous les committers soient d'accord, l'un d'entre eux envoie un courrier au nouveau développeur et lui propose un accès de commit direct aux dépôts du projet.

CollabNet a engagé Mike tout spécialement pour travailler sur Subversion. Pour ceux qui le connaissaient déjà, ses aptitudes à coder et son envie de travailler sur le projet ne faisaient aucun doute. De plus, les développeurs volontaires avaient une très bonne relation avec les employés de CollabNet. Ils n'auraient certainement pas émis d'objection si nous avions donné l'accès de commit à Mike dès le jour de son embauche. Mais nous savions que nous établirions alors un précédent. Si nous avions accordé l'accès à Mike sans passer par le processus habituel, nous aurions envoyé le message que CollabNet, de part son statut de mécène principal, avait le droit d'ignorer les règles du projet. Même si les conséquences n'auraient pas forcément été visibles sur le champ, progressivement les développeurs bénévoles se seraient sentis privés de leur droit de vote. Les autres développeurs doivent mériter leur accès de commit, CollabNet l'achète.

Donc Mike accepta de commencer chez CollabNet comme tout autre développeur volontaire, sans accès de commit. Il envoya des correctifs aux listes de diffusion publiques, là où ils pouvaient être vérifiés par tout le monde (et l'ont été). Il fut aussi dit sur les listes que nous le faisions délibérément, afin que tout le monde comprenne bien la démarche. Après quelques semaines d'activité intense de la part de Mike, quelqu'un (je ne me souviens plus si c'était un développeur de CollabNet ou pas) proposa qu'on lui donne l'accès de commit, lequel lui fut accordé, comme nous nous y attendions.

Cette cohérence vous apportera la crédibilité que l'argent ne pourra jamais acheter. Et la crédibilité est une monnaie de valeur dans les discussions techniques : elle fournit une immunité contre la remise en cause des motivations. Dans le feu de la discussion, les gens ne se contenteront pas nécessairement d'arguments techniques pour remporter la bataille. Le principal donateur du projet, en raison de sa profonde implication et de son intérêt évident pour la direction prise par le projet, est une cible plus facile que les autres. En respectant scrupuleusement les règles du projet dès le début, le donateur ne s'expose pas plus que les autres.

Vous pouvez aussi lire une histoire similaire sur http://blogs.sun.com/roller/page/DaneseCooper/20040916 à propos de l'accès de commit. Cooper était alors la « Diva Open Source » chez Sun Microsystem, je crois que c'était son titre officiel. Dans ce billet, elle décrit comment la communauté de développement Tomcat parvint à faire respecter par Sun les mêmes règles concernant l'accès de commit pour ses propres développeurs et les développeurs extérieurs.

Tout ceci implique également que le modèle de gouvernance du « Dictateur bienveillant » (voir la section « Le dictateur bienveillant » dans le Chapitre 4, Infrastructure sociale et politique) est plus compliqué à mettre en place en présence de dons, en particulier si le dictateur travaille pour le donateur principal. Une dictature ayant peu de règles, il est difficile pour le donateur de prouver qu'il se conforme aux standards de la communauté, même si c'est effectivement le cas. Ce n'est évidemment pas impossible, il suffit que le meneur du projet soit capable de voir les choses à la fois du point de vue d'un développeur extérieur et de celui du donateur. En tous cas, je vous conseille de garder sous le coude une proposition de système de gouvernance non dictatoriale, prête à être sortie dès que vous percevez les signes indicateurs d'une insatisfaction grandissante dans la communauté.

Signer des contrats

Le travail sous contrat doit être géré avec précaution dans les projets de logiciel libre. Idéalement, vous voulez que le travail de la personne sous contrat soit accepté par la communauté, et ajouté à la distribution publique. En théorie, peu importe qui est le signataire, tant que son travail est bon et satisfait aux lignes directrices du projet. La théorie et la pratique peuvent se rejoindre également : une personne complètement étrangère au projet proposant un bon correctif le verra en général ajouté au logiciel. Par contre, produire un bon correctif, une amélioration importante ou une nouvelle fonctionnalité, pour une personne complètement étrangère au projet, n'a rien de trivial : elle doit d'abord en discuter avec le reste du projet. La durée de cette discussion est par nature imprévisible. Un contrat payé à l'heure pourrait vous coûter nettement plus cher que prévu. Payé au forfait, le développeur pourrait se retrouver avec plus de travail qu'il ne peut supporter.

Deux solutions existent. La plus courante est de prévoir intelligemment la durée du processus de discussion, en se basant sur des expériences passées, en prévoyant une marge d'erreur, et baser le contrat là-dessus. Cela aide également à décomposer le problème en autant de parties indépendantes que possible, pour faciliter la prévision de chaque partie. L'autre possibilité est de signer le contrat uniquement pour la livraison d'un correctif, et de traiter séparément l'acceptation du correctif par le projet. Il devient alors beaucoup plus simple de rédiger le contrat, mais il vous incombe de maintenir le correctif tant que vous dépendez du logiciel, du moins le temps de parvenir à faire entrer le correctif, ou une fonctionnalité équivalente, dans le développement. Évidemment, même avec ces solutions privilégiées, le contrat ne peut pas imposer l'intégration du correctif au code, cela reviendrait à vendre quelque chose qui n'est pas à vendre (que se passerait-il si le reste du projet décidait sans prévenir de ne pas supporter cette fonction ?). Cependant, le contrat peut exiger un effort de bonne foi pour que la modification soit acceptée par la communauté, et qu'elle soit validée dans le dépôt si la communauté le juge bon. Par exemple, si des règles existent au sujet des modifications du code, le contrat peut y faire référence, et préciser que le travail doit y être conforme. En pratique, tout fonctionne généralement comme prévu.

La meilleure tactique pour que la signature d'un contrat se révèle payante est d'engager un développeur du projet, un committer de préférence. L'influence d'un développeur au sein d'un projet est principalement due à la qualité du code qu'il produit et aux relations avec ses pairs. Le fait qu'il soit sous contrat pour mener à bien certaines tâches ne change en rien son statut, quoique cela puisse amener un examen plus attentif de ces faits et gestes. La plupart des développeurs ne risqueraient pas leur statut à long terme dans un projet en supportant une nouvelle fonctionnalité inappropriée ou largement désapprouvée. En fait, en engageant un développeur, en plus du travail sur le code, vous obtiendrez (ou devriez obtenir) aussi des conseils concernant des modifications ayant une chance d'être acceptées par la communauté. Vous bénéficierez également d'un léger glissement des priorités du projet. Puisque les priorités sont établies en fonction des disponibilités de chacun, quand vous achetez le temps de quelqu'un, le travail de cette personne remonte un peu dans la liste des priorités. C'est une vérité bien comprise par les développeurs Open Source expérimentés, et certains d'entre eux feront attention au travail de la personne sous contrat, simplement parce qu'il a une chance d'être achevé : ils veulent donc aider à ce qu'il soit bien fait. Peut-être n'écriront-ils aucune ligne du code, mais ils discuteront quand même de sa conception et en feront des vérifications, les deux pouvant être très utiles. Pour toutes ces raisons, il vaut mieux faire signer une personne parmi celles déjà impliquées dans le projet.

Deux questions surviennent alors : les contrats devraient-ils toujours être privés ? Et s'ils ne le sont pas, devriez-vous vous inquiéter des possibles tensions engendrées par l'embauche de tel développeur plutôt que tel autre ?

Mieux vaut être transparent au sujet des contrats, quand vous le pouvez. Sinon l'attitude du signataire pourrait sembler étrange aux autres membres de la communauté : il va peut-être, soudainement, vouloir donner une priorité importante à des fonctions auxquelles il n'avait jamais prêté attention par le passé. Quand les gens lui demanderont la raison de ce revirement, comment pourra-t-il répondre de façon convaincante s'il ne peut évoquer le fait d'avoir signé un contrat pour les écrire ?

Ne soyez pas présomptueux non plus, ne faites pas passer (ni vous ni le contractant) vos accords pour plus importants qu'ils ne le sont. Trop souvent, j'ai vu des prestataires débarquer sur une liste de développement en pensant que leurs contributions allaient être prises plus sérieusement pour le simple fait d'être payés. Ce genre d'attitude montre au reste du projet que pour la personne signataire, le contrat, en opposition au code résultant du contrat, est la chose qui compte. Mais pour les autres développeurs, seul le code compte. Quoiqu'il arrive, l'attention devrait être centrée sur les problèmes techniques, pas sur des histoires de qui paie qui. Un développeur de la communauté Subversion, par exemple, manie l'aspect contrat d'une manière particulièrement élégante. Pendant qu'il parle de ses modifications du code sur IRC, il dira à part (souvent sous la forme d'une remarque privée à l'un des committers) qu'il est payé pour son travail sur cette fonction, ou sur ce correctif en particulier. Mais en même temps, il donne systématiquement l'impression de vouloir de toute façon travailler sur ce changement et qu'il est content que l'argent lui en donne la possibilité. Il révèlera, ou pas, l'identité de son client, mais dans tous les cas, il ne se repose pas sur le contrat. L'essentiel de son discours est technique, et porte sur la manière de mener les choses à bien, les mentions à ses contrats ne sont que des remarques.

Cet exemple illustre une autre raison de ne pas cacher l'existence des contrats. Il se peut que plusieurs organisations financent des contrats sur un même projet Open Source. Si chacun sait ce que les autres tentent de faire ils peuvent partager leurs ressources. Dans le cas ci-dessus, le donateur principal du projet (CollabNet) n'est impliqué d'aucune manière dans ces contrats ponctuels, mais savoir que quelqu'un d'autre finance certaines corrections de bogues permet à CollabNet de concentrer ses ressources sur d'autres bogues, ce qui au final améliore l'efficacité globale du projet.

Quelle conséquence aura cette barrière artificielle créée par les contrats ? En général, il n'y en a pas, notamment quand les personnes rémunérées sont des membres bien implantés dans le projet et respectés par la communauté. Personne ne s'attend à ce que les contrats soient répartis équitablement entre tous les committers. Les gens comprennent l'importance des relations à long terme : les incertitudes liées à la signature de contrats sont telles, qu'une fois trouvée la personne avec qui vous pouvez travailler en toute confiance, vous êtes peu enclin à changer d'interlocuteur par simple soucis d'équité. Voyez les choses ainsi : à la signature du premier contrat, il n'y aura pas de plainte puisqu'il fallait de toute évidence choisir quelqu'un (ce n'est pas de votre faute, si vous ne pouvez engager tout le monde). Par la suite, engager la même personne une deuxième fois relève du bon sens : vous la connaissez déjà, votre association a fonctionné précédemment alors pourquoi prendre des risques inutiles ? Il est donc parfaitement normal de se reposer sur une ou deux personnes dans la communauté plutôt que de répartir le travail régulièrement.

Révision et acceptation des changements

Malgré tout, l'aboutissement d'un contrat dépend beaucoup de la communauté. L'implication des autres membres, dans la conception et le processus de vérification des modifications importantes, ne peut pas être ignorée. Elle doit être considérée comme une partie du travail, et être entièrement prise en compte par la personne sous contrat. Ne voyez pas l'examen fait par les autres développeurs comme un obstacle à surmonter, voyez le comme un espace de question/réponse et de conception libre. Ce n'est pas une épreuve à endurer, c'est une opportunité à saisir.

Cas d'étude : le protocole d'authentification de mot de passe CVS

En 1995, nous n'étions qu'un binôme à assurer le support et les améliorations pour CVS (Concurrent Versions System ; voir http://www.cvshome.org/). Mon partenaire Jim et moi même étions, de manière officieuse, les personnes chargées de maintenir CVS à ce moment. Mais nous n'avons jamais vraiment pris la peine de penser aux relations que nous entretenions avec la communauté de développement existante de CVS, des volontaires pour la plupart. Pour nous, ils envoyaient les correctifs et nous les appliquions, c'était à peu près comme ça que ça marchait.

À cette époque, le travail en réseau sur CVS n'était possible que grâce à un programme de connexion distant tel que rsh. Le fait d'utiliser le même mot de passe, pour l'accès à CVS et pour ce programme, était un risque de sécurité évident qui découragea de nombreuses entreprises. Une grande banque d'investissement nous engagea pour créer un nouveau système d'authentification, afin qu'ils puissent utiliser CVS en ligne de manière sécurisée depuis leur bureau distant.

Jim et moi avons accepté le contrat et pris le temps d'établir un nouveau système d'authentification. Notre solution était plutôt simple (les États-Unis exerçaient un contrôle sur l'exportation de code chiffré à cette époque, donc nos clients comprenaient que nous ne pouvions introduire une authentification forte), mais comme nous n'avions pas d'expérience dans ce domaine, nous avons commis quelques gaffes qui n'auraient pas échappées à un expert. Nous aurions facilement détecté ces erreurs si nous avions pris le temps d'écrire un premier jet et de le soumettre aux autres développeurs pour inspection. Mais nous ne l'avons jamais fait, ignorant les compétences des volontaires prêts à nous aider. Certains que les gens accepteraient sûrement tout ce que nous pourrions proposer et, parce que nous ignorions nos lacunes, nous n'avons pas pris la peine de faire le travail de manière ouverte, c'est-à-dire, d'envoyer fréquemment des correctifs, en faisant des petites modifications, facilement digestibles pour une branche spécifique, etc. Le protocole d'authentification résultant n'était pas très bon, et bien sûr, une fois mis en place, difficilement améliorable pour des raisons de compatibilité.

L'expérience ne posait pas de problème, nous aurions facilement pu apprendre ce que nous devions savoir. C'est plutôt notre attitude vis-à-vis de la communauté de développeurs bénévoles qui posait problème. Nous considérions alors la validation des modifications comme un obstacle plutôt qu'une opportunité d'amélioration. Puisque nous savions que tout ce que nous faisions serait accepté (comme c'était effectivement le cas), nous n'avons pas fait l'effort d'impliquer les autres.

De toute évidence, lorsque vous choisissez un contractant, vous voulez quelqu'un ayant les bonnes aptitudes techniques et une bonne expérience pour cette tâche. Mais il est aussi important de choisir quelqu'un ayant un bon passé de relations constructives avec les autres développeurs au sein de la communauté. Ainsi vous n'engagez pas seulement une personne, vous engagez un agent susceptible de s'appuyer sur un réseau de compétences pour s'assurer que le travail réalisé est robuste et facile à maintenir.

Financer ce qui ne touche pas à la programmation

Mais la programmation n'est la seule activité au sein d'un projet Open Source, loin s'en faut. Du point de vue des volontaires du projet, c'est la partie la plus visible et la plus glamour. Ce qui veut malheureusement dire que les autres activités, comme la documentation ou les tests formels par exemple, peuvent parfois être négligés, comparés à l'attention qu'ils reçoivent dans les logiciels propriétaires en tout cas. Les entreprises arrivent parfois à compenser cette lacune en assignant une partie de leur infrastructure de développement de logiciel interne à des projets Open Source.

La clé du succès de cette opération est de réussir à faire la transition entre les processus internes de l'entreprise et ceux de la communauté de développement publique. Une telle transition ne se fait pas sans heurts : souvent les deux groupes ne se ressemblent en rien, et les différences ne peuvent être gommées que par une intervention humaine. L'entreprise peut, par exemple, utiliser un système de suivi de bogues différent de celui du projet publique. Et même s'ils utilisent le même logiciel de suivi, les données qui y sont stockées seront très différentes puisque les besoins de suivi de bogues d'une entreprise ne sont vraisemblablement pas les mêmes que ceux d'une communauté de logiciel libre. Une information inscrite dans un suivi devrait peut-être apparaître dans l'autre, en enlevant les parties confidentielles ou, à l'inverse, en en ajoutant.

Les parties qui suivent traitent de la création et du maintien de ces connexions. Au final, le projet Open Source devrait tourner plus souplement, la communauté reconnaissant le fait que l'entreprise investit une partie de ses ressources, sans pour autant avoir l'impression que l'entreprise poursuit uniquement ses propres objectifs.

Assurance Qualité (ou : Tests professionnels)

Les logiciels propriétaires bénéficient souvent de l'attention d'équipes dédiées entièrement à l'assurance qualité : chasse aux bogues, tests de performances et d'extensibilité, vérification de l'interface et de la documentation, etc. Par expérience, ces activités ne sont pas traitées avec autant de rigueur par la communauté de volontaires dans un projet de logiciel libre. C'est en partie dû au fait que les volontaires sont rares pour ces travaux peu valorisants, mais aussi parce que les développeurs comptent sur leur grande communauté d'utilisateurs pour avoir de nombreux retours d'expérience et, en ce qui concerne les performances et l'extensibilité, en partie parce que les volontaires ont, de toute façon, rarement accès aux ressources matérielles suffisantes.

Maintenant, l'équation « beaucoup d'utilisateurs = beaucoup de testeurs » n'est pas totalement dénué de sens. Ce n'est certainement pas très utile d'assigner des testeurs aux fonctions basiques en utilisation normale : ces bogues-là seront rapidement détectés par les utilisateurs au cours de leur usage courant du logiciel. Mais parce que les utilisateurs essayent simplement d'obtenir un résultat, ils ne vont pas d'eux même se mettre à explorer les confins inexplorés des fonctionnalités du programme, et laisseront certainement passer certaines catégories de bogues. De plus, quand ils trouvent une astuce pour contourner facilement un bogue, ils l'utilisent souvent sans prendre la peine de remonter le bogue. Plus insidieusement, l'utilisation que font vos clients (les personnes qui motivent votre intérêt pour le logiciel) du programme peut être complètement différente de l'usage qu'en fait l'utilisateur lambda.

Une équipe de test professionnelle peut mettre à jour ce genre de bogues et ne fait pas de distinction entre un logiciel libre et un logiciel propriétaire. Le plus difficile reste de faire le lien entre l'équipe de test et l'équipe de développement. Les services de tests internes ont en général leur manière bien particulière de rapporter les résultats des tests, en employant un jargon spécifique à l'entreprise ou en s'appuyant sur une connaissance spécialisée de clients particuliers et de leurs données. Ces rapports ne sont pas adaptés à un système de suivi de bogues public, à la fois à cause de leur forme et pour des problèmes de confidentialité. Même si le logiciel de suivi interne de bogues de votre entreprise est le même que celui utilisé par le projet public, les dirigeants pourraient avoir besoin de faire des commentaires spécifiques aux entreprises et d'apporter des changements aux metadonnées concernant les incidents (par exemple, pour élever la priorité interne du problème ou prévoir sa résolution pour un client en particulier). En général ce type de note est confidentielle, parfois elles ne sont même pas montrées au client. Mais, quand bien même ne seraient-elles pas confidentielles, elles ne concernent en rien le projet public, et par conséquent, elle ne devraient pas distraire les volontaires.

C'est le cœur du rapport de bogue lui-même qui est important pour le public. En fait, un rapport de bogue émanant de votre service de test a, en quelque sorte, plus de valeur qu'un autre envoyé par un utilisateur quelconque puisque le service de test pousse plus loin ses investigations que les autres utilisateurs. Comme il est peu probable que vous receviez ce rapport de bogue précis de la part d'une autre source, vous avez vraiment intérêt à le préserver et à le rendre disponible au projet public.

Le service qualité peut directement remplir un rapport dans le suivi public de problèmes, s'ils sont suffisamment à l'aise avec. Sinon un intermédiaire (en général l'un des développeurs) peut « traduire » le rapport interne du service de test et le répertorier dans le suivi public. Traduire signifie simplement « décrire le bogue en ne faisant pas référence à des informations confidentielles du client » (la manière de le faire survenir peut utiliser des données du client, avec l'accord du client évidemment).

Il est préférable, d'une certaine manière, que le service qualité remplisse directement les rapports dans le système de suivi public. L'implication de votre entreprise dans le projet gagne en visibilité : des rapports de bogue utiles consolideront sa crédibilité autant que n'importe quelle contribution technique. Un lien direct entre les développeurs et l'équipe de test s'établit. Par exemple, si l'équipe qualité interne surveille le système de suivi public, un développeur peut valider un correctif pour un bogue d'extensibilité (pour lequel le développeur peut ne pas avoir les ressources nécessaires au test), en ajoutant une note au rapport demandant à l'équipe qualité de vérifier si le correctif a l'effet désiré. Quelques développeurs opposeront une certain résistance, les programmeurs ont tendance à voir le service qualité, au mieux, comme un mal nécessaire. L'équipe qualité peut facilement surmonter cette réticence en trouvant des bogues importants et en remplissant des rapports compréhensibles. L'interaction directe entre l'équipe qualité et l'équipe de développement perd nettement de son intérêt si leurs rapports ne sont pas au moins aussi bons que ceux provenant de la communauté d'utilisateurs réguliers.

Quoi qu'il en soit, une fois qu'un rapport public existe, le rapport interne original devrait simplement y faire référence pour ce qui est du contenu technique. La direction et les développeurs payés peuvent continuer à annoter le rapport interne avec des commentaires particuliers à l'entreprise comme ils le jugent nécessaire, mais ils doivent continuer à utiliser le rapport public pour les informations qui devraient être disponibles à tous.

En vous engageant dans cette voie vous devez vous attendre à plus de contraintes de gestion. Maintenir deux rapports pour un bogue représente, naturellement, plus de travail que de maintenir un seul rapport. En contrepartie, beaucoup plus de codeurs verront ce rapport et pourront apporter leur contribution à la solution.

Conseils légaux et protection

Les organisations, qu'elles soient ou non à but lucratif, sont presque les seules entités à prêter attention aux problèmes juridiques dans les logiciels libres. Les développeurs pris individuellement comprennent souvent les nuances entre les différentes licences Open Source, mais ils n'ont, en général, ni le temps ni les ressources pour suivre les lois sur le droit d'auteur, les marques déposées et les brevets en détail. Si votre entreprise possède un service juridique, il peut aider un projet en contrôlant les droits d'auteur du code et en aidant les développeurs à comprendre les possibles problèmes liés aux brevets et aux marques déposées. Dans le Chapitre 9, Licences, droits d'auteurs et brevets, nous aborderons plus en détail la forme exacte que peut prendre cette aide. Assurez-vous surtout que la communication entre le service juridique et la communauté de développement, si elle existe, se fasse en tenant compte des différences entre les deux parties. Il arrive que ces deux groupes s'ignorent, chacun pensant que l'autre n'a pas les connaissances spécifiques requises. Un intermédiaire (en général un développeur ou alors un avocat ayant des connaissances techniques) pourra faire le lien entre les deux et l'assurer aussi longtemps que nécessaire.

Documentation et convivialité

La documentation et la convivialité sont deux points faibles connus des projets Open Source, bien que à mon avis, au moins en ce qui concerne la documentation, la différence entre les logiciels libres et propriétaires soit souvent exagérée. Néanmoins, par expérience, on constate que beaucoup de projets Open Source n'ont pas de documentation extraordinaire ni ne recherchent la convivialité.

Si votre entreprise veut aider à combler ces lacunes dans un projet, elle devrait chercher à engager des gens qui ne sont pas des développeurs réguliers du projet, mais, qui seront capables d'interagir de façon productive avec les développeurs. Il ne vaut mieux pas engager de développeurs actif pour deux raisons : d'une, vous ne rognerez pas sur le temps de développement, et de deux, ceux qui sont au plus près du logiciel, ne sont, en général, pas les mieux placés pour écrire la documentation ou pour en étudier la convivialité parce qu'ils ont du mal à voir le logiciel du point de vue d'une personne extérieure au développement.

Dans tous les cas, les personnes travaillant sur ces problèmes seront amenées à communiquer avec les développeurs. Trouvez des gens qui ont un niveau technique suffisant pour parler à l'équipe de programmation, mais qui ne sont pas autant impliqués dans le logiciel afin qu'ils puissent s'identifier aux utilisateurs normaux.

Un utilisateur de niveau moyen est certainement la personne la plus à même d'écrire une bonne documentation. En fait, après la publication de la première édition de ce livre, j'ai reçu cet e-mail d'un développeur Open Source qui s'appelle Dirk Reiners :

Un commentaire sur L'argent ; « Documentation et convivialité » : quand nous avons eu de l'argent à dépenser, et que nous avons décidé qu'un tutoriel pour débutant était ce dont nous avions besoin en priorité, nous avons engagé un utilisateur de niveau moyen pour l'écrire. Il était passé par la phase d'apprentissage suffisamment récemment pour se souvenir des problèmes, mais il les avait surmontés, il savait donc comment les décrire. Cela lui a permis d'écrire quelque chose, et les développeurs n'avaient plus que des petites corrections à apporter concernant ce qu'il n'avait pas écrit correctement, mais il couvrait quand même ces choses « évidentes » que les développeurs auraient omises.

C'était vraiment la personne idéale pour nous, car son boulot était de présenter le logiciel à d'autres personnes (des étudiants), il rassemblait donc l'expérience de beaucoup d'utilisateurs, ce qui était une coïncidence heureuse pour nous mais certainement assez rare aussi.

Fournir hébergement/bande passante

Pour un projet qui n'utilise pas les services d'une forge (voir la section appelée « Forges » dans la |Chapitre 3, Infrastructure technique), fournir un serveur, une connexion réseau et, mieux encore, une aide à l'administration système, peut être d'une importance primordiale. Même si c'est tout ce que votre organisation fera pour le projet, cela peut être une manière relativement efficace d'entretenir une bonne image, mais vous n'obtiendrez en retour aucune influence sur les décisions prises par le projet.

Vous pouvez sûrement espérer une bannière de publicité, ou un signe de reconnaissance sur la page principale du projet, remerciant votre entreprise pour la mise à disposition de l'hébergement. Si vous faites en sorte que l'adresse Web du projet soit sous le nom de votre entreprise, vous obtiendrez une association un peu plus marquée simplement au travers de l'URL. La plupart des utilisateurs penseront que le logiciel a un rapport avec votre entreprise, même si vous n'apportez rien du tout au développement. Mais les développeurs ne sont pas dupes, et ne seront pas forcément satisfaits que vous hébergiez le projet, sauf si vous apportez d'autres ressources que simplement de la bande passante. Après tout, les possibilités d'hébergement sont nombreuses maintenant. La communauté pourra au final décider que ce mérite indu ne vaut pas la commodité apportée par l'hébergement offert, et décidera de déménager le projet ailleurs. Donc si vous voulez offrir un hébergement, faites le, mais prévoyez de rapidement vous impliquer encore plus, ou soyez circonspect à propos du niveau d'engagement que vous prétendez fournir.

Marketing

N'en déplaise aux développeurs Open Source, le marketing fonctionne. Une bonne campagne marketing peut alimenter le bouche à oreille autour d'un produit Open Source, au point que même les codeurs les plus bornés se mettent à voir d'un bon œil le logiciel pour des raisons qu'ils ne peuvent pas vraiment définir. Une description détaillée de la course à l'armement du marketing en général n'est pas le sujet de ce livre. Toute entreprise impliquée dans un logiciel libre réfléchira, tôt ou tard, aux moyens de se vendre, de vendre le logiciel ou de vendre ses relations avec le logiciel. Les conseils ci-dessous vous aideront à éviter les pièges classiques de ce type d'effort, voir aussi la section appelée « Publicité » dans le Chapitre 6, Communication.

Souvenez vous que vous êtes surveillé

Afin de conserver la communauté de développeurs bénévoles de votre côté, il est très important de ne rien dire qui ne soit pas vérifiable. Contrôlez scrupuleusement toutes vos affirmations et donnez au public les moyens de les vérifier de son côté. La vérification indépendante et rapide est une grande part de l'Open Source et cela s'applique au-delà du code.

Évidemment, personne ne conseillerait aux entreprises de donner des informations non-vérifiables de toute façon. Mais, dans les activités Open Source, le nombre de gens possédant les compétences pour vérifier ces affirmations est exceptionnellement élevé, des gens qui ont probablement une connexion à Internet à haut-débit et les contacts qu'il faut pour publier leurs découvertes et faire des dégâts s'ils le veulent. Quand une grande industrie chimique pollue une rivière, c'est vérifiable, mais seulement par des scientifiques formés, qui peuvent être réfutés par les scientifiques de cette industrie chimique, le public, perplexe se demandera qui croire. À l'opposé, votre comportement dans le monde Open Source n'est pas seulement visible et enregistré, il est aussi facile pour beaucoup de personnes de le vérifier indépendamment, d'aboutir à leurs propres conclusions et de propager ces conclusions par le bouche à oreille. Ces voies de communications sont déjà établies, c'est l'essence même du fonctionnement de l'Open Source, et elles peuvent être utilisées pour transmettre toutes sortes d'informations. Vous défendre est en général très dur, voir impossible, en particulier quand ce que les gens disent est vrai.

Par exemple, vous pouvez dire que votre organisation a « fondé le projet X » si vous l'avez effectivement fait. Mais ne vous proclamez pas « créateurs de X » si la majeur partie du code a été écrite par des développeurs étrangers à votre projet. À l'inverse, n'affirmez pas que vous avez une communauté de développeurs volontaires profondément engagée si, par une simple vérification des dépôts, n'importe qui peut constater que l'écrasante majorité des modifications sont apportées par vos employés, et non pas par des volontaires extérieurs à votre entreprise.

Il n'y a pas si longtemps, j'ai vu une annonce faite par une entreprise informatique très connue affirmant qu'ils allaient publier un paquet logiciel important sous une licence Open Source. Quand la première annonce a été faite, j'ai jeté un œil à leur dépôt de gestion de versions, désormais public, et j'ai vu qu'il ne contenait que trois révisions. En d'autres termes, ils ont réalisé l'importation du code source mais presque rien n'a changé depuis. Ce n'est pas inquiétant en soi, ils venaient juste de faire l'annonce après tout. Il ne fallait pas s'attendre à voir tout de suite une activité frénétique.

Un peu plus tard, ils ont fait une nouvelle annonce. Voilà ce qu'elle disait, les noms et les numéros de version ont été remplacés par des pseudonymes :

Nous sommes heureux d'annoncer qu'après avoir subi des tests rigoureux réalisés par la Singer Community, Singer 5 pour Linux et Windows est maintenant prêt pour une utilisation professionnelle.

Curieux de savoir ce qu'ils avaient découvert par leurs « tests rigoureux », je suis repassé par le dépôt pour y voir l'historique des changements récents. Le projet en était toujours à la version 3. Apparemment, ils n'avaient pas trouver un seul bogue qui valait la peine d'être corrigé avant la sortie ! En pensant que les résultats des tests de la communauté avaient dû être enregistrés quelque part, j'ai ensuite examiné le système de suivi de bogues. Il y avait exactement six problèmes a traiter, dont quatre l'étaient déjà depuis quelques mois.

Cela défie l'entendement. Quand les testeurs s'attaquent à de gros morceaux compliqués d'un logiciel pendant un certain temps, ils trouveront forcément des bogues. Même si les correctifs pour ces bogues ne sont pas inclus dans la version à venir, on s'attend quand même à voir une certaine activité dans le logiciel de gestion de versions, activité résultante du processus de test, ou au moins de nouveaux rapports. Pourtant, selon toute vraisemblance, rien ne s'est passé entre l'annonce du passage à une licence Open Source et la première version Open Source.

Le problème n'est pas que l'entreprise ait menti à propos des tests faits par la communauté. Je ne sais pas du tout s'ils mentaient ou pas. Mais ils ne se rendaient pas compte qu'un observateur pouvait voir ça comme un gros mensonge. Puisque ni le dépôt de gestion de versions ni le suivi de problèmes ne donnent d'informations indiquant que le prétendu test rigoureux a eu lieu, l'entreprise n'auraient pas dû faire l'annonce du tout, ou alors, en fournissant un lien clair vers des résultats tangibles des tests (« Nous avons trouvé 278 bogues, cliquez ici pour plus de détails »). Ce dernier aurait permis à n'importe qui de mesurer l'activité de la communauté très rapidement. En l'état, cela m'a pris plusieurs minutes pour déterminer que, quoi que fut ce test au final, il n'avait pas laissé de trace aux endroits habituels. Ce n'est pas beaucoup demander, et je suis sûr de ne pas être le seul à avoir pris la peine de faire cette recherche.

La transparence et la vérifiabilité sont aussi essentielles aux remerciements bien formulés. Voir la section « Remerciements » dans le Chapitre 8, Encadrer les volontaires pour en savoir plus à ce propos.

N'attaquez pas les produits Open Source concurrents

Abstenez vous de critiquer les logiciels Open Source concurrents. Vous pouvez tout à fait exposer des faits négatifs, c'est à dire des affirmations facilement vérifiables, comme c'est souvent le cas dans les bons tableaux comparatifs. Mais il vaut mieux éviter les caractérisations négatives moins rigoureuses pour deux raisons. Premièrement, elles sont susceptibles d'initier une guerre malsaine qui éloigne des discussions productives. Et surtout, deuxièmement, il se peut que certains développeurs volontaires de votre projet travaillent également sur le projet concurrent. C'est plus probable qu'il n'y paraît de prime abord : les projets appartiennent au même domaine (c'est pourquoi ils sont en compétition) et les développeurs ayant des compétences dans ce domaine peuvent apporter leur contribution partout où leur expérience est utile. Même quand il n'y a pas de chevauchement direct, il est probable que les développeurs sur votre projet soient au moins en relation avec les développeurs de l'autre projet. Des messages commerciaux trop négatifs pourraient affecter les liens personnels constructifs qu'ils entretiennent.

S'attaquer aux produits closed source concurrents semble être plus largement accepté dans le monde Open Source, en particulier quand ce sont des produits Microsoft. Personnellement, je déplore cette tendance (bien qu'encore une fois, il n'y ait aucun mal à faire une comparaison directe basée sur des faits), non seulement parce que c'est grossier, mais aussi parce qu'il peut être dangereux pour un projet de commencer à croire en sa propre popularité, et, de ce fait, ignorer que les rivaux peuvent en fait être meilleurs. De manière générale, faites attention aux effets que peuvent avoir les annonces commerciales sur votre propre communauté de développement. Les gens peuvent devenir tellement enthousiastes à cause du soutien des dollars du marketing, qu'ils ne voient plus objectivement les forces et les faiblesses de leur logiciel. Il est normal, et même attendu, de la part des développeurs de l'entreprise de montrer un certain détachement par rapport aux annonces commerciales, même dans les forums publics. Évidemment, ils ne devraient pas contredire le message commercial directement (à moins qu'il soit en fait faux, mais il est souhaitable que ce genre de faux-pas soit détecté plus tôt). Mais ils peuvent le tourner en dérision de temps en temps, c'est un moyen de ramener le reste de la communauté sur Terre.

Chapitre 4 : Infrastructure sociale et politique

Page d'accueil du projet

Chapitre 6 : Communication