La gestion d’une communauté de développeurs d’un projet open source est assez délicate. Le langage de programmation Rust, conçu et développé de façon ouverte au sein de Mozilla depuis une bonne dizaine d’années, fait largement appel à sa communauté dans sa structure et son mode de développement.

Son originalité par rapport au management de projet en entreprise apparaît de façon intéressante dans le témoignage et les réflexions de Mara Bos, une jeune développeuse impliquée dans le projet dont Framalang a traduit ci-dessous les propos.

Article original sur le blog de l’autrice : Rust is not a company

Traduction Framalang : Fabrice, Côme, goofy

Rust n’est pas une entreprise

par Mara Bos

L’année dernière, en tant que contributrice occasionnelle au projet Rust, je n’ai pas trop réfléchi à la structure organisationnelle de l’équipe derrière le projet. J’ai vu une hiérarchie d’équipes et de groupes, de chefs d’équipe, etc. Tout comme n’importe quelle autre organisation. Cette année, après m’être davantage impliquée, et devenue membre de l’équipe Library ¹ puis cheffe d’équipe, j’ai pris le temps de me demander pourquoi nous avons cette structure et à quoi servent ces équipes.

Pas une entreprise

Dans la plupart des entreprises, on trouve des directeurs et des actionnaires et autres trucs dans le genre en haut de la hiérarchie, qui définissent les buts de l’entreprise. Objectifs, jalons, dates limites, et autres choses qui vont sûrement mener l’entreprise vers le but final quel qu’il soit ; généralement l’argent.

Ensuite il existe plusieurs niveaux de management répartis en départements et en équipes pour diviser la charge de travail. Chaque niveau prend en charge une part des objectifs et s’assure que sa part est faite, en assignant des tâches aux employés en bas de la hiérarchie, tous travaillant d’une manière ou d’une autre à atteindre l’objectif principal commun.

Alors que la structure derrière un gros projet open source comme Rust peut sembler similaire, vue de loin, c’est souvent complètement l’inverse. Dans un tel projet, les objectifs et buts ne sont pas ceux des équipes d’en haut, mais effectivement ceux des contributeurs.

En tant qu’équipe library, nous pourrions par exemple essayer de décider que le mécanisme de formatage (std::fmt) devrait être réécrit pour être plus petit et plus efficace. Mais prendre cette décision ne provoque pas la réécriture. Et nous n’avons pas d’employés à qui assigner les tâches. Ce n’est pas comme ça que ça fonctionne.

Au lieu de cela, un contributeur passionné d’algorithmes de formatage pourrait se manifester, et commencer à travailler sur le problème. Notre travail en tant qu’équipe library est de faire en sorte que cette personne puisse travailler. S’assurer que son projet est en accord avec le reste de la bibliothèque standard, relire son travail et fournir un retour utile et constructif. Si davantage de personnes interviennent pour collaborer sur ce projet, mettre en place un groupe de travail pour aider à tout organiser, etc.

Les entreprises ne font pas travailler le premier venu sur quelque chose. C’est ce qui fait que l’open source est particulier et si génial, si on s’y prend bien.

Objectifs personnels

Idéalement, l’objectif d’un projet open source comme Rust est simplement la combinaison des buts personnels de toutes les personnes travaillant dessus. Et là est la difficulté. Parce que quand une nouvelle personne arrive, on ne lui assigne pas une tâche qui correspond à nos objectifs. Cette personne arrive plutôt avec ses propres objectifs et ses propres idées, les ajoutant à un ensemble déjà assez varié d’objectifs potentiellement conflictuels.

Et c’est pourquoi un projet open source piloté par des bénévoles a besoin d’une structure de management. On ne peut pas juste mettre ensemble une centaine de personnes avec chacune ses propres buts et espérer que tout se passe bien.

Donc ce que fait le management, c’est prendre en considération tous les buts personnels de toutes les personnes travaillant sur un sujet, et essayer de les guider de manière à ce que les choses fonctionnent. Ça peut impliquer le fait de dire non à des idées quand elles seraient incompatibles avec d’autres idées, ou ça peut impliquer beaucoup de discussions pour harmoniser les idées afin qu’elles soient compatibles. C’est exactement l’opposé de la manière dont fonctionne une entreprise typique, où les objectifs viennent d’en haut, et où le management décide de la manière de les répartir et les assigner aux personnes qui effectuent le travail technique.

Alors que beaucoup de projets open source, dont Rust, ont un cap ou un plan d’action, ces derniers doivent reposer sur les objectifs des contributeurs individuels du projet pour que ça fonctionne. Dire « notre objectif principal en 2021 est d’améliorer les mécanismes de formatage dans la bibliothèque standard » devrait faciliter le travail des personnes travaillant déjà dessus, et attirer les personnes qui voulaient déjà travailler sur quelque chose de ce genre. Ça devrait les aider parce que nous priorisons toutes les décisions de management et les révisions de code dont ils ont besoin. Ça devrait permettre aux personnes de se concentrer et d’avancer davantage. Mais sans ces contributeurs, mettre en place de tels objectifs n’a pas de sens. Contrairement à une entreprise, nous n’avons pas à choisir ce sur quoi les personnes passent leur temps, et nous n’employons pas de personnes auxquelles assigner des tâches.

Et c’est une bonne chose.

C’est la raison pour laquelle les gens veulent travailler sur Rust.

Je ne prétends pas qu’un langage de programmation ne pourrait pas être géré « d’en haut » comme une entreprise le ferait. Beaucoup de langages de programmation ont été et sont développés de cette manière avec beaucoup d’efficacité. Ce que je dis, cependant, c’est que personnellement je ne veux pas que le projet Rust fonctionne de cette manière.

Je ne veux pas gérer le département library de l’entreprise Rust. Je veux aider les personnes qui veulent améliorer les bibliothèques du langage Rust.

Un espace pour s’épanouir

Différents contributeurs ont des objectifs très différents, travaillent avec des méthodes très variées, et ont des besoins très différents des structures de management.

Pour certains d’entre eux, nous avons des processus en place destinés à leur rendre le travail plus facile. Une personne qui veut travailler sur une nouvelle fonctionnalité du langage peut soumettre ses idées via une RFC ² et prendre part dans une discussion avec l’équipe library pour des conseils et de l’aide. Quelqu’un qui veut améliorer une grande partie du code du compilateur ³ peut soumettre une proposition de changement majeur (MCP) et en discuter avec l’équipe du compilateur. Et quelqu’un qui veut résoudre un problème dans la bibliothèque standard peut soumettre une proposition de modification et la voir relue et évaluée par des personnes qui connaissent le contexte.

En d’autres termes, nous avons créé un espace pour ces types de contributeurs. De l’espace pour faire leur travail, de l’espace pour obtenir des retours, de l’espace pour obtenir de l’aide, de l’espace pour obtenir une reconnaissance, tout l’espace dont ils ont besoin pour réussir.

Cependant, il existe malheureusement beaucoup de types de contributeurs pour lesquels nous n’avons pas créé un espace, ou pas le bon espace.

Jusqu’à une époque récente, l’équipe library était principalement concentrée sur la conception de l’API. Les problèmes critiques d’implémentation étaient gérés par l’équipe du compilateur par nécessité. Les modifications de code plus modestes étaient relus et évalués par des relecteurs individuels de l’équipe library. Mais il n’y avait pas de gestion prévue pour de plus gros changements de code. Ça signifiait qu’il n’y avait pas d’espace pour une personne qui aurait voulu remettre à neuf le code de std::fmt. Il n’y avait pas d’équipe qu’elle aurait plus rejoindre pour travailler là-dessus, rendant beaucoup plus difficile, voire impossible, d’atteindre son but.

C’est pourquoi j’ai lancé la nouvelle équipe Library.

Faire de la place pour quelque chose peut souvent amener à (accidentellement) retirer de la place pour autre chose. Une personne qui n’est pas très impliquée dans le code mais qui veut appliquer son expérience dans la conception d’API et qui se soucie beaucoup de l’interface de la bibliothèque standard ne s’épanouirait pas dans une équipe qui aime avoir des réunions hebdomadaires à propos des problèmes de correction du code et de la manière avec laquelle résoudre ces problèmes avant la prochaine version publique.

Voilà pourquoi nous avons à présent l’équipe Library API

Nous avons maintenant aussi une équipe de « Contributeurs à Library ». Un endroit pour les personnes qui sont plus impliquées dans le projet que les contributeurs occasionnels, mais qui ne font pas partie des équipes qui prennent les décisions finales. Ça fait de l’espace pour les personnes qui veulent, par exemple, travailler sur seulement un aspect particulier de la bibliothèque, ou aider à relire les modifications proposées. Jusqu’à il y a environ un an, il n’y avait pas d’espace particulier pour qu’une personne relise les changements ou qu’elle s’implique davantage d’autres manières, sans faire directement partie d’une équipe avec beaucoup plus de responsabilités.

J’ai réussi à effectuer ces changements de structure d’équipe avec l’aide des membres des équipes Core et Library, qui m’ont mise en capacité de le faire. En retour, ces changements vont, je l’espère, permettre à des membres de ces nouvelles équipes de s’épanouir, et ainsi permettre à encore plus de personnes de contribuer, pour que finalement cela soit bénéfique pour tous les utilisateurs et utilisatrices du langage.

Continuer à changer

Je n’ai pas l’impression que nous ayons maintenant un espace pour toute personne souhaitant contribuer. Mais une fois que la poussière de la réorganisation se sera dispersée, je pense que le résultat sera une amélioration par rapport à ce que nous avions auparavant, et que ça correspond mieux au projet tel qu’il est aujourd’hui.

« Aujourd’hui » est le mot important ici. Ces équipes sont faites autour des membres actuels et des personnes qui, je pense, pourraient devenir des membres dans un futur proche. Mais ce groupe de personnes et leurs besoins changent, parfois à une vitesse surprenante. Et dans un projet qui est entièrement défini par les personnes qui y contribuent, ça change le projet en lui-même et la structure dont il a besoin, tout aussi rapidement.

En 2018, l’équipe Library était très impliquée dans l’aide aux auteurs des bibliothèques ⁴ populaires de l’écosystème. L’équipe a publié un ensemble de guides, et va réviser les bibliothèques et travailler conjointement avec leurs auteurs pour les implémenter. Tout cela pour améliorer la cohérence et la qualité de l’écosystème de librairies Rust.

Il y a quelques jours encore, c’était toujours techniquement une partie des buts affichés de l’équipe, même si en pratique ça n’était plus vraiment le cas ; particulièrement depuis qu’Ashley Mannix a quitté le projet il y a un moment. Sans les personnes qui ont pour but personnel de faire que des choses se produisent, les choses ne se produisent pas.

Et c’est très bien comme ça.

Tout le monde a une longue liste de vœux pour Rust, de choses qui ne se font pas parce que personne ne travaille dessus. Nous ne sommes pas une entreprise avec des dates limites et des jalons qu’il nous faut absolument atteindre. Nous sommes un groupe, divers et fluctuant, de personnes qui essaient de gérer tout ça avec passion, en s’efforçant de faire en sorte que tous les efforts aboutissent harmonieusement.

Il y a beaucoup de choses pour lesquelles nous devrions avoir de l’espace, mais pour lesquelles nous n’avons encore de place. Mais si nous continuons à essayer, si nous continuons à effectuer de petites améliorations. À nous adapter. À prendre en compte les personnes autour de nous qui veulent contribuer elles aussi ; si nous continuons à réfléchir à la façon dont nous pouvons les aider, eux et tous les autres. Alors chaque pas sera un pas dans la bonne direction, ainsi Rust prospérera et toutes les nombreuses personnes qui travaillent sur Rust et avec Rust s’épanouiront.

Photo « Rusty but pretty »  par Jeanne à vélo, licence CC-BY-SA

Aujourd’hui c’est un peu spécial copinage, mais pourquoi pas ? Ils ne sont pas si nombreux les navigateurs web à la fois open source, grand public et à la pointe des technologies, respectueux des personnes qui les utilisent et de leurs données, distribués en langue locale à peu près partout dans le monde, pour toutes les plateformes, etc.

Il est temps de considérer que c’est une ressource précieuse pour tous (et pas seulement pour la communauté du libre).

– D’accord, mais comment y contribuer lorsqu’on est seulement utilisateur ou utilisatrice?

Pascal Chevrel qui répond aujourd’hui à nos questions nous présente une version de Firefox trop peu connue mais qui mérite toute notre attention et même notre implication : Firefox Nightly

Bonjour Pascal ! Commençons par le début : peux-tu te présenter ?
Bonjour, Parisien, 45 ans, je suis impliqué dans le projet Mozilla depuis pratiquement sa création et je travaille à plein temps pour Mozilla depuis 11 ans. De formation plutôt économique et linguistique, j’ai longtemps travaillé sur l’internationalisation des sites web de Mozilla, l’animation de communautés de traducteurs et le développement d’outils de suivi et d’assurance qualité de nos traductions. Depuis un an, j’ai quitté mes précédentes fonctions pour rejoindre l’équipe Release Management qui est chargée d’organiser et de planifier les livraisons de Firefox. Dans ce nouveau contexte, au sein du département Product Integrity, je suis maintenant responsable du canal Nightly de Firefox.

 

Alors, je doute que beaucoup des personnes qui nous lisent sachent ce qu’est exactement Nightly, tu peux nous en dire plus ?
Nightly est la version alpha de Firefox, chaque jour nous compilons Firefox avec les modifications apportées par les développeurs la veille à notre code source et nous proposons cette version de Firefox au téléchargement afin de recevoir des retours sur l’état de qualité du logiciel.

Quel est l’intérêt pour moi, péquin moyen, d’utiliser Nightly ?
Pour un internaute lambda, pas forcément à l’aise avec l’informatique, il n’y a effectivement aucun intérêt à utiliser Nightly. Les utilisateurs « ordinaires » sont encouragés à utiliser le canal Release qui est la version finale grand public et pas une version alpha ou bêta de Firefox.

Pour un utilisateur averti, utiliser Nightly signifie avoir accès à une version de Firefox qui plusieurs mois de développement d’avance sur la version finale et donc de pouvoir utiliser des fonctionnalités auxquelles n’ont pas encore accès les utilisateurs de Firefox. Depuis plusieurs mois, nous faisons un gros travail de modernisation et de nettoyage du code source de Firefox afin d’améliorer ses performances, les utilisateurs de Nightly ont donc accès à un navigateur beaucoup plus performant que la version grand public.

Pour un utilisateur averti et sensible aux valeurs véhiculées par Mozilla et par le logiciel libre, c’est aussi le meilleur moyen de participer à un projet de logiciel libre lorsque l’on a pas de temps à investir dans des activités de bénévolat. Le simple fait d’utiliser Nightly est une aide plus que précieuse au développement de Firefox car Nightly envoie par défaut des données de télémétrie et les rapports de plantage à nos développeurs qui peuvent ainsi repérer immédiatement toute nouvelle régression.

Attends ! Ça veut dire que vous préparez toutes les nuits une nouvelle version de Firefox ?! Elle doit être pleine de bogues ! Ça marche vraiment ton machin ?
Toutes les nuits en effet (d’où son nom de Nightly), nous compilons Firefox avec le code de la veille, dans toutes les langues, pour tous les systèmes d’exploitations que nous supportons, en 32 comme en 64 bits. Toutes ces versions (builds) doivent passer notre batterie de tests automatisés qui valident un niveau de qualité minimal. Évidemment, c’est une version alpha, donc moins stable, elle peut planter plus facilement qu’une version destinée au grand public…

Ceci dit c’est très utilisable, j’utilise des nightlies depuis 2002 et les véritables problèmes sont rares. Lorsqu’un vrai problème passe entre nos filets, en général la télémétrie nous en informe en quelques heures et nous livrons une deuxième nightly dans la journée pour le régler ou fournir une solution d’atténuation de l’impact causé par le bug (retour arrière sur le patch fautif, désactivation temporaire d’une nouvelle fonctionnalité si le retour arrière n’est pas possible).

Et si j’installe Nightly, ça veut dire que ça me remplace mon Firefox habituel ? Et mes favoris et mots de passe enregistrés ?

Déjà, on dit marque-page, « favori » c’est de la terminologie Microsoft, je peux avoir dans mes marque-pages le site des impôts, ça ne veut pas dire que ce soit un des mes sites favoris 😉

On peut tout à fait installer Nightly à côté d’un Firefox classique, la chose importante est de ne pas leur faire partager le même profil de données. Le plus simple est d’installer Nightly dans un nouveau profil et de synchroniser les données (marque-pages, historiques, mots de passe…) entre les deux versions via Firefox Sync, notre service de synchronisation de données.

Histoire de bien comprendre : je dois télécharger Nightly tous les matins pour profiter des dernières mises à jour ?

Non, Nightly se met à jour en arrière-plan tout seul, lorsque la nouvelle version est disponible et peut être installée, une petite flèche verte apparaît sur l’icône de menu et il suffit de cliquer dans ce menu sur un bouton qui appliquera la mise à jour, ce qui se traduit concrètement par la fenêtre qui se ferme et se rouvre en quelques secondes.

Allez, fais-nous rêver : c’est quoi les nouvelles fonctionnalités attendues ?
En novembre, nous allons sortir une mise à jour majeure de Firefox, la plus grosse mise à jour du logiciel depuis 2011. Nous travaillons à une modernisation importante du moteur de rendu des pages (Gecko) en intégrant des parties mûres de notre autre moteur de rendu en R&D, Servo. Ce moteur est écrit dans un nouveau langage informatique très performant, Rust, les gains attendus en termes de performances sont importants. Ce projet de modernisation des fondations s’appelle Quantum. Il s’agit d’un projet proprement titanesque sur lequel plusieurs équipes de développeurs travaillent à plein temps depuis plusieurs mois, la version de novembre intégrera les premiers fruits de ce travail.

Nous travaillons aussi à une modernisation de l’interface actuelle de Firefox avec notre équipe d’ergonomes et de designers afin d’améliorer aussi l’interaction avec l’utilisateur, ce projet s’appelle Photon. Tu peux voir à quoi ressemblera Firefox d’ici quelques mois en parcourant ce diaporama illustré d’aperçus de la future interface.

Tous les travaux en cours sur Quantum et Photon ne sont disponibles que sur Nightly, les amateurs de performances et de design peuvent donc avoir accès en avant première à ces avancées.

En termes de fonctionnalités spécifiques à Nightly, la gestion d’identité multiples dans une même session (qui permet d’avoir des onglets « boulot » et des onglets « perso » par exemple) semble être la nouveauté la plus appréciée de nos utilisateurs sur ce canal.

Bon si c’est pour avoir une version toute en anglais, merci bien !
Nous proposons Nightly dans toutes nos langues, il est donc disponible au téléchargement en français. Évidemment, pour les nouvelles fonctionnalités, il faut parfois attendre quelques jours pour voir celles-ci en français dans l’interface, il arrive donc parfois que certaines phrases ou items de menu soient en anglais. Mais c’est rare, les traducteurs veillent au grain.

 

Excellent ! Nightly, j’en veux © Je fais comment ?
Mozilla fournit des binaires pour Windows, Mac et Linux à cette adresse : https://nightly.mozilla.org. La seule difficulté à l’installation par rapport à un Firefox pour le grand public est qu’il faut créer un profil de données séparé si l’on veut installer Nightly à côté d’un Firefox déjà installé et pas le remplacer. Nous travaillons sur notre installeur pour qu’à l’avenir, ce profil séparé soit créé automatiquement sans intervention de l’utilisateur mais ce ne sera probablement pas effectif avant 2018.

Notre wiki contient des informations détaillées (mais en anglais) sur l’installation de Nightly selon son système d’exploitation, dont un screencast pour Windows.

Mais au fait, ça fait quand même beaucoup, beaucoup d’énergie dépensée par Mozilla pour une version de Firefox plutôt méconnue. C’est quoi votre intérêt ?

Pour développer Firefox qui est un projet de grande envergure (des centaines de développeurs, une base de code très importante, près de 100 langues et 4 systèmes d’exploitation pris en charge…), il faut le compiler tous les jours et avoir une infrastructure d’intégration continue en place, il était donc logique de proposer ces versions (que nous utilisons déjà en interne) à nos utilisateurs afin de pouvoir bénéficier d’un bêta test externe qio réponde à des questions comme : est-ce que le site de ma banque en Belgique fonctionne avec ? Est-ce que la traduction est bonne ? Est-ce qu’il est stable sur ma configuration ?…

Cela représente donc un investissement mais avoir une version dédiée au bêta-test communautaire est fait partie (ou devrait faire partie) de tout projet de logiciel libre communautaire.

Au fait, beaucoup de gens l’utilisent ?
Trop peu de gens utilisent Nightly, essentiellement les employés Mozilla et notre communauté de bénévoles les plus impliqués dans le projet Mozilla, quelques dizaines de milliers de personnes dans le monde. Cela peut sembler beaucoup dans l’absolu mais c’est en réalité assez faible car le Web est immense, les configurations matérielles sur lesquelles tournent Firefox sont des plus diverses dans le monde et nous n’avons pas aujourd’hui assez de retours d’utilisation (que ce soit la télémétrie ou des rapports de bugs plus formels) afin de prendre les meilleures décisions de développement.

Nous recherchons donc des utilisateurs mais bien sûr nous sommes très clairs sur le fait que Nightly est destiné à un public plus à l’aise avec l’informatique que la moyenne et prêt à accepter des changements de comportement ou d’interface du logiciel au jour le jour avec en contrepartie l’accès en avant-première à des fonctionnalités innovantes.

Si vous voulez aider Mozilla, que vous êtes à l’aise avec l’informatique, utiliser Nightly à la place ou à côté de votre navigateur actuel (qui n’a pas à être Firefox) est probablement le moyen le plus simple de participer au projet.

Donc, même si je n’y connais rien de rien en logiciel libre, en code, et tous les autres trucs techniques, rien qu’en utilisant Nightly, je fais avancer le schmilblick ?
Si vous êtes à l’aise avec l’informatique (en gros, si vous savez installer et désinstaller un logiciel sans faire appel à la cousine en école d’ingénieur), simplement utiliser Nightly aide énormément Mozilla et les développeurs de Firefox.
Nous avons aujourd’hui une qualité de Nightly qui est suffisante pour de très nombreux utilisateurs sans connaissances techniques particulières.

Si je vois des trucs qui clochent, je le signale où et comment ? Parce que moi le bugzilla, comment dire…
Pour les francophones, le plus simple est d’expliquer ce qui cloche dans nos forums de mozfr à cette adresse : https://forums.mozfr.org/viewforum.php?f=24
S’il s’avère que c’est effectivement un problème dont nous n’avons pas connaissance, nos modérateurs les plus anglophiles se chargeront d’ouvrir un ticket sur Bugzilla et d’agir comme intermédiaires avec les développeurs. Je passe sur le forum moi-même deux fois par semaine.

Et si je suis un développeur, et que les mots « code source », « mercurial », « bugzilla » ou « RTFM » me parlent, je peux aider quand même ?

Si vous êtes développeur non seulement vous pourrez rapporter des bugs directement dans Bugzilla mais on peut aussi vous aider à écrire le patch pour résoudre ce bug ! Il y a d’ailleurs une vingtaine de développeurs Firefox qui sont francophones si l’anglais vous fait un peu peur.

Les développeurs mais aussi les utilisateurs les plus techniques peuvent ouvrir des bugs et faire une recherche du patch qui a causé une régression grâce à l’outil mozregression

Tiens une question qu’on nous pose souvent, qui peut paraître hors sujet, mais en fait pas du tout : qu’est-ce que je peux dire à mon cousin qui utilise Google Chrome, afin qu’il envisage de passer à Firefox ?

Il n’y a pas de réponse unique à cette question car pour cela il faudrait savoir pourquoi il utilise Chrome. Si ton cousin est sensible au respect de sa vie privée, utiliser Firefox va probablement de soi. Si ce qui importe pour lui ce sont les performances, alors Nightly est certainement dans la course avec Chrome, voire plus performant sur certaines activités, ce n’a pas toujours été le cas donc c’est important à souligner. S’il est un utilisateur compulsif d’onglets, la gestion des onglets de Nightly est certainement plus riche et performante que celle de Chrome ; avoir une session avec plusieurs centaines d’onglets ouverts sur une machine récente ne pose aucun problème sous Nightly.

Je pense que de nombreux utilisateurs qui sont passés de Firefox à Chrome il y a quelques années seraient très surpris des avancées (performances, ergonomies, fonctionnalités) que nous avons intégrées dans Firefox. C’est encore plus vrai pour Nightly et je reçois quasiment quotidiennement du feedback d’utilisateurs Chrome passés avec bonheur à Nightly, C’est très encourageant pour notre grosse livraison 57 en novembre évidemment. Le magazine en ligne américain CNET a publié en juin un article intitulé « New speed boost means maybe it’s time to try Firefox again » plus qu’élogieux et ils n’ont testé que la version grand public 54. Nightly qui est en 56 est déjà bien plus performant.

Merci Pascal ! Un dernier mot ? Ou une question que tu aurais aimé qu’on te pose ?

Un grand merci à toi pour l’intérêt que tu portes à Firefox, Mozilla et mon travail sur Firefox Nightly ! Merci aussi pour le travail de vulgarisation que fait Framasoft en ce qui concerne le logiciel et la culture libre. Firefox est l’outil qui permet à Mozilla d’avoir un impact sur le Web. Étant donné le travail que fait Framasoft sur la décentralisation et de dégooglisation du web, les lecteurs de cet article seront peut être intéressés par cette récente annonce de Mozilla dans laquelle nous annonçons un budget de 2 millions de dollars dédié à financer les projets de décentralisation du Web.

… et le slogan du blog de Nightly pour le mot de la fin :
Améliorons ensemble la qualité, version après version (Let’s improve quality, build after build!)