Plume : bilan personnel du projet

En mars 2018, l’idée d’un nouveau projet apparaît dans mon esprit¹. La spécification ActivityPub avait été rendue « officielle » quelques mois auparavant, et pas mal de gens semblaient s’y intéresser. Je me suis dit que ça pourrait être sympa de développer un petit projet fédéré.

J’ai d’abord pensé à une galerie de photos, à la Instagram (Pixelfed n’existait pas encore, ou n’était pas assez connu pour que j’en aie entendu parler). Mais au final ce qui me motivait le plus — et qui me semblait le plus simple à implémenter si je voulais juste expérimenter avec ActivityPub — était de faire un moteur de blog fédéré. C’est ainsi qu’est né la première version de Plume, en Crystal. Mais très vite j’ai eu des bugs avec le langage (qui était un peu expérimental, on va pas se mentir), et j’ai décidé de recommencer le peu que j’avais fait en Rust. J’avais déjà un peu touché à Rust, mais c’est vraiment avec Plume que je l’ai découvert.

Petit à petit, d’autres personnes sont venues me donner un coup de main. On a été une petite équipe assez motivée au début du projet, mais depuis octobre 2019 (environ), c’est de plus en plus compliqué de continuer à travailler sur le projet (pour différentes raisons selon les personnes, je ne vais détailler que les miennes ici, si je détaille). On a eu une période à vide, mais j’essaie de me re-motiver depuis quelques semaines, pour ne pas laisser le projet mourir.

Bref, c’était un historique rapide du projet, mais ce n’est pas vraiment de ça dont j’ai envie de parler, c’était juste pour le contexte. Je voudrais surtout faire un bilan de ce que le projet m’a appris et m’a apporté, pendant ces deux ans et quelques.

Rust

Comme je l’ai dit un peu plus haut, je connaissais très peu Rust avant de commencer à travailler sur Plume. J’ai appris le langage sur le tas, découvrant les concepts petit à petit.

Et je suis assez vite tombée sous le charme. Même si au début j’avais du mal à comprendre certaines erreurs, certains concepts (je n’avais fait que très peu de développement « bas niveau », la mémoire et les pointeurs ça me parlait pas forcément beaucoup), j’ai trouvé des solutions. Seule ou avec de l’aide. Le plus souvent assez inélégante et peu optimisées, mais qui compilaient.

Bref, je vais pas faire de la propagande pour Rust. Juste c’est un chouette langage même si au début on capte pas forcément tout (ce qui ne veut pas dire qu’on ne peut rien faire, juste il faut y aller doucement, et ne pas avoir peur d’écrire du code que d’autres personnes plus expérimentées pourraient juger comme « inélégant »).

Au-delà d’une nouvelle syntaxe, Rust m’a appris beaucoup de nouveaux concepts en informatique, et m’a beaucoup fait progresser je pense. Tout ce qui touche à la gestion de la mémoire, de l’ordre supérieur, et des types, je l’ai beaucoup découvert (ou redécouvert) grâce à Rust. J’avais déjà touché à certain de ces concepts, mais ils étaient moins présents et je ne les avais pas autant « explorés ».

J’ai rencontré des gens

Si vous avez contribué à Plume, ça va parler de vous, donc lisez pas cette partie si vous avez pas envie.

Ça fait un peu cliché peut-être, mais c’est quand même chouette mine de rien.

J’ai assez vite été rejoint sur le projet par d’autres personnes. Ce n’était pas la première fois que je travaillais avoir quelqu’un d’autre sur un projet à distance, mais c’était sûrement la première fois que ça a duré aussi longtemps, et qu’il y avait autant de monde.

Tou⋅te⋅s les contributeurices ne sont pas resté⋅e⋅s. Certain⋅e⋅s ont fait une modification et n’ont plus touché au code. Toutes les personnes qui sont dans le salon Matrix ne le lisent plus forcément². Mais c’est pas grave, c’est chouette de voir que des gens ont eu envie d’aider, que le projet leur a suffisamment plût pour ça, même si ça n’a été qu’une fois.

