Inner Source : Quand les entreprises se réinventent en communautés open source

Le repository privé est la clé de voûte de l’architecture logicielle qui va sous-tendre l’initiative Inner Source de l’entreprise. Outre les solutions logicielles, tous les grands services de « repos » proposent des offres d’hébergement de projets privées pour les entreprises. Les communautés open source intéressent de plus en plus les DSI et pas uniquement pour aller vers l’Open Source : cette nouvelle organisation du travail des développeurs peut être transposée en entreprises ! C’est ce que l’on nomme l’Inner Sourcing. De Facebook à IBM en passant par Amazon, les Bell Labs, Samsung, Paypal et, tout dernièrement Microsoft, de plus en plus d’éditeurs de logiciels et services basculent vers l’Inner Sourcing, c’est-à-dire calquer l’organisation de leurs équipes internes de développement sur les pratiques des communautés open source. Mieux, ce mouvement touche désormais des entreprises plus traditionnelles comme Ericsson, Nokia, Philips Healthcare, ou même Thales, une entreprise dont on imagine mal voir le code source de ses armes publié sous licence open source. Cette idée de transformer les développeurs d’une entreprise en une communauté open source interne n’a rien de très nouveau. Cette piste a été évoquée dès l’an 2000 par Tim O’Reilly. En mettant en place ce type d’organisation, les entreprises espèrent accélérer les cycles de développement par une amélioration de la collaboration entre développeurs, améliorer aussi la qualité du code produit, la qualité de la documentation du code, etc. Gaël Blondelle, vice-président en charge du développement de l’écosystème de la fondation Eclipse souligne : « L’Inner Source correspond bien au contexte où l’entreprise a de multiples silos de développement qui communiquent mal entre-eux. L’Inner Sourcing permet de mieux faire collaborer ces silos et éviter de voir le même code redéveloppé en plusieurs endroits. » Difficile d’évoquer l’Inner Source en entreprise sans parler de chaîne d’intégration continue. Il s’agit d’un prérequis pour se lancer dans une telle stratégie.

Pas de méthode universelle

Contrairement aux méthodes agiles et autres démarches DevOps, il n’existe pas de méthode et de définition exacte de l’Inner Sourcing. Pour cet expert de l’Open Source, trois grands principes doivent être privilégiés dans la mise en place d’une démarche Inner Source : la transparence, l’ouverture et la méritocratie. « Pour la transparence, tout ce qui survient dans un projet doit être écrit sur un média interne public du projet, qu’il s’agisse d’un wiki, d’un forum, d’une mailing list. C’est une bonne pratique qui est assez facile à répliquer en entreprise. L’ouverture, c’est permettre à n’importe qui de participer à un projet open source, même si c’est un concurrent. En Inner Source, cette ouverture est faisable : il suffit qu’un manager décrète que dans le cadre de la transformation digitale, n’importe qui pourrait contribuer à un projet publié sur la forge d’entreprise. » C’est sans doute la méritocratie qui est le concept le plus difficile à imposer en entreprise où la hiérarchie et l’avancement de chacun est déterminé par les RH. « Le développeur doit montrer publiquement ce que l’on sait faire, avoir fait ses preuves en tant que contributeur avant d’être coopté par les autres contributeurs », souligne Gaël Blondelle. « C’est certainement ce qu’il y a de plus compliqué à mettre en place dans une entreprise traditionnelle car cette méritocratie se heurte à l’organisation d’entreprise. » « Getting Started with InnerSource, la bible de l’Inner Sourcer décrit comment Paypal a mis en place cette organisation en interne et l’Américain diffuse ce modèle via l’initiative InnerSource Commons.

Partage d’expériences

Paypal est sans doute l’entreprise qui milite le plus pour l’adoption de l’Inner Source par les entreprises. De nombreux ouvrages ont été publiés sur la question prenant le spécialiste du paiement Internet en exemple et Paypal est à l’origine d’InnerSource Commons, une initiative open source visant à regrouper les meilleures pratiques dans ce domaine et publier des Patterns, des modèles à suivre qui sont bien évidemment disponibles sous licence ouverte sur GitHub. En France, Florent Zara, CTO de Henix et responsable de la stratégie Inner Source chez un grand énergéticien européen, a créé un groupe de travail qui réunit plusieurs grands comptes français afin de partager les expériences de chacun. Plusieurs grandes entreprises françaises échangent sur diverses thématiques clés dans la réussite de tels projets, parmi lesquelles la rédaction de templates de chartes internes, les aspects juridiques, de gestion de communautés mais aussi évoquer les métriques et la manière dont une entreprise par vocation commerciale peut mesurer les gains financiers qu’elle peut tirer d’une telle démarche.

