Outre mon habituelle soif de découvertes technologiques, de rencontres et de réseautage, j’avais une raison de plus cette année de me rendre sur le salon Open Source Experience. Je devais en effet y recevoir, au nom de CS GROUP, le prix de la Meilleure stratégie open source, décerné par l’Union des entreprises du logiciel libre et du numérique ouvert (CNLL) dans le cadre du concours Les Acteurs du Libre.

Trophée de la meilleure stratégie open source 2023

Étant l’artisan de la gouvernance sur laquelle a été bâtie cette stratégie et animant depuis sa création en 2013 notre Open Source Program Office (OSPO), je tire une fierté personnelle de ce prix. Il vient récompenser mon engagement et un long travail d’acculturation des équipes et des managers de CS GROUP au logiciel libre et aux modèles de collaboration et d’innovation ouvertes. Ce prix est pour moi une belle reconnaissance de mes pairs.

Comme je l’ai écrit sur LinkedIn, rien de tout cela n’aurait été possible sans le soutien et l’engagement d’autres personnes, qui ont joué un rôle clé dans le processus. Sans elles, toute l’énergie et la conviction que je mets dans mon travail n’auraient pas pu aboutir au si joli bilan dont peut légitimement se targuer CS GROUP aujourd’hui.

Je vous propose un tour d’horizon de cette gouvernance.

Naissance et mission d’un OSPO

C’est en 2008 que CS GROUP a décidé de libérer la bibliothèque de mécanique spatiale Orekit, qui allait devenir le logiciel emblématique de son savoir-faire (tant dans le domaine métier adressé qu’en conduite de projet libre), et son plus grand succès technique et communautaire.

Mais ce n’est qu’en 2013 que CS GROUP s’est dotée d’un OSPO (initialement baptisé « Comité de Pilotage du Logiciel Libre (CPLL) », car si le terme OSPO existait déjà à l’époque, son usage n’était guère répandu et il n’avait pas encore la valeur d’étendard universellement compris qu’il a acquise à partir de 2020). Il a reçu dès le départ pour mission de :

  • Acculturer les collaborateurs – personnel technique, mais aussi chefs de projets, responsables d’activité et commerciaux – au logiciel libre, au droit d’auteur et aux licences, de manière à leur donner un vocabulaire commun, une compréhension partagée des opportunités, des avantages, des risques et des enjeux, ainsi que les bons réflexes (i.e. se poser les bonnes questions en amont, rechercher du support auprès de l’OSPO, des experts en logiciel libre et du service juridique).

  • Sécuriser l’usage du logiciel libre en qualifiant à la demande, sur le plan juridique, voire de manière holistique (qualification juridique et technique, évaluation de la vitalité du projet et de sa communauté, vérification de l’existence d’une offre de support commercial…), les composants libres intégrés dans les projets. Assez vite, le besoin de qualification s’est étendu aux autres ressources immatérielles disponibles sur Internet (données, images, polices de caractères, fichiers audios et vidéos, documents ou plus récemment, modèles d’IA).

  • Sécuriser les libérations et contributions de code en vérifiant qu’elles sont :

    • Possibles – les droits patrimoniaux sur l’œuvre n’ont pas été cédés à un tiers, et le cadre règlementaire et contractuel du projet permet cette publication
    • Réfléchies – vérifier que l’émetteur de la demande a évalué les enjeux, s’est posé les bonnes questions, a un avis et sait dans quel processus il s’aventure
    • Opportunes – la publication doit être conforme à la stratégie de l’entreprise et approuvée par la chaine hiérarchique du demandeur – chef de projet, responsable d’activité et directeur de division
    • Valorisantes – la publication est pertinente et sérieuse, le code est propre et un minimum documenté, les mentions de copyright et de licence sont correctes, les bonnes pratiques du logiciel libre sont respectées

Pour mener a bien sa mission, l’OSPO a élaboré la gouvernance du logiciel libre et open source de l’entreprise, qu’il a documentée via :

  • Une Charte du logiciel libre et open source et 9 règles d’or (version synthétique de la charte)
  • Des procédures de libération et de contribution, ainsi que les modèles de dossier associés et des exemples
  • Des guides de licences (rédigés à la demande)

