Accéder à une communauté de développeurs tout en restant propriétaire : la réponse de l'Inner Source

Qu’est ce que l'Inner Source ?

Issu de l’Open Source, l'Inner source s’intègre au sein des entreprises ou d’un groupement d’entreprises pour profiter du meilleur de la culture Open Source : la collaboration, l’innovation, l’amélioration, mais sans l’accès public.

Au début des années 2000, Tim O’Reilly invente le terme “ inner source” qui se développe alors au sein des entreprises réticentes à l’utilisation d'un plus grand ensemble appelé “l’Open Source”. L’Open Source prône l’accès, la modification, l’usage et le partage des codes sources de manière illimitée.

Cela signifie donc que l'Inner source est un Open Source à accès restreint comprenant uniquement votre organisation ou un ensemble d’organisations partenaires. L’accès externe est ainsi impossible. L’Inner Source se présente comme l’instrument permettant d’avoir accès à une grande communauté de développeurs tout en alliant le besoin business de rester propriétaire du code.

Comment marche l’Inner Source ?

L’inner Source Intra-Entreprise

Créer un Inner Source intra-entreprise permet une mise en commun des ressources et des compétences de chaque salarié au sein d’une même organisation. Ainsi, un développeur du département A pourra contribuer au projet du département C, mais les données ne seront publiques qu’au sein de l’entreprise, aucun accès extérieur n’est possible.

L'Inner source Inter-entreprise

Créer un Inner Source inter-entreprise permet une mise en commun des ressources et des compétences de l’ensemble des salariés de chaque département de chaque entreprise. Ainsi, un développeur d’un département A d’une société X pourra soumettre un projet à l’Inner Source inter-entreprise pour que les développeurs d’un département C d’une entreprise Y contribue au projet.

L’Inner source est collaboratif et les développeurs peuvent choisir le temps qu’ils veulent allouer en fonction de leurs besoins. Ainsi, ce modèle reste basé sur les besoins et la disponibilité des équipes de développement. La gestion est plus rationalisée et efficace.

L’entreprise doit faire preuve de transparence, d’ouverture et de méritocratie pour appliquer l’Inner Source :

• Transparence : Tout doit être écrit dans un média interne public au sein de l'organisation ou du groupement d’entreprises. Le manager reste owner du projet mais toute l’organisation a accès au travail ce qui permet une prise de hauteur.
• Ouverture : Permettre à quiconque qui y a accès de contribuer à un projet Inner Source. Par l’apport de différentes équipes, l’Inner Source contribue à l’amélioration continue et l’envie de progresser de chaque développeurs
• Méritocratie : Le développeur souhaitant prendre part à un projet doit avoir “fait ses preuves” avant d'être coopté par les autres contributeurs du projet. Ce qui permet de créer des équipes “forces spéciales”, particulièrement compétentes, en fonction de la complexité et du sujet des projets. Les propriétaires du projet cooptent les meilleurs développeurs en complémentarité avec leurs besoins et leurs équipes.

Cet “Open Source” interne est doué d’une assurance qualité efficace dû à la collaboration, le partage et la transparence des projets. Cependant, chaque manager de projet reste propriétaire et responsable. Ainsi, il veille à ce que les ajouts n’affectent pas la qualité du logiciel. Les codes sont partagés, peuvent être modifiés mais restent la propriété du “Owner”.

Quels sont les avantages de l’Inner source ?

L’amélioration de la collaboration entre développeurs permet l’accélération de cycles de développement, la qualité et la mise sur le marché du produit.

Selon le magazine Allemand CIO von IDG, un mensuel informatique pour les managers, l’Inner Source permettrait pour 87% des interrogés une réduction des coûts de support et de gestion IT, et pour 40% une réduction considérable de l'intégration et de la formation. Par ailleurs, les analystes de Forrester, une entreprise qui produit des rapports sur l’impact de la technologie dans le monde du business, mettent en évidences que l’Inner Source représente une économie de 45 minutes par jour par développeur. “L’Inner Source permet une bien meilleure qualité du code et un taux de réutilisation plus élevé” déclare le responsable IT d’une entreprise de médias.

