Sommaire
NdA: Cet article, How 'open' should your open source be?, 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 est (et a toujours été) 100% open source. Il respecte les 10 prérequis de la définition de l'Open Source Initiation, utilise une licence approuvée par l'OSI, 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 clôt le projet aux contributions (externes) en Janvier 2021, expliquant 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, 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. 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", 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, 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, 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 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 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, 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.
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 lors de sa conférence Should I merge this feature? lors du 2021 Global Maintainer Summit. Plotka est un des nombreux mainteneurs des projets Prometheus et 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, Kubernetes et Apache Mesos. Pendant ce temps, il dit avoir traversé tout le spectre de "fermé" à "ouvert" sur la gestion des contributions.
Plotka dit 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, 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 à 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 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, 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, rédacteur et éditeur chez DX Tips, propose une méthode pour découper le monolithe du mainteneur, 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 🙂
# Lecture complémentaire
Posté par azmeuk (site web personnel) . Évalué à 10.
Sur ce thème de la gestion humaine des projets de logiciels libres, je conseille la lecture de « Working in Public: The Making and Maintenance of Open Source Software » de « Nadia Eghbal ». Elle dessine un état de l'art de la manière de gérer un projet de LL aujourd'hui, allant du « on file les clés à tout le monde » au « je n'accepte aucun patch, et à la rigueur je redéveloppe moi-même ceux qu'on me soumet ».
Elle y traite aussi d'autres aspects des projets, à savoir le ratio entre le nombre d'utilisateurs et le nombre de contributeurs, et les dynamiques que cela crée. Sont évoquées aussi les « cultures » des différentes communautés, souvent en fonction des langages de programmation. Elle a interviewé du beau monde aussi.
En bref, pas de révélation majeur, mais un portrait assez détaillé de l'état de la gestion de projet des LL.
# Traduction et licence
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
Quelle est la licence de l'article initial pour vérifier si la publication de la traduction est possible (hors accord de l'auteur) ?
[^] # Re: Traduction et licence
Posté par David Delassus (site web personnel) . Évalué à 1.
J'avais fait quelques recherches en amont, il semblerait que le contenu publié par Github soit sous licence CC0-1.0 ( https://github.com/github/site-policy#license ), cela exclut l'usage de la marque "Github".
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Traduction et licence
Posté par David Delassus (site web personnel) . Évalué à 1.
Il me semblait qu'il s'agissait de la licence des contenus de Github, pas la licence des règles à proprement parlé. Les "terms and conditions" de Github sont très dur à naviguer.
Dans tout les cas, il me semble également que donner un lien vers l'article original est suffisant selon la loi américaine (qui serait celle en vigueur vu que Github est une entreprise américaine), mais je ne suis pas avocat.
Parallèlement, je suis curieux de savoir pourquoi tu mets le mot "traduit" entre guillemets…
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Traduction et licence
Posté par David Delassus (site web personnel) . Évalué à 3.
Comme dit plus haut, il me semble que la loi américaine autorise les traductions avec attribution.
Oui je veux bien savoir pourquoi tu insinue que j'ai pas passé 2h à traduire l'article et pourquoi tu te montres si condescendant.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Traduction et licence
Posté par aiolos . Évalué à 9.
Tu es quand même hyper difficile et condescendant ; le texte comporte certes des fautes, et des anglicismes, mais c'est largement lisible !
On a des doutes sur la licence, mais je pense que tu peux proposer des améliorations…
[^] # Re: Traduction et licence
Posté par David Delassus (site web personnel) . Évalué à 2.
J'ai contacté l'auteur pour avoir une confirmation explicite mais il est dans une autre timezone, si d'ici demain j'ai pas de réponse, je demanderai aux mods de takedown l'article.
J'ai le markdown en local si je reçois une réponse positive plus tard que ça.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Traduction et licence
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 4.
takedown ?
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Traduction et licence
Posté par David Delassus (site web personnel) . Évalué à 2.
Retirer / supprimer
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Traduction et licence
Posté par Julien Jorge (site web personnel) . Évalué à 10. Dernière modification le 15 mai 2023 à 15:10.
Mettre « Le texte que tu as "traduit" » avec des guillemets à « traduit », c'est déjà méprisant. Ça se lit : « le texte que tu as soi-disant traduit, si on peut qualifier de traduction cet assemblage hasardeux de mots ».
Répondre à une demande d'éclaircissement par « Tu veux vraiment une explication ? », c'est aussi très méprisant. Ça se lit : « Tu veux vraiment que je t'explique pourquoi c'est de la crotte ? T'es tellement nul que tu ne le vois pas toi même ? ».
Ce n'est pas être exigeant, c'est juste être désagréable et humiliant. Je t'invite donc à balayer devant ta porte : si tu veux prendre de haut les textes de quelqu'un, commence par les tiens.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 15 mai 2023 à 15:52.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Traduction et licence
Posté par David Delassus (site web personnel) . Évalué à 10.
Dire "c'est de la merde" c'est facile.
Dire "à cet endroit tu aurais pu améliorer comme cela" c'est plus difficile.
Toi tu choisis la facilité, tu insultes et humilie et dit "c'est de la merde". Tu prend de haut et te montre très condescendant.
Ce n'est pas de la critique que tu fais, pas de la critique constructive en tout cas. Les critiques constructives, je les accepte avec plaisir, tout est bon pour s'améliorer. Les critiques du type "c'est de la merde", je les ignore. C'est du pur troll, rien de plus.
Et bah franchement, maintenant tu me traites de pute à karma, sous quel prétexte ? sous le prétexte que ma traduction est amateure ?
Newsflash : Je suis un amateur. Je n'ai jamais prétendu être autre chose qu'un amateur. M'aurais tu dis ou je me suis planté et ce que j'aurais pu améliorer que je t'aurais remercié.
Mais la ? Va chier en fait. J'ai décidé de traduire cet article car il me semble que la gouvernance des projets open source est un sujet qui intéresse la communauté de LinuxFR, et qu'un journal aurait donné plus de visibilité qu'un simple Lien.
Vas-y moinsse, j'en ai rien à foutre du karma. Preuve en est, j'ai plussé ton commentaire irrespectueux, condescendant et méprisant.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Traduction et licence
Posté par barmic 🦦 . Évalué à 10.
Tu ne semble pas apprécier pourtant.
Maintenant en commentant pour simplement montrer ton jugement non constructif, tu t'attendais à quoi ? Toi qui insinue qu'il posterai un journal qui a dû lui prendre un sacré temps, comprends que ton comportement est difficile à comprendre et qu'au final ça ne paraît pas malin. Si ce n'est pas pour être constructif, ça ne peut mener qu'à des esclandres.
Ton jugement est si important qu'il se doit d'être partagé coût que coût si peu argumenté soit il ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Traduction et licence
Posté par Zenitram (site web personnel) . Évalué à 6.
A partir du moment où (quasi?) tous les lecteurs de ta prose interprètent de la même manière, il faut peut-être se demander si le problème n'est pas que vraiment tu as écrit de manière condescendante.
(et après on me trouve condescendant…)
Victimisation pour éviter la critique.
Je constate qu'il est de plus en difficile de te faire la moindre critique sans recevoir ta condescendance.
Peu de mots ont changé dans cette phrase par rapport à ta phrase.
Et ça vaut aussi… Pour toi, alors que tu refuses les critiques et railleries sur ta prose.
Hôpital, Charité…
Ca ne remet aucunement en cause le fond du problème (que l'auteur de la traduction n'ai pas respecté la licence et traduit avant d'avoir eu l'autorisation cf plus bas, alors que le libre est fortement basé sur les licences à respecter).
[^] # Re: Traduction et licence
Posté par David Delassus (site web personnel) . Évalué à 7.
Cela n'arrivera plus, je ne pensais pas violer un copyright, ce n'était pas mon intention.
Mais le problème que Bruno remontait était sur la qualité de la traduction, pas sur la licence que je n'ai pas respecté.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Traduction et licence
Posté par David Delassus (site web personnel) . Évalué à 8. Dernière modification le 15 mai 2023 à 19:12.
J'ai reçu la réponse de l'auteur :
Réponse positive donc, si vous pouvez modifier la préface selon leur préférence, merci :)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Traduction et licence
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
Préface modifiée, merci.
[^] # Re: Traduction et licence
Posté par aiolos . Évalué à 5.
Je ne veux bien sûr rien exiger, mais je me disais que le contenu n'étant pas sous une licence libre comme il est coutume sur ce site, il pourrait être bon d'ajouter une note précisant qu'il a été traduit par accord express de l'auteur mais que le contenu n'est pas libre.
[^] # Re: Traduction et licence
Posté par Zenitram (site web personnel) . Évalué à 3.
La "note" est déjà la : l'auteur a décoché la case sur le licence libre, donc le journal est non libre (pas de licence accordée indiquée = non libre).
Mais ça, par contre, oui, ça me semble être utile.
Genre
"NdA: Cet article, How 'open' should your open source be?, a été initialement publié sur GitHub's The ReadME Project, et traduit par mes soins avec le consentement express de son auteur."
[^] # Re: Traduction et licence
Posté par Zenitram (site web personnel) . Évalué à 3.
Je me suis trompé : "Licence CC By‑SA." en haut. A part si l'auteur de la traduction a reçu ce droit de faire (il a accord de traduction, pas de changement, de ma compréhension), il faut changer dans la DB ce 'bool'.
[^] # Re: Traduction et licence
Posté par David Delassus (site web personnel) . Évalué à 2.
Oui, erreur de ma part, je ne fais jamais attention à cette case à cocher.
La traduction étant un travail dérivé, je n'ai reçu que le droit de la distribuer via ce site, je ne peux donc pas dispenser d'autres droits.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Traduction et licence
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Modifications faites.
# Pinaillage sur le titre
Posté par raphj . Évalué à 9.
Le titre "How open should your open source be?" ne me revient pas.
Il n'y a pas de plus ou moins open source. C'est open source, ou ce n'est pas open source. Autrement dit : ça colle à la définition d'open source, ou pas.
Maintenant, on peut se demander si un projet est ouvert à la contribution, ou pas, ou un peu, à quelle point, etc. Mais c'est autre chose. Mélanger les deux concepts, ça n'aide pas. D'ailleurs, un projet n'a pas besoin d'être open source pour accepter des contributions. source-available suffit.
Ce sont juste deux concepts très distincts. Avec un certes beaucoup de porosité, mais pour réfléchir clairement à un problème, ça vaut le coup de distinguer les choses et pas tout mélanger.
La confusion est déjà beaucoup trop présente, ce n'est pas malin de l'entretenir. On lit trop souvent "ce projet n'accepte pas les contributions extérieures, ce n'est pas vraiment open source". Bah si. À commencer par SQLite. Mais c'est cette confusion qui est derrière cette phrase.
J'accepte des contributions sur des projets libres que j'ai lancé. C'est super cool mais c'est aussi vite un sujet de tracas aussi, parce qu'on ne veut pas heurter, parce que ça demande de faire des compromis, etc. De mon côté pour le moment je trouve que ça vaut le coup et que c'est une source de fun, mais je comprends le choix d'autres personnes de ne pas avoir le même avis pour leur cas précis.
[^] # Re: Pinaillage sur le titre
Posté par aiolos . Évalué à 5. Dernière modification le 15 mai 2023 à 10:48.
C'est un jeu de mot sur le double sens de "open"… Un peu comme "free software", en somme.
[^] # Re: Pinaillage sur le titre
Posté par raphj . Évalué à 3.
J'ai vu, mais je ne suis pas sûr que tout le monde capte la subtilité et dans ce cas, pas mal de gens risquent de penser que les deux occurrences de "open" de ce titre sont les mêmes.
Et d'ailleurs, contrairement à la traduction, c'est "open source" qui est qualifié de open, pas "open source project". "Project" n'apparait pas dans le titre.
Je comprend l'envie de faire des beaux titres / titres accrocheurs / provocateurs, et aussi de jouer un peu avec le langage, c'est plutôt plaisant. Mais c'est justement un point critique.
Bon, tout cela étant dit, l'article lui-même est plutôt clair. Peut-être que le titre joue volontairement sur la confusion pour la régler plus tard dans l'article.
[^] # Re: Pinaillage sur le titre
Posté par barmic 🦦 . Évalué à 4.
Je lis moins le titre come "A quel point voter project devrait être open source ?", mais comme "Comment votre projet doit être open source ?" et il y a pleins de façons de faire.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pinaillage sur le titre
Posté par HL . Évalué à 1. Dernière modification le 17 mai 2023 à 15:57.
Effectivement il semble que c'est plus la manière que quantitativement… Dans ce cas « Comment votre source ouverte devrait être ouverte ? »
Mais DeepL propose en premier une traduction avec « dans quelle mesure », ce qui revient à dire « à quel point ».
[^] # Re: Pinaillage sur le titre
Posté par barmic 🦦 . Évalué à 2.
Il semblerait que les IA aient des biais ;)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pinaillage sur le titre
Posté par raphj . Évalué à 2. Dernière modification le 17 mai 2023 à 19:07.
"De quelle manière", peut-être ?
C'est là qu'on se rend compte qu'une traduction correcte nécessite parfois le contexte, et même avec, elle peut être sujette à interprétation. Parfois parce que la formulation de départ est en réalité ambigüe.
D'ailleurs, c'est le cas ici. how a les deux sens et encore plus : "in what manner", "by what means", "to what degree or extent", "in what condition" (https://www.wordreference.com/enfr/how).
[^] # Re: Pinaillage sur le titre
Posté par David Delassus (site web personnel) . Évalué à 6.
Comme dans l'article il est mentionné à un moment une échelle allant de 0 (on accepte rien) à 10 (on accepte tout). La traduction de "How" par "À quel point" me semblait pertinente.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# Translator 2: Judgment Day
Posté par Lutin . Évalué à 3.
Militant ?
[^] # Re: Translator 2: Judgment Day
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 15 mai 2023 à 10:27.
Ambassadeur est aussi une traduction correcte. Mais évangéliste sûrement pas. On peut dire aussi "avocat", il se fait l'avocat de telle cause ou encore porte-voix.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Translator 2: Judgment Day
Posté par Misc (site web personnel) . Évalué à 6.
Je propose:
- Militambassadeur.
[^] # Re: Translator 2: Judgment Day
Posté par groumly . Évalué à 4.
Tant qu’on a des Ferrero Rocher, ça me va.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Translator 2: Judgment Day
Posté par jseb . Évalué à 8.
ou « défenseur » si on n'est pas un vrai avocat (celui qui est tout vert avec un kernel au milieu).
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: Translator 2: Judgment Day
Posté par fero14041 . Évalué à 4.
Bonjour,
J'aurais plutôt été partisan initialement d'une traduction en "évangéliste", pour ma part. Certes, il y a anglicisme, mais comme souvent dans une telle différence de culture, on manque en Europe de rôle pendant avéré. Il y a selon moi un côté militant très prononcé, à vouloir porter la bonne parole / vision, à vouloir convaincre l'autre (qu'il soit demandeur ou non): du prosélytisme (WikiPédia). Qui fait évidemment écho au christianisme évangélique. Et puis, c'est un terme déjà utilisé pour ce rôle dans la tech.
Par contre, la rédaction de ce commentaire m'a permis de comprendre qu'"évangéliste", faisant référence directe aux Évangélistes, ne matchait pas (3ème paragraphe de la notice WikiPédia sur l'Évangélisme). Du coup, "prosélyte" pourrait sans doute convenir, mais il est quand même bien négativement connoté, et je ne suis pas sûr qu'on trouve des offres d'emploi intitulées comme tel. Ça se rapproche de "lobbyiste" (autre anglicisme), mais n'est peut-être pas vendeur sur sa carte de visite…
[^] # Re: Translator 2: Judgment Day
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à -9.
Ce n'est pas tant que c'est un anglicisme, mais bon, ça fait référence à la religion, à une religion de surcroît. Et cela est à éviter.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Translator 2: Judgment Day
Posté par Lutin . Évalué à 8.
En quoi c'est un problème ? Le mot a un sens figuré qui n'a aucun lien avec la religion, de la même manière qu'on dit que le K&R est la bible du C ou qu'on parle de baptême quand on fait une chose pour la première fois.
[^] # Re: Translator 2: Judgment Day
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à -10.
Pour moi ça reste un truc religieux (et donc forcément haïssable). Et, comme il existe d'autres expressions plus adéquates je ne vois pas l'intérêt de recourir à un vocable aussi connoté. Ça révèle surtout un manque de vocabulaire, je trouve.
La bible c'est un peu différent : c'est le livre des livres donc on peut avoir le livre des livres de ceci ou de cela.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Translator 2: Judgment Day
Posté par Zenitram (site web personnel) . Évalué à 4.
Et tu ne te rends même pas compte que tu dis le contraire de la phrase précédente…
La "bible" est autant connoté religieux que "évangéliste"!
On pourrait utiliser tes phrases contre "bible", mais bon, c'est "un peu différent" (on ne sait pas vraiment pourquoi, parce que "livre des livres" ça passe alors que "amener la bonne nouvelle" non, si si il y a une différence).
Bof, il pourrait y avoir des arguments plus pertinents quand même, sans se retrouver avec des écarts gigantesques quand on applique l'argument ailleurs, si vraiment il y a un soucis.
[^] # Re: Translator 2: Judgment Day
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à -3.
Non je me contredis pas, voir https://www.cnrtl.fr/etymologie/bible.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Translator 2: Judgment Day
Posté par alberic89 🐧 . Évalué à 5.
Je vous ferais remarquer au passage que la Bible n'est pas un livre, mais un recueil de livres, les livres de la Bible qui ont chacun un nom, une période d'écriture, un style et un message bien distinct.
Par exemple, dire que le livre de la Genèse ou L'Apocalypse sont des récits historiques au même titre que les Évangiles est faux.
L'intention d'écriture des Évangiles est de garder un témoignage écrit des évènements, alors que les deux autres livres sont davantage des récits de visions prophétiques.
Un autre exemple est le livre des Proverbes, dont l'intention est clairement exprimée au chapitre 1:
La plus grande difficulté de la Bible est que tous les livres ne disposent pas d'une telle introduction.
L'informatique n'est pas une science exacte, on n'est jamais à l'abri d'un succès
[^] # Re: Translator 2: Judgment Day
Posté par David Delassus (site web personnel) . Évalué à 6.
Je préfère prôner la tolérance que la haine. Il ne faut pas mélanger religion (la philosophie) et religion (le dogme).
Dissonance cognitive. Pourquoi on pourrait pas dire "la Torah du C", ou "le Quran du C" ?
La bible ce n'est pas "le livre des livres", c'est un livre comme d'autres.
La France, et le français donc, a une culture très influencé par la chrétienté. Cela comprend les jours fériés, les expressions de langage, la manière dont on mange (je me souviens quand j'étais enfant, que le vendredi à la cantine de l'école on mangeait du poisson), etc…
Est-ce un mal ? Doit-on s'en éloigner ? Peut-être, je ne sais pas, je n'ai pas envie de débattre la dessus.
Mais ce que l'on ne peut nier, c'est que la connotation religieuse de certains mots a disparu il y a bien longtemps.
https://www.topito.com/top-expressions-origine-religieuse
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Translator 2: Judgment Day
Posté par Zenitram (site web personnel) . Évalué à 6.
Frigo fait référence à une marque aujourd'hui disparue, mais on n'y pense pas quand on parle de frigo. Perso, en tant qu'athée je n'y vois pas de soucis à l'usage d'un mot donc l'usage est différent de la source (comme plein de mots en français) car le comprend comme évangéliste technologique et vois la source du mot comme secondaire (comme j'utilise "libriste" sans penser à la personne peu avenante qui a défini les 4 libertés et "open sourciste" sans penser à l'adorateur des armes qui a défini la chose), je n'y pense pas du tout quand j'utilise le mot "évangéliste" dans ce contexte.
Par contre, on pourrait argumenter avec plus objectivité que "bouh origines" qu'il n'est sans doute pas adapté ici (on ne parle pas de "Technology evangelist" mais de "advocate"), je traduirai "advocate" par "partisan" par exemple ("militant" a une connotation négative pour pas mal de monde, je l'éviterai), même si ce n'est pas non plus une traduction précise (compliqué de traduire ce mot…)
[^] # Re: Translator 2: Judgment Day
Posté par Faya . Évalué à 3.
( Frigidaire vend encore des frigos )
[^] # Re: Translator 2: Judgment Day
Posté par alberic89 🐧 . Évalué à 2.
Ça me fait penser à l'entreprise chinoise Creality, qui se qualifient d' « évangélistes de l'impression 3d », sans aucune connotation religieuse.
L'informatique n'est pas une science exacte, on n'est jamais à l'abri d'un succès
[^] # Re: Translator 2: Judgment Day
Posté par Donk . Évalué à 2.
Moi, je propose plaideur ou plaidoyeur.
[^] # Re: Translator 2: Judgment Day
Posté par fabien . Évalué à 3.
J'arrive après la bataille sur la traduction, mais là on a une confusion:
Voilà voilà, c'était la minute corporate de quelqu'un qui a subi pas mal de pression des stakeholders pour satisfaire les shareholders. (Et parfois le shareholder est un stakeholder, mais à mon niveau ça se voit pas trop).
[^] # Re: Translator 2: Judgment Day
Posté par David Delassus (site web personnel) . Évalué à 2.
Effectivement, je me suis gouré.
Et effectivement, parfois un actionnaire est aussi un associé.
Il n'empêche que traduire "stakeholder" dans le contexte de cette phrase était assez difficile. Et je ne suis toujours pas satisfait du mot que j'ai choisi
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Translator 2: Judgment Day
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 5.
À ne pas confondre avec les steak holders, qui sont les personnes qui font cuire les pièces de viande lors d’un barbecue.
-->[]La connaissance libre : https://zestedesavoir.com
# Pull request
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9.
Exact, mais franchement orienté. Bravo pour la tournure dépréciative qui décrit une fonctionnalité en ligne de commande. Il y aurait eu plein de façons neutres de dire la même chose, sans sous-entendre qu'en 2005, un outil en ligne de commande c'est nul.
Allez, par exemple : « Git, un gestionnaire de version distribué et open source en ligne de commande créé par Linus Torvalds, a vu le jour en 2005. »
Si on veut, mais pour être honnête, il faudrait préciser que c'est une interface pour certains aspects de Git. Parce qu'enregistrer des modifications à un fichier et tout, ça se fait en ligne de commande, pas dans l'interface de Github.
Et pour être honnête, il faut aussi reconnaître que c'est une interface utilisateur supplémentaire pour Git. Parce que bon, une interface utilisateur, il y en a déjà une, la ligne de commande justement.
Faux. Pull request, ça veut dire demande de
git pull, et ça existait déjà depuis que Git existe, et c'est très utilisé pour le développement du noyau Linux. Ça consiste tout simplement à écrire à quelqu'un pour lui dire « Salut, j'ai codé une fonctionnalité, tu la trouveras dans telle branche de mon dépôt. Si ça te plaît, peux-tu faire ungit pulldessus pour l'intégrer à ton projet ? Bisous. »Github a introduit une interface graphique pour les pull requests, mais n'a en aucune façon inventé le concept.
Sans doute. Ça a rendu ce mode de contribution plus accessible. Mais de grâce, cessez de prétendre que Github a inventé la PR.
[^] # Re: Pull request
Posté par David Delassus (site web personnel) . Évalué à 2.
Je le lis plutôt comme "bien que git soit apparu en 2005, la méthode de collaboration c'est toujours les mails".
git format-patchetgit send-mailen sont la preuve.Oui bon, il fallait bien comprendre ici que l'on parlait de l'interface graphique qui te permet de le faire en quelques clics au lieu d'envoyer un patch par mail.
Github a bien inventé une interface graphique pour collaborer sur Git.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Pull request
Posté par Psychofox (Mastodon) . Évalué à 4.
Dans les faits ce qui est appellé pull-request dans la plupart des forges sont plus souvent des merge request avec une pull request implicite quand la source est un fork (ce qui n'est pas toujours le cas).
# Débat à la con
Posté par Psychofox (Mastodon) . Évalué à 6.
Tout est dans le titre.
Chacun gère son projet commme il l'entend. Certains veulent une communauté, d'autres pas. Certains code un truc, le publient et l'abandonnent parce que pas le temps ou plus l'utilité, d'autres les maintiennent plus ou moins indéfiniment ou jusqu'à ce que le projet ne leur servent plus.
# Merci pour ce travail
Posté par azerttyu (site web personnel) . Évalué à 6.
Hello
Juste pour dire merci pour ce travail de traduction. Cela fait plaisir.
Peu importe les mauvaises langues :)
[^] # Re: Merci pour ce travail
Posté par Luc-Skywalker . Évalué à 2.
tout à fait, car en lisant le journal j'avais "sqlite" en permanence en tête.
Le propos m'a paru du coup très pertinent.
"Si tous les cons volaient, il ferait nuit" F. Dard
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.