Le discours, le rêve, les promesses… parfois irréalistes
1. Chacun⋅e est libre d’utiliser la monnaie Ǧ1
Promesse tenue, personne ne vous y oblige, et vous pouvez l’accepter sans condition.
2. Chacun⋅e crée une même part de monnaie
Promesse presque tenue. Il ne suffit pas d’exister, mais de se faire certifier pour ça.
3. Chacun⋅e a les mêmes droits dans la Ǧ1, il n’y a pas de chef
Le code est public, tout le monde a le droit de créer ses variantes s’iel le souhaite.
Sur le papier ça sonne bien mais, dans la réalité, avoir le droit ne suffit pas à être en mesure d’exercer ce droit. Et même en restant strictement sur les droits, tout le monde n’a pas les mêmes : membre et non-membre, modérateur ou administrateur des forums, forger et autres médias de l’écosystème Ǧ1. Certaines personnes ont des droits que d’autres n’ont pas.
4. Chacun⋅e a les mêmes pouvoirs dans la Ǧ1, il n’y a pas de chef
Là on en est loin. Outre les différences de droits citées juste au-dessus, avoir le droit de lire et de modifier du code ne suffit pas à le comprendre, et donc de pouvoir le modifier pour en obtenir ce qu’on veut.
De même, avoir le droit en tant que membre de faire tourner un nœud et d’écrire en blockchain ne suffit pas à avoir les compétences pour le faire (le faire permet de soutenir son bon fonctionnement), et encore moins celle de faire des choix éclairés qui permettraient d’exercer un pouvoir décisionnel sur l’orientation du fonctionnement de la monnaie.
Le récit de fonctionnement démocratique entre les membres grâce au pouvoir de forger des blocs est donc un leurre.
Peu font tourner un nœud et parmi eux, la plupart, pour ne pas dire la totalité, suivent et font confiance aux dev quand il s’agit de faire des mises à jour, plutôt que d’appliquer un regard méticuleux, critique et chronophage pour exercer pleinement leur pouvoir décisionnel. Et pour cause : le bagage de compétences et de temps nécessaires à ça est très élevé et donc il exclu de facto la très grande majorité des gens.
Sur ce plan, la gouvernance est donc davantage technocratique que démocratique.
Je critique, je critique, mais alors, concrètement, comment ça marche aujourd’hui ?
Qui décide quoi ?
Une tentative pour décrire la réalité informelle
Mars 2024, vu par @1000i100
Aujourd’hui une équipe technique travaille en bonne intelligence à faire en sorte que l’écosystème de la Ǧ1 fonctionne au mieux avec les ressources disponibles.
Qu’est ce que j’appelle en bonne intelligence ?
Chacun a ses spécialités et sujets de prédilection. Nous avons appris, avec les années et l’observation du travail des autres, à nous faire mutuellement confiance sur le fait d’être compétents sur ce sur quoi on travail, et sur le fait de vouloir contribuer à cet écosystème et non le saboter. A partir de là, chacun travaille à son rythme, là ou ça lui semble utile, et discute avec les autres quand ça lui semble nécessaire pour se coordonner. On ne comprend pas forcément le détail de ce que font les autres, mais tant qu’on a les grandes lignes et surtout les endroits qui pourraient impacter ce sur quoi on travaille, c’est suffisant pour bosser ensemble.
Les sous groupes au sein de l’équipe technique
Parmi les spécialités, il y a le travail sur le cœur de blockchain. Ça implique de comprendre finement : blockchain, fonctionnement réseau, cryptographie asymétrique et les concepts de la TRM. Ce qui implique aussi pas mal de math et de sécurité informatique. Aujourd’hui cela consiste à corriger les bugs dans DuniterV1 quand on les identifie, et ça, ça implique aussi de maitriser les langages Typescript et node.js. Ça consiste aussi à développer les briques nécessaires pour que DuniterV2 fasse ce qu’on souhaite (être conforme à la TRM et être au plus proche de la V1 pour qu’il soit plus facile de le mettre en oeuvre). Et le fasse de manière rapide, efficace et sécurisée. Le développement de DuniterV2 implique de comprendre le langage Rust et le framework substrate en plus des concepts listés en début de paragraphe.
D’autres développeurs s’occupent de créer, faire évoluer ou maintenir en état des interfaces destinées à faciliter l’utilisation de la Ǧ1. La plus connue d’entre elle est le “logiciel client” Cesium. Les compétences nécessaires ici sont, quel que soit le logiciel client : design, ergonomie, programmation et avoir un certain bagage également en réseau, sécurité informatique et cryptographie. Dans le cas de Cesium, derrière la programmation c’est javascript, typescript, ionic et angular qu’il faut savoir utiliser. Pour silkaj, c’est le langage Python, pour Ǧecko, c’est Flutter…
Il y a aussi ceux qui développent les sites web qui expliquent ce qu’est la Ǧ1 et indiquent où trouver quoi. Les compétences nécessaires sont encore différentes, même si on en retrouve certaines en commun.
Il y a l’administration système : ceux qui installent les logiciels sur des serveurs et vérifient que ça tourne correctement. Il y en a pour les forum.duniter.org forum.monnaie-libre.fr pour la forge logicielle git.duniter.org, pour les sites web… Là encore c’est un paquet de compétences qu’il faut maitriser et c’est à cet endroit qu’on se rend le plus compte des parties centralisées dans l’écosystème actuel.
Parmi les administrateurs système il y a une catégorie un peu à part : ceux qui s’occupent des nœuds Duniter. Eux, on les appelle les forgerons. Comme les autres, ils sont indispensables au bon fonctionnement de l’écosystème, mais contrairement aux autres, du fait du fonctionnement de la blockchain, s’il y en a quelques-uns qui font n’importe quoi, ce n’est pas grave. L’écosystème est prévu pour y résister (ce qui veut aussi dire, par opposition, que dans les autres sous-groupes les conséquences de comportements hasardeux, voir malveillants, seraient très probablement lourdes en répercussions).
Qui choisit les orientations et les priorités ?
Une part non négligeable de la gouvernance actuelle est issue de la culture du logiciel libre. Celui qui a le temps, la compétence et la volonté de faire quelque chose le fait, pour pouvoir s’en servir soi-même. En général, l’auteur en informe la communauté comme il peut, pour qu’elle puisse s’en saisir si ça lui est utile.
Les utilisateurs peuvent exprimer leurs idées et suggestions de manière purement consultative, et l’auteur ou autre personne ayant le temps, la compétence et la volonté de réaliser des évolutions les code, puis les propose à qui en veut.
Pour le développement de logiciel client comme Cesium, c’est exactement comme ça que ça se passe, mais avec la taille de la communauté, un besoin supplémentaire est apparu : celui d’utilisateur⋅ice expert⋅e relais entre développeurs et utilisateurs.
Le rôle d’utilisateur⋅ice expert⋅e relais entre utilisateur et développeur
Nombre d’utilisateurs débordant d’idées et de frustrations de ne pas être en mesure de les mettre en place elleux-même.
Pour libérer du temps aux développeurs pour qu’ils puissent développer davantage, le rôle relais d’utilisateur⋅ice expert⋅e consiste à prendre le temps avec les utilisateurs :
- de clarifier ce qui est souhaité
- de regarder si d’autres demandes couvrent déjà le besoin
- de filtrer ce qui semble réalisable et de le traduire de manière digeste et compréhensible vu du côté technique
- de transmettre les propositions pertinentes aux développeurs adéquats
- de faire patienter et gérer les frustrations associées
- d’expliquer pourquoi telle ou telle autre proposition ne tient pas la route techniquement
- de faire appréhender l’ampleur du travail nécessaire pour réaliser correctement certaines demandes
- ou encore d’expliquer ce qui pourrait déjà répondre au besoin sans développement supplémentaire
En plus de libérer du temps aux développeurs, ces compétences, principalement de communication, sont rarement le fort des développeurs, qui le font souvent assez mal en s’agaçant, se braquant, s’épuisant… Bref, ce rôle relais, qui implique d’arriver à comprendre superficiellement les enjeux techniques et d’arriver à parler aussi bien avec les développeurs qu’avec les utilisateurs, est crucial pour le passage à l’échelle qu’a déjà effectué la Ǧ1 par rapport à ses débuts, et sera encore plus vital par la suite avec son adoption croissante (et des enjeux multilingues se profilent en plus de ceux listés précédemment).
En sens inverse, pour éviter les déformations du bouche à oreille, il reste important que les développeurs puissent demander aux auteurs de propositions toutes les nuances qu’ils imaginent si le récapitulatif qui leur a été fait ne leur suffit pas.
Enfin, les développeurs sont les premiers utilisateurs de leurs logiciels et ont eux mêmes une imagination florissante. La plupart du temps, ils ne manquent pas d’idées pour faire évoluer leur logiciel, mais plutôt de temps pour coder ces évolutions. Notamment en tant que développeurs bénévoles, les demandes utilisateurs restent purement informatives/consultatives, donc chaque développeur avance selon ses propres priorités, si cela implique de ne développer que ses propres idées parce que c’est ce qui le motive, les retours utilisateurs sont dans ce cas superflu. En pratique, que ce soit via les utilisateur⋅ices expert⋅es qui font relais ou via les échanges avec les autres développeurs, il est rare que les demandes venant de la part de nombreuses personnes différentes restent ignorées (au contraire d’une demande répétée d’un utilisateur unique insistant).
Pour le cœur Duniter
TODO
L’influence du penseur d’origine, Stéphane Laborde auteur de la TRM, est moindre qu’il y a quelques années : ses prises de positions ne font pas consensus dans tous les domaines, loin de là. Pour autant, quand il parle de conformité à la TRM il reste très écouté par les développeurs.
Pour l’administration des serveurs
Les serveurs du forum, de la forge (gitlab) et des autres sites et services sont gérés par quelques personnes qui généralement attendent quelques temps d’échanges sur le forum et de rencontre pour partager les accès aux serveurs aux personnes qui semblent compétentes, motivées, et avec du temps pour s’occuper de tout ça. Globalement ça marche bien, même si parfois il y a quelques ratés (mon pseudo un peu atypique a été pris pour du spam début 2019 et pas mal de mes écrits de l’époque ont été supprimés au moment de faire du ménage parmi les faux comptes qui avaient été créés sur git.duniter.org, et les sauvegardes n’étaient pas suffisamment rigoureuses pour qu’on ait pu récupérer mes écrits. Mon code en revanche était dupliqué ailleurs et il a donc survécu).
Tous les membres de cette équipe n’ont pas forcément les mêmes accès aux mêmes serveurs. Par exemple : j’ai mis à disposition certains services (runner gitlab) depuis mon serveur, dont je suis le seul administrateur. D’autres serveurs sont gérés collectivement, mais les accès ne sont partagés qu’à ceux qui ont le temps de s’impliquer au moment où ces serveurs sont mis en place et configurés. N’étant plus actif sur ce secteur ces derniers années, je n’ai pas d’accès ssh sur les serveurs installés depuis, ni sur les serveurs perso que certains groupes locaux utilisent pour proposer des services globaux.
Bref, la gouvernance ici ressemble pas mal à : tu veux faire “ça”, tu as l’air de savoir ce que tu fais, si tu n’as pas tes propres machines pour le faire, peut-être qu’une des personnes qui a les accès à un serveur et qui te fait confiance te partagera l’accès à ce serveur pour que tu puisses le faire dessus. Ou encore : il y a “tel” souci. Qui parmi l’équipe a une idée pour le résoudre (et le temps de l’essayer) ? Ok, as-tu les accès ou as-tu besoin que je te les passe pour le faire ? Si je te les passe, soit c’est de manière temporaire juste pour l’intervention, soit ça peut être plus durable si tu les stockes chiffrés sur une machine linux intégralement chiffrée¹ pour la rendre difficile à compromettre.
¹ Chiffré signifie ce qui est communément appelé crypté, mais c’est chiffré si vous avec le code pour déchiffrer, c’est crypté si vous ne l’avez pas.
La métaphore du BTP pour rendre ça plus concret
TODO
Construire le futur avec pragmatisme
Plutôt que de se convaincre d’une illusion, en se voilant la face sur ce qui se passe réellement, je préfère prendre acte du réel, aussi imparfait soit-il, pour être en mesure de le faire évoluer en le rapprochant de ce qui me fait rêver. Et je vous invite à faire de même ici avec la Ǧ1 comme à tout endroit où vous percevez même subtilement un décalage entre ce qui se passe et le récit auquel il est confortable de se raccrocher.
Formaliser pour faire évoluer
V2
TODO
Audelas
TODO
Séparer les pouvoirs :
- dev
- admin infra dev
- admin infra forum (communication)
- admin infra sites web (communication)
- forgerons
- comité technique
- assemblée tirée au sort (aléactifs comme contre pouvoir)
- référendum ?