Communication externe

Il va vous falloir un site vitrine pour avoir une référence.

En parler, faire des annonces et des articles. Les gens n’aiment pas forcément, mais, franchement, forcez-vous, essayez, sur les réseaux sociaux, sur des canaux spécialisés. Là, je reste très générique parce que, évidemment, suivant qu’il s’agit d’une bibliothèque, d’une application, de l’embarqué, du SI [Système d’Information] ou que sais-je, les canaux ne sont pas du tout les mêmes. Ils peuvent être métiers, purement techniques, etc., mais identifiez-les et communiquez.

N’hésitez pas aussi à faire des conférences. Une collaboratrice de CS a fait, aujourd’hui, sa première conférence. C’est chouette, c’est génial, et j’espère que ce n’est que sa première. Elle a parlé de logiciel libre. Voilà, il faut les faire connaître. Des interviews, des podcasts, plein de choses.

Et surtout, soyez certain d’une seule chose : les gens ne vont pas venir vers vous spontanément. Ils ne vont pas dire « ça fait trois mois que je n’ai pas regardé le site d’Orekit ! Qu’est-ce qu’il y a de neuf ? Si ça se trouve, ils ont fait des trucs. Je vais aller voir le code et je vais faire un diff. » Ça ne marche pas comme ça.

Soyez proactifs, annoncez, expliquez que vous évoluez même si vous n’avez pas fait une release, dites « on avance, on est sur tel sujet ». Veillez à avoir une communication régulière. Régulière ne veut pas dire intensive, ça ne veut pas dire que le matin, quand vous avez déjeuné, la seconde chose à faire de la journée, c’est de publier un post sur Orekit. Non ! Mais, de temps en temps, vous annoncez, vous expliquez un petit peu ce qui se fait, vous dites qu’il y a des nouveaux commiters, plein de choses. Soyez proactifs.

Attentes des (potentiels) utilisateurs

Et puis, vous devez peut-être vous poser la question des attentes. Vous comprenez bien que si les gens utilisent votre logiciel ou y contribuent, c’est simplement parce que votre logiciel répond à leurs attentes.

Si on réfléchit, de manière générale, aux attentes des potentiels utilisateurs, clairement, ils vont vouloir une réponse ergonomique et efficace à leur besoin. Tout à l’heure, Jean-Baptiste Kempf, pour ceux qui ont assisté à ses conférences [5], a dit des choses intéressantes. Il a dit : « On mise sur l’IA pour faire du sous-titrage. En France, on s’en fiche, tout est traduit, mais ce n’est pas le cas dans tous les pays. » Ce n’est donc pas son besoin à lui, c’est un besoin des utilisateurs de VLC. Quand il parle de libcaca [6], qui rend la vidéo sous forme de flux ASCII Art, c’est intéressant pour des gens qui veulent vérifier que les flux passent, ce n’est pas son besoin à lui. Il l’a fait parce qu’il savait qu’il y avait un intérêt, que ça pouvait être utile.

Les gens veulent évidemment un outil facile à mettre en œuvre. S’il faut trois heures, voire dix-huit, pour pouvoir commencer à l’utiliser, soyez sûr que personne ne l’utilisera.

Évidemment, idéalement il doit être ergonomique, efficace, robuste, fiable. Oui, faites votre possible. Suivant la criticité de l’outil, c’est plus ou moins prépondérant.

Par contre, on va vous demander un manuel d’utilisation consistant, et la pire réponse que vous puissiez faire, c’est « tu as le code, lis-le ! ». Ça, c’est insupportable ! À la base, je suis développeur, c’est une réponse que je ne supporte pas. Un logiciel non documenté, ça ne s’utilise pas, ça se met à la poubelle.

Et puis, comme je vous l’ai dit, dès que vous allez avoir des utilisateurs, c’est le début des soucis, gentils, parfois, mais soucis, donc ils vont vouloir échanger avec vous. Il faut leur proposer un lieu d’échanges.

Attentes des (potentiels) contributeurs

Si on pense aux contributeurs, ils vont vouloir un accès libre au dépôt de code source, je dis bien dépôt. Message à ceux qui font du Libre en interne et qui, tous les six mois, publient un tarball sur leur site web. Oui, c’est du Libre s’il y a une licence libre à l’intérieur, sur l’archive. Par contre, ne vous étonnez pas de ne pas avoir de contributeurs : personne ne peut contribuer à un logiciel qu’il ne peut pas suivre au quotidien. Tous les six mois, c’est « oh ! un paquet surprise, je vais déballer, je vais voir ce qu’il y a dedans, ça va être super chouette ! ». Non, vous n’aurez pas de contributeurs ! Donc, votre dépôt de code doit être public et, si possible, vous devez le publier au fil de l’eau.

Ils vont avoir besoin d’une documentation technique pour plonger dans votre code.

Et puis, proposez-leur des outils collaboratifs, efficaces, au goût du jour. Faites un effort, si votre pile technologique ne tient plus la route, changez.