Il met en œuvre, fait évoluer et anime cette gouvernance depuis maintenant 10 ans.

Publications instruites par l’OSPO

En 10 ans, cet OSPO a instruit 35 demandes de contribution substantielles à des projets libres portés par des tiers et 25 demandes de libération de logiciels développés par CS GROUP sur fonds propres. Quatre types de demandes de publication de code sont examinés par l’OSPO :

  1. Contribution ponctuelle à un projet libre tiers

    Pour répondre à son besoin, une équipe de CS GROUP a modifié le code source d’un projet libre publié par un tiers, dans le but de l’améliorer ou d’en étendre le périmètre fonctionnel. Elle souhaite reverser cette évolution au projet libre et ne projette pas d’y contribuer par la suite. Il s’agit alors d’octroyer au demandeur une autorisation ponctuelle, strictement délimitée et connue à l’avance.

  2. Contribution au long cours à un projet libre tiers

    Un collaborateur souhaite reverser au fil de l’eau à un projet libre publié par un tiers, les évolutions qu’il doit réaliser dans le cadre de sa mission. Il demande à l’OSPO l’autorisation de contribuer de manière récurrente (i.e. « autant que nécessaire dans le cadre de sa mission ») à ce projet libre. De facto, la nature, le volume et le périmètre fonctionnel du code contribué ne sont pas connus à ce stade. Il appartiendra au chef de projet de les fixer au fil du temps, en fonction des besoins du projet. L’autorisation donnée par l’OSPO est alors bornée par trois informations fournies dans la demande :

    • les collaborateurs qui vont contribuer ;
    • le projet libre bénéficiaire ;
    • le contexte interne (il fixe le cadre contractuel et juridique, et donc la faisabilité de la contribution).

    Si l’un de ces éléments change, une nouvelle demande doit être adressée à l’OSPO.

  3. Contribution à un projet libre tiers sur le temps personnel d’un collaborateur

    De manière générale, les salariés n’ont pas besoin de l’accord de leur employeur pour contribuer à un projet libre tiers sur leur temps libre et avec leurs moyens propres, tant que leur contribution ne peut pas être qualifiée d’acte déloyal et n’engendre aucun conflit d’intérêt. Si un tel risque se profile, les collaborateurs de CS GROUP ont pour instruction d’obtenir l’accord préalable de leur hiérarchie pour que la situation soit identifiée et claire des deux côtés. Le collaborateur demande alors une autorisation à l’OSPO qui, s’il l’octroie, en définit précisément les limites.

  4. Libération de projet

    Il ne s’agit plus ici de contribuer à un projet libre porté par un tiers, mais de publier sous licence libre un logiciel développé par CS GROUP sur fonds propres et de décider si l’entreprise s’inscrit dans une démarche à long terme. Le cas échéant, la poursuite du développement et l’animation du projet vont demander à CS GROUP un investissement humain et financier. Toute stratégie est envisageable, de l’absence de suite à la mise en œuvre de moyens ambitieux, mais le demandeur doit y réfléchir. Le dossier est fait pour qu’il se pose toutes les questions nécessaires.

    L’OSPO n’impose pas de licence particulière, mais il vérifie que la licence envisagée est libre et open source (respectivement au sens de la Free Software Definition et de l’Open Source Definition), compatible avec celles des composants intégrés et que cette licence est pertinente au regard du contexte et des objectifs de la libération.

Retour d’expérience sur la gouvernance

Après 10 ans, on peut raisonnablement dresser un bilan et tirer les leçons d’une gouvernance.

Pragmatisme de rigueur

Lorsque nous avons élaboré la gouvernance du logiciel libre et open source, nous avons eu à cœur d’être pragmatiques et de définir des règles soutenables et équilibrées.