Qui dit Inner Source ne dit pas forcément Open Source

Si le vice-président de la fondation Eclipse espère que ces démarches Inner Source finiront par transformer les entreprises françaises en contributeurs actifs dans les communautés open source avec la publication de certains de leurs projets sous licences ouvertes, l’Inner Sourcing ne conduit nécessairement pas à l’Open Source. De même qu’une telle démarche n’est pas directement liée aux méthodes agiles et à DevOps. Gilles Gravier, directeur et consultant senior de l’activité open source et Blockchain de Wipro distingue pour sa part trois grandes approches : « Il y a d’une part des entreprises qui vont vers l’Inner Source afin de stimuler l’innovation et la créativité tant parmi leurs collaborateurs internes que parfois leurs partenaires. La deuxième raison est plus récente et c’est l’accompagnement de DevOps distribué à large échelle et enfin une troisième motivation, c’est la volonté d’aller vers l’Open Source. Paradoxalement, je ne suis pas très fan de cette approche car bien souvent les entreprises attendent que leur projet soit fini, que le code soit nickel pour le publier or un projet n’est jamais achevé et cela n’aboutit jamais au final ! » Le dernier venu au mouvement Inner Source va faire sourire plus d’un barbu de l’Open Source puisque c’est Microsoft ! Qui a annoncé récemment basculer ses équipes développements sur ce nouveau mode d’organisation.

Intégration continue, un préalable

Le volet outillage ne peut être négligé dans le succès d’un projet d’Inner Soucing. Mettre en place un repository de code, que ce soit en interne ou sur l’un des nombreux services Cloud disponibles comme GitHub, GitLab, SourceForge et leurs nombreuses alternatives qui permettent d’héberger des projets privés ne suffit pas. En effet, c’est bien d’une chaîne d’intégration continue complète dont il faut disposer afin de véritablement profiter du coup de turbo que va représenter l’Inner Sourcing dans le développement du code. Sophie Gautier, coordinateur des projets de la fondation The Document Foundation et consultante pour le cabinet Inno3 souligne : « Il faut bien évidemment mettre en place un système de gestion de versions distribué, mais aussi des solutions de gestion d’assurance qualité. Un morceau de code ne pourra être contribué dans le système qu’à partir du moment où celui-ci a passé les tests unitaires qui lui sont attachés. » La contributrice au projet OpenOffice.org estime que l’entreprise doit déjà avoir une bonne maturité dans l’intégration continue avant de pouvoir songer à l’Inner Sourcing, l’idéal étant d’avoir une chaîne d’intégration continue complète et surtout automatisée qui va permettre au développeur de réaliser le commit de son code et voir celui-ci basculer en production sans intervention humaine. « Cette approche nécessite un ensemble d’outils de gestion des tests, les Tinderbox et une plate-forme de type Jenkins permet de faire tourner ces tests de manière permanente. Celle-ci doit être couplée avec le système de bug tracking comme Mantis ou Jira. » Toute cette chaîne d’outils existe en Open Source et elle est aujourd’hui parfaitement bien documentée et déployée pour tout ou partie chez les grands comptes français. En outre, le volet documentation de code qui est la clé dans le succès de l’approche ne doit pas être négligé, des outils tels que Doxygen viennent extraire les commentaires du code afin de générer automatiquement la documentation. Si l’Inner Source intéresse les grands comptes qui font travailler des bataillons de développeurs à travers le monde, Florent Zara estime que l’approche peut tout aussi intéresser les ETI : « Je connais une ETI française de trois cents personnes dans le domaine financier avec des développeurs qui travaillaient en silos avec 1 à 2 développeurs par spécialité. Le jour où un développeur quitte l’entreprise, c’est une compétence qui disparaît. L’Inner Source permet de casser ces silos et de mieux partager l’information entre tous ces développeurs ».

L’Open Badge, un outil de valorisation du développeur Inner Source

