URL: https://linuxfr.org/users/linkdd/journaux/a-quel-point-votre-projet-open-source-doit-il-etre-ouvert Title: À quel point votre projet open source doit-il être ouvert ? Authors: David Delassus Date: 2023年05月14日T15:21:00+02:00 Tags: foss, interview, gouvernance et contribution Score: 40 NdA: Cet article, [How 'open' should your open source be?](https://github.com/readme/featured/how-open-is-open-source), a été initialement publié sur GitHub's The ReadME Project, et traduit par mes soins avec le consentement express de son auteur. --- Dans les faits, le projet [Litestream](https://github.com/benbjohnson/litestream) est (et a toujours été) 100% open source. Il respecte les 10 prérequis de la [définition](https://opensource.org/docs/osd) de l'Open Source Initiation, utilise une [licence approuvée par l'OSI](https://opensource.org/licenses/), et vous êtes plus que bienvenu pour forker et modifier le projet comme bon vous semble. Cependant, il y a un hic: depuis quelques temps, le projet n'a pas accepté de contribution de code d'aucune sorte. Mais pourquoi, vous allez demander? Une des raisons principales pour faire quelque chose d'open source, après tout, c'est de recevoir des contributions. Pourquoi emprunter la voix de l'open source si ce n'est pour pas accepter de code ? Le mainteneur de Litestream, [Ben Johnson](https://github.com/benbjohnson) clôt le projet aux contributions (externes) en Janvier 2021, [expliquant](https://github.com/benbjohnson/litestream/commit/a8d63b54aa5bd2d9639af01e1e0c2098a65b323a#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R121) dans une section du "README", intitulée **"Open-Source, not Open-Contribution"**, que gérer les contributions externes, même petites, était trop chronophage.> En tant que auteur de [BoltDB](https://github.com/boltdb/bolt), je pense que accepter et maintenir des patchs tiers ont contribué à mon burn out et l'éventuel archivage du projet.> Même les petites contributions requiert typiquement plusieurs heures de mon temps pour les tester et valider correctement.> Je suis reconnaissent pour l'engagement de la communauté et envers les personnes qui reportent des bogues, ou suggèrent des fonctionnalités. Je ne souhaite pas paraître autre que accueillant, cependant, j'ai pris la décision de garder le projet fermé aux contributions pour ma propre santé mentale et la viabilité à long terme du projet. Bien que l'approche de Johnson est un peu extraordinaire, et peut remettre en question certains hypothèses à propos de ce qui est et ce qui n'est pas open source, cela démontre que l'open source n'est pas une solution unique pour tout les problèmes. Certains projets acceptent des contributions qui peuvent être abandonnées, pendant que d'autres vont avoir un processus détaillé et une longue liste de prérequis, tandis que d'autres choisissent d'accepter du code que de certaines personnes (de confiance ?). En tant que mainteneur open source, le fardeau constant des "bugfix" et des demandes de fonctionnalités demande beaucoup d'attention. Simplement refuser les contributions externes peut être vu comme une échappatoire facile, mais cela peut introduire d'autres limitations. On va revenir plus tard à Johnson et son approche non-orthodoxe un peu plus tard. D'abord, regardons comment nous en sommes arrivé là.>> Je ne souhaite pas paraître autre que accueillant, cependant, j'ai pris la décision de garder le projet fermé aux contributions pour ma propre santé mentale et la viabilité à long terme du projet. ## L'Open Source dévore le monde (et a besoin d'anti-acide) Les premiers logiciels étaient écrit par des chercheurs et des académiciens, et était ouvert par défaut. Ils ne pouvait même pas être sous copyright avant 1974. On ne connaissaient même pas l'expression désormais commune "open source" jusqu'à ce Christine Peterson [l'invente en 1998](https://opensource.com/article/18/2/coining-term-open-source-software). Cette même année, l'OSI se forma et établissait la sus-cité définition de l'Open Source, qui reste le mètre étalon par lequel on juge l'ouverture d'un projet aujourd'hui. Pendant de nombreuses de ces années, des méthodes fastidieuses et chronophages, telle que les listes de courriel, étaient le standard "de-facto" pour la collaboration dans l'open sourece. Git, le gestionnaire de version distribué et open source, créé par Linus Torvalds, n'arrivera pas avant 2005, et même à cette époque, il n'offrait qu'un outil en ligne de commande. 3 ans plus tard, Github créa une interface utilisateur pour Git et [introduis les "Pull Request"](https://github.blog/2008-02-23-oh-yeah-there-s-pull-requests-now/), une fonctionnalité qui changea la manière dont les mainteneurs gèrent les patchs dans l'open source, ce qui serait au cœur du succès récent de l'Open Source selon certains.> Une des choses extraordinaires que Github a fait, c'est de rendre les contributions faciles et accessible. Cela a amené tellement plus de monde dans l'open source, et c'est merveilleux. D'un autre côté, cela a aussi facilité la possibilité de faire des demandes sans aucun contexte. -- [Julia Ferraioli](https://github.com/juliaferraioli), ingénieure logiciel et ambassadeur de l'Open Source *NdA: évangéliste ou ambassadeur, quelle meilleure traduction pour "advocate" ?* Avec cette facilité d'accès, les projets Open Source peuvent vivre leurs propre version de [l'effet Slashdot](https://fr.wikipedia.org/wiki/Effet_Slashdot), où la popularité peut être écrasante pour un mainteneur solitaire.> Dès que l'on se fait connaitre, on a basiquement un nombre illimité d'actionnaire. On est soudains plongé dans de la gestion de projet, de la diplomatie, du marketing, et de la stratégie de marque. *NdA: "stakeholder" se traduit par actionnaire, ou investisseur. Mais je pense que c'est ici utilisé plus dans le sens "stake holder", celui qui détient les enjeux.* Ferraioli argumente que la réaction réflexe que vous auriez pu avoir envers Ben Johnson fermant son projet aux contributions de code n'est pas à propos de la définition de l'Open Source, mais plutôt à propos du [modèle social](https://leaddev.com/agile-other-ways-working/vision-social-model-open-source) qui a évolué avec le temps. Bien que la définition de l'OSI offre 10 caractéristiques concises, ceux qui pratiquent et participent à l'Open Source assument souvent que les logiciels Open Source devraient être ouvert aux contributions de la communauté, accueillant dans les discussions autour de la direction d'un projet, and voulant bien accepter de nouveaux développeurs et mainteneurs.> Il y a de nombreux projets Open Source que les gens ne considèrent pas Open Source car ils ne construisent pas une communauté, ou ne publient pas beaucoup de mise à jour, mais l'Open Source n'est pas juste à propos des contributions. C'est également de l'apprentissage, de la compréhension, de l'enseignement. Les projets de recherche sont Open Source en partie pour permettre des tiers de vérifier indépendamment leurs résultats. Par leur nature, ils ne peuvent pas accepter de contributions quelles qu'elles soient.> Ils sont toujours Open Source. Ils ont une valeur immense. Les gens peuvent apprendre de ces projets, les modifier, les forker. Il y a tellement de raisons pour lesquelles ils sont toujours de merveilleux exemples de logiciel Open Source, et je pense qu'on est un peu trop prompt à rejeter cela. Au delà de la recherche Open Source, cependant, certains projets Open Source choisissent de limiter les contributions pour d'autres raisons.>> Il y a de nombreux projets Open Source que les gens ne considèrent pas Open Source car ils ne construisent pas une communauté, ou ne publient pas beaucoup de mise à jour, mais l'Open Source n'est pas juste à propos des contributions. ## Open Source, mais fermé aux contributions Le langage de programmation [Lua](https://github.com/lua) a été Open Source peu après ses débuts en 1993, mais est resté fermés aux contributions externes depuis tout ce temps. Lua priorise la vitesse, la portabilité, la simplicité et la petite taille de l'exécutable, et le projet a trouvé une popularité considérable dans les domaines des systèmes embarqués et du développement de jeux. Le langage a été créé par une équipe de 3 personnes, mais pour l'écrasante majorité de son existence, il a été principalement développé et maintenu par [Roberto Ierusalimschy](https://github.com/roberto-ieru), qui est parfaitement clair sur le fait qu'il voulait que le projet soit Open Source pour que n'importe qui puissent l'utiliser et y avoir accès, les normes sociales autour des logiciels Open Source n'étaient pas une priorité. Pour Ierusalimschy, ce n'est pas parce qu'il aurait du gérer les problèmes du succès dans l'Open Source et décidé ensuite de refuser les contributions.> On avait pas cette idée que le logiciel Open Source voulait dire être ouvert aux développeurs. On pensait que peut être d'autres personnes pourrait vouloir utiliser notre logiciel, alors on lui a donné une licence libre. On n'a jamais réfléchit à comment d'autres personnes pourraient vouloir contribuer. De la même manière que Johnson arrêta d'accepter les contributions de code pour Litestream, Ierusalimschy dit que les contributions étaient le cadet de ses soucis.> Les gens veulent toujours envoyer du code. Je plaisante toujours sur le fait que le code est la partie la plus facile. J'attends de vous que vous justifiez de pourquoi une idée est bonne, et de fournir une bonne explication. Ierusalimschy indique que le but du projet est la raison principale du pourquoi il reste le seul contributeur.> Un des principaux arguments de ventes de Lua c'est que c'est vraiment petit. C'est difficile de garder quelque chose petit quand tout le monde veut y contribuer quelque chose de neuf. C'est l'effet "comité" : tout le monde veut que leurs idées soient dans le langage, et ensuite pouvoir dire "j'ai donné cette idée au langage". Personne ne dira jamais "J'étais celui qui a supprimé cela pour garder le langage petit". Bien que Lua n'accepte pas de contributions, Ierusalimschy précise que la communauté a inspiré de nombreuses fonctionnalités au fur et à mesure des années, et elle aide pour des tâches telles que tester le langage pour sa portabilité.> On apprécie que les gens utilisent différentes machines, de toutes sortes. Un des buts de Lua, c'est la portabilité, donc quand on publie une version beta, on demande aux gens de l'essayer sur leurs machines. C'est très pratique pour les tests.>> Un des principaux arguments de ventes de Lua c'est que c'est vraiment petit. C'est difficile de garder quelque chose petit quand tout le monde veut y contribuer quelque chose de neuf. Personne ne dira jamais "J'étais celui qui a supprimé cela pour garder le langage petit". ## Quand "fermé" n'est pas à la hauteur de sa réputation Pour Ben Johnson, c'est une histoire un peu différente. Johnson a déjà vécu un certain niveau de succès dans l'Open Source quand il décida de fermer Litestream aux contributions en Janvier 2021. Avec BoltDB, Johnson a du gérer des personnes devenant un peu agressives/combatives autour de certaines Pull Requests et dans les discussions qui suivaient.> Les gens commentaient à propos de comment ils pensaient que cela devait être fait, et je ne me sentais pas forcément confortable avec leurs suggestions. Il y avait beaucoup de pression sociale parfois. Être clair dès le début "je n'accepte rien" rend les choses plus facile. Sur l'aspect technique, Johnson fait écho au ressenti de Ierusalimschy à propos des contributions.> Je ne trouve même pas que le code c'est si dur en soit. Écrire le code, c'est seulement 5% de l'effort pour livrer quelque chose. Après, c'est des années de maintenance, de bugfix, d'écriture de documentation, d'écriture de tutoriels, etc. C'est ça le plus dur. Johnson pointe également la complexité technique de Litestream comme une raison supplémentaire pour limiter les contributions de code.> Les gens soumettraient des demande de fonctionnalité, et quand, même si cela pourrait être une raisonnablement petite fonctionnalité, tester une base de données sur des cas particuliers c'est vraiment pénible. C'est une énorme responsabilité pour toutes les fonctionnalités entrante. Je n'ai juste pas la bande passante ou l'énergie pour prendre les fonctionnalités de tout le monde et gérer tout cela. Peu après avoir clos le code aux contributions, Johnson a ajouté une section dans le README pour adresser cela.> Beaucoup des contributions les plus importante sont sous la forme de test, de retour d’expérience, et de documentation. Elles aident à rentre le logiciel plus solide et l'usage plus accessible pour les autres utilisateurs. Maintenant, vous pourriez vous demander: Pourquoi Johnson ne demande-t-il pas simplement de l'aide de la communauté ? Après tout, c'est comme ça que beaucoup de projets gèrent le problème de la bande passante : ils agrandissent l'équipe de mainteneur, rejoignent une fondation, ou créent un business model autour du projet pour répondre aux besoins du succès.> J'aime travailler par moi même. Ajouter des gens transforme un problème technique, ce qui est la raison pour laquelle je me suis mis au développement logiciel, en un problème humain. ![A grand re-opening sign](https://images.ctfassets.net/s5uo95nf6njh/1xswVTvWOGv7ZWyk2PheQk/afb9c1f9792e39d7ff5557b35f86f164/tim-mossholder-Cg7xHNo0ur0-unsplash.jpg?w=1440&fm=avif) Pour finir, cependant, Johnson découvrit que rester complètement fermé signifiait perdre certains avantages, et après 9 mois, Johnson changea un peu la règle. Reconnaissant que la règle précédente était "trop vague et a empêché la contribution de petits patchs facilement testables", Johnson réouvra Litestream aux Pull Requests pour des bugfixes. Est-ce que c'est avantages perdus ne pourraient pas s'étendre à d'autres parties du projet, vous pourriez demander ? C'est là que le but personnel d'un mainteneur entre dans l'équation.> Avec BoltDB, j'étais plus jeune dans ma carrière, donc un de mes buts était d'agrandir mon réseau, de faire connaître mon nom, et de créer une communauté plus large. Avec Litestream, je suis plus loin dans ma carrier, donc cela n'entre pas autant en jeu dans mes objectifs. Je travaille sur Litestream parce que j'aime le challenge et l'exploration qui vient avec quand on travaille dans une niche si spécial. J'espère que l'outil fournira de la valeur pour les autres, mais je ne suis plus intéressé par la reconnaissance.>> Écrire le code, c'est seulement 5% de l'effort pour livrer quelque chose. Après, c'est des années de maintenance, de bugfix, d'écriture de documentation, d'écriture de tutoriels, etc. C'est ça le plus dur. ## Trouver l'équilibre entre ouvert et fermé Bien que Johnson ne soit pas intéressé par ajouter des mainteneurs à cause des "problèmes humains", cela reste une solution commune bien que pas invulnérable, comme le dit [Bartek Plotka](https://github.com/bwplotka) lors de sa conférence [Should I merge this feature?](https://www.youtube.com/watch?v=uC4Xay0q9_Q) lors du [2021 Global Maintainer Summit](https://globalmaintainersummit.github.com/). Plotka est un des nombreux mainteneurs des projets [Prometheus](https://github.com/prometheus/prometheus) et [Thanos](https://github.com/thanos-io/thanos), parmi bien d'autres, et il a pris part à l'Open Source depuis 2015 quand il a démarré en tant que contributeur à [OpenStack](https://github.com/openstack), [Kubernetes](https://github.com/kubernetes/kubernetes) et [Apache Mesos](https://github.com/apache/mesos). Pendant ce temps, il dit avoir traversé tout le spectre de "fermé" à "ouvert" sur la gestion des contributions. Plotka [dit](https://www.youtube.com/watch?v=uC4Xay0q9_Q) qu'il démarra comme un "optimiste inexpérimenté" qui, si on lui donnait les clés du royaume, aurait accepté d'ajouter la possibilité de faire le café dans Mesos. Sur une échelle de 1 à 10, avec 1 n'acceptant aucune Pull Request et 10 les acceptant toutes, Plotka se place lui même à 9. Plus le temps passa, cependant, il découvrit que le coût de maintenance du code supplémentaire était réel, avec de nouvelles fonctionnalités qui introduisent un fardeau pour le support, les problèmes de sécurité, et potentiels problèmes de stabilité, parmi d'autres inconnues. A partir de 2018, il est devenu un mainteneur de Prometheus et un "pessimiste attentionné" qui a désormais de réelles responsabilités envers des utilisateurs finaux dans des environnements de productions. Il se trouva soudainement à 3 sur cette même échelle.> Je faisais parti de la prise de décisions clés, et on bloqua presque tout. On pensait que l'on faisait ça pour une bonne raison : stabiliser le projet, éviter la confusion des gens, et mieux aider nos utilisateurs. Le seul problème, selon Plotka, c'était que limiter les contributions vient avec son propre lot de problème bien distinct. Pour un projet comme Prometheus, qui repose sur une équipe de mainteneur pour tout garder en marche, bloquer les contributions signifiait limiter la quantité de nouveaux mainteneurs potentiels. Beaucoup de mainteneur changent de métier, prennent leurs retraites, ou perdent de l'intérêt dans le projet, donc il est important de mentorer et ajouter de nouveaux membres à l'équipe. En bloquant trop d'idées, on était en train de démotiver les potentiels contributeurs et on décourageait tout le monde de proposer des changements. Échouer dans la première interaction a eu un impact négatif sur comment la communauté de développeurs potentiels percevaient le projet et les futures relations. Après plusieurs années, Plotka indique que lui et l'équipe de Prometheus trouva un juste milieu, le plaçant à 6, un "assistant réaliste", sur son échelle d'ouverture. Au lieu de prendre une position fermé ou ouverte par défaut, Plotka dit qu'il essaye de sympathiser avec les problèmes de l'utilisateur pour les aider à trouver des solutions faisables. Cette décision donna un second souffle qui permit au projet et à sa communauté de grandir et prospérer. En même temps, accepter les contributions avec enthousiasme présente toujours les mêmes risques, donc il trouva des solutions techniques pour limiter les risques. Par exemple, cacher les fonctionnalités expérimentale derrière des "feature flag" permit aux utilisateurs finaux d'activer les nouvelles fonctionnalité, assurant que leurs expérience n'est pas cassée pour chaque ajout. Fournir une API stable pour le projet permit aux développeurs de s'intégrer avec et de créer des fonctionnalités supplémentaires via ces intégrations, qui n'ont donc pas besoin d'être maintenu et supporté par le projet. Plotka recommande également de fournir de la documentation des intégrations et des tests de compatibilité pour s'assurer que n'importe quel tiers fonctionne correctement avec votre projet. Finalement, il suggère d'avoir un processus pour accepter ou rejeter les Pull Requests de fonctionnalité, avec un focus pour les "débloquer".> Votre réponse par défaut pour accepter des fonctionnalités devrait être "nom" mais "oui" pour débloquer des contributeurs potentiels. Essayez de comprendre quel est le problème qu'ils essayent de résoudre, mettez vous à leur place, et avancez vers une solution. La solution pourrait être de merger la Pull Request s'il n'y a pas de meilleure manière, mais pourrait être aussi de suggérer quelque chose que l'utilisateur n'a pas pensé. Essayez de ne jamais dire "non" sans raisonnement. La réalité et que nos hypothèses autour de l'ouverture dans l'Open Source son souvent très idéalistes. Les projets Open Source imposent souvent des restrictions sur les contributions, dépendant de caractéristiques comme la complexité, la taille, la criticalité, et autres. Par exemple, de nombre langages de programmations Open Source ont un long processus pour les propositions de fonctionnalité, sans parler des restrictions sur les contributions de code. Alors qu'une petite bibliothèque "frontend" peut être relativement ouverte aux contributions, un projet comme Kubernetes mets la [barre bien plus haut](https://octoverse.github.com/#try-a-new-practice-pull-request-wrangling), mais pas trop haut pour qu'il puisse avoir plus de 35 000 contributeurs. La plupart des projets, cependant, se trouvent au milieu de spectre d'ouverture.>> Votre réponse par défaut pour accepter des fonctionnalités devrait être "nom" mais "oui" pour débloquer des contributeurs potentiels. Essayez de comprendre quel est le problème qu'ils essayent de résoudre, mettez vous à leur place, et avancez vers une solution. ## Réconcilier les hypothèses avec la réalité D'une certaine manière, la chose la plus non-orthodoxe à propos de la décision de Johnson, ce n'est pas qu'il a décidé de fermer son projet aux contributions, mais qu'il a clairement communiqué à ce propos, quelque chose qui [reçu beaucoup d'attention](https://news.ycombinator.com/item?id=25940195) à l'époque. Ferraioli suspecte qu'il y a bien plus de projets qui suivent silencieusement le même chemin.> C'est perçu comme une action hostile, en opposition avec poser des limites pour vous-mêmes, ce qui est saint. On devrait encourager les gens à être transparent sur le fait de ne pas avoir la capacité d'accepter des contributions. Au lieu de ça, les gens refusent simplement, silencieusement d'accepter les contributions sans communication explicite. D'une certaine manière, c'est mieux dans l'esprit des gens que d'être direct à ce propos, et c'est dommage. Ferraioli propose un model sur [comment communiquer sur l'état de votre projet Open Source](https://leaddev.com/agile-other-ways-working/how-communicate-state-your-open-source-project) qui donne aux mainteneurs 9 "états" suggéré, tel que "développement actif", "développement en pause", "stable", "abandonné", pour clairement communiquer sur le status d'un projet et définir les attentes des utilisateurs finaux et potentiels contributeurs. Si on regarde au projet archivé BoltDB de Ben Johnson, par exemple, on trouve une longue explication de Johnson dans le README:> Bolt est dans un état stable, et a de nombreuses années d'usage en production avec succès. C'est pourquoi je pense que le laisser dans l'état actuel et la décision la plus prudente. Johnson redirige les utilisateurs qui désire une version de BoltDB "avec plus de fonctionnalités" vers [bbolt](https://github.com/coreos/bbolt), un fork par CoreOS. Selon la proposition de Ferraioli, Johnson pourrait simplement déclarer le projet "abandonné". Le statut d'un projet est juste un domaine ou les projets Open Source et leurs mainteneurs pourraient bénéficier d'une meilleure communication. [Shawn "Swyx" Wang](https://github.com/sw-yx), rédacteur et éditeur chez [DX Tips](https://dx.tips/), propose une méthode pour [découper le monolithe du mainteneur](https://github.com/readme/guides/maintainer-monolith), où la communication se concentre plutôt sur les besoins du projets que sur son état. Wang se concentre sur la différence entre les normes sociales autour de l'Open Source et la réalité du terrain.> Les gens choisissent par défaut le modèle du Dictateur Bienveillant à Vie, où les auteurs sont responsables de tout. Cela cause beaucoup de burnout. La manière dont on se comporte est un résultat des normes que l'on voit autour de nous, et pour changer notre comportement, il faut changer notre environnement. Le changement suggéré par Wang implique la création d'un fichier `MAINTAINERS.md` par exemple, qui fournit une structure pour permettre aux gens de s'engager dans le projet sans s'attaquer à l'actuel status quo de "l'engagement éternel".> Si c'est un problème sociale, alors on a des modèles qui ont été testé par le temps dans l'histoire humaine. On peut les étudier, apporter cette expertise, et explorer d'autres forme de gouvernance. Par exemple, tout comme de nombreuses positions dans la vie publique sont limitées dans le temps, les contributeurs pourraient rejoindre les projets Open Source pour une période définie, au lieu d'avoir les sentiments qu'ils sont engagés avec le projets indéfiniment.> Je pense que de nombreuses personnes choisissent de ne pas faire du tout de l'Open Source parce que la perception de "l'engagement éternel" est la norme. Au lieu de ça, restructurons le contrat social pour que le fardeau ne soit pas si lourd, et augmentons la quantité d'Open Source disponible. Donnons plus de succès aux projets qui ont déjà du succès en améliorant notre modèle de gouvernance. --- NdA: Merci d'avoir lu cette traduction, j'espère que vous appréciez cette interview de divers acteurs de l'Open Source sur la gouvernance des projets et la gestion des contributions 🙂

AltStyle によって変換されたページ (->オリジナル) /