Qu’est-ce que l’InnerSource ?
QU'EST-CE QUE L'INNERSOURCE ?
Le terme InnerSource a été inventé pour la première fois par Tim O’Reilly en 2000 pour décrire l’utilisation de techniques de développement open source au sein d’une organisation pour développer du code propriétaire. Il promeut les principes d’ouverture et de transparence à l’intérieur du pare-feu d’une entreprise.
Lorsque l'InnerSource est mise en œuvre à grande échelle, vous pouvez consulter tout le code de votre organisation, utiliser ce qui est utile et apporter les modifications nécessaires à votre contexte. Les « Trusted Committers » décident ensuite d'intégrer ou non ces modifications dans la base de code originale. Cela reproduit le fonctionnement de la communauté open source, à l'exception que le code source résultant reste dans les limites de l'entreprise. Une excellente façon de s'habituer à la culture open source dans un environnement sûr.
Bien que l’InnerSource puisse être utilisée comme une étape vers l’open source, les organisations qui l’implémentent rapportent que cette pratique permet également de briser les silos organisationnels, de réduire les goulots d’étranglement, de favoriser le partage des connaissances et d’accélérer l’innovation. En effet, la dernière génération de développeurs ayant grandi dans un monde d’open source, avec les niveaux d’autonomie et de responsabilité qui y sont associés, l’adoption de l’InnerSource contribue à créer un environnement de travail qui facilite la recherche et la rétention des développeurs les plus talentueux d’aujourd’hui.
Origines de l'InnerSource
Bien que le terme ait été inventé au début des années 2000, l’idée de l’InnerSource a réellement commencé à prendre de l’ampleur en 2015, lorsque Danese Cooper, défenseure de longue date de l’open source, a commencé à plaider pour son utilisation.
Cela a coïncidé avec un intérêt croissant pour l’open source dans les entreprises. Danese Cooper avait été embauchée pour diriger les programmes open source de PayPal, mais elle a rapidement réalisé que PayPal devait beaucoup apprendre sur la collaboration ouverte avant de pouvoir participer avec succès à l’écosystème open source. En 2015, elle a prononcé un discours liminaire lors de la conférence annuelle OSCON et a annoncé que PayPal allait se concentrer sur le développement des compétences InnerSource dans le cadre de son parcours vers le développement open source. Lors de cette conférence, elle a également annoncé la formation de l’InnerSource Commons, une communauté de pratique pour les individus ayant pour objectif de créer et de partager des connaissances sur l’InnerSource.
Depuis lors, l’InnerSource a été adoptée par des dizaines de milliers de développeurs, dans toutes les industries, de la grande technologie à la banque, la fabrication et le commerce de détail, aux quatre coins du globe.
Le concept central : un développement logiciel efficace au-delà des silos
La réutilisation du code est devenue une priorité
clé pour de nombreuses organisations.
Dans les organisations traditionnelles cloisonnées, du code réutilisable peut exister, mais les équipes ne peuvent tout simplement pas le trouver, ne peuvent pas lui faire confiance ou n’ont aucune incitation à y contribuer. L’InnerSource aborde systématiquement chacun de ces obstacles.
En adoptant des pratiques open source en interne, le code est découvrable dans toute l’organisation et tout ingénieur peut proposer des modifications à n’importe quelle base de code. L’équipe hôte agit en tant que « Trusted Committers », examinant et fusionnant les contributions plutôt que d’écrire chaque ligne de code elle-même. L’InnerSource fournit ainsi les principes et les pratiques qui permettent une collaboration efficace dans le développement logiciel au-delà des frontières organisationnelles.
Impossible de le trouver
Code caché dans les dépôts d'équipe
Dépôts partagés et découvrables avec une documentation standardisée
Impossible de lui faire confiance
Qualité inconnue, pas de processus de révision
Le fait que le code InnerSource ait été écrit pour être vu et réutilisé, associé à une culture de révision par les pairs, produit un code de meilleure qualité et renforce la confiance
Impossible de contribuer en retour
Les frontières organisationnelles empêchent les PR
Les pratiques InnerSource (par exemple, le rôle de Trusted Committer) formalisent les contributions inter-équipes
En quoi est-ce différent de l'Open Source ?
Les mécanismes sont très similaires,
mais la portée est différente.
-
Open Source : Le code est accessible au public.
-
InnerSource : Le code reste visible et modifiable uniquement par les employés de votre organisation. Il protège votre propriété intellectuelle tout en libérant le potentiel de votre personnel.
Pourquoi les organisations adoptent l’InnerSource
-
Délai de mise sur le marché plus rapide : Les équipes ne sont plus bloquées par des dépendances envers d'autres départements.
-
Partage des connaissances : La documentation et la prise de décision transparente deviennent la norme, empêchant les connaissances d'être piégées dans des esprits individuels.
-
Code de meilleure qualité : Avec plus d'yeux sur le code et un processus de révision standardisé, les bogues sont détectés plus tôt.
-
Satisfaction des développeurs : Les ingénieurs se sentent habilités à résoudre leurs propres problèmes et à se connecter avec leurs pairs en dehors de leur unité immédiate.
Démarrer avec l’InnerSource
Découvrez le livre
pour plus d'idées sur la façon de démarrer dans votre organisation.