Évidemment, la qualité de conception et de codage, ça ne nuit pas. Tout à l’heure, Jean-Baptiste en parlait, il disait que dans VLC, la qualité de code est importante. Pour Orekit, c’est essentiel.

Et surtout, inversez le miroir. Demandez-vous si vous collaborez quand vous ne vous sentez pas en confiance et quand vous pensez qu’en face on vous cache tout ou beaucoup de choses. Non, vous ne vous engagez pas dans un projet, quel que soit son ordre, vous ne vous engagez pas sur un projet si vous ne sentez pas une relation de confiance et un peu de transparence. Donc, quand vous êtes à la tête d’un projet libre, vous devez faire en sorte d’instaurer cette transparence, cette confiance, pour mettre les bases d’une collaboration saine.

Que faire sur le plan technique ?

Sur le plan technique, que faire ?

Le problème principal. Je vous assure que deux projets sur trois, voire quatre sur cinq, je ne sais pas, ne sont pas capables d’écrire un readme correct. Le readme, c’est le CV de votre projet. Ce n’est pas sa documentation in extenso, c’est juste un endroit où on doit avoir, sous forme synthétique, les informations qui intéressent peu ou prou la plupart des gens. Certains ne savent pas faire. Il existe, sur le Net, toute une littérature, il existe des guides, il existe même des outils qui vous aident à générer. Essayez-les. Je vous ai pointé deux choses [makeareadme.com et readme.so] qui ne sont pas trop mal, qui peuvent vous aider, mais ça ne fera que l’amorçage du boulot.

Derrière, en fait, quand on réfléchit dans un readme, que faut-il ? Dans tout ce que j’ai listé, quand je mets, par exemple, « installation », ce n’est pas 3 000 lignes sur l’installation : soit c’est le truc qui s’installe super vite et vous l’expliquez là, soit c’est compliqué et vous renvoyez vers un guide d’installation. Pareil pour beaucoup d’autres choses. Vous avez le nom du projet, une courte description. Il y a de nombreux projets où, en lisant le readme, je sais pas à quoi sert le logiciel, vous n’en reviendriez pas. Piochez au hasard dans GitHub, vous allez voir.

Les badges, c’est sexy, mais évitez le sapin de Noël. Certains sont sympas pour montrer que vous adhérez à des pratiques, que vous avez des niveaux de qualité, etc. OK, mais sinon pas trop. Shields.io vous permet de générer des badges comme vous voulez.

Les visuels, ça peut être sympa pour se faire une idée très vite. Ils doivent être simples, si vous voulez que vos utilisateurs voient un petit peu, s’il y a lieu. Pour une bibliothèque de calcul intensif, comme Orekit, un visuel, un tableau de chiffres, non !

J’ai parlé de l’installation.

L’usage qui peut être synthétique, c’est plus une mise en train.

Pareil pour le support. Où est-ce que je peux trouver du support ?

La feuille de route, s’il y en a une, c’est sympa de la pointer pour que les gens aient le point d’entrée.

Pour les contributions, pointer vers le guide des contributions, on y reviendra.

Dire merci aux gens ; quand une personne vient de faire un chose importante pour votre projet, c’est bien aussi.

Et puis le copyright et la licence. Dites-le, c’est mieux, si on le dit. Ça évite d’aller chercher ou de poser une issue.

Fournir une documentation pertinente

Y a-t-il des développeurs dans la salle ? Oui, un certain nombre. On vous a déjà demandé d’écrire la doc d’un logiciel ? Oui. Aussi peu que ça ! Aux autres, on ne vous demande pas ? Ah, d’accord, OK. On vous a expliqué comment écrire une bonne doc ? Ah oui, mais, toi, tu n’as pas le droit de jouer, il triche, on a travaillé ensemble.

Tous les développeurs ont une injonction : il faut écrire la doc. À part quand vous avez des processus très lourds d’entreprise, avec un plan de documentation plus ou moins utile et très formel, on ne vous explique pas. Et encore, même quand vous avez ce plan, on vous explique la structure qu’il doit avoir, on ne vous explique pas ce que doit contenir la doc. On ne vous a jamais expliqué, on vous a dit « vas-y, écris la doc, tu es grand, tu te débrouilleras. ». Eh bien moi je vous conseille cette ressource, The Documentation System [7], faite par la personne qui a pensé la documentation de la bibliothèque standard Python. C’est un site web qui se lit in extenso en une grosse demi-heure. Si la lecture n’est pas votre truc, il y a aussi une vidéo d’une demi-heure, qui dit à peu près la même chose, sous forme un peu différente, etc. Ce gars-là vous explique de quoi est composée une doc, les différents types de doc, ce qui doit être le présupposé, ce qui n’a rien à faire, quel état d’esprit vous devez adopter quand vous écrivez un tutoriel, un guide, etc. Vous voulez documenter, eh bien ça a sa place là. Franchement, ça démystifie la doc et c’est simple à suivre. Il faut le lire, le relire de temps en temps, c’est une demi-heure de lecture.

Coder et documenter en anglais