En plus, il y a pas mal de contributeurices qui ne se sont pas arrêté⋅e⋅s à leur première fois. J’ai dû discuter avec ces gens, d’abord pour travailler ensemble, mais doucement on a appris à se connaitre un peu. On est sans doute pas les meilleur⋅e⋅s ami⋅e⋅s du monde, mais on s’entend bien, et on arrive à parler d’autres sujets que de Plume de temps en temps.

Gérer un projet

J’ai aussi beaucoup appris en termes de gestion de projet.

« Mon » projet ?

Mais face à tou⋅te⋅s ces contributeurices, il a fallu que j’organise le projet, et que je rende leur contribution possible. C’était la première fois que je gérais quelque chose de cette envergure, et je voulais le faire le mieux possible. Je ne voulais pas que ça soit mon projet, mais que d’autres personnes s’en emparent aussi³³.

Au final, ce n’est pas vraiment un succès je crois : j’ai annoncé il y a quelques mois vouloir arrêter de contribuer au projet — par manque de temps et de motivation — et de le laisser à quelqu’un d’autre, mais personne dans la communauté n’a réellement été capable de vraiment reprendre le projet en main. J’ai un peu l’impression que sans moi, le projet ne peut pas continuer à avancer (et j’ai un peu l’impression de me donner beaucoup d’importance en écrivant ça, mais en même temps les faits semblent me donner raison). Depuis j’ai retrouvé un peu de motivation, et je pense que je vais en profiter pour faire une transition en douceur vers de nouveaux mainteneureuses plutôt que d’abandonner totalement le projet du jour au lendemain comme j’ai eu envie de le faire depuis longtemps.

Au niveau du code

Ça va parler technique, n’hésitez pas à sauter cette section si vous n’y comprenez rien.

Plume est un projet de logiciel, le code reste donc assez central. Et je pense qu’une des raisons pour lesquelles il est difficile pour quelqu’un d’autre de reprendre le projet est que le code est trop complexe à comprendre, on a trop de mal à se familiariser avec.

Il y a plusieurs raisons à ça, dont je suis plus ou moins responsable :

• déjà, j’ai choisi un langage (Rust) et des dépendances (Rocket, Diesel) qui ne sont pas habituelles pour du développement web. Ces technologies sont relativement nouvelles, peu de monde les maîtrisent, et Rust peut faire peur (le langage a la réputation d’être dur à prendre en main au début, malgré tous les avantages qu’on en tire ensuite). Ça pu rebuter des gens, mais je sais que ça en a aussi attiré quelques-uns : des personnes voulaient s’essayer au Rust, et se sont dit que Plume serait un bon projet pour ça.
• j’ai tendance à écrire du code pas forcément très propre. Ça passe bien sur des projets où il n’y a que moi, mais quand il y a plein d’autres personnes, ça marche moins. Le code que j’ai écrit au début n’était pas parfait, je me disais que je corrigerais ça plus tard, mais au final je n’ai jamais vraiment pris la peine de le faire. Le code manque de documentation et c’est sans doute dur de s’y retrouver quand on n’en est pas familier.
• j’ai fait de mauvais choix techniques. Enfin, il n’y en a qu’un que je regrette vraiment et qui bloque le projet je pense : celui de WebAssembly pour le front-end. Je pense que j’ai fait ce choix surtout parce que j’avais envie de jouer avec cette nouvelle technologie qui avait l’air sympa. Certes, ça permet d’avoir du code en Rust à la fois sur le front-end et sur le back-end, mais ça complexifie beaucoup la compilation pour pas grand-chose. Et des opérations qui sont assez triviales en JavaScript sont beaucoup plus dures à faire en Rust⁴. Heureusement, ce choix serait assez simple à annuler, on pourrait revenir à du JavaScript assez facilement. Mais ça me semble bête de refaire le chemin inverse, alors que peut-être WebAssembly va rapidement devenir plus simple à utiliser. On verra bien.
• pour revenir sur les dépendances, le fait que l’écosystème Rust, et particulièrement l’écosystème web en Rust, soit assez jeune et immature nous désavantage aussi. Il n’y a pas de patterns bien établis sur lesquels on peut se reposer. Et certaines de nos dépendances ont des bugs contre lesquels on ne peut pas faire grand-chose, à part attendre les mises à jour. Un exemple de ça est le fait que Plume plante au bout de quelques heures et qu’il faut redémarrer l’instance (ce qui peut se faire automatiquement, heureusement). Ce bug ne se trouve pas dans le code de Plume, mais dans une dépendance d’une de nos dépendances. Ça peut-être un an qu’il est là, et même s’il devrait être résolu bientôt, c’est long d’attendre⁵…

