Comment gérer un programme InnerSource réussi

Effectué

Nous expliquons ici comment concevoir un programme InnerSource pour bénéficier du meilleur modèle open source au sein d’une organisation de développement de logiciels.

Qu’est-ce que InnerSource ?

Tout le monde peut librement utiliser, modifier et partager un logiciel Open Source. Grâce aux logiciels open source, tout le monde peut consulter, modifier et distribuer un projet dans n’importe quel but, l’idée étant que le partage du code permet d’obtenir des logiciels de meilleure qualité et plus fiables.

InnerSource est la pratique qui consiste à appliquer des modèles open source à des projets avec un public limité. Une entreprise peut par exemple établir un programme InnerSource qui reflète la structure d’un projet Open Source classique, sauf qu’il est accessible seulement aux employés de cette entreprise. En fait, il s’agit d’un programme open source derrière le pare-feu de votre entreprise.

Avantages d’InnerSource

Un programme InnerSource peut offrir de nombreux avantages par rapport aux modèles propriétaires traditionnels.

Tout d’abord, ils encouragent la transparence. L’accès au code source d’autres projets de l’entreprise peut aider les développeurs à être plus productifs quand ils travaillent sur leurs propres projets. Ils peuvent voir comment les différentes équipes résolvent des problèmes similaires aux leurs, et trouvent souvent du code et d’autres ressources qu’ils peuvent réutiliser. L’accès aux problèmes, aux demandes de tirage et aux plans des projets des équipes fournit également de meilleures informations qui leur permettent de comprendre la vitesse et la direction du projet.

Ensuite, ils réduisent les frictions. Supposons qu’une équipe de consommateurs dépend d’un correctif de bogues ou d’une nouvelle fonctionnalité pour un projet appartenant à une autre équipe. DANS un programme InnerSource, ils ont un canal par lequel ils peuvent proposer les modifications dont ils ont besoin. Et si ces modifications ne peuvent pas être fusionnées pour une raison quelconque, l’équipe consommatrice a la possibilité de dupliquer (fork) le projet selon ses besoins.

Enfin, ils standardisent les pratiques. Un défi courant auquel les organisations de développement doivent faire face est que les différentes équipes divergent souvent dans la façon dont ils fonctionnent. La création d’un programme InnerSource est une excellente opportunité d’adopter des conventions standard qui peuvent être utilisées dans chacune des équipes de développement, même si elles ne suivent pas des pratiques identiques. Par exemple, deux équipes peuvent préférer des processus différents pour accepter les contributions. La standardisation de la façon dont ils communiquent leurs différents processus simplifie grandement la collaboration entre elles.

Ces exemples ne sont que quelques-uns des avantages des programmes InnerSource. Pour plus d’informations, consultez Une introduction à InnerSource.

Configurer un programme InnerSource sur GitHub

Définir la visibilité et les autorisations du référentiel

Vous pouvez configurer les dépôts GitHub avec trois niveaux de visibilité. Des pages « introuvables » s’affichent pour les utilisateurs qui ne satisfont pas à l’exigence de visibilité quand ils essaient d’accéder à votre référentiel. Les niveaux sont les suivants :

• Les dépôts publics sont visibles par tout le monde. Utilisez cette visibilité pour les projets qui sont réellement open source et qui offrent un accès à des personnes à l’intérieur et à l’extérieur de votre organisation.
• Les dépôts internes ne sont visibles que par les membres de l’organisation qui en est propriétaire. Utilisez cette visibilité pour les projets InnerSource.
• Les dépôts privés sont visibles seulement par le propriétaire, et par les équipes ou les personnes individuelles qu’il ajoute. Utilisez cette visibilité pour les projets auxquels seuls des utilisateurs et des groupes spécifiques doivent avoir accès.

Une fois que vous avez établi la visibilité du référentiel, vous pouvez configurer des autorisations sur une base individuelle ou d’équipe. Il existe cinq niveaux d’autorisation :

• Le niveau Read (Lecture) est recommandé pour les contributeurs hors code qui veulent voir ou discuter du projet.
• Le niveau Triage est recommandé pour les contributeurs qui doivent gérer de façon proactive les problèmes et les demandes de tirage sans accès en écriture.
• Le niveau Write (Écriture) est recommandé pour les contributeurs qui effectuent activement des envois (push) au projet.
• Le niveau Maintain (Gestion) est recommandé pour les chefs de projet qui doivent gérer le dépôt sans avoir accès à des actions sensibles ou destructrices.
• Le niveau Admin (Administration) est recommandé pour les personnes qui ont besoin d’un accès complet au projet, notamment aux actions sensibles et destructrices, comme la gestion de la sécurité ou la suppression d’un dépôt.

Découvrez plus d’informations sur les autorisations d’accès aux dépôts par niveau.

Créer des dépôts découvrables

Au fil de l’accroissement d’un programme InnerSource, le nombre de référentiels va probablement augmenter considérablement. Bien qu’il soit intéressant d’avoir toutes ces ressources disponibles pour l’organisation, trouver un contenu avec une certaine efficacité peut devenir un défi. Pour résoudre ce problème de façon proactive, une meilleure pratique des équipes consiste à réfléchir à ce qu’elles peuvent faire pour que d’autres utilisateurs puissent trouver et utiliser leurs référentiels facilement.

Voici quelques-unes des bonnes pratiques :

• Utilisez un nom descriptif pour le dépôt, comme warehouse-api ou supply-chain-web.
• Incluez une description concise. Une ou deux phrases doivent suffire pour que les utilisateurs potentiels sachent si le projet peut répondre à leurs besoins.
• Attribuez une licence à votre référentiel afin que les clients sachent comment ils peuvent utiliser, modifier et distribuer le logiciel.
• Incluez un fichier README.md dans le référentiel. GitHub utilise ce fichier comme page d’accueil quand des personnes visitent le dépôt.

Ajouter un fichier README

Un fichier README communique les attentes de votre projet et vous aide à gérer les contributions. Les fichiers README peuvent :

• Expliquez l’objectif et la vision du projet pour que les consommateurs potentiels sachent s’il correspond à leurs besoins.
• Offrez des aides visuelles, comme des captures d’écran ou des exemples de code, pour illustrer le projet en action.
• Inclure des liens vers une version de production ou de démonstration de l’application pour permettre son examen.
• Définissez les attentes pour les prérequis et les procédures de déploiement.
• Ajouter des références aux projets dont vous dépendez. Ces références constituent un bon moyen de promouvoir le travail des autres.
• Utiliser Markdown pour guider les lecteurs via un contenu correctement mis en forme.

Si vous placez votre fichier README dans le répertoire racine de votre référentiel ou dans le répertoire .github ou docs masqué, GitHub reconnaît et expose automatiquement votre fichier README aux visiteurs du référentiel. Si un référentiel contient plusieurs fichiers README, le fichier affiché est choisi parmi les emplacements suivants dans cet ordre : répertoire .github, puis répertoire racine du dépôt et enfin répertoire docs.

Consultez des exemples pratiques de fichiers README (LISEZ-MOI).

Une fois le projet lancé, utilisez l’e-mail et d’autres canaux de mise en réseau pour le promouvoir. Atteindre un public approprié peut entraîner une augmentation significative de la participation au projet.

Gérer des projets sur GitHub

Au fur et à mesure que les projets prennent de l’ampleur, l’afflux des utilisateurs et des contributions peut nécessiter un travail de gestion important. Selon le projet, une quantité importante de travail peut être nécessaire seulement pour gérer les attentes des participants au projet.

Pour résoudre ce problème de façon proactive, GitHub recherche un fichier CONTRIBUTING.md à la racine (ou /docs ou /.github) d’un référentiel. Utilisez ce fichier pour expliquer la stratégie de contribution pour le projet. Les détails exacts peuvent varier, mais il est judicieux de permettre aux contributeurs potentiels de savoir quelles conventions le projet suit. Par exemple, où l’équipe recherche des demandes de tirage, quels détails sont demandés pour les rapports de bogues, et ainsi de suite.

Si un fichier CONTRIBUTING.md existe, GitHub présente un lien vers celui-ci quand les utilisateurs créent des problèmes ou des demandes de tirage pour les encourager à le suivre.

Consultez des exemples pratiques de fichiers CONTRIBUTING.md

En outre, envisagez d’ajouter un fichier CODEOWNERS au référentiel pour définir des individus ou des équipes responsables de l’examen des modifications de code.

Créer des modèles de problème et de demande de tirage

GitHub prend en charge des modèles de démarrage pour les nouveaux problèmes et les nouvelles demandes de tirage. Utilisez ces modèles pour fournir le texte de description initial d’un problème ou d’une demande de tirage nouvellement créés.

Par exemple, si votre projet a un fichier .github/ISSUE_TEMPLATE.md, l’utilisateur voit ce contenu à chaque fois qu’il démarre le processus de création d’un problème. Au lieu de référencer constamment les détails nécessaires indiqués dans un fichier CONTRIBUTING.md, ils peuvent simplement remplir le problème comme un formulaire en utilisant le texte du modèle.

C’est la même chose pour les demandes de tirage, sauf que le chemin est .github/PULL_REQUEST_TEMPLATE.md.

Découvrez quelques modèles pratiques de problème et de demande de tirage de GitHub.

Définir des workflows

Pour les projets qui encouragent les contributions externes, veillez à spécifier le workflow suivi par le projet. Le workflow doit inclure des détails sur l’emplacement et la façon dont les branches doivent être utilisées pour les bogues et les fonctionnalités. Il doit également inclure la façon dont les demandes de tirage doivent être ouvertes, et tous les autres détails que les personnes en dehors de l’équipe du référentiel doivent connaître avant qu’elles n’envoient de code. Si vous n’avez pas encore un flux de travail à l’esprit, vous pouvez envisager d’utiliser le flux GitHub.

Vous devez communiquer une stratégie de gestion des versions et des déploiements. Ces parties du workflow affectent la gestion quotidienne des branches et des fusions : il est donc important de les communiquer aux contributeurs. Découvrez plus d’informations sur la façon dont elles sont liées à votre stratégie de branchement Git.

Mesure du succès du programme

Toute équipe s’aventurant dans InnerSource doit réfléchir aux types de métriques qu’elle veut suivre pour évaluer la réussite de son programme. Bien que des métriques traditionnelles comme « délai de commercialisation » et « bogues signalés » soient toujours applicables, elles ne vont pas nécessairement illustrer les avantages obtenus via InnerSource.

Au lieu de cela, vous pouvez envisager d’ajouter des indicateurs de performance qui montrent comment la participation externe a amélioré la qualité du projet. Le dépôt reçoit-il des demandes de tirage de sources externes qui résolvent des bogues et ajoutent des fonctionnalités ? Y a-t-il des participants actifs dans des discussions sur le projet et son avenir ? Le programme inspire-t-il une expansion InnerSource qui va engendrer des avantages ailleurs dans l’organisation ?

En résumé, les métriques peuvent être difficiles à mettre au point, surtout quand il s’agit de mesurer la valeur et l’effet des contributions individuelles et de l’équipe. Si elles sont mal utilisées, les métriques peuvent nuire à la culture et aux processus existants, et amoindrir le sentiment collectif envers l’organisation ou l’équipe dirigeante. Quand vous envisagez de mesurer l’adoption d’InnerSource, prenez en compte les conseils sur les indicateurs de performance suivants :

• Mesure des processus, pas de leurs résultats
  • Délai de production des revues de code
  • Taille des demandes de tirage
  • Travail en cours
  • Temps nécessaire à l’ouverture
• Mesure par rapport à des objectifs, et non pas dans l’absolu
• Mesure des équipes, et non pas des personnes individuelles
  • Nombre de contributeurs uniques à un projet
  • Nombre de projets réutilisant du code
  • Nombre de @mentions d’équipes transverses

En savoir plus sur les succès que d’autres ont appréciés dans ces études de cas InnerSource.