tag:linuxfr.org,2005:/tags/interview/publicLinuxFr.org : les contenus étiquetés avec « interview »2024-03-11T09:12:06+01:00/favicon.pngtag:linuxfr.org,2005:Bookmark/80232024-03-08T05:18:54+01:002024-03-08T09:42:53+01:00Nathalie Azoulai : "Les codeurs informatiques ont un pouvoir d'écriture comparable aux scribes (…)<a href="https://www.radiofrance.fr/franceinter/podcasts/l-invite-de-7h50-du-week-end/l-invite-de-7h50-du-we-du-samedi-13-janvier-2024-2412060">https://www.radiofrance.fr/franceinter/podcasts/l-invite-de-7h50-du-week-end/l-invite-de-7h50-du-we-du-samedi-13-janvier-2024-2412060</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/135076/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/gilcot/liens/nathalie-azoulai-les-codeurs-informatiques-ont-un-pouvoir-d-ecriture-comparable-aux-scribes#comments">ouvrir dans le navigateur</a>
</p>
Gil Cot ✔https://linuxfr.org/nodes/135076/comments.atomtag:linuxfr.org,2005:Bookmark/67062023-06-24T14:15:26+02:002023-06-25T06:20:28+02:00Entretien avec Håkon Wium Lie, à l'origine des CSS<a href="https://evrone.com/blog/hakon-wium-lie-interview">https://evrone.com/blog/hakon-wium-lie-interview</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/131671/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/gilcot/liens/entretien-avec-hakon-wium-lie-a-l-origine-des-css#comments">ouvrir dans le navigateur</a>
</p>
Gil Cot ✔https://linuxfr.org/nodes/131671/comments.atomtag:linuxfr.org,2005:Bookmark/65992023-06-05T05:52:52+02:002023-06-05T05:52:52+02:00[podcast] For those who just don’t Git it (interview with Pierre-Étienne Meunier)<a href="https://stackoverflow.blog/2023/05/23/for-those-who-just-dont-git-it-ep-573/">https://stackoverflow.blog/2023/05/23/for-those-who-just-dont-git-it-ep-573/</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/131467/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/gilcot/liens/podcast-for-those-who-just-don-t-git-it-interview-with-pierre-etienne-meunier#comments">ouvrir dans le navigateur</a>
</p>
Gil Cot ✔https://linuxfr.org/nodes/131467/comments.atomtag:linuxfr.org,2005:Diary/406972023-05-14T15:21:00+02:002023-05-16T10:28:23+02:00À quel point votre projet open source doit-il être ouvert ?<h2 class="sommaire">Sommaire</h2>
<ul class="toc">
<li>
<ul>
<li><a href="#toc-lopen-source-d%C3%A9vore-le-monde-et-a-besoin-danti-acide">L'Open Source dévore le monde (et a besoin d'anti-acide)</a></li>
<li><a href="#toc-open-source-mais-ferm%C3%A9-aux-contributions">Open Source, mais fermé aux contributions</a></li>
<li><a href="#toc-quand-ferm%C3%A9-nest-pas-%C3%A0-la-hauteur-de-sa-r%C3%A9putation">Quand "fermé" n'est pas à la hauteur de sa réputation</a></li>
<li><a href="#toc-trouver-l%C3%A9quilibre-entre-ouvert-et-ferm%C3%A9">Trouver l'équilibre entre ouvert et fermé</a></li>
<li><a href="#toc-r%C3%A9concilier-les-hypoth%C3%A8ses-avec-la-r%C3%A9alit%C3%A9">Réconcilier les hypothèses avec la réalité</a></li>
</ul>
</li>
</ul>
<p>NdA: Cet article, <a href="https://github.com/readme/featured/how-open-is-open-source">How 'open' should your open source be?</a>, a été initialement publié sur GitHub's The ReadME Project, et traduit par mes soins avec le consentement express de son auteur.</p>
<hr>
<p>Dans les faits, le projet <a href="https://github.com/benbjohnson/litestream">Litestream</a> est (et a toujours été) 100% open source. Il respecte les 10 prérequis de la <a href="https://opensource.org/docs/osd">définition</a> de l'Open Source Initiation, utilise une <a href="https://opensource.org/licenses/">licence approuvée par l'OSI</a>, 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.</p>
<p>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 ?</p>
<p>Le mainteneur de Litestream, <a href="https://github.com/benbjohnson">Ben Johnson</a> clôt le projet aux contributions (externes) en Janvier 2021, <a href="https://github.com/benbjohnson/litestream/commit/a8d63b54aa5bd2d9639af01e1e0c2098a65b323a#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R121">expliquant</a> dans une section du "README", intitulée <strong>"Open-Source, not Open-Contribution"</strong>, que gérer les contributions externes, même petites, était trop chronophage.</p>
<blockquote>
<p>En tant que auteur de <a href="https://github.com/boltdb/bolt">BoltDB</a>, je pense que accepter et maintenir des patchs tiers ont contribué à mon burn out et l'éventuel archivage du projet.<br>
Même les petites contributions requiert typiquement plusieurs heures de mon temps pour les tester et valider correctement.<br>
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.</p>
</blockquote>
<p>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.</p>
<p>On va revenir plus tard à Johnson et son approche non-orthodoxe un peu plus tard. D'abord, regardons comment nous en sommes arrivé là.</p>
<blockquote>
<blockquote>
<p>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.</p>
</blockquote>
</blockquote>
<h3 id="toc-lopen-source-dévore-le-monde-et-a-besoin-danti-acide">L'Open Source dévore le monde (et a besoin d'anti-acide)</h3>
<p>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 <a href="https://opensource.com/article/18/2/coining-term-open-source-software">l'invente en 1998</a>. 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.</p>
<p>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 <a href="https://github.blog/2008-02-23-oh-yeah-there-s-pull-requests-now/">introduis les "Pull Request"</a>, 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.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>-- <a href="https://github.com/juliaferraioli">Julia Ferraioli</a>, ingénieure logiciel et ambassadeur de l'Open Source</p>
<p><em>NdA: évangéliste ou ambassadeur, quelle meilleure traduction pour "advocate" ?</em></p>
<p>Avec cette facilité d'accès, les projets Open Source peuvent vivre leurs propre version de <a href="https://fr.wikipedia.org/wiki/Effet_Slashdot">l'effet Slashdot</a>, où la popularité peut être écrasante pour un mainteneur solitaire.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p><em>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.</em></p>
<p>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 <a href="https://leaddev.com/agile-other-ways-working/vision-social-model-open-source">modèle social</a> 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.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>Au delà de la recherche Open Source, cependant, certains projets Open Source choisissent de limiter les contributions pour d'autres raisons.</p>
<blockquote>
<blockquote>
<p>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.</p>
</blockquote>
</blockquote>
<h3 id="toc-open-source-mais-fermé-aux-contributions">Open Source, mais fermé aux contributions</h3>
<p>Le langage de programmation <a href="https://github.com/lua">Lua</a> 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 <a href="https://github.com/roberto-ieru">Roberto Ierusalimschy</a>, 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é.</p>
<p>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.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>Ierusalimschy indique que le but du projet est la raison principale du pourquoi il reste le seul contributeur.</p>
<blockquote>
<p>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".</p>
</blockquote>
<p>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é.</p>
<blockquote>
<p>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.</p>
<blockquote>
<p>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".</p>
</blockquote>
</blockquote>
<h3 id="toc-quand-fermé-nest-pas-à-la-hauteur-de-sa-réputation">Quand "fermé" n'est pas à la hauteur de sa réputation</h3>
<p>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.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>Sur l'aspect technique, Johnson fait écho au ressenti de Ierusalimschy à propos des contributions.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>Johnson pointe également la complexité technique de Litestream comme une raison supplémentaire pour limiter les contributions de code.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>Peu après avoir clos le code aux contributions, Johnson a ajouté une section dans le README pour adresser cela.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f696d616765732e6374666173736574732e6e65742f7335756f39356e66366e6a682f31787377565476574f4776375a57796b32506865516b2f61666239633166393739326533396437666635353537623335663836663136342f74696d2d6d6f7373686f6c6465722d43673778484e6f307572302d756e73706c6173682e6a70673f773d3134343026666d3d61766966/tim-mossholder-Cg7xHNo0ur0-unsplash.jpg?w=1440&fm=avif" alt="A grand re-opening sign" title="Source : https://images.ctfassets.net/s5uo95nf6njh/1xswVTvWOGv7ZWyk2PheQk/afb9c1f9792e39d7ff5557b35f86f164/tim-mossholder-Cg7xHNo0ur0-unsplash.jpg?w=1440&fm=avif"></p>
<p>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.</p>
<p>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.</p>
<blockquote>
<p>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.</p>
<blockquote>
<p>É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.</p>
</blockquote>
</blockquote>
<h3 id="toc-trouver-léquilibre-entre-ouvert-et-fermé">Trouver l'équilibre entre ouvert et fermé</h3>
<p>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 <a href="https://github.com/bwplotka">Bartek Plotka</a> lors de sa conférence <a href="https://www.youtube.com/watch?v=uC4Xay0q9_Q">Should I merge this feature?</a> lors du <a href="https://globalmaintainersummit.github.com/">2021 Global Maintainer Summit</a>. Plotka est un des nombreux mainteneurs des projets <a href="https://github.com/prometheus/prometheus">Prometheus</a> et <a href="https://github.com/thanos-io/thanos">Thanos</a>, parmi bien d'autres, et il a pris part à l'Open Source depuis 2015 quand il a démarré en tant que contributeur à <a href="https://github.com/openstack">OpenStack</a>, <a href="https://github.com/kubernetes/kubernetes">Kubernetes</a> et <a href="https://github.com/apache/mesos">Apache Mesos</a>. Pendant ce temps, il dit avoir traversé tout le spectre de "fermé" à "ouvert" sur la gestion des contributions.</p>
<p>Plotka <a href="https://www.youtube.com/watch?v=uC4Xay0q9_Q">dit</a> 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.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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".</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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 <a href="https://octoverse.github.com/#try-a-new-practice-pull-request-wrangling">barre bien plus haut</a>, 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.</p>
<blockquote>
<blockquote>
<p>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.</p>
</blockquote>
</blockquote>
<h3 id="toc-réconcilier-les-hypothèses-avec-la-réalité">Réconcilier les hypothèses avec la réalité</h3>
<p>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 <a href="https://news.ycombinator.com/item?id=25940195">reçu beaucoup d'attention</a> à l'époque. Ferraioli suspecte qu'il y a bien plus de projets qui suivent silencieusement le même chemin.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>Ferraioli propose un model sur <a href="https://leaddev.com/agile-other-ways-working/how-communicate-state-your-open-source-project">comment communiquer sur l'état de votre projet Open Source</a> 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:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>Johnson redirige les utilisateurs qui désire une version de BoltDB "avec plus de fonctionnalités" vers <a href="https://github.com/coreos/bbolt">bbolt</a>, un fork par CoreOS. Selon la proposition de Ferraioli, Johnson pourrait simplement déclarer le projet "abandonné".</p>
<p>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. <a href="https://github.com/sw-yx">Shawn "Swyx" Wang</a>, rédacteur et éditeur chez <a href="https://dx.tips/">DX Tips</a>, propose une méthode pour <a href="https://github.com/readme/guides/maintainer-monolith">découper le monolithe du mainteneur</a>, 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.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>Le changement suggéré par Wang implique la création d'un fichier <code>MAINTAINERS.md</code> 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".</p>
<blockquote>
<p>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.</p>
<p>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.</p>
</blockquote>
<hr>
<p>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 🙂</p>
<div><a href="https://linuxfr.org/users/linkdd/journaux/a-quel-point-votre-projet-open-source-doit-il-etre-ouvert.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/131226/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/linkdd/journaux/a-quel-point-votre-projet-open-source-doit-il-etre-ouvert#comments">ouvrir dans le navigateur</a>
</p>
David Delassushttps://linuxfr.org/nodes/131226/comments.atomtag:linuxfr.org,2005:Bookmark/54202022-11-17T21:13:00+01:002022-11-17T21:13:00+01:00Thousands Have Joined Mastodon Since Twitter Changed Hands. Its Founder Has a Vision for Democratizi<a href="https://time.com/6229230/mastodon-eugen-rochko-interview/">https://time.com/6229230/mastodon-eugen-rochko-interview/</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/129330/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/gilcot/liens/thousands-have-joined-mastodon-since-twitter-changed-hands-its-founder-has-a-vision-for-democratizi#comments">ouvrir dans le navigateur</a>
</p>
Gil Cot ✔https://linuxfr.org/nodes/129330/comments.atomtag:linuxfr.org,2005:Bookmark/53192022-10-27T19:39:04+02:002022-10-27T19:39:04+02:00Récit par Laurent de la Clergerie de son aventure à la tête de LDLC (podcast, à partir de 13min)<a href="https://www.radiofrance.fr/franceculture/podcasts/les-pieds-sur-terre/les-patrons-sympas-8599777">https://www.radiofrance.fr/franceculture/podcasts/les-pieds-sur-terre/les-patrons-sympas-8599777</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/129138/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/antistress/liens/recit-par-laurent-de-la-clergerie-de-son-aventure-a-la-tete-de-ldlc-podcast-a-partir-de-13min#comments">ouvrir dans le navigateur</a>
</p>
antistresshttps://linuxfr.org/nodes/129138/comments.atomtag:linuxfr.org,2005:Bookmark/53152022-10-27T00:27:39+02:002022-10-27T00:27:39+02:00An interview with Jean-Baptiste Kempf<a href="https://www.livevideostack.cn/news/an-interview-with-jean-baptiste-kempf-vlc-will-always-be-free-and-maintained-by-users/">https://www.livevideostack.cn/news/an-interview-with-jean-baptiste-kempf-vlc-will-always-be-free-and-maintained-by-users/</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/129131/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/antistress/liens/an-interview-with-jean-baptiste-kempf#comments">ouvrir dans le navigateur</a>
</p>
antistresshttps://linuxfr.org/nodes/129131/comments.atomtag:linuxfr.org,2005:Bookmark/50802022-08-27T12:58:19+02:002022-08-27T12:58:19+02:00[podcast] Toxic data, ce que les réseaux sociaux disent de notre société<a href="https://audioblog.arteradio.com/blog/153024/podcast/189734/toxic-data-ce-que-les-reseaux-sociaux-disent-de-notre-societe-entretien-avec-david-chavalarias-signal-sur-bruit-s-2-ep-6">https://audioblog.arteradio.com/blog/153024/podcast/189734/toxic-data-ce-que-les-reseaux-sociaux-disent-de-notre-societe-entretien-avec-david-chavalarias-signal-sur-bruit-s-2-ep-6</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/128598/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/olivedeparis/liens/podcast-toxic-data-ce-que-les-reseaux-sociaux-disent-de-notre-societe#comments">ouvrir dans le navigateur</a>
</p>
Big Petehttps://linuxfr.org/nodes/128598/comments.atomtag:linuxfr.org,2005:Bookmark/46932022-05-16T18:38:57+02:002022-05-16T18:38:57+02:00Entrevue: cybersécurité et souveraineté numérique<a href="https://news.infomaniak.com/cybersecurite-et-souverainete-numerique/">https://news.infomaniak.com/cybersecurite-et-souverainete-numerique/</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/127765/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/cg/liens/entrevue-cybersecurite-et-souverainete-numerique#comments">ouvrir dans le navigateur</a>
</p>
cghttps://linuxfr.org/nodes/127765/comments.atomtag:linuxfr.org,2005:Bookmark/42432022-02-04T09:46:34+01:002022-02-04T09:46:34+01:00Interview [en] du développeur solo de Dwarf Fortress, un projet de 20 ans<a href="https://stackoverflow.blog/2021/12/31/700000-lines-of-code-20-years-and-one-developer-how-dwarf-fortress-is-built/">https://stackoverflow.blog/2021/12/31/700000-lines-of-code-20-years-and-one-developer-how-dwarf-fortress-is-built/</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/126799/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/bux-2/liens/interview-en-du-developpeur-solo-de-dwarf-fortress-un-projet-de-20-ans#comments">ouvrir dans le navigateur</a>
</p>
buxhttps://linuxfr.org/nodes/126799/comments.atomtag:linuxfr.org,2005:Bookmark/41172022-01-12T23:58:02+01:002022-01-12T23:58:02+01:00Lisp interview: pourquoi et comment Kina Knowledge utilise Common Lisp pour ses analyses de document<a href="https://lisp-journey.gitlab.io/blog/lisp-interview-kina/">https://lisp-journey.gitlab.io/blog/lisp-interview-kina/</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/126556/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/dzecniv/liens/lisp-interview-pourquoi-et-comment-kina-knowledge-utilise-common-lisp-pour-ses-analyses-de-document#comments">ouvrir dans le navigateur</a>
</p>
dzecnivhttps://linuxfr.org/nodes/126556/comments.atomtag:linuxfr.org,2005:Bookmark/38702021-11-23T09:40:29+01:002021-11-23T09:40:29+01:00[podcast] Le code a changé : Le Français qui a vu naître Google<a href="https://www.franceinter.fr/emissions/le-code-a-change/le-francais-qui-a-vu-naitre-google">https://www.franceinter.fr/emissions/le-code-a-change/le-francais-qui-a-vu-naitre-google</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/126037/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/olivedeparis/liens/podcast-le-code-a-change-le-francais-qui-a-vu-naitre-google#comments">ouvrir dans le navigateur</a>
</p>
Big Petehttps://linuxfr.org/nodes/126037/comments.atomtag:linuxfr.org,2005:Bookmark/37852021-11-02T13:55:32+01:002021-11-02T13:55:32+01:00[podcast + trad fr] Sismique #77 La fin de la croissance ? - DENNIS MEADOWS<a href="https://www.sismique.fr/post/77-la-fin-de-la-croissance-dennis-meadows">https://www.sismique.fr/post/77-la-fin-de-la-croissance-dennis-meadows</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/125855/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/olivedeparis/liens/podcast-trad-fr-sismique-77-la-fin-de-la-croissance-dennis-meadows#comments">ouvrir dans le navigateur</a>
</p>
Big Petehttps://linuxfr.org/nodes/125855/comments.atomtag:linuxfr.org,2005:News/406502021-09-13T15:30:26+02:002021-09-13T16:14:58+02:00Interview de Nicolas Lécureuil, président du bureau de MageiaLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>Nicolas Lecureuil alias <a href="//linuxfr.org/users/neoclust">NeoClust</a> traîne ses guêtres sur LinuxFr.org depuis 2005, mais, surtout, il est président du bureau (<em>board</em>) de <a href="https://www.mageia.org/fr/">Mageia</a>, l’organe qui chapeaute le projet, depuis le début de l’année 2021. Avant cela, et sans doute aussi pour cela, Nicolas a été, et reste, très présent un peu partout dans Mageia, forums, listes de discussion ou encore le chaudron où se mitonnent les nouvelles versions de la distribution. On verra, au cours de cet entretien, que c’est un mageien de la première heure et on découvrira aussi ses ambitions et projets pour cette distribution qui est l’une des plus accessibles au grand public.</p>
<p>Avant de lui laisser la parole, interviewer Nicolas a été évident et facile pour l’utilisatrice de Mageia que je suis, mais, bien entendu, le champ est ouvert. Si vous avez des suggestions de personnes à interviewer, et comment les contacter, pour d’autres distributions, n’hésitez pas à le signaler dans les commentaires, ou par un autre moyen. Sur ce, bonne lecture.</p>
</div><ul><li>lien nᵒ 1 : <a title="https://www.mageia.org/fr/" hreflang="fr" href="https://linuxfr.org/redirect/109103">Mageia</a></li><li>lien nᵒ 2 : <a title="https://blog.mageia.org/fr/" hreflang="fr" href="https://linuxfr.org/redirect/109104">Blog de Mageia</a></li><li>lien nᵒ 3 : <a title="https://www.mageialinux-online.org" hreflang="fr" href="https://linuxfr.org/redirect/109105">Mageia Linux Online (MLO), communauté francophone de Mageia</a></li><li>lien nᵒ 4 : <a title="https://ml.mageia.org/l/lists" hreflang="en" href="https://linuxfr.org/redirect/109106">Listes de discussion de Mageia</a></li><li>lien nᵒ 5 : <a title="https://linuxfr.org/news/la-huitieme-mageia" hreflang="fr" href="https://linuxfr.org/redirect/109107">La Huitième Mageia</a></li></ul><div><h2 class="sommaire">Sommaire</h2>
<ul class="toc">
<li><a href="#toc-un-nouveau-pr%C3%A9sident-du-bureau-board">Un nouveau président du bureau (<em>board</em>)</a></li>
<li><a href="#toc-mageia-et-son-environnement">Mageia et son environnement</a></li>
<li><a href="#toc-les-%C3%A9volutions-de-mageia">Les évolutions de Mageia</a></li>
<li><a href="#toc-pour-finir">Pour finir</a></li>
</ul>
<h2 id="toc-un-nouveau-président-du-bureau-board">Un nouveau président du bureau (<em>board</em>)</h2>
<p><strong>Comment es-tu tombé dans le chaudron ?</strong></p>
<p>J’ai commencé à contribuer à <a href="https://fr.wikipedia.org/wiki/Mandrake">Mandrake</a> par hasard, j’avais vu un CD dans un magazine, j’ai testé et voulu aider.</p>
<p>J’ai tout de suite trouvé sur IRC des gens super sympas et à l’écoute. Utilisant KDE de base, environnement de bureau que j’ai trouvé simple d’accès j’ai commencé à contribuer en envoyant des correctifs au mainteneur de l’époque, qui était un employé de <a href="https://fr.wikipedia.org/wiki/Mandriva">Mandrakesoft</a>.</p>
<p>Dans un second temps j’ai commencé à réellement contribuer à KDE.</p>
<p>Un jour, lorsqu’un employé de Mandriva (après la fusion de Mandrakesoft et Connectiva) est parti, Anne Nicolas (Ennael) m’a proposé de venir le remplacer, je ne pourrai jamais assez la remercier pour cette proposition. C’est avec plaisir que j’ai intégré les effectifs. Le sentiment que j’avais en tant que contributeur n’a pas changé, les collègues étaient aussi agréables. J’ai appris à mieux connaître certaines personnes, je ne vais pas les citer j’aurais trop peur d’en oublier une.</p>
<p>Mon rôle chez Mandriva au début a été de m’occuper de la partie « desktop » pour la distribution d’une part et de la relation avec nos clients pour leurs bugs KDE d’autre part.</p>
<p>Par la suite, j’étais empaqueteur et chargé de l’intégration de la distribution MBS (Mandriva Business server). Cette distribution était basée sur <a href="https://wiki.mageia.org/en/General_report_2012#Mandriva_will_base_MBS_on_Mageia">Mageia (EN)</a> et permettait de fournir Pulse qui est un logiciel web de gestion de parc informatique (inventaire, déploiement de paquets, <em>imaging</em>, sauvegarde, etc.) à certains de nos clients.</p>
<p>Il a donc été tout naturel pour moi de rejoindre mes anciens amis, collègues et contributeurs pour Mageia. Même si certains me manquent (Coling, mikala par exemple), j’ai toujours eu un énorme plaisir à bosser avec aussi bien les anciens que les nouveaux. Tout ce petit monde m’enrichit chaque jour.</p>
<p><strong>Comment devient-on membre du « Board » de Mageia et son président ?</strong></p>
<p>Les membres du Board sont élus par les membres de Mageia, il faut donc être connu/reconnu pour son engagement envers la distribution, par exemple en triant les bogues, en participant aux réunions sur IRC. Les mandats de secrétaire, trésorier et président, hormis sur les sujets administratifs, n’ont pas d’importance, car toutes les décisions sont collégiales au <a href="https://wiki.mageia.org/en/Org_Board">Board (EN)</a> ou au <a href="https://wiki.mageia.org/en/Org_Council">Council (EN)</a><sup id="fnref1"><a href="#fn1">1</a></sup>. Il est vrai, être francophone aide forcément pour toutes questions administratives pour ces trois rôles.</p>
<p><strong>Quel est le profil des membres actuels ?</strong></p>
<p>Il n’y a pas de profil à proprement parler, les personnes sont très variées, sur le plan professionnel comme sur le plan géographique, il y a un infirmier, un étudiant, quelques développeurs logiciel, des Finlandais, des Canadiens, des États-uniens, des Anglais, des Français, etc. Mais c’est la passion et l’engagement autour de Mageia qui les réunissent.</p>
<p><strong>Comment envisages-tu cette gouvernance de Mageia ? Et d’ailleurs, commence cela se passe ?</strong></p>
<p>J’envisage cette gouvernance comme ambitieuse et pleine de co-constructions. Pour l’instant nous prenons nos marques et commençons dans le bureau à travailler à ce que nous pourrons proposer au Conseil (<em>Council</em>), le premier projet étant le renouvellement de notre parc serveur.</p>
<p>Le second projet est de relancer le développement de certaines briques de notre distribution comme urpmi. En effet urpmi est un gestionnaire de paquets complet, simple, et qui fonctionne très bien. Il lui manque le support de nouvelles fonctionnalités de rpm.</p>
<p>Nous avons dans les mains une très bonne distribution pour laquelle nous pouvons avoir de l’ambition, si nous comblons quelques lacunes.</p>
<p>Nous pourrions envisager de créer une LTS, si nous arrivons à trouver de nouveaux contributeurs pour s’occuper des mises à jour de sécurité, car, pour l’instant (sauf pour les paquets maintenus en stable par leurs mainteneurs officiels (comme le kernel/glibc/rpm/…) je m’occupe d’une bonne partie de ces mises à jour et je ne serais pas contre un petit coup de main (cela me permettrait de me dégager un peu de temps pour d’autres tâches dans la distribution). Une version LTS permettrait à certaines entreprises d’envisager l’utilisation de Mageia plus sereinement.</p>
<p><strong>As-tu des objectifs précis pour ta mandature ?</strong></p>
<p>J’ai plusieurs objectifs, mais ceux-ci n’engagent que moi tant que je n’ai pas discuté avec le Council.</p>
<p>Le premier est de relancer la communication autour de Mageia. Nous avons une super équipe, l’équipe Atelier, très réactive, à nous, développeurs, empaqueteurs, etc., de leur donner de quoi faire une bonne communication. J’aimerais aussi que de nouvelles personnes puissent intégrer ces instances car en ayant un œil nouveau, de nouvelles idées, cela peut relancer notre manière de communiquer (on doit bien se l’avouer, la communication n’a jamais été notre point fort).</p>
<p>Nous avons commencé avec des articles de blog afin de relancer la contribution à notre distribution car comme beaucoup de projets ce sont souvent les mêmes personnes qui contribuent, certains s’essoufflent et de ce fait prennent un peu de recul avec le projet (mais ceci est vrai pour bon nombre de projets dans et hors du monde informatique).</p>
<p>Il nous faut aussi attirer de nouveaux contributeurs et des nouvelles contributrices. Comme j’aime le dire : je préfère avoir des personnes qui ne s’occupent que d’un logiciel/une brique bien et ne font que ça plutôt que quelqu’un qui voudrait toucher à tout et finalement ne ferait pas grand-chose.</p>
<p>Je suis heureux de toujours avoir eu des contributeurs compétents autour de KDE/Plasma. J’ai eu mikala à une époque (qui pourra toujours revenir si l’envie et surtout le temps reviennent) et maintenant j’ai David<sup id="fnref2"><a href="#fn2">2</a></sup> qui fait un travail énorme et je ne pourrai jamais assez le remercier.</p>
<p><strong>As-tu une formation ou un parcours lié à l’informatique, si oui, est-ce que cela t’es utile pour Mageia ?</strong></p>
<p>J’ai beaucoup appris seul, et énormément grâce à l’aide et aux connaissances d’autres contributeurs.</p>
<p>J’ai à la base une formation de biochimiste, mais j’ai toujours aimé l’informatique. De ce fait après mes études, j’ai repris une formation diplômante en technicien de support Linux. Je pense que ma formation scientifique m’a apporté une certaine rigueur. Et, grâce à mon entreprise qui m’en donne l’occasion, j’apprends petit à petit à développer.</p>
<h2 id="toc-mageia-et-son-environnement">Mageia et son environnement</h2>
<p><strong>À la base de Mageia, on a une association de droit français, qu’en est-il de l’impact de Mageia hors de France ?</strong></p>
<p>J’avoue ne pas encore bien connaître l’impact de Mageia hors de France. Ce que je sais c’est que nous avons des contributeurs dans le monde entier, et de manière assez importante en Espagne avec <a href="https://www.blogdrake.net/">Blogdrake (ES)</a>.</p>
<p>Si une communauté Mageia hors de France participe à un évènement pour faire la promotion de la distribution nous sommes toujours intéressés de le savoir, car nous pouvons faire un article de blog « retour en image ».</p>
<p><strong>Comment analyses-tu le fait que Mageia n’occupe plus les dix premières place dans le classement <a href="https://distrowatch.com/">Distrowatch (EN)</a> ?</strong></p>
<p>Je pense que cela est surtout dû au fait que nous n’avons pas beaucoup ni bien communiqué ces dernières années sur notre projet. De ce fait, moins de monde allait se renseigner sur nous sur ce site. </p>
<p>Cependant, le classement Distrowatch n’a jamais pour moi été un objectif ni un repère, car bien que ce soit une sorte de « thermomètre », je ne connais aucun utilisateur lambda qui l’utilise réellement. Cela met en avant le nombre de clics sur le site mais en aucune manière la qualité de la distribution, ni celle de sa communauté.</p>
<p>En effet, Mageia a une communauté fidèle que ce soit du côté français avec <a href="https://www.mageialinux-online.org">Mageialinux-online (MLO)</a> ou espagnol avec <a href="https://www.blogdrake.net/">Blogdrake (ES)</a> (pour n’en citer que deux).</p>
<p><strong>Y a-t-il des interactions entre Mageia et d’autres distributions ?</strong></p>
<p>Il y a pour ne parler que de David et moi, une interaction avec l’équipe Java de Fedora. Chez Mageia, nous utilisons la pile Java de Fedora, et nous essayons dès que possible de leur fournir des correctifs pour cette pile. J’ai prévu de faire redescendre chez eux les correctifs sécurité que nous ajouterons chez Mageia.</p>
<p><strong>Est-ce que la pandémie a impacté l’évolution de Mageia, si oui comment ?</strong></p>
<p>Honnêtement, je n’en ai aucune idée.</p>
<p>Nous n’avons aucun système de mesure d’audience, ni au sein de la distribution ni au sein du développement, donc sur le plan utilisation, nous ne pouvons rien dire. Sur le plan engagement, c’est mitigé. Il y a de nouvelles personnes qui arrivent pour prêter main forte, sur les équipes telles que la communication et l’assurance-qualité (tester les paquets et les mises à jour avant « le grand public »), et d’autres qui se retrouvent avec plus de travail dans la vraie vie. Au final, nous n’avons pas l’impression que la pandémie ait beaucoup impacté l’évolution de Mageia.</p>
<h2 id="toc-les-évolutions-de-mageia">Les évolutions de Mageia</h2>
<p><strong>Dans les commentaires de la dépêche de présentation de Mageia 8 il a été reproché à Mageia son choix de ne pas inclure Nextcloud 21 tout de suite à cause de la version de PHP. Peux-tu nous rapporter le contexte de cette décision ? (précision Nextcloud a, depuis, été intégré à la distribution).</strong></p>
<p>Lorsque l’on maintient une distribution il y a plusieurs choses à prendre en compte :</p>
<ul>
<li>la date de livraison de la distribution ;</li>
<li>la durée de maintenance de cette dernière ;</li>
<li>la migration que devront faire les utilisateurs et les utilisatrices finaux.</li>
</ul>
<p>Concernant le dernier point, on envisage assez logiquement une migration lors du passage d’une version stable à une autre mais rarement lors de la mise à jour de paquets dans une version stable. Il est assez désagréable pour un administrateur lors d’une simple mise à jour de sécurité de devoir modifier sa configuration.</p>
<p>Mageia 8 est sortie avec PHP 8 et nous nous attendions à une levée de boucliers car « c’était trop tôt », « décidément ils ne réfléchissent pas »…</p>
<p>Au sein de la liste de développement, il y a eu des discussions riches sur ce sujet. Cela a permis de mettre en relief qu’il nous semble important que nous soyons capables de soit maintenir plusieurs versions de PHP (dans ce cas précis), soit permettre de co-installer plusieurs versions (PHP 7 contre PHP 8).</p>
<p>Le souci auquel nous avons eu à faire face était que la fin de vie de PHP 7 arrivait en début de cycle, ce qui aurait obligé les utilisateurs à migrer en pleine version stable de Mageia avec tous les soucis de migration possible.</p>
<p><strong>Aujourd’hui, si un choix similaire devait se présenter, quelle décision Mageia pourrait prendre ?</strong></p>
<p>Je pense qu’il faut analyser cette situation et travailler pour qu’un tel souci, une telle frustration ne se reproduise pas, tout en étant conscients de notre « capacité à faire », c’est-à-dire, notre capacité, sur le temps de support, de maintenir une ou plusieurs versions d’un même logiciel, d’une même librairie.</p>
<p>Je pense qu’il faut dans le cycle de la distribution, discuter bien en amont des versions que nous voulons et nous y tenir et communiquer là-dessus. De ce fait, il aurait été acté longtemps avant que nous allions passer a php8 et ainsi cela aurait laissé le temps à tout le monde de réagir.</p>
<p><strong>D’une manière générale comment décide-t-on de quel logiciel empaqueter, de quel logiciel mettre de côté ?</strong></p>
<p>Tout est une question d’utilité. Nos empaqueteurs et empaqueteuses ajoutent ce qu’ils utilisent. Cependant, même en partant de cette logique certains logiciels n’ont pas eu l’autorisation d’être ajouté.</p>
<p>En effet, si un logiciel est proposé pour être maintenu, il doit se conformer à un certain nombre de règles :</p>
<ul>
<li>une licence compatible avant tout ;</li>
<li>pas de téléchargements pendant le build, tout build doit être idempotent ;</li>
<li>de manière générale, pas d’applications figées qui ne sont plus maintenues ni les applications ayant des failles de sécurité non corrigées depuis un certain temps ;</li>
<li>pas d’application qui nécessite des centaines de dépendances à rajouter à la distribution sans mainteneur.</li>
</ul>
<p><strong>Toujours dans les commentaires de cette dépêche, au sujet de la durée de maintenance de Mageia 7 et des versions N – 1 en général, tu réponds « On peut justement réfléchir à modifier cette date, ça ne me semblerait pas déconnant ». Cela donnerait quoi ?</strong></p>
<p>Pour la Mageia 7, ce n’est pas énorme, je l’avoue, mais nous avons prolongé le support d’un mois, jusqu’au 30 juin. Il est assez compliqué actuellement avec le nombre de bénévoles, de s’engager sur une extension trop importante du support. Cependant, si nous arrivons à intégrer de nouveaux contributeurs, cela pourra/sera rediscuté, que ce soit des empaqueteurs ou de la QA (assurance qualité).</p>
<p>Car notre QA ne fait pas que tester l’installation des packages, cela pourrait être fait de manière automatique. Notre QA vérifie aussi que les CVEs<sup id="fnref3"><a href="#fn3">3</a></sup> ne sont plus valides avec les nouvelles versions. Cela prend du temps mais c’est une plus-value de Mageia.</p>
<p><strong>Le cycle de vie de Mageia est relativement long, ce qui est confortable, mais quelques logiciels très utilisés ont des cycles nettement plus courts. Penses-tu qu’il serait possible de faire évoluer la politique actuelle de Mageia et d’avoir plus de mises à jour de ces logiciels entre deux versions ?</strong></p>
<p>J’aimerais beaucoup que nous adaptions cette politique. Ça a déjà commencé avec par exemple la mise à jour de LibreOffice. Nous mettrons à jour en version 7.2 dès qu’elle sera disponible.</p>
<p>Je pense aussi qu’il est possible d’adapter cela pour certains logiciels si les mainteneurs sont actifs et réactifs. Concernant Plasma et les autres environnements de bureau, c’est un peu plus compliqué car, par exemple, pour Plasma, il y a Plasma-workspace en tant que tel, mais il y a aussi les KFrameworks à mettre à jour régulièrement (une sortie par mois), et les KDE Gears (Applications KDE comme Dolphin, KMail, K3b…) qui ont des mises à jour majeures en avril, août et en décembre et plein de petites versions mineures entre deux.</p>
<p>Il serait possible de sortir chaque nouvelle version mais cela implique une quantité très importante de paquets RPM à tester et à vérifier qu’ils s’installent correctement. L’équipe QA manque de bras pour ça (cependant cela peut changer en fonction du nombre de personnes impliquées).</p>
<p><strong>Une des critiques que l’on fait souvent, de l’extérieur, à Mageia c’est son abondance d’environnements de bureaux. Que réponds-tu à cela ?</strong></p>
<p>À cela je réponds que c’est un faux débat pour moi. En effet, si un contributeur ou une contributrice vient dans Mageia avec la volonté de maintenir un environnement de bureau et si on lui dit qu’il faut plutôt maintenir Plasma ou Gnome, il y a une chance sur deux qu’il ou elle ne le fasse pas et aille soit ailleurs soit redevienne simple utilisateur. Cependant, il faudrait que nous fassions un audit des environnements de bureau et ne garder que ceux maintenus et fonctionnels.</p>
<p><strong>Mageia jusqu’à présent utilisait des googleries ou des outils Framasoft pour certaines tâches (écriture collaborative, planning d’évènements, etc.). Est-ce qu’il est prévu que la distribution utilise ses propres outils à la place ?</strong></p>
<p>Actuellement il n’y a aucun projet de l’équipe sysadmin de Mageia pour héberger de tels projets, nous avons déjà pas mal de projets en cours, mais une fois que la liste sera épurée, ce n’est pas impossible.</p>
<p><strong>Si on veut se rapprocher du chaudron où se concocte la future Mageia, par exemple en empaquetant, que faut-il faire, avoir, connaître ? Comment ça se passe ?</strong></p>
<p>Pour se rapprocher de la version de développement, il y a plusieurs approches en fonction de ce que l’on souhaite faire.</p>
<p>La première est la simple utilisation : pour ce faire, on peut (et c’est même conseillé) s’inscrire en parallèle sur la liste<sup id="fnref4"><a href="#fn4">4</a></sup> de diffusion <a href="https://ml.mageia.org/l/info/dev">de Mageia dev</a>. Cela permet d’être au courant des modifications (par exemple récemment lorsque rpm a changé de gestionnaire de base de données).</p>
<p>La seconde, est destinée aux personnes souhaitant s’investir. Pour ce faire en plus de la liste dev, il y a la liste <a href="https://ml.mageia.org/l/info/atelier-commits">commits</a>, qui permet d’avoir en temps réel des mails des modifications dans la distribution (cotés rpms), et <a href="https://ml.mageia.org/l/info/soft-commits">soft-commits</a> pour avoir les modifications dans les logiciels (mmc, urpmi, installeur, etc.).</p>
<p>Dans les deux cas, vous devez migrer une installation de Mageia 8 vers Cauldron <sup id="fnref5"><a href="#fn5">5</a></sup> en modifiant les dépôts d’urpmi avec la méthode indiquée dans <a href="https://wiki.mageia.org/en/Cauldron-fr">le wiki de Mageia</a>. Comme les dépôts de Cauldron sont souvent modifiés au cours d’une journée, il est préférable d’utiliser un miroir spécifique. Si vous êtes en France, nous suggérons l’utilisation de <a href="http://ftp.free.fr/mirrors/mageia.org/distrib/cauldron/">celui de free.fr</a>.</p>
<p>Dans un premier temps, utilisez le chaudron dans une machine virtuelle est vivement conseillée. Son utilisation en production est déconseillée. Les mises à jour y sont trop fréquentes et peuvent parfois casser le système en attendant que la plupart des composants soient recompilés (par exemple lors de la mise à jour de la pile Perl ou Python, etc.).</p>
<h2 id="toc-pour-finir">Pour finir</h2>
<p><strong>Au niveau professionnel, quels logiciels libres utilises-tu, sur quel OS ?</strong></p>
<p>Au niveau professionnel mes deux outils les plus importants sont <a href="https://fr.wikipedia.org/wiki/Vim">Vim</a> et <a href="https://fr.wikipedia.org/wiki/Git">Git</a>. Je n’ai jamais réussi à utiliser un IDE graphique pour remplacer Vim de manière efficace. Je les utilise sur Debian et Mageia (avec une préférence pour l’une des 2 😉).</p>
<p><strong>Hormis Mageia, as-tu une autre distribution GNU/Linux préférée ou autre système libre (*BSD, Haiku, etc.) ? Et pourquoi, quels sont tes logiciels libres préférés ?</strong></p>
<p>Pour le travail j’utilise Debian et Centos, car nous fournissons notre logiciel sur ces deux systèmes d’exploitation.</p>
<p>J’utilise mes ordinateurs presque uniquement pour travailler, du coup le nombre de logiciels utilisés est assez limité, car en plus de Vim et Git j’utilise <a href="https://fr.wikipedia.org/wiki/Jitsi">Jitsi</a>, Firefox, VLC.</p>
<p><strong>Quelle question aurais-tu adoré qu’on te pose ? (évidemment tu peux y répondre)</strong></p>
<p><em>Qu’est ce qui fait de Mageia une bonne distribution ?</em></p>
<p>Mageia a, comme tout un chacun, ses particularités, ses spécificités, elle répond à la plupart des besoins usuels, c’est une bonne distribution, même si elle ne peut pas plaire à tout le monde. Cela repose sur plusieurs éléments :</p>
<ul>
<li>ses contributeurs et contributrices, actifs, à l’écoute, qui font de leur maximum pour satisfaire leur utilisation et celle des utilisateurs et des utilisatrices ;</li>
<li>sa communauté, très active, que ce soit en France ou dans d’autres pays.</li>
</ul>
<p>L’écoute est très importante pour avoir une bonne distribution, c’est pour cela que je pense qu’il faudrait qu’on mette en place un système hors <a href="https://fr.wikipedia.org/wiki/Bugzilla">Bugzilla</a>, pour poser des questions, et avoir l’avis des utilisateurs et des utilisatrices de manière plus simple et efficiente.</p>
<p><strong>Quelle question aurais-tu détesté qu’on te pose ? (en espérant que je ne te l’ai pas posée).</strong></p>
<p><em>Est-ce que ce n’est pas trop dur de venir à la tête de Mageia après Ennael ?</em></p>
<p>Simplement parce que je dois tout à Anne, car si elle n’avait pas fait appel à moi il y a douze ans, je ne sais pas si ma route professionnelle m’aurait permis d’avoir le temps de contribuer.</p>
<p>Elle m’a permis d’intégrer une équipe de personnes géniales (pas besoin de citer ils et elles se reconnaitront) et d’apprendre énormément de choses.</p>
<p>Encore merci à elle :-)</p>
<p><strong>Merci beaucoup Nicolas.</strong></p>
<div class="footnotes">
<hr>
<ol>
<li id="fn1">
<p>[N. d. M.] : le « Board » (bureau) de Mageia est l’instance qui chapeaute le projet, il est composé de membres élus. Le « Council » (conseil), qui réunit des représentants élus de chaque « Team » (équipe) de Mageia, décide de la vie du projet Mageia. Chaque « Team » est axée sur un domaine : Atelier, <em>Bug Squad</em> (anti-bogues, voir l’interview de <a href="//linuxfr.org/news/interview-de-marja-van-waes-membre-du-Council-de-mageia">Marja</a>), <em>Packagers</em> (empaquetage), QA (assurance qualité), <em>Security Team</em> (sécurité), etc. Le tout repose, administrativement, sur une association de droit français. <a href="#fnref1">↩</a></p>
</li>
<li id="fn2">
<p>[N. d. M.] : David Geiger alias david_david qui est le co mainteneur de KDE chez Mageia. <a href="#fnref2">↩</a></p>
</li>
<li id="fn3">
<p>[N. d. M.] : CVE pour <em>Common Vulnerabilities and Exposures</em>, dictionnaire d’informations publiques relatives aux vulnérabilités de sécurité. <a href="#fnref3">↩</a></p>
</li>
<li id="fn4">
<p>[N. d. M.] : la langue de toutes les listes de discussion de Mageia est l’anglais. <a href="#fnref4">↩</a></p>
</li>
<li id="fn5">
<p>[N. d. M.] : <em>Cauldron</em> est le chaudron magique où se concoctent toutes les nouvelles versions de Mageia. <a href="#fnref5">↩</a></p>
</li>
</ol>
</div>
</div><div><a href="https://linuxfr.org/news/interview-de-nicolas-lecureuil-president-du-bureau-de-mageia.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/125365/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/interview-de-nicolas-lecureuil-president-du-bureau-de-mageia#comments">ouvrir dans le navigateur</a>
</p>
YsabeauBenoît Sibaudpalm123https://linuxfr.org/nodes/125365/comments.atomtag:linuxfr.org,2005:Bookmark/32192021-06-17T10:14:23+02:002021-06-17T10:14:23+02:00[vidéo YT] Benjamin Bayart et Marc Rees chez Thinkerview<a href="https://youtu.be/EOWeewlc2CE">https://youtu.be/EOWeewlc2CE</a> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/124623/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/olivedeparis/liens/video-yt-benjamin-bayart-et-marc-rees-chez-thinkerview#comments">ouvrir dans le navigateur</a>
</p>
Big Petehttps://linuxfr.org/nodes/124623/comments.atom