Qu'est-ce que l'innersource ?
L'innersource est une stratégie de développement logiciel qui encourage les entreprises à adopter une approche et une culture open source pour collaborer plus efficacement.
L'innersource est de plus en plus populaire au sein des équipes de développement et d'ingénierie ultra-performantes, qui adoptent des processus open source afin de travailler et de collaborer plus efficacement. Lorsque les équipes adoptent l'approche innersource, elles développent leurs propres logiciels propriétaires, mais au lieu de restreindre l'accès au code à une équipe spécifique, elles ouvrent ce processus à tous les membres de l'organisation, y compris les développeurs, les chefs de produit et d'autres parties prenantes, afin que chacun puisse contribuer au code source.
L'innersource est une stratégie de développement logiciel qui applique des pratiques open source au code propriétaire. L'innersource peut favoriser une culture open source. Toutefois, contrairement aux projets open source publics, les logiciels développés en mode innersource restent la propriété de l'entreprise et sont destinés à un usage interne. Les équipes utilisent l'innersource pour accroître la visibilité, encourager la collaboration et éliminer les silos traditionnels entre les équipes.
En choisissant une approche d'ouverture par défaut pour leurs projets internes, les entreprises favorisent la réutilisation des solutions existantes, minimisent la redondance et encouragent la collaboration entre les membres de l'équipe tout en tirant pleinement parti des talents de l'ensemble de ses collaborateurs. Toute entreprise, quelle que soit sa taille, peut bénéficier des avantages de l'innersource en intégrant constamment des pratiques modernes de développement logiciel inspirées des projets open source à grande échelle.
Par exemple, dans les grandes entreprises, les équipes de développement sont souvent dispersées entre différents services ou fuseaux horaires. Plusieurs développeurs peuvent ne jamais se rencontrer ni avoir accès aux mêmes stratégies de service. Cependant, avec l'innersource, ils peuvent s'aligner sur le même modèle de workflow, qui a fait ses preuves dans les projets open source.
PayPal démontre comment les pratiques de développement open source sont bénéfiques pour les entreprises en termes d'efficacité et de rentabilité, même si le caractère « open (ouvert) » du concept « open source » se limite en pratique à l'équipe interne de l'entreprise et non au grand public. D'autres entreprises pionnières adoptant l'innersource, telles que Bosch, Autodesk, Bloomberg et SanDisk, démontrent leur capacité à mener à bien des projets complexes et à créer des produits innovants en utilisant le même système Lean allégé et peu coûteux dans l'open source.
En fait, les grandes entreprises fonctionnent de la même manière que les grands projets open source. En milieu professionnel et dans les initiatives open source, nombreux sont les aspects dynamiques : plusieurs contributeurs, une variété d'outils, et une multitude de directives et de stratégies. Dans le modèle d'entreprise traditionnel, en revanche, les équipes opèrent sous la direction et les instructions d'une hiérarchie de hauts dirigeants. L'efficacité de l'entreprise repose donc en partie sur la capacité des managers à garder une vue d'ensemble sur la grande quantité d'informations reçues.
L'abondance d'informations entraîne souvent un problème de gestion, il n'est donc pas surprenant que des projets puissent être négligés. Plus les projets sont complexes ou impliquent un grand nombre d'équipes, plus les tâches risquent de passer inaperçues pendant un certain temps. Dans les projets open source, les informations relatives au développement sont gérées par un processus de documentation et de contrôle qui vise à éviter que des composants ne soient négligés au fil du temps.
Les pratiques de workflow open source les plus importantes pour les entreprises sont les suivantes :
- Visibilité
- Duplication
- Poussée/Merge requests (requêtes de fusion)
- Tests
- Intégration continue
- Documentation
- Gestion des tickets
En adoptant une approche open source du développement logiciel, les entreprises comblent les lacunes et éliminent les silos, ce qui conduit à un cycle du développement logiciel plus efficace et plus cohérent. En outre, cela ouvre la voie à une meilleure expérience pour les développeurs, à des méthodologies de développement rationalisées et à une culture de collaboration transparente.
Cette approche augmente non seulement la vélocité des développeurs, mais favorise également une collaboration plus étroite entre les membres de l'équipe principale dans divers projets de développement.
Les entreprises qui utilisent l'innersource bénéficient des avantages typiques du développement open source, y compris :
- Code de haute qualité : grâce aux tests unitaires, à la couverture de code et à l'intégration continue, les équipes améliorent la qualité du code plus tôt dans le cycle du développement.
- Documentation complète : le code est mieux documenté, à la fois dans les commentaires et de façon moins formelle dans les discussions, ce qui conduit à une source unique de vérité, à une plus grande transparence et à un partage des connaissances.
- Réutilisation efficace du code : le code et l'architecture sont détectables et disponibles dans toutes les équipes et dans l'ensemble de l'entreprise.
- Forte collaboration : les revues de code ont moins de frictions, la communication devient plus forte et les contributions augmentent en nombre.
- Culture saine : les silos sont décomposés, de sorte que la satisfaction au travail des développeurs s'améliore, ce qui améliore la rétention et le recrutement.
Voici quelques-uns des problèmes souvent rencontrés par les grandes organisations que l'innersource pourrait aider à résoudre.
| Défi | Solution |
|---|---|
| Communication : Dans les grandes organisations, il n'y a généralement pas une seule équipe unifiée œuvrant à un seul objectif. Au contraire, les membres de l'équipe ont tendance à être répartis en plusieurs équipes déconnectées, ayant chacune leurs structures et leur leadership. Les normes et les terminologies de communication peuvent varier d'une équipe à l'autre, et la communication et le partage des connaissances entre les silos sont minimes et inefficaces. | Les systèmes open source permettent la participation et les contributions à grande échelle. Les lignes de communication sont directes et visibles par tous les membres du projet. Les hiérarchies de communication sont généralement plates, éliminant le bruit inutile et reliant les contributions aux parties prenantes. |
| Découverte : une solution logicielle peut être créée plusieurs fois dans différents services, essentiellement due à la multiplication des efforts, simplement parce que les services manquent de communication, de transparence et de collaboration. Souvent, il n'existe pas de processus pour vérifier si une solution a déjà été créée. | L'avantage des projets open source est qu'ils sont transparents par nature. Comme elles ont accès au projet, les équipes peuvent tenter de déterminer s'il existe une solution à un problème auquel une équipe est confrontée. Si une personne ne fait pas de recherche avant de commencer une tâche, les autres contributeurs du projet ont une visibilité totale et peuvent identifier une solution préexistante. Les projets open source facilitent la découverte des solutions existantes et aident à réduire la duplication des efforts. |
| La bureaucratie : dans la plupart des environnements commerciaux, il existe des structures organisationnelles qui décident ce à quoi les membres de l'équipe peuvent accéder. Un membre de l'équipe peut savoir qu'une solution existe, mais il doit demander l'accès à un projet à un administrateur, ce qui oblige le développeur et l'administrateur à se détourner de tâches importantes. | Avec les projets open source, les membres de l'équipe disposent d'un accès total pour travailler sur les projets ou les voir. Cette visibilité et cet accès réduisent le travail administratif et les délais de gestion des requêtes d'accès. |
| Apporter des modifications : dans un contexte commercial traditionnel, si les équipes ont un accès en lecture seule à un projet, elles n'ont pas les autorisations ou la capacité de modifier ou d'ajouter une fonctionnalité. Elles doivent demander à quelqu'un d'autre de le faire. Si les personnes désignées responsables des changements n'ont pas le temps ou n'en voient pas l'intérêt, les contributeurs n'ont aucun recours. L'équipe responsable de l'application est chargée de s'assurer que son application respecte les délais et qu'elle fonctionne correctement, de sorte que le job d'une ressource dépend étroitement de la tenue à jour de cette application. Même si une autre équipe pourrait bénéficier de cette nouvelle fonctionnalité, la requête de modification de l'application pourrait interférer avec la stabilité de l'application, faisant de l'octroi de l'accès un risque. Si un développeur ne peut pas y accéder pour apporter les modifications nécessaires, cela conduira les équipes à construire leur propre code base ou application unique pour résoudre le problème, ce qui peut se produire plusieurs fois, si plusieurs personnes sont confrontées au même problème. Cela conduit à ce que de nombreuses applications soient créées séparément pour résoudre le même problème. | Si les équipes veulent apporter une modification à un projet open source, elles n'ont pas besoin d'obtenir d'approbation. Au lieu de cela, elles contribuent à la modification et laissent le système tester sa fonctionnalité et sa validité. En pratique, les équipes dupliquent à partir du code base, apportent des modifications et créent une requête de fusion qu'un autre développeur peut vérifier, tester, et pour laquelle il peut poser des questions. Les personnes responsables d'accepter la requête de fusion ont une charge de travail réduite par rapport à l'autre scénario, car elles n'ont pas eu à faire le travail supplémentaire elles-mêmes. Par ailleurs, comme la fonctionnalité a été testée, elles savent que cela fonctionne. Par ailleurs, cette approche réduit la charge globale sur le générateur de rapports qui ne doit prendre en charge qu'un seul code base au lieu de huit. |
Pour les équipes qui travaillent en collaboration sur différents fuseaux horaires, ce qui est le cas de la plupart des équipes aujourd'hui, et les organisations qui ont plusieurs services, l'innersource est un moyen simple de créer un workflow plus efficace. Les équipes peuvent briser les silos d'informations et encourager une collaboration plus efficace dans l'ensemble de l'organisation. L'innersource permet également d'accélérer l'intégration des développeurs, et peut encourager les membres de l'équipe à contribuer à la communauté de logiciels open source.
Avec l'adoption de projets innersource, les approches de développement traditionnelles sont remplacées par des workflows de développement plus dynamiques, inclusifs et efficaces.
L'innersource représente un tournant dans la façon dont les organisations abordent le développement de logiciels. Il promet non seulement une amélioration de la qualité et de la sécurité des produits logiciels, mais également une transformation culturelle qui contribuera à la réussite des organisations. L'utilisation de pratiques de l'innersource permet aux entreprises de relever les défis du développement de logiciels modernes avec agilité, tout en promouvant l'innovation collaborative pour la croissance de l'entreprise
Alors que les organisations se tournent vers l'avenir, l'adoption de l'innersource s'impose comme un impératif stratégique qui les équipera pour relever les défis émergents et tirer parti des nouvelles opportunités.
Découvrez comment GitLab simplifie le développement de logiciels
En savoir plus sur l'innersource et le développement de logiciels collaboratif
Voir toutes les ressources
Lancez-vous dès maintenant
Découvrez comment la plateforme DevSecOps unifiée de GitLab peut aider votre équipe.