• Collaboration : Les développeurs ne travaillent plus en silos. Ainsi, dans un contexte de turn over fréquent, le partage de l’information et sa diffusion, la collaboration entre les développeurs et la communication sont des éléments primordiaux. L’Inner Source permet de diffuser le savoir et la connaissance des projets de chacun. Cela peut pallier le problème d’un développeur qui quitterait l’entreprise et vient faciliter la formation du nouveau le remplaçant.
• Pragmatisme : Un code est développé une fois. Cela évite qu’un même code soit développé plusieurs fois dans différents endroits, ce qui constitue une perte de temps et l’augmentation de potentielles erreurs.
• Qualité : La collaboration entre développeurs renforce la qualité du code et ouvre des perspectives d’innovations. La mise en commun des compétences et la possibilité de prendre part à un projet d’un autre département permet de résoudre des problèmes, de bénéficier de plusieurs code review et d’augmenter l'implication des collaborateurs.
• Rapidité : Grâce aux inputs de tous les développeurs, il est possible de construire un processus de déploiement plus efficace pour ainsi réduire le temps de chaque déploiement. Aussi, l’intégration continue, étant un préalable à l’Inner Source, il apparaît une diminution du nombre d’interventions.
• Répartition : La mise en commun des projets répartit leurs coûts et leurs risques sur plusieurs équipes, ce qui pousse à l’innovation.
• Confidentialité et sécurité : Tout est accessible en interne et tout peut être réglé en interne (documentation, tests, planification, la gestion des versions). L’Inner Source pourrait également être un rempart contre le Shadow IT (l’utilisation de logicielles, sans l’accord préalable du département informatique), en utilisant uniquement l’Inner Source comme support de partage.

Dès lors l’Inner Source, apparaît comme une solution pertinente qui implique les développeurs, les pousse à la collaboration et au partage. Il ressort d’une étude menée par le géant Microsoft, sur un de ses projets Inner source, que plus d’un tiers du code provenait d’une autre équipe.

L’Inner Source, pour qui ?

Les entreprises qui mettent en place l’Inner Source sont souvent motivées par une de ses 3 raisons :

• Stimuler l’innovation, le partage, la créativité, et le buy in des collaborateurs ou partenaires
• Accompagnement DevOps à large échelle
• Aller vers l’Open Source

Les entreprises qui prônent l’Inner Source sont souvent d’une taille importante comme :

• Géant du web: Facebook, IBM, Amazon,Samsung, Paypal, Microsoft, Spotify, Rent the Runway
• Entreprises Traditionnelles : Philips Healthcare, Thalès, Décathlon, Bell Labs, Thomson Reuters
• Cabinets de conseil : Sopra Steria, Accenture

mais il convient également aux ETI ou à un groupement de petites entreprises partenaires.

Bosch, par exemple, a intégré en 2009 l’Inner Source par son programme “Bosch Internal Open Source” (BIOS) pour créer un nouveau système de R&D.

Paypal se fait également fervent défenseur de l’Inner Source depuis 2014 à l’arrivée de son nouveau directeur Open Source Danese Cooper. L’organisme de paiement explique à travers un manifeste son engagement pour l’adoption de l’Inner Source, un monde ouvert et rapide en contradiction avec l’ancien monde, de développement fermé et lent.

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

Les 4 étapes préalables à l’Inner Source :

• Étape 1 : Sélection des Outils (non exhaustive) :
• Repository privé : Pièce maîtresse de l’architecture de l'Inner Source. Tous les grands services de repository présentent une offre d'hébergement de projets privés pour les entreprises (Github, GitLab, Source Forge).
• Gestion de version : GIT par exemple
• Gestion des tests : Jenkins, Tinderbox (faire tourner les tests de manière permanente)
• Système de bug tracking : Jira, Mantis etc.
• Obtenir la documentation : Doxygen etc. (extraire les commentaires du code et obtenir la doc)
• Étape 2 : Une nécessaire maturité de l’intégration continue au sein de l’organisation ou du groupement d’organisation. L’Inner Source induit une chaine d’intégration continue complète et automatisée pour que le développeur puisse commit son code et le voir directement en production sans intervention humaine
• Étape 3 : Renseigner l’actif numérique de l’entreprise (si telle équipe a un passif sur IOS, ou telle personne a un passif sur tel langage informatique). Les informations seront stockées dans l'Inner Source pour envoyer des requêtes ciblées à la bonne personne/ bonne équipe en fonction du besoin du projet.
• Étape 4 : Renseigner tous les paramètres de sécurité, de confidentialité, les procédures de tests. L’Inner Source doit être “aussi ouverte que possible et aussi fermée que nécessaire”

L’Inner Source, la collaboration renforcée par la libération du capital interne à une organisation.

L’Inner Source permet aux développeurs de contribuer aux efforts de différentes équipes de différents pays au sein d’une même organisation ou d’un groupement d’organisations partenaires. Derrière ce système de fonctionnement, l’Inner Source représente une manière d’impliquer les employées dans la prise et l’implémentation des décisions de l’organisation. L’Inner Source implique une philosophie particulière de relations humaines, bordée de récompenses et de motivations apportant une grande flexibilité d’outils et un large éventail de créations. En outre, sans ce système les entreprises ont tendance à externaliser une grande partie du développement où chaque équipe dépend des bibliothèques de tiers, ce qui peut entraîner de la frustration en raison de l'inadéquation des exigences et l’inadaptation des retours entre les équipes internes et externes à l’organisation.