On entend souvent parler de l’Open Source comme une grande avancée dans le monde de l’IT. Projets dont le code est ouvert à tous, où tous peuvent contribuer, quel que soit leur niveau, les avantages sont multiples, les principaux étant :

  • Tout le monde peut contribuer, ce qui veut dire que les projets peuvent potentiellement avancent d’”eux-mêmes”
  • Des personnes de tous les niveaux peuvent y contribuer, ce qui permet de partager le savoir et faire monter des gens en compétence
  • De donner à tous la possibilité d’apporter leurs compétences et leur expertise aux projets, permettant une augmentation de la qualité du code
  • Les développeurs qui ont du temps libre à côté de leurs projets peuvent décider ou non de contribuer à n’importe quel projet, quelle que soit la taille ou la nature de leur contribution
  • Donner de la visibilité à l’entreprise, si le projet Open Source est intéressant, d’autres développeurs et probablement des utilisateurs du projet pourraient vouloir y intégrer des fonctionnalités, qui seront ensuite disponibles à tous les autres utilisateurs

L’Open Source présente beaucoup d’avantages pour une entreprise, mais elle présente également un inconvénient majeur, le principal pour lequel les entreprises ne vont pas vers l’Open Source : le code doit être ouvert, public, en accès libre et donc récupérable et réutilisable par tous.

Pour une entreprise, cela signifie que le travail que ses développeurs auront fourni sur leur temps de travail pourrait être réutilisé par des gens externes à l’entreprise et qui n’auraient rien apporté en échange.

L’Inner Source, qu’est-ce que c’est ?

L’Inner Source est un concept développé dans la fin des années 90 et cité sous ce nom pour la première fois par Tim O’Reilly en 2000. Basé sur les principes de l’Open Source, l’Inner Source en reprend absolument tous les concepts à l’exception d’un seul : l’ouverture du code au monde extérieur.

Concrètement, l’Inner Source est une forme d’Open Source, mais avec un niveau d’ouverture seulement interne à l’entreprise.

Pour imager :

  • Une équipe au sein de l’entreprise décide de démarrer un projet qui sera ouvert en Inner Source
  • Elle démarre le projet et met en place tous les prérequis (voir plus bas) afin de garder le projet sur les rails à tout moment
  • Elle ouvre la visibilité du projet, en fait la publicité et invite les développeurs qui souhaitent y participer à le faire, selon les règles de contribution à ce projet
  • Elle reste seule Owner du projet, ce qui veut également dire qu’elle reste responsable de la qualité et de la maintenabilité du code, ainsi que des déploiements ou de la publication de l’application
  • Dès lors, tous les développeurs et/ou utilisateurs intéressés par l’ajout de nouvelles fonctionnalités au projet peuvent prendre en main le projet, en lire la documentation, monter en compétences dessus puis un jour être capable d’intégrer leurs propres fonctionnalités au produit, pour eux et pour tous les autres

Les avantages de l’Inner Source pour l’entreprise sont multiples, les principaux étant l’accélération du Time To Market, en permettant à tous de participer à un projet ; l’augmentation de la satisfaction des développeurs, permettant à tous de participer aux projets qui leurs plaisent au sein de l’entreprise ; une augmentation drastique de la qualité des projets, car tous peuvent apporter leur expertise sur l’architecture, les bonnes pratiques, la qualité ; la diminution du Time To Market de futures projets, car la réutilisation de code en interne est permise et donc les fonctionnalités ne sont pas développées plusieurs fois ; etc…

Le tout sans pour autant avoir besoin d’ouvrir le code source au public et de voir le travail de ses développeurs réutilisé partout sur le net.

Les prérequis de l’Inner Source

L’Inner Source peut séduire, il peut cependant s’avérer dangereux pour la stabilité des produits si certains prérequis ne sont pas respectés. L’idée d’avoir un projet ouvert à toutes les équipes de l’entreprise doit immédiatement soulever des questions, on a l’habitude d’avoir des équipes qui travaillent ensemble sur le développement d’un produit, avec des pratiques, des outils, des réunions, bref un ensemble de pratiques permettant la collaboration.

Comment cette collaboration est-elle possible entre des développeurs d’équipes différentes ?

Plusieurs prérequis sont essentiels :

  • Recueil du besoin dans un référentiel (Backlog ou Cahier des Charges) ayant le même niveau de visibilité que le projet (publique au sein de l’entreprise)
  • Ouverture des réunions de travail, au moins pour certaines, afin que toute personne externe à l’équipe Owner puisse venir récupérer / fournir des informations
  • Maintenance et publication d’une documentation exhaustive du contenu du projet, de ses fonctionnalités, de son architecture, ainsi que de tout ce qui gravite autour (où et comment il est déployé, les outils de qualité utilisés)
    Le mieux est d’extraire la documentation, directement depuis le code, et de la publier depuis les pipelines de CD du projet
  • Publier au sein du projet un guide de contribution, citant toutes les règles de nommage, les normes de code, les outils à utiliser, l’environnement de travail à avoir, ainsi que le processus de publication et d’acceptation de fonctionnalités
    Le fonctionnement le plus sain est que toute personne désirant développer une fonctionnalité le fasse sur une branche, puis créé une Merge Request sur le dépôt Git, afin que le code produit puisse être revu et vérifié par les membres de l’équipe Owner
  • (Important) Avoir sur le projet une grosse culture des tests, et mettre en place des pipelines de CI/CD avec exécution systématique de ces tests pour toute nouvelle Merge Request, afin de valider la non-régression de toute modification. Ces pipelines ont également pour but de faciliter et d’accélérer la mise en ligne du produit afin que les utilisateurs puissent rapidement bénéficier de leurs propres contributions

L’Inner Source présente tous les avantages de l’Open Source, sans les inconvénients. Les développeurs sont libres sur leur “temps de battement” de développer sur les projets de leur choix, sans aucune obligation et sans risquer de faire baisser la qualité des dits projets.

L’Inner Source a aujourd’hui été adopté par de très grandes firmes comme HP, Philips, Microsoft, Google ou Nokia, mais n’est pas inadapté aux petites et moyennes structures.

Faites cependant attention à bien respecter ses prérequis, leur manquement pourraient entrainer des conséquences désastreuses sur le développement de vos projets.

©️ Julien Pontillo, Consultant JavaScript Fullstack chez Klanik