L’un des points clés a été le choix du niveau de décision : trop bas, il n’intègre pas la vision stratégique de l’activité, trop haut, il requiert trop de contextualisation et demande aux cadres dirigeants d’accorder de l’attention à des sujets d’intérêt marginal à leurs yeux, ce qui conduit à l’enlisement du processus de décision. Il a ainsi été décidé d’arrêter la remontée de la chaine hiérarchique au niveau du directeur de division. C’est en effet lui qui a la vision d’ensemble de la stratégie dans le domaine d’activité considéré. Le directeur de département et le chef de projet sont aussi consultés, car ils peuvent avoir connaissance d’informations qui échappent au directeur de division.

L’OSPO instruit la demande. Il procède à divers contrôles (code, licence, bonnes pratiques…), s’assure de l’accord de la hiérarchie du demandeur, traite les éventuelles réserves et donne l’accord formel au demandeur, mais il ne va jamais à l’encontre d’un refus de la chaine hiérarchique du demandeur. Lorsque cette dernière donne son feu vert, c’est l’OSPO qui donne l’accord formel au demandeur car, de par ses membres, il représente les directions technique et juridiques de CS GROUP. À travers l’OSPO, le collaborateur reçoit donc l’accord des directions technique et juridique. Il est alors couvert et personne ne peut lui reprocher cette publication ultérieurement.

Les échanges ont lieu par mail et c’est l’OSPO qui les archive en même temps que les dossiers. Il trace aussi les décisions. L’OSPO examine les demandes au fil de l’eau pour ne pas introduire de latence indue dans la prise de décision et ne pas enrayer la dynamique de l’équipe. Ce faisant, la gouvernance mise en place est perçue par tous comme efficace et réellement opérationnelle. Ce n’est pas le cas dans beaucoup d’entités avec lesquelles nous avons pu échanger, qui ont fait le choix de processus beaucoup plus lourds et formels, qui tuent dans l’œuf les velléités de contribution ou de libération de code.

Traitement simplifié des corrections de bogue

Les contributions qui sont de simples corrections de bogues ont été exclues du processus standard, car l’intérêt de CS GROUP à toujours reverser aux projets libres les corrections de bogues est évident. Ces contributions sont donc autorisées sur simple accord du chef de projet. Il connait le contexte contractuel du projet et peut donc déterminer si cette contribution est possible et si la décision appartient à CS GROUP ou si l’accord du client est nécessaire.

Cette exception peut sembler anecdotique, mais elle dédramatise les micro-contributions qui, dans beaucoup d’entreprises, sont une source d’angoisse et de décisions dommageables. Ne pas savoir contribuer en toute simplicité et sans retard une correction de bogue, c’est jouer contre l’intérêt de l’entreprise.

Évolution de la charte et des procédures

En 10 ans, l’OSPO a eu à traiter les questions les plus variées. À l’usage, les procédures se sont révélées perfectibles et certains choix arbitraires contre-productifs. Ces erreurs de jeunesse ont conduit l’OSPO à réviser les procédures et la gouvernance afin de fluidifier les processus et de les rendre plus pertinents et justifiés. Il a pu le faire aisément, car le Comité Exécutif de CS GROUP lui avait délégué l’évolution de la gouvernance.

De l’intérêt d’embarquer toutes les parties prenantes

Dans la plupart des entreprises qui se sont dotées d’un OSPO, vous verrez une personne bomber le torse en même temps qu’elle vous déclarera « l’OSPO, c’est moi ! ». À CS GROUP, l’OSPO n’est pas une personne, mais un groupe, et pas l’importe lequel. Comme je l’ai mentionné plus haut, il embarque toutes les directions internes qui comptent dans l’affaire. Ce faisant, il a une grande autonomie. A contrario, lorsque l’OSPO est réduit à une personne, celle-ci doit faire entériner ses décisions par les directions juridique et technique, et elle ne peut en réalité prendre aucune décision sans leur aval. Cette subordination alourdit considérablement les processus et pose d’autres problèmes.

