Comment concevoir un programme open source
Ici, nous abordons les éléments clés à prendre en compte dans la conception d’un programme open source.
Qu’entendons-nous par « open source » ?
Un programme open source ne se limite pas à offrir un accès public à un codebase. Il s’agit d’ouvrir un projet vivant à la participation de quiconque souhaite contribuer. S’il est exécuté correctement pour un projet approprié, un programme open source peut vous aider à améliorer considérablement la qualité de votre produit.
L’une des raisons majeures qui poussent les entreprises à rendre leurs projets open source est de faire participer la communauté. Les projets populaires reçoivent d’importantes contributions de la communauté, tout cela gratuitement.
Ce n’est pas toujours par pur altruisme. Les personnes et les organisations consomment des projets, car elles en retirent un bénéfice personnel ou professionnel. Si un projet ne répond pas à leurs besoins ou attentes, elles ont la possibilité de résoudre elles-mêmes les bogues détectés ou d’ajouter des fonctionnalités. Au lieu de conserver ces améliorations dans des fourches privées, elles sont tenues de contribuer en réintégrant ces modifications dans le référentiel source pour les inclure au projet de référence. Ce cycle vertueux d’amélioration est ce qui incite de nombreuses entreprises à produire des logiciels selon le modèle open source.
Objectifs de l’open source
Pour résumer, la participation à un logiciel open source comprend trois dimensions :
- Les consommateurs, qui consultent ou utilisent les dépôts de tiers.
- Les contributeurs, qui participent activement à l’amélioration des dépôts de tiers.
- Les producteurs, qui créent et gèrent leurs propres dépôts ouverts à des tiers.
Les organisations qui vont plus loin dans leur réflexion sur ce qu’elles souhaitent obtenir de chaque dimension ont intérêt à évaluer leur situation actuelle. Chaque dimension comporte cinq niveaux de processus.
- Ad hoc : aucun processus n’est en place. La réussite dépend des efforts individuels.
- Géré : il existe un processus partiellement documenté. La réussite dépend de la discipline.
- Défini : il existe un processus documenté, standardisé et intégré. La réussite dépend de l’automatisation.
- Mesuré qui a un processus géré de façon quantitative. La réussite dépend de la mesure des métriques par rapport aux objectifs de l’entreprise.
- Optimisé : il existe un processus qui est amélioré en continu et de manière fiable par le biais de changements incrémentiels et novateurs. La réussite dépend de la réduction du risque lié au changement.
Pour savoir plus précisément où se situe votre organisation, consultez les auto-évaluations de l’open source.
Quel intérêt auriez-vous à passer en open source ?
Beaucoup de projets n’ont pas vocation à être open source. Vos critères pourront être différents selon les objectifs et le niveau de processus de votre entreprise, mais nous vous recommandons de prendre en compte les quelques critères ci-dessous avant de rendre un projet open source :
Votre projet contient-il des droits de propriété intellectuelle que vous souhaitez protéger ? Si c’est le cas, l’open source n’a pas d’intérêt. Ne publiez pas ces types de projets en open source, sauf si vous estimez que les bénéfices sont supérieurs aux risques.
Le projet est-il dans un état stable et contient-il du code de bonne qualité ? Le projet n’a pas besoin d’être parfait, mais les contributeurs potentiels risqueront de s’en détourner si votre projet est dans un état initial déplorable.
Votre projet sera-t-il utile à des personnes extérieures à votre entreprise ? Si ce n’est pas le cas, vous n’obtiendrez probablement aucune participation.
Les personnes extérieures à votre entreprise sont-elles en mesure de contribuer au projet ? Elles ont besoin de l’accès à toutes les dépendances du projet, aux processus de build et à tout autre élément requis pour exécuter le projet. S’ils sont dans l’incapacité d’exécuter le projet, ils ne pourront pas y contribuer.
Votre équipe dispose-t-elle d’une bande passante suffisante pour assurer le support d’un programme open source ? Si ce n’est pas le cas, attendez qu’il le soit. Si vous publiez un projet en open source sans en assurer ensuite le support, vous risquez de perdre l’occasion d’établir une relation de confiance avec la communauté.
Ces questions ne reflètent que quelques-unes des considérations communes. Votre organisation peut devoir tenir compte d’autres exigences métier ou réglementaires.
Conception d’un programme open source
L’exécution d’un programme open source est similaire à l’exécution d’un programme InnerSource, mais pour une audience publique. Quelques points supplémentaires doivent donc être pris en considération.
Définition des attentes de la communauté
Des fichiers comme README.md et CONTRIBUTING.md sont encore plus importants, car ils sont exposés à des personnes qui ne connaissent pas le contexte de votre organisation. Ils doivent être évalués du point de vue d’une personne extérieure à l’entreprise pour garantir la clarté de leur contenu.
En outre, votre code de conduite est une stratégie importante à communiquer. La norme est d’ajouter un fichier CODE_OF_CONDUCT.md à la racine de votre référentiel et de l’utiliser pour expliquer le comportement attendu des participants dans votre communauté. Ce document doit être révisé par plusieurs groupes de votre organisation, notamment par votre équipe juridique. Heureusement, il existe de nombreux codes de conduite standard sur lesquels s’appuyer pour commencer. Beaucoup de projets utilisent ces codes en l’état, sans aucune modification. Pour en savoir plus, consultez ce guide des codes de conduite open source.
Préparation des employés à la maintenance d’un dépôt
Les employés ne sont pas toujours habitués à travailler avec la communauté open source. Pour faciliter leur préparation, nous recommandons que l’entreprise propose un ensemble de guides couvrant les éléments clés que chacun doit connaître avant de se lancer. Ces guides doivent être publiés dans un référentiel ou un portail interne dont l’accès est restreint aux seuls employés de l’entreprise ; ils doivent également être mis à jour régulièrement. Voici quelques-uns des guides les plus importants :
Un guide « Ce projet doit-il devenir open source ? », qui fournit un cadre de réflexion pour déterminer si un projet candidat est ou non adapté à l’open source. Ce guide peut prendre la forme d’un organigramme, d’une série de questions ou d’une liste de considérations.
Une liste de vérification de la configuration, qui recense tous les éléments de travail qu’une équipe doit effectuer avant et après le lancement d’un projet open source. Cette liste doit inclure l’obtention de l’approbation pour publier le projet en open source, les revues du code pour s’assurer que les données sensibles sont supprimées avant la mise en ligne du projet, une marque ou une fonction de recherche de projet open source pour éviter les conflits de nommage, etc.
Une liste de contacts, qui indique les coordonnées des personnes principales de votre organisation à contacter en cas de besoin d’un support direct de la part des responsables de la maintenance. Cette liste doit notamment inclure des personnes des équipes de la sécurité des logiciels, de la sécurité du site, des questions juridiques, des relations publiques, etc.
Un lien vers un dépôt de démarrage qui peut être cloné comme point de départ. Le dépôt doit contenir un exemple de fichier README, de licence, de code de conduite, de guide de contribution et de tout autre fichier de support à fournir avec chaque projet open source publié par votre entreprise. Il ne doit contenir aucun élément que vous ne voudriez pas transmettre accidentellement à une audience publique.
Un guide pour le chargé de maintenance, qui explique les responsabilités d’un chargé de maintenance dans le maintien de l’intégrité du dépôt. Ces responsabilités incluent la mise à jour de la documentation du référentiel, l’assurance que les problèmes et les demandes de tirage sont exposés aux personnes appropriées en temps voulu, etc.
Un guide de communication, qui fournit des conseils de maintenance de référentiel sur certains sujets que vous préférez ne pas inclure dans les fichiers publics tels que
README.md,CONTRIBUTING.mdouCODE_OF_CONDUCT.md. Il peut s’agir de sujets commerciaux sensibles, comme les discussions entre concurrents, ou des points de conduite plus généraux, comme la façon de reconnaître les contributeurs les plus pertinents.Une FAQ interne, qui fournit des réponses approuvées aux questions courantes. Cette liste est particulièrement utile si les sujets que votre entreprise aborde dans le cadre de la maintenance d’un programme open source comportent des subtilités juridiques.
Une stratégie de licence, qui liste les licences qui ont été approuvées ou refusées par le service juridique pour l’utilisation du programme open source ou la contribution au programme.