Nous sommes en France. C’est connu, les langues étrangères ne sont pas notre fort. On peut encore voir pas mal de logiciels qui sont codés, voire commentés ou documentés en français. Je comprends, l’anglais est une difficulté pour moi aussi, mais, franchement, utilisez l’anglais pour maximiser vos chances de réutilisation à l’échelle mondiale, de contributions à l’échelle mondiale. Si vous n’êtes pas à l’aise, a minima pour amorcer, commencez à coder en anglais et à écrire les commentaires en anglais. Au pire, vous aurez, un jour, un Américain habitant au Japon qui vous dira « vous êtes vraiment trop nul en anglais » et qui vous filera un coup de main. Mais faites cet effort-là.

Et puis, de nos jours, vous avez des traducteurs automatiques comme DeepL, vous avez des correcteurs qui vérifient que vous n’avez pas écrit les choses un peu n’importe comment. Vous avez un truc qui existe depuis 25 ans : le Grand Dictionnaire terminologique. Merci à nos amis québécois parce qu’en fait, suivant le domaine de la technique dont vous parlez, un mot ne se traduit pas de la même manière. Donc, pouvoir interroger en disant « mon domaine c’est la mécanique, comment traduit-on "bielle" ? ». Je suis dans l’informatique, comment traduit-on un serveur ?, on est d’accord, ce n’est pas waiter. Après, vous avez des dictionnaires très intéressants. J’ai découvert Cambridge Dictionary qui est vraiment une mine d’informations. Faites cet effort.

Faciliter la mise en œuvre

Si votre projet nécessite d’installer 43 dépendances, un compilateur, la bonne version du compilateur, de lire quatre kilomètres de doc, de s’arracher les cheveux pour comprendre pourquoi ça ne veut pas compiler sur votre machine, etc., vous êtes sûr que personne ne l’utilisera. Donc, veillez à fournir une forme prête à l’emploi. Là aussi, c’est un terme généraliste, parce que, suivant le type de logiciel que vous utilisez, son contexte de déploiement, etc., la bonne forme – il peut y en avoir plusieurs –, mais la bonne forme, c’est un binaire statique ou empaqueté avec toutes ses dépendances. Ça peut être un paquet pour votre distribution, pour votre langage, parce que beaucoup de langages modernes proposent un gestionnaire de paquets qui vont être téléchargés sur une source avec les dépendances. Donc, pensez à le faire. Et puis ça peut être aussi, sinon ou en plus, une image Docker[Docker, plateforme permettant de lancer certaines applications dans des conteneurs logiciels]], un script Docker Compose, ou un Chart Helm [8], pour déployer sur Kubernetes [9].

Et puis, il vous faut un guide de démarrage, un getting started, des tutoriels, des choses qui vont vous permettre d’amorcer la pompe, qui vont permettre aux gens de commencer à mettre en œuvre.

Favoriser l’échange

Il vous faut favoriser l’échange en mettant à disposition :

• un outil de signalement de bugs et de demandes d’évolution ;
• un forum moderne ; les phpBB et compagnie, vous oubliez. Je pense plutôt à des outils comme Discourse [10]. Je n’en connais pas d’autres du niveau de Discourse, il y en a peut-être d’autres, je ne suis pas omniscient, mais, franchement, Discourse est génial.
  À une époque, Orekit utilisait des listes de diffusion et, les listes de diffusion, ça a beaucoup de travers. Ça a quelques avantages, pour des vieux comme moi, mais ça a beaucoup de travers. Et, en 2018, j’ai dit à l’équipe d’Orekit « la liste de diffusion n’est plus au goût du jour. Je vous propose Discourse. Je vais vous faire une démo, vous allez voir, ça permet de coloriser du code, ça permet de joindre des documents, des images. Ça permet d’interagir de manière beaucoup plus riche, etc. Ça crée de la connaissance en ligne qui est pérenne, qui est indexable donc trouvable. C’est génial ! ». Je leur ai présenté et ils ont dit « banco, vas-y, on déploie un Discourse. » Ce à quoi je ne m’attendais pas, c’est qu’en quelques semaines, le trafic a été multiplié par 2,5 par rapport aux listes de diffusion. Preuve que la liste de diffusion était un frein, que les gens ne voulaient pas s’abonner et qu’ils ont préféré de très loin Discourse. Aujourd’hui, on est d’accord, la mécanique spatiale ce n’est pas Candy Crush, ce ne sont pas des millions d’utilisateurs, c’est vraiment un microcosme. Je crois qu’à l’heure actuelle, le forum d’Orekit ce sont environ 800/850 comptes actifs, beaucoup de messages échangés par jour. Je crois qu’on doit être, hors bots, donc vraiment de visiteurs identifiés ou non identifiés, aux alentours de 22 000 pages vues par mois. C’est énorme, c’est vraiment le point de rencontre de communauté.