La méritocratie est l’un des points clés dans le succès d’une stratégie d’Inner Sourcing. Sur une communauté open source, un développeur peut faire reconnaître ses compétences par ses pairs. En entreprise cette méritocratie peut être recréée par un système de badges, à la façon des scouts. Initiée par la fondation Mozilla en collaboration avec la Fondation MacArthur, le format Open Badge vise à faire sortir des limites de l’entreprise la reconnaissance de ces badges avec un format reconnu de tous et qu’il est possible d’ajouter à un CV. De tels badges commencent à être attribués par des universités, y compris en France avec les universités de Caen et de Tours ou encore l’Université confédérale Léonard-de-Vinci.

« Mon espoir, c’est que les entreprises qui adoptent l’Inner Source aillent un jour vers l’Open Source »

Gaël Blondelle, vice-président de la fondation Eclipse.

« L’Inner Sourcing, c’est appliquer les bonnes pratiques de l’Open Source dans les entreprises, regarder comment fonctionnent les fondations Open Source pour essayer de répliquer leurs modes de fonctionnement dans les entreprises, adapter ces mécanismes aux contraintes des entreprises. Mon espoir, c’est que les entreprises qui adoptent l’Inner Source aillent un jour vers l’Open Source, ce qui semble être un cheminement assez naturel, mais ce n’est pas nécessairement lié et c’est même parfois le contraire qui se passe. Nous avons collaboré avec Thales qui a commencé par faire de l’Open Source avant de songer à répliquer cette démarche sur ses projets internes et faciliter le partage de code parmi ses multiples filiales à l’international. »

« L’Inner Source est un excellent moteur pour faire du DevOps Distribué »

Gilles Gravier, directeur et consultant senior de l’activité open source et Blockchain de Wipro.

« Travailler en mode DevOps en local, cela fonctionne très bien, par contre dès lors que les équipes sont réparties sur plusieurs continents, c’est plus compliqué. Ce que nous proposons aux entreprises, c’est mettre en place des mécanismes de type Inner Source où l’on va mettre en place des dépôts de code source communs à toutes les équipes qui travaillent en mode distribué, chacun sur des éléments différents. Cela permet de transformer un modèle DevOps qui n’est pas tellement pensé pour travailler sur des points géographiquement très éloignés en un modèle qui fonctionne très bien. En cela, j’estime que l’Inner Source est un excellent moteur pour faire du DevOps Distribué ».

« Il est préférable de démarrer la démarche sur un petit projet »

Sophie Gautier, coordinateur des projets de la fondation The Document Foundation, consultante pour le cabinet Inno3.

« Il n’y a pas de méthodologie toute faite pour aller vers l’Inner Source. Il faut laisser la place à une certaine ouverture dans le modèle et chaque entreprise doit choisir ses outils en fonction de son mode de travail interne. Il y a bien évidemment de grands principes d’industrialisation du code à respecter, comme de disposer d’une plate-forme d’intégration continue, c’est du bon sens. J’estime qu’il est préférable de démarrer la démarche sur un petit projet, pouvoir qualifier l’ensemble de la démarche afin de réfléchir à la charte qui doit être rédigée en fonction de la culture d’entreprise. Il faut notamment réfléchir à la façon dont seront récompensés les contributeurs, la manière dont seront gérés les conflits, etc. »

« L’Open Source a gagné dans les infrastructures, mais aussi dans les mentalités »

Florent Zara, CTO et consultant senior en stratégie open source/Inner Source chez Henix

« On assiste à un véritable mouvement des grands comptes français sur le sujet de l’Inner Source. Les grandes banques sont en train de sortir du bois et le groupe de travail que j’ai monté accueille déjà la Société Générale, le Groupe Adeo (Leroy Merlin), la SNCF va se lancer à son tour, de même que PSA, qui partagent leurs expériences sur leurs projets d’Inner Sourcing. L’Open Source a gagné sur les infrastructures d’entreprise, mais aussi dans les mentalités et les processus de développement. Les entreprises veulent aujourd’hui reproduire ce qui fait le succès des communautés open source en interne, pour des questions de qualité de code, pour faciliter la collaboration des équipes internes, mais aussi renforcer leur attractivité sur le marché de l’emploi auprès des développeurs, des experts UX, des Data Scientists. »