Je m’en suis rendu compte au détour d’une conférence sur le sujet, quand une personne du public m’a demandé si nous rédigions un avenant au contrat de travail lorsque nous autorisions un collaborateur à contribuer à un logiciel libre. Je lui ai répondu que c’était inutile, puisque les directions juridique et technique s’exprimaient à travers l’OSPO et que les décisions étaient tracées (par mail et dans notre forge). Le collaborateur était couvert, personne ne pouvait lui reprocher ultérieurement ses contributions tant qu’il restait dans le périmètre convenu.

Besoin d’un effort de formation constant

Acculturer les équipes c’est bien, mais entre accroissement et renouvèlement des effectifs, c’est un véritable travail de Sisyphe, un effort difficile à maintenir dans le temps, surtout lorsque d’autres besoins de formation deviennent prioritaires.

Alors que notre programme de sensibilisation des collaborateurs au droit d’auteur et au logiciel libre avait donné d’excellents résultats, j’ai malheureusement constaté après une suspension de ce programme que la culture collective s’érodait très vite. J’ai vu réapparaitre dans les projets et les réponses à appel d’offres des erreurs grossières qui avaient complètement disparu deux ans auparavant et qu’il a fallu rattraper. Du coup, nous avons réintroduit une version allégée de ce programme dans le cycle de formation des nouveaux embauchés et quelques responsables d’activité commencent même à demander la réintroduction du programme originel, à minima pour leurs équipes.

Libérations et contributions

Orekit, notre plus belle réussite

La réussite d’Orekit démontre la capacité de CS GROUP à conduire un projet libre et à jouer le jeu de l’ouverture, de la collaboration et de la confiance, favorisant l’éclosion d’une communauté saine et fortement impliquée.

Orekit est une bibliothèque de mécanique spatiale en Java, dont CS GROUP a initié le développement en 2002, avant de la libérer en 2008. Orekit constitue aujourd’hui une référence dans son domaine, utilisée par de nombreux industriels du spatial, des agences gouvernementales, des laboratoires de recherche et dans l’enseignement. Orekit apparait dans de nombreux travaux scientifiques ayant trait à la mécanique spatiale.

CS GROUP a fait le choix d’un développement totalement ouvert : code source, documentation, tests et données (très importantes dans ce domaine) sont publiés au fil de l’eau sur la forge dédiée du projet, accessible à tous.

CS GROUP a sciemment choisi de publier Orekit sous une licence libre permissive (Apache v2.0) parce qu’elle rendait l’intégration d’Orekit « indolore » dans les applications propriétaires. Ce choix tactique a largement contribué à son adoption.

Afin d’ancrer durablement Orekit dans sa communauté, en 2012, CS GROUP a ouvert la gouvernance du projet à des tiers, sur la base d’un modèle méritocratique emprunté à la fondation Apache. À ce jour, le Project Management Committee (PMC) compte 14 membres représentant 9 entités différentes.

Par ailleurs, le projet compte 9 committers externes, autrement dit 9 personnes qui ont un droit d’écriture sur les dépôts de référence du projet sans pour autant travailler pour CS GROUP, ni être subordonnées à l’entreprise par un quelconque lien contractuel. Parmi les 6 personnes qui sont autorisées à dérouler le processus de release et qui partagent la clé cryptographique de signature des artéfacts, 3 seulement travaillent pour CS GROUP. Aujourd’hui, personne au sein de l’entreprise ne s’émeut qu’une release d’Orekit – projet porté par CS GROUP – soit menée par un contributeur travaillant pour l’US Navy ou Airbus Defence & Space.

Le support communautaire est assuré via le forum Discourse et le gestionnaire de bogues du projet. Hors trafic engendré par les bots, 24 000 pages sont consultées en moyenne chaque mois sur le forum où 680 utilisateurs disposent d’un compte actif (c’est considérable vu le microcosme adressé par cette bibliothèque). De plus en plus de membres de la communauté contribuent à l’animation du forum et y partagent leur expérience et leur savoir-faire.

Nous veillons à appliquer les bonnes pratiques de l’open source en matière d’animation et de gouvernance de projet. Voici ce que donne l’auto-évaluation d’Orekit, initiée en 2019, vis-à-vis des meilleures pratiques recommandées par l’Open Source Security Foundation (OpenSSF) :

  • 1er niveau (bronze) : 100 % des exigences satisfaites
  • 2d niveau (argent) : 89 % des exigences satisfaites
  • 3e niveau (or) : 57 % des exigences satisfaites

Un écosystème est né autour Orekit, marqué principalement par trois projets :

  • Hipparchus, bibliothèque mathématique avancée, issue d’un fork du projet Apache Commons Math initié par CS GROUP pour répondre aux besoins d’Orekit en s’affranchissant du dictat du projet tutélaire Apache Commons.
  • Rugged, bibliothèque de correction géométrique d’image à des fins d’orthorectification, basée sur Orekit.
  • Orekit Python Wrapper, encapsulation en Python de l’API d’Orekit, initiée et maintenue par l’agence spatiale suédoise (SSC). Ce wrapper connait un succès impressionnant et participe grandement à l’adoption d’Orekit.

Nous sommes fiers du travail accompli et de la dimension communautaire que prend le projet au fil des ans. En 2023, les contributions à Orekit venant de la communauté ont pour la première fois été plus importantes que celles venant de CS GROUP.

Autres projets libres

Le cas d’Orekit reste une exception en termes d’effort consenti (tant en investissement qu’en durée). Mais nous avons libéré bien d’autres outils. Certains, bien documentés et activement maintenus pour répondre à l’évolution de nos besoins, ont trouvé leur public au fil des ans. Le projet EODAG est le plus emblématique d’entre eux. Libéré en 2018, cet outil en Python permet, via une API unique, d’interroger diverses infrastructures de données spatiales pour identifier et récupérer sélectivement les produits répondant aux critères de recherche. Aujourd’hui, EODAG a une belle réputation parmi les personnes friandes d’images satellitaires et certains de nos clients en préconisent même l’usage dans leurs appels d’offre.

Nous contribuons aussi, de manière ponctuelle ou soutenue, à divers projets libres tiers. Par exemple, CS GROUP maintient depuis des années le support de l’architecture PowerPC dans le noyau Linux.

Sans surprise, nous ne consacrons pas les mêmes efforts à tous les projets publiés. Certains sont de simples démonstrateurs technologiques qui n’ont pas vocation à être maintenus après publication. Ils nous permettent, à un instant donné, de prouver notre savoir-faire ou d’orienter les choix techniques de nos clients dans un domaine précis. D’autres sont abandonnés après plusieurs années de développement actif, parce qu’ils n’ont pas rencontré le succès attendu ou parce que notre stratégie et nos priorités ont changé. Cette franchise ne devrait pas choquer ceux d’entre vous qui ont un peu roulé leur bosse dans l’industrie ; Github regorge de projets morts. Ces publications ont néanmoins un réel intérêt pour d’autres que nous. Primo, le code source de ces outils est mis à la disposition des utilisateurs, qui ne se trouvent pas démunis et peuvent continuer à le maintenir si c’est leur intérêt. Secundo, d’autres personnes peuvent découvrir ce code source et décider de l’utiliser dans leur propre projet.

Conclusion

En 10 ans – et même 15 si nous remontons à la libération d’Orekit – nous avons réalisé de belles choses, connu de magnifiques succès et quelques échecs, enduré des moments difficiles, mais nous avons aussi beaucoup appris. Des situations qui se sont présentées à nous il y a 10 ans seraient bien mieux gérées aujourd’hui. J’espère vous inspirer un petit peu en partageant en toute transparence mon expérience avec vous, et vous aider à élaborer dans votre entreprise une gouvernance du logiciel libre efficace, qui réponde aux attentes des collaborateurs et permette à votre entreprise de véritablement intégrer le libre dans sa stratégie, au lieu de décourager toute initiative en ce sens, comme j’ai pu le voir dans bien des entités.

Et qui sait, peut-être que dans quelques années, vous gagnerez à votre tour le prix de la meilleure stratégie open source. ;)