• Plein de projets vous diront « Discord, c’est génial. Optez pour Discord. » Au-delà du fait que c’est un logiciel propriétaire – je ne vais pas développer mon avis sur le sujet aujourd’hui, ce n’est pas le sujet –, c’est une messagerie instantanée, c’est « tire et oublie ». Vous étiez là le jour J, vous avez vu passer l’échange, vous avez pu y participer, vous avez pu en prendre de la graine. Génial ! Vous étiez en vacances, vous n’étiez pas disponible, tant pis pour vous ! Ça ne crée pas un contenu indexable, ça ne crée pas un contenu qui est trouvable et vous ne pouvez pas interagir de manière asynchrone, sauf dans une certaine limite de temps. Sur le forum d’Orekit, parfois des gens déterrent des sujets qui ont six mois pour dire « je suis confronté à ce problème avec d’autres conditions, d’autres paramètres, etc. ».
• Comme je l’ai dit, oubliez les listes de diffusion, ça se fait plus.

Faciliter la contribution

Vous devez aussi faciliter la contribution. Et, pour faciliter la contribution, vous devez proposer un guide de contribution. Ce guide de contribution va vous permettre de guider les gens, du coup, de faciliter la mise en jambes afin d’entrer dans le projet. Et déjà, est-ce que, dans ce qu’on a vu jusqu’à présent, je vous ai déjà dit quelque part que vos contributions étaient bienvenues ? Non. Il y a quelques années, je n’ai pas fait gaffe, Orekit avait un guide de contribution et ça commençait par un git clone. Eh bien dites-donc, comme entrée en matière ! Alors, je me suis permis de contribuer un petit patch : « Salut les gars, bonjour. Vous envisagez de contribuer ? C’est génial, merci par avance, c’est chouette, cool. Sachez que vous pouvez contribuer de plein de manières, évidemment par du code, mais si vous participez au forum, que vous apportez votre expertise, c’est déjà de la contribution. Si vous soumettez des bugs ou des demandes d’évolution, c’est cool, ça nous aide. Et puis vous savez qu’il y a la documentation, on peut toujours la parfaire, on peut toujours écrire des tutoriels supplémentaires. Et puis on a un site web, etc. » Voilà ! Dire toutes les manières qu’il y a de contribuer. Je ne connais pas Java, je ne connais pas la mécanique spatiale, je pense être utile au projet Orekit. Il y a d’autres manières que le code de contribuer.

Vous devez aussi faciliter la prise en main. Effectivement, vous avez un git clone, vous expliquez à la personne comment compiler, etc., mais peut-être lui expliquer comment on déploie l’environnement. Si vous êtes dans un projet qui a un environnement de développement un peu complexe, eh bien expliquer comment faire, filer des scripts pour déployer automatiquement l’environnement développement, voire fournir une image Docker qui contient toutes les dépendances, tous les outils. Ça peut être sympa.

Et puis, plutôt que ne rien dire et rabrouer les gens, « tu as contribué, c’est sympa, mais mince, tu n’as pas écrit les tests » ou alors « et la doc, c’est pour les chiens ? Tu attends peut-être qu’on la fasse pour toi ! ». Non ! Déjà, on ne répond pas comme ça. Si je vois quelqu’un répondre comme ça sur un forum, il y a un Dinot qui débarque et qui met une petite tape derrière la tête. Ça, c’était il y a 15 ans dans Orekit, aujourd’hui, ils sont géniaux ! Franchement, j’ai une communauté géniale qui me scotche au quotidien par son savoir-vivre, son savoir travailler ensemble, ses bonnes pratiques et c’est top. Il y a 15 ans, c’était un peu plus rude.

Donc, expliquez vos attentes. Vous voulez que ce soit testé, OK, qu’il y ait la documentation, etc. Expliquez tout ce que vous attendez. Il n’y a pas que les contributeurs qui ont des attentes, le projet a des attentes. À Orekit, on ne veut pas que l’ATV ou son successeur fasse un strike dans l’ISS. Certes, ça rapporte beaucoup de points, mais très ponctuellement. Après, on vous fait quelques reproches. Donc, ils ont des exigences de qualité, de validation.

Et puis, s’il y a des règles de codage, dites-le, pointez les ressources. Pareil, pour les fichiers de configuration. Je ne sais pas si vous connaissez le projet EditorConfig ou des choses comme ça. On peut faire plein de choses.

Organiser la collaboration technique

Vous devez aussi organiser cette collaboration technique. Donc, pour cela, avoir un workflow Git documenté. On peut même, dans des forges comme GitHub, GitLab, forcer des workflows. Si vous voyez des gens qui ne respectent pas ces workflows, vous pouvez protéger des branches, etc., faire en sorte que les gens ne travaillent que par merge requests ou pull requests.

Faites en sorte d’utiliser un workflow qui soit soutenable et adapté à votre projet. Si vous êtes dans du Web, que vous êtes dans un mode course en avant, que la toute nouvelle version remplace les anciennes, OK, prenez un trunk based. Si vous êtes dans un projet comme Orekit, avec un centre de contrôle qui est qualifié avec Orekit 11 ou 12, on hésite à passer, comme ça, à Orekit 13 alors que les satellites contrôlés sont déjà en vol et pourtant, s’il y a un bug, on aimerait bien qu’il soit corrigé. Mais là, vous allez avoir besoin d’avoir des release branches pour pouvoir faire des patchs sur les différentes versions.

Des tests automatisés, franchement, ça sécurise le projet.

Mettez en place de l’intégration continue suivant les cas. Typiquement si vous faites une bibliothèque de déploiement en continu, ça n’a pas de sens. Mais, si vous faites une application, ça peut avoir du sens, mais, à minima, une livraison en continu fluidifie les process.

Le suivi qualimétrique. Si vous faites une petite bibliothèque JavaScript qui, je ne sais pas, ajoute des paillettes qui tombent sur l’écran, ce n’est pas très fiable, ce n’est pas très grave, sans doute, peut-être, tant que tout le monde ne l’utilise pas. Si vous faites des outils qui ont des missions un peu plus critiques, il vous faut mettre en place un suivi qualimétrique pour détecter les régressions, pour détecter les baisses de performance, pour vous assurer que toutes les exigences de qualité sont respectées.

Une feuille de route et des jalons, ça peut être utile, ça peut aider à se projeter. Avec la feuille de route, on voit un petit peu ce qu’il est prévu de faire, on peut même voir, du coup, qu’un développement est prévu, s’y intéresser, se greffer dessus, dire « ce sujet m’intéresse, je veux bien contribuer. »

Les jalons. Je connais une bibliothèque qui s’appelle Ossim, qui ne sait pas ce qu’est une release. Ils sont en version dev depuis…, je ne sais pas, peut-être que j’avais encore des couches à l’époque. C’est terrible ! Faites des jalons, c’est sympa, ça marque le coup, ça permet de communiquer, et puis, au moins, les gens savent que ça, c’est une version stable, qui a été testée, on ne se récupère pas un code de moitié développé, une fonction à moitié développée.

Adopter une licence libre

Au niveau des licences, il y a plusieurs aspects juridiques. La licence, si elle est mal choisie, si elle est mal fagotée, c’est vraiment potentiellement un point bloquant. Donc, il faut la choisir. Vous n’êtes peut-être pas des juristes, mais plusieurs types d’outils peuvent vous aider :

• Choose an open source license [11] va vous aider à choisir une licence parmi quelques-unes majeures ;
• TLDRLegal, Too Long, Didn’t Read [12], est un site qui fait des synthèses d’un certain nombre de licences ;
• open source.org [13], j’aurais pu mettre aussi le site de la FSF [Free Software Foundation], sur lequel il y a une liste de licences, qui vous explique un petit peu ces textes et vous verrez si la licence est compatible avec l’Open Source Definition ou la Free Software Definition.

Donc, ça va vous faire des guides.

Une fois que vous aurez choisi votre licence, veillez à ce que les composants que vous intégrez soient compatibles. Récemment, j’ai fait l’audit d’un logiciel qui était annoncé sous licence MIT. Cool, c’est bien. Quand j’ai fait le bilan des dépendances, je me suis aperçu qu’à l’intérieur, il y avait un composant sous licence GNU GPL [14]. Voilà ce que j’appelle une chimère juridique, un truc qui n’aurait jamais dû exister. Et puis, c’est sympa : les gens croient utiliser un composant sous licence libre permissive et, un jour, quelqu’un risque de leur chercher des poux dans la tête en disant « votre code, est sous GPL. – Comment ça sous GPL ? – Si. »

Et puis, la plus mauvaise idée que vous puissiez avoir, c’est d’écrire votre propre licence. Franchement ! Je vois une licence que je n’ai jamais vue, soit on me demande un audit, je vais la lire, etc., soit on me dit « conseille-nous un composant. » Déjà, il y a une licence complètement exotique, que le type a écrit sur un coin de table, il est quasiment disqualifié. Par exemple, pour l’Agence spatiale européenne, l’open source, et elle n’a pas tort de considérer ça pour ne pas se faire à refourguer n’importe quoi, ça veut dire « licence identifiée par l’OSI [Open Source Initiative] comme conforme à l’open source definition ». Pourquoi ? En France, vous avez la licence CeCILL [15], c’est super, mais, en dehors de la France, ça ne parle à personne. C’est un frein à l’adoption. Ça a été longtemps un frein à l’adoption de Scilab [16] et, du coup, Scilab a fini par choisir GPL.

Au niveau européen, vous avez l’EUPL [European Union Public License] [17], à ne pas confondre avec l’EPL [Eclipse Public License]. Ce n’est pas mal, elle est traduite en 23 langues. Mais bon, en dehors de l’Europe, ça ne parle à personne. Essayez de prendre des licences majeures, connues, etc., et je ne vous parle pas des licences de l’ESA [European Space Agency], il y en a six, trois libres, trois presque libres, qui existent en sept versions, avec en plus l’une d’elles qui a une clause facultative. Donc, en fait, il n’existe pas six licences, mais huit.

Gérer les droits patrimoniaux

L’autre problème, ce sont les droits patrimoniaux : à qui appartient, in fine, le code ? Si rien n’est fait, le code appartient à qui l’a écrit ou à qui a payé la personne qui l’a écrit. Mais bon, rester dans le flou, ce n’est pas génial.

Vous avez trois stratégies possibles.

La première stratégie, c’est ce qu’on appelle le copyright assignment, en français le transfert des droits patrimoniaux. En fait, le porteur du projet exige que tous les contributeurs lui transfèrent les droits patrimoniaux, le copyright. Pour lui, c’est super confortable, parce que, comme il est le seul ayant-droit, il fait, après, ce qu’il veut. Il faut savoir que c’est clivant. À moins que vous vous appeliez la FSF, ne le faites pas ! La FSF le fait pour de bonnes raisons. Elle le fait parce que, comme elle est la seule ayant-droit sur les logiciels du projet que GNU, si on veut attaquer le projet, on n’a pas d’autre choix que d’attaquer la FSF. Elle a les moyens de se défendre et, au pire, elle pourrait appeler à l’aide, appeler au financement, et plein de gens la financeraient pour qu’elle puisse se défendre à la hauteur des enjeux. OK. Même si c’est la FSF, même si c’est pour la bonne cause, il y a des gens qui disent « non, je ne contribue pas à GNU, parce qu’ils exigent le transfert du copyright. » Si vous vous appelez Sébastien Dinot ou je sais pas quoi, que vous exigez le transfert du copyright, vous pouvez toujours attendre les contributions, je vous assure.

Les accords de contribution, du type CLA [Contributor License Agreement], sont des accords où les contributeurs gardent leurs droits, mais, pour sécuriser les projets, ils disent « je vois qu’Orekit est diffusé sous licence Apache, je suis d’accord pour que mon code soit diffusé avec Orekit sous licence Apache v2. » Ça, ce n’est pas mal. Généralement, par exemple c’est le cas d’Orekit, mais on a copié sans vergogne la stratégie de la fondation Apache, le CLA se divise en deux documents : l’ICLA. pour Individual Contributor License Agreement, et le CCLA pour Corporate Contributor licensed Corporate.

L’individual, le gars dit « c’est bon, je suis auteur du code, ou alors j’ai vérifié que les dépendances que j’intègre sont bien sous licence conforme et tout, donc je sais ce que je fais et, oui, je suis d’accord pour que mon code soit intégré à Orekit sous licence Apache. »

Le second, surtout dans le cadre d’Orekit, un projet qui est quand même pas mal adapté en milieu professionnel, c’est « je suis l’employeur de ce monsieur ou de cette dame et moi, employeur, j’autorise cette dame ou ce monsieur à contribuer au projet libre Orekit, à verser son code. » Ça sécurise le projet.

Pendant longtemps, on a cru que c’était la panacée, parce que ça semblait blindé. En fait, il y a quand même quelques problèmes. Déjà, c’est une lourdeur administrative. Pour l’équipe, gérer ça, c’est un peu lourdingue, ça retarde les contributions, il faut obtenir les accords, etc., donc ça retarde les intégrations du code. Les gens ont parfois un peu de la gêne et disent « il faudrait quand même que ton employeur signe ça. ». Pour info, on n’a, à peu près, pas eu de refus. La seule fois où on a eu un refus, c’est assez drôle, mais je n’ai pas le temps, et, en fait, ça s’est très bien fini.

Il y a surtout un autre problème : les gens oublient de dire qu’ils ont changé d’employeur, que, donc, il faudrait mettre à jour le CLA pour qu’il soit toujours valide.

Donc, vous croyez que vous avez sécurisé, mais pas du tout.

Pour lutter contre ça, que fait, par exemple, à la fondation Eclipse, les CLA ont une durée de validité limitée à trois ans. Donc, tous les trois ans, vous devez refaire l’ICLA/CCLA. Ce n’est pas mal vu, mais, trois ans, c’est arbitraire et puis, surtout, ça accentue le problème principal du CLA qui est sa lourdeur administrative. Du coup, on a pas mal d’entreprises, de projets – quand je dis projets ou entreprises, dans le lot il y a Red Hat, GitLab et compagnie – qui ont abandonné le couple ICLA/CCLA pour passer sur ce qu’on appelle le certificat d’origine du développeur, le DCO, Developer Certificate of Origin. C’est un petit texte court, d’une vingtaine de lignes, qui, grosso modo, laisse reposer toute la responsabilité sur le développeur, sur le contributeur. C’est moins sûr au niveau juridique, ça dit « moi, contributeur, j’ai vérifié que j’avais le droit de faire ce que je fais, etc., je le fais correctement et oui, je suis d’accord pour que vous intégriez ça. »

Pour faciliter encore plus, ce ne sont pas des documents qu’on signe et qu’on envoie. Non, c’est un champ par convention qui est ajouté au commit Git, avec l’option « -s », signed off. Par convention, l’ajout de ce champ veut dire « j’adhère au DCO et je soumets mon code sous format DCO. » Comme c’est à chaque commit, du coup, c’est renouvelé à chaque fois systématiquement. Vous prenez Codium [18], vous pouvez même configurer Codium pour que, automatiquement, il rajoute le « -s », donc le champ signed off.

Favoriser l’éclosion d’une communauté

Sur le plan social, que faire ? Sur plan social, il faut favoriser l’éclosion d’une communauté. On est dans de l’humain ; c’est du technique et du juridique, mais, dans le Libre, on est avant tout dans l’humain. Donc, il faut répondre aux attentes non techniques des utilisateurs.

Comme je vous disais, montrez de la bienveillance, de la considération. Toujours pareil : inversez le miroir, mettez-vous de l’autre côté. Si on s’adresse mal à vous, vous claquez la porte. Donc, pensez-y quand vous vous adressez aux gens. Peut-être, effectivement, que c’est un débutant et c’est le troisième de la semaine qui… Tant qu’il n’abuse pas. S’il y en a un qui abuse, il y a des moyens très simples.

Petite astuce. Une pratique m’amuse beaucoup au sein de la communauté Orekit. Ils font du super support, franchement, c’est génial, ils répondent toujours à des questions parfois très techniques, très pointues, très métier, ils répondent super bien. Donc, quand vous arrivez, vous posez la question, vous la formulez bien, vous recevez très vite des réponses, parfois de plusieurs personnes. C’est génial. Parfois, il y en a quand même qui abusent. On se rend compte, en fait, qu’ils veulent qu’on code à leur place, ou alors ils sont un peu lourds, on va dire, ils abusent un peu. Eh bien, plutôt que d’envoyer paître les gens, une pratique tacite s’est installée, que j’aime bien : quand quelqu’un se met vraiment à abuser, les réponses viennent de plus en plus tard, il y a de plus en plus de latence pour la réponse. Donc, la personne va peut-être être obligée de se bouger un peu, monter un petit peu en compétences, etc. Elle va revenir avec des questions peut-être un peu moins triviales. Ça évite d’être désagréable avec les gens formellement. Et puis surtout, quand vous êtes désagréable avec quelqu’un, tout le monde voit autour que vous êtes désagréable avec cette personne, donc, vous faites passer un mauvais message. À la limite, être désagréable avec la personne qui attend que vous codiez pour elle gratos, pourquoi pas ? Le problème, c’est que toute la communauté voit ça et le retient : « À Orekit, tu peux te faire moucher », ou alors « tu as vu, comment il s’appelle, Dinot, purée ! Tu as vu comment il a répondu ? » Non.

Faites en sorte d’agir en transparence, créez un climat de confiance.

Fournissez le support. Airbus Defence and Space, quand ils ont fait leur coming out, ils ont dit « on utilise Orekit depuis quatre ans et on va se mettre à contribuer. C’est génial ! ». Ils sont mis à le dire dans des conférences et tout, c’était super, on aurait dit qu’on les avait payés. Ce qui m’a marqué, c’est qu’ils disaient qu’Orekit c’est fantastique, ça calcule bien, vite et tout, c’est fiable, mais ils disaient « lisez le support, c’est hallucinant, le support de la communauté. Vous posez une question, ils vous répondent, vous pouvez discuter avec eux. Nous on paie des éditeurs propriétaires, on n’a pas ce niveau-là de qualité ; on paie super cher, on n’a pas ce niveau-là de support. »

Doter le projet d’une gouvernance

Vous devez aussi doter votre projet d’une gouvernance formelle.

La gouvernance, c’est quoi ? C’est votre constitution. C’est le document qui explique comment vous allez travailler ensemble. Vous pouvez mettre l’objectif du projet, pour que tout le monde soit d’accord sur le cap, mais vous allez indiquer le socle de principes et de règles de fonctionnement.

En publiant cette gouvernance, vous allez faire en sorte que ces règles de fonctionnement soient connues de tous et de toutes. Ça introduit de la transparence, de la confiance, ça permet l’engagement des gens. Ils savent dans quoi ils s’aventurent : c’est ça l’objectif du projet ; les décisions sont prises comme ça, par ces personnes-là. OK. Il y a ces rôles-là dedans. OK, très bien, d’accord, je sais, ça me convient ; si ça ne me convient pas, je passe mon chemin, mais si ça me convient, je m’engage. C’est vraiment bien.

Faites cependant attention. Vous savez ce que c’est, quand même, qu’une constitution. C’est un truc assez sacré, on n’y touche pas tous les quatre matins. Donc ça sacralise des règles. Orekit existe depuis 22 ans, il y a encore écrit, dans sa gouvernance, que les contributions se font par patch envoyé par mail. Je vous rassure, il y a belle lurette que ce n’est plus le cas. Mais je pense, quand j’aurai le temps, que ça vaudra un patch et une v5 de la gouvernance. Il va falloir que le PMC [Project Management Committee] se prononce. Je vais leur suggérer ça, quand même, et deux/trois petites broutilles.

Donc, évitez, quand même, de tout sacraliser. Il faut avoir de la souplesse. Un guide de contribution, ça ne se met pas dans la gouvernance.

Choisir le modèle de gouvernance

Vous avez quatre modèles de gouvernance, je ne vais pas pouvoir développer.

Vous avez le dictateur bienveillant à vie, BDFL, c’est Linus Torvalds avec noyau Linux. Sympa pour la personne qui pilote le projet, très dur pour les autres et ça pousse au fork très vite.

Vous avez la méritocratie. C’est un pouvoir qui est distribué et qui est fonction du mérite que vous accumulez. C’est comme cela que fonctionne Orekit. En apparence, c’est extrêmement vertueux. Le problème de la méritocratie, c’est qu’on ne remet jamais en cause le mérite des personnes. Or, vous avez des personnes qui ont été très méritantes il y a 10 ans, il y a 15 ans, qui ne font plus rien dans le projet, mais tout le monde sait ce qu’on leur doit historiquement. Ces personnes continuent d’être écoutées, en plus elles sont membres du PMC, elles sont membres des autorités de décision, etc. Quand un jeune développeur, par contre, patche, envoie du code, des corrections tous les jours, il s’exprime, si le vieux, qui fait partie du PM, n’est plus d’accord, personne n’écoute le jeune contributeur. Ce n’est pas normal. Donc, la méritocratie a un travers, elle recrée des mécanismes de caste. Soit il faut avoir une méritocratie sage, qui sache dire, à un moment, « tu n’es plus actif, donc tu sors du PMC, place à de nouveaux », mais cela ne fait pas dans la méritocratie, soit il faut peut-être réfléchir à autre chose.

C’est ce qu’on fait des gens qui ont pris un modèle qu’on appelle démocratique. Grosso modo, on va mettre, comme dans nos démocraties, des élections, des mandats à durée déterminée, des renouvellements soit par entier, par tiers, par moitié, tous les un, deux, trois ans, etc., et le pouvoir tourne. Les personnes doivent, du coup, candidater individuellement, expliquer quelle est leur vision du projet, quel est leur objectif. Bref, elles doivent vendre leur candidature, elles doivent faire une campagne politique. On renouvelle.

Après, il y a modèle libéral où, là, c’est la do-ocratie : ceux qui font ont raison et puis on va se baser sur du consensus mou, etc.

Ce n’est pas forcément facile de tout éviter.

Pour les gouvernances, on n’est pas obligé de partir zéro.

Vous avez Minimum Viable Governance [19] un projet qui vise à fournir une gouvernance minimaliste d’organisation de projets.

Vous avez Governing open [20], avec pas mal de questionnements, pas mal de guides, etc.

Vous avez aussi plein d’autres choses.

Adopter un code de conduite

Dernière chose : il faut que vous adoptiez un code de conduite. C’est mon objectif pour 2025 pour le projet Orekit.

La communauté Orekit fonctionne tellement bien, les gens sont tellement Bisounours qu’ils n’ont jamais vu l’intérêt de prendre un code de conduite. Mais c’est vrai, on voit que ce ne sont que des bons citoyens. « Bonjour les gars. Tiens, j’ai pensé à ça. Regardez, j’ai réfléchi, il y a quatre scénarios, j’ai fait des diagrammes et tout. J’ai évalué les stratégies. Je propose qu’on utilise ça. Qu’est-ce que vous en pensez ? – Ah, oui, c’est cool, tu as raison, mais tu ne prends pas en compte ce cas-là. – Ah, oui, tu as raison. Je vais y réfléchir, je refais ma copie, je reviens. » Quand on est comme ça, on n’a pas besoin de code de conduite. Le problème, c’est que le jour où une personne toxique va débarquer, comment vous lui expliquerez que ce n’est pas du délit de sale gueule, mais que son comportement, son attitude, sa façon de faire n’est pas acceptable. On n’est pas dans l’arbitraire, c’est contraire aux règles du projet, mais il faut en avoir. Donc, ça, c’est un code de conduite. Et croyez-moi, ce que j’ai vu dans certains projets libres m’a rendu sûr qu’il faut un code de conduite et pourtant, à la base, je ne suis pas pour le politiquement correct.

Donc une licence, un cadre légal de collaboration et la gouvernance, c’est le cadre social.

Un projet libre a un coût

Même si le logiciel est libre, il a un coût :

• 42 années-homme rien que pour CS ;
• les serveurs, la CI et compagnie, c’est 2 550 euros par an ;
• les Orekit Days, pour la communauté, c’est plusieurs dizaines de milliers d’euros à chaque édition ;
• les plateformes SaaS, ne croyez pas que ce soit gratos. Quand on commence à avoir un projet qui a de l’ampleur, qui consomme beaucoup de ressources, ça devient payant, ça peut devenir très cher ;

Bref, il faut financer tout ça.

On peut financer par des moyens humains et par de l’argent, mais on peut fournir du mécénat, par nature, en accueillant des événements ou en faisant plein de choses, en mettant à disposition des moyens, des machines.

Vous pouvez aussi vous adresser à une fondation. Il y en a qui savent financer des projets ou qui savent fournir l’hébergement.