Qu’est-ce que le développement “Inner Source” et pourquoi l’utiliser ?

Inner source vs Open Source

Inner Source, fréquemment écrit « InnerSource », fait référence à la mise en place de processus et de méthodologies de développement open source à l’intérieur d’une organisation. Alors que l’open source implique la création d’outils accessibles au public, l’inner source désigne le fait de travailler sur des projets internes en recourant à des approches dérivées de l’open source.

Les processus open source permettent une collaboration simple et rapide. Les questions et les demandes sur des plateformes comme GitHub, accessibles au public, permettent à chacun de contribuer à un projet. Les bogues sont découverts et corrigés rapidement, en toute sécurité et en toute transparence, dans un environnement qui favorise les discussions régulières entre les responsables et les utilisateurs.

Ce modèle peut fortement opposer la manière dont les logiciels sont développés au sein des grandes organisations. Dans ces environnements, les outils sont développés de manière ponctuelle par des équipes individuelles. Les gens travaillent en silos, contribuant à leur propre domaine, sans se soucier des travaux qui se déroulent ailleurs.

C’est quoi Inner Source ?

Le concept d’inner source consiste à appliquer les leçons tirées de l’open source à des projets internes d’une organisation. Cela consiste à rendre visible le code de différents projets intéressant à partager, créant ainsi une culture plus ouverte où les équipes peuvent trouver des projets existants qui pourraient également être utiles à leur travail, afin que chacune y apporte ses propres améliorations.

Inner Source ne concerne pas uniquement le code. Il peut être étendu pour comprendre des ressources et de la documentation plus diverses concernant l’entreprise, ses opérations et ses logiciels. L’objectif est de permettre aux individus de travailler sur d’autres projets en lien avec leurs propres projets afin de mettre leur expérience au service de l’organisation, même s’ils sont engagés pour travailler dans un domaine précis.

Inner Source : Les avantages

Les adeptes du ” innersource ” soulignent plusieurs avantages de cette approche, parmi lesquels figurent la réduction des gaspillages, l’accélération des délais de lancement, la diminution des tensions entre les équipes et l’amélioration de la qualité du code.
Tous ces avantages se rejoignent pour améliorer la productivité de l’organisation.

• Réduction des gaspillages, amélioration de la réutilisation

Dans les grandes entreprises, il arrive que des codes similaires soient dupliqués dans plusieurs projets appartenant à des équipes différentes. Si les équipes ne se parlent pas, le fait que vous ayez trois bibliothèques de mise en cache identiques peut passer inaperçu.
La publication du code en interne permettra de prévenir les autres équipes de la présence d’outils similaires, ce qui favorisera le développement commun sur une base de code unique. La roue ne sera plus réinventée, ce qui permettra à chacun de rester concentré sur sa tâche et contribuera à accélérer le délai de lancement.

• Amélioration de la qualité du code

Un code conçu dans un espace ouvert est davantage visible, de sorte que les bogues sont plus facilement détectés durant le processus de développement. Lorsqu’une nouvelle équipe adopte une bibliothèque partagée, elle peut découvrir des problèmes qui n’avaient pas été détectés jusque-là. La mise en œuvre de corrections profitera à tous les projets exploitant cette bibliothèque.

En complément du partage de code, du partage des connaissances et des bonnes pratiques de développement entre les équipes qui sont essentielles. Des solutions intégrées dans les outils des développeurs existent pour permettre aux équipes de partager facilement des connaissances avec l’ensemble de l’entreprise. Les plugins et la plateforme proposés par Promyze (www.promyze.com) permettent d’utiliser les pratiques de l’Inner Source et de les appliquer au partage de bonnes pratiques de développement.

Des formations au CleanCode complémentent cette approche.
Dans ce domaine notre plateforme Upskill4IT apporte des solutions innovantes pour former les collaborateurs sur ces bonnes pratiques.

• Diminution des tensions au sein des équipes

Le passage à un système ouvert peut sembler délicat au début, toutefois, le développement en interne a pour but de faire tomber les barrières et d’améliorer la collaboration. Le développement clos peut créer des situations de tension si vous découvrez qu’une autre équipe a conçu une meilleure version d’une fonctionnalité que vous utilisiez. Dans un système ouvert, ce problème est résolu en collaborant sur une base de code commune qui inclut les fonctionnalités nécessaires à l’ensemble du groupe.

Comment mettre en place un système d’Inner Source ?

Dans sa version la plus simple, l’Inner Source est appliqué en utilisant votre plateforme de gestion de version et en transformant la confidentialité des projets de Privé à Interne.

Deux aspects fondamentaux sont à prendre en compte dans toute transition : la communication et les outils.
La première consiste à informer les membres à propos de ce qui se passera et de la manière dont ils pourront collaborer aux différents projets.

Le deuxième aspect, les outils, implique la sélection des logiciels qui permettront de gérer le système de travail inner source . Une équipe logicielle opérationnelle utilisera déjà un système de contrôle de version, tel que Github, pour la gestion du code.

Inner Source fait appel à un modèle de développement unifié qui fonctionnera de manière cohérente sur tous les projets. Cela signifie qu’il faut utiliser au maximum les fonctionnalités du système de gestion et de votre plateforme d’hébergement, comme GitHub ou GitLab.

Pensez également à la manière dont les documents annexes, tels que la documentation et les listes de corrections, sont stockés et mis à disposition. Créez une page wiki ouverte à toutes les équipes pour ce genre de documents. Veillez également à ce que tous les bogues et les demandes de fonctionnalités soient répertoriés dans un emplacement principal. Ainsi, toutes les personnes de l’organisation pourront trouver les informations dont elles auront besoin. De plus, cela permet aux individus d’apporter des améliorations à des projets qui ne leur sont pas destinés durant une période creuse – n’importe qui peut trouver des rapports de bogues et commencer à les résoudre, ce qui entraîne des améliorations au sein de l’entreprise en général.

Inner Source : Les inconvénients

L’Innersource est basé sur un modèle collaboratif, ces systèmes qui se basent sur ce modèle ont tous le même problème, très peu de monde participe. Pour résoudre ce problème, il faut “animer” la communauté Inner Source avec des personnes qui vont avoir un rôle clé “les ambassadeurs de l’inner source“.

Inner Source est déjà devenu une réalité dans de nombreuses entreprises. Les avantages qui peuvent être obtenus sont séduisants dans les situations où une efficacité et un débit élevés sont souhaités. Comme toute méthode de travail, elle n’est pas nécessairement adaptée à tous les environnements.

L’une des craintes les plus fréquentes concernant l’inner source est son impact sur la sécurité et la divulgation d’informations. Les similitudes entre l’inner source et l’écosystème open source sont limitées : en effet, le code d’une application ou d’une structure ouverte ne contient rien de sensible, alors que vous pouvez avoir affaire à des systèmes exclusifs très protégés dans le cadre de votre travail.

Il est normal que certains projets soient toujours confidentiels et accessibles uniquement par les parties concernées et les responsables du projet. Cependant, le fait d’avoir ce genre de  projets, qui ne peuvent être rendues visibles à l’ensemble de l’organisation, ceci ne doit pas signifier pour autant que le projet d’inner source est voué à l’échec.

Un autre défi de l’inner source est de communiquer les attentes aux développeurs. Les développeurs sont parfois réticents à explorer des projets ouverts, surtout si l’inner source est introduit dans une organisation habituellement fermée. Ce problème peut être résolu de différentes manières, par exemple en accordant aux développeurs du temps pour inspecter le code créé par d’autres équipes.

Il peut également être utile de commencer petit, en n’exposant que les ressources de base qui seront utiles à de nombreuses équipes au sein de l’organisation.

Conclusion

L’Inner source consiste à prendre les méthodes de développement de la communauté open source et à les appliquer aux projets et aux procédures internes. Elle facilite le partage des bonnes pratiques et l’accès sans entrave au code et à de la documentation utile tout en favorisant la collaboration et la communication.

Correctement mis en œuvre, l’Inner source peut représenter un point fort pour une organisation en réduisant les répétitions, en augmentant le rendement et en favorisant une culture du développement plus juste. Le choix de laisser des projets ouverts au sein de l’organisation permet aux créateurs de profiter des talents de toute l’organisation. De la même manière que les principaux outils et logiciels Open Source tirent parti des capacités collectives de la communauté, les logiciels internes peuvent créer des outils internes qui vont au-delà de ce qu’une seule équipe pourrait réaliser.

Inner Source peut être difficile à mettre en place. Il peut susciter des désaccords entre les propriétaires des codes et des méfiances de la part des développeurs. Lors de la mise en place du développement du Inner Source, quelle qu’en soit la forme, veillez à ce que les gens soient sur la même longueur d’onde, en précisant clairement les attentes et les procédures de travail. Tout le monde a besoin de se sentir à l’aise pour contribuer au projet afin que tous les avantages du Inner Source puissent se concrétiser.

Si vous souhaitez du support pour structurer une stratégie Inner Source au sein de votre entreprise, vous pouvez également nous contacter.

Nous  proposons en effet un mini audit gratuit pour une première analyse des axes à optimiser sur le sujet au sein de votre entreprise.