ActivityPub, pour le meilleur et pour le pire

En plus de ça, on peut ajouter un autre facteur qui fait sans doute peur, et qui personnellement me décourage beaucoup de continuer à maintenir le projet. Je veux parler d’ActivityPub, le protocole de fédération de Plume (et de Mastodon, Pleroma, Pixelfed, Peertube, Mobilizon, Funkwhale, et tant d’autres).

L’idée derrière est assez chouette : un protocole de fédération standard, et assez souple pour couvrir tous les usages. La fédération pourrait vraiment changer notre façon de concevoir l’informatique à mon avis, et faciliter le passage à des solutions plus respectueuses de la vie privée.

Mais en pratique, ActivityPub n’est pas si extraordinaire que ça.

Déjà, le design du protocole a été conçu pour des cas assez spécifiques. Il utilise des concepts « d’héritage », faciles à modéliser dans les langages orientés objet, mais beaucoup plus durs à mettre en place dans des langages qui ont un système de type différent (genre tous les langages fonctionnels, et Rust).

Il a aussi été pensé pour des serveurs génériques. Les serveurs génériques sont des implémentations qui seraient capables de gérer n’importe quel type de contenu (ou activité, comme on les appelle dans le context d’ActivityPub). On pourrait avec une seule instance, un seul compte, gérer messages privés, articles de blog, photos, vidéos, forums, etc. L’idée des serveurs génériques est vraiment chouette, mais un peu complexe à mettre en place, donc ce n’est pas la voie qui a été prise. En pratique chaque implémentation se contente de gérer quelques types d’activités : Mastodon pour les messages courts, Pixelfed pour les photos, Peertube pour les vidéos, etc. Je trouve que c’est assez dommage, on pourrait mettre en commun beaucoup d’efforts, mais on préfère avancer chacun dans notre coin. Pour moi, c’était assez décourageant de travailler sur Plume en réalisant que ce n’était pas la meilleure façon de faire, qu’on aurait pût bâtir un serveur générique, qui aurait fait plus que Plume, et qui l’aurait sans doute mieux fait. C’est pour ça que j’ai essayé de me lancer dans un autre projet appelé RATP (Rust AcTivityPub), un serveur générique écrit en Rust. Mais je n’ai qu’un prototype pour le moment, et je n’y aie pas retouché depuis plusieurs semaines.

Le protocole est aussi très imprécis ou incomplet sur certains points. La sécurité n’a pas été vraiment pensée par exemple, et les différentes implémentations se sont donc débrouillées comme elles ont pu. Le souci est que les surcouches rajoutées ne sont pas forcément les mêmes partout, et elles ne sont pas forcément documentées. Pour s’assurer d’être compatible avec Mastodon et/ou Pleroma, j’ai dû lire leur code plusieurs fois, parce que juste suivre ce qui est dit dans la spécification ActivityPub ne suffit pas à avoir un serveur capable de communiquer avec tous les autres.

ActivityPub globalement n’est pas la chose la plus simple à implémenter au monde (même s’il y a sans doute plus dur), surtout si on veut faire les choses bien. C’est assez décourageant de travailler avec un protocole aussi complexe alors qu’on aurait sans doute pu faire plus simple sans perdre en possibilités.

Apprendre de ses erreurs

Comme je l’ai dit, je n’avais jamais géré de projet avant, et c’est quelque chose que j’ai un peu appris sur le tas avec Plume. Le souci c’est que si apprendre sur le tas ça marche bien pour des compétences « techniques », dans le cas de la gestion de projets nos décisions et nos actions ont souvent un impact sur des personnes. Apprendre en faisant des erreurs dans ce cas-là, c’est pas génial.

Et des erreurs j’en ai fait. Comme j’étais un peu perdue, j’ai eu tendance à copier la façon de s’organiser d’autres projets, sans forcément réfléchir si c’était adapté à Plume.

La première erreur que j’ai faite je crois, c’est de copier Pixelfed sur l’idée du concours de logo. Au tout début du projet, Plume n’avait pas de logo, et Pixelfed venait d’organiser un concours pour répondre à ce problème : chacun pouvait proposer une icône, la communauté votait, et læ gagnant⋅e remportait un peu d’argent.

Le souci avec ce genre de concours, c’est que pour tous ceux qui ne sont pas sélectionnés, ça a été du travail gratuit. Alors, OK, dans les communautés de logiciel libre (et associatives en général), le travail bénévole gratuit est omniprésent. Mais en général, quand on propose du code on est quasiment sûr qu’il sera accepté, quitte à faire quelques retouches. On a pas travaillé pour rien. Le concours de logo qu’on a organisé est en fait l’équivalent des hackathons pour une entreprise, où plusieurs équipes de développeureuses sont en compétition et où au final une seule verra son travail retenu.

Bref, à l’époque je n’avais pas ce recul, et j’ai organisé ce concours. Petit à petit je me suis rendu compte que c’était un mauvais choix, et j’ai fait quelques petites choses pour limiter les dégâts : j’ai proposé un peu d’argent à tous les participants, qu’ils aient gagné ou non, et on a ajouté une option pour pouvoir changer le logo d’une instance facilement, comme ça si un⋅e administrateurice préférait un autre logo proposé, ou voulait créer le sien, c’était possible de changer assez facilement⁶.

Mais malgré ça, le mal était fait. Ce que j’aurais dû faire plutôt, c’était trouver un⋅e graphiste qui veuille bien travailler avec nous, qu’on aurait pu payer si iel le souhaitait, et qui nous aurait fait un seul et unique logo, bien fini, et qui correspondait à nos attentes.

Autre chose que je regrette un peu, c’est le fait de trop se vendre comme une alternative. Beaucoup de projets libres font ça, mais je pense que ça n’est pas si bénéfique en termes de communication. Certes, c’est assez simple de se représenter ce que l’application fait si on dit « On est une alternative à YouTube/Doodle/Office/etc ». Mais en même temps, ça donne l’impression qu’on a juste copié quelque chose qui existait déjà, qu’on apporte rien d’original. Ça décourage plus les gens qu’autre chose : pourquoi changer si le logiciel est le même ? Je pense qu’une fois qu’on sait ce que fait l’application globalement, on ne va pas chercher les petits détails qui font la différence, en général. On va voir Mastodon comme un clone de Twitter, et on ne va pas regarder l’aspect fédéré ou la fonctionnalité de content warning qui ajoutent un plus. En plus de ça, si les gens testent notre service en ayant en tête l’idée que c’est une « alternative à… », iels vont sans cesse chercher à comparer les deux, voir ce qui manque sur la version alternative, ce qui est différent (et qui changerait leurs habitudes, donc qui ne plaît pas forcément).

Plume s’est d’abord présenté comme une alternative à Medium, plateforme de blog centralisée et qui a une forte tendance à rendre tout payant, qui est assez populaire pour des raisons toujours un peu mystérieuses pour moi. Ce n’était pas la meilleure stratégie à mon avis, Plume n’est pas Medium sur de nombreux points. Je dirais même que l’un des seuls points commun est qu’on peut publier des articles de blog avec les deux applications, c’est tout. La communauté (ou les communautés) qu’on y retrouve n’est pas la même, le design est différent, il n’y a pas de logique commerciale derrière Plume, Medium n’est pas du tout fédéré, etc. Ce sont deux logiciels très différents au final, et vendre Plume comme un Medium-like ne fait pas de sens si on regarde bien.

Dernier regret dans mes choix autour de ce projet, c’est l’organisation que j’ai choisie. Comme je l’ai dit, je ne voulais pas que ça soit « mon » projet. Je voulais que d’autres personnes contribuent, et s’approprient le projet. Ça tombait bien, Funkwhale, qui grandissait en parallèle, semblait vouloir prendre la même direction, et réussissait assez bien à le faire de ce que je voyais. J’ai donc pris exemple sur ce qu’iels faisaient au niveau de leur organisation sur certains points, espérant créer la même dynamique pour Plume.

J’ai par exemple mis en place un groupe Loomio, où on pouvait discuter des améliorations à apporter et organiser des votes ou des sondages. Au final, il a très peu servi, la plupart des discussions ont lieu sur GitHub ou sur Matrix. Je pense que Loomio n’était pas vraiment adapté pour Plume, mais je ne me suis pas posé cette question avant de le mettre en place.

Au final j’ai toujours trop l’impression que Plume est « mon » projet. La communauté était sans doute moins importante que celle de Funkwhale. Ou alors j’ai fait des mauvais choix que je n’ai pas réussi à analyser et à corriger. Ou bien il est impossible de faire d’un projet de logiciel libre un véritable commun, qui appartient à tous et non pas à une seule personne. Cette dernière piste me semble assez intéressante à creuser : si on regarde Funkwhale, il me semble que si Agate⁷ disparaissait demain, le projet serait sacrément ralenti au mieux, malgré tous les efforts pour que le développement soit transparent et ouvert à tou⋅te⋅s. Unixcorn, un projet d’hébergement de services en ligne (à la manière des CHATONS), a aussi été abandonné parce que l’ambition de créer une communauté et de créer ensemble n’est jamais devenue réalité. En plus, il y a peut-être un lien à faire avec la culture de rock-stars qu’on retrouve dans le logiciel libre, qui fait qu’on a tendance à retenir quelques noms et à toujours revenir à ces personnes. Ce biais ferait qu’on associe un projet à une personne, qu’on met en avant, et non pas à une communauté entière : « Ah oui, Plume, le projet d’Ana. » et pas « Ah oui, Plume, le projet de tous les gens qui font que Plume existe aujourd’hui. ».

D’un autre côté, peut-être que si j’avais gardé Plume comme « mon » projet avant tout (sans pour autant refuser les contributions, mais sans spécialement chercher à les encourager non plus), peut-être que j’aurais pu avancer plus efficacement, n’attendant pas la validation d’autres personnes avant de mettre en place un changement, évitant des discussions sur les fonctionnalités à implémenter, et gagnant du temps en ne mettant pas en place les structures qui facilitent la contribution, temps que j’aurais pu utiliser pour écrire du code ou de la documentation, pour faire des choses qui font avancer le projet plus « concrètement ». Mais je ne sais pas si ça aurait été mieux, et je crois que je préfère avoir échoué à faire de Plume un projet communautaire après avoir essayé, plutôt que d’avoir fait avancé le projet plus efficacement, mais en décourageant des personnes de contribuer parce que je ne tendais pas assez la main.

En réalité, je ne sais pas si les efforts pour rendre la contribution accessible à tou⋅te⋅s ont vraiment été payants. Si nous n’avions pas fait ces efforts d’ouverture et de transparence, de gestion « démocratique » du projet, est-ce qu’il y aurait eu moins de contributeurices ? Peut-être qu’il y en aurait eu plus ? Ou peut-être que nous n’avons pas poussé ces efforts assez loin pour réellement changer quelque chose ? Malheureusement, je crois qu’on ne pourra jamais répondre à ces questions, il aurait fallu tester différentes stratégies en parallèle et comparer les résultats, mais ce n’est pas vraiment réalisable…

Conclusion

Je crois avoir dit tout ce que je voulais dire. J’espère que je n’ai pas trop raconté ma vie, et que ces quelques réflexions pourront aider d’autres personnes à mieux mener leurs projets (que ça soit du logiciel libre, ou non).

Comme je l’ai dit, je vais sans doute doucement m’écarter de Plume, si j’arrive à trouver quelqu’un (ou plusieurs personnes) pour le reprendre à ma place. En attendant, je continuerais quand même à avancer dessus, et à apprendre et à découvrir de nouvelles choses grâce à ce projet.