Nous avons eu une réunion, hier, avec notre collectif du Sou. Nous avons remonté, les personnes présentes au RML8 et moi-même, les divergences autour de la vision d’une monnaie unique en production, vis à vis d’une monnaie plus restreinte en taille, comme le Sou. La taille et le nom de ces monnaies seront vraisemblablement les seules différences majeures entre elles.
J’ai aussi parlé de ce post important, concernant un bug corrigé en version 0.50.5 :
Nous voila donc au coeur du sujet.
J’ai indiqué au collectif les conséquences de ces informations : ce choix met un terme à nos tests en Mayenne du Sou… ;( ou du moins nous empêchera toute montée de version > 0.5 (sauf à forker Duniter)
Aussi, nous avons une question. En fonction de la réponse, j’ai ensuite détaillé les choix qui s’ouvrent à notre collectif :
@cgeek, est-ce acceptable pour toi de décaler le code de gestion des versions antérieures dans une méthode spécifique ? (genre deprecated - ainsi, les développeurs ne sont pas perturbés à la lecture, et le code concerné est clairement flaggé)
Quitte à retirer ce code un peu plus tard : quand par exemple nous aurons développé la fonctionnalité de synchro de noeuds à partir d’un état figé (SNAPSHOT) de la BblockChain.
Avec une telle fonction, en effet, des nouveaux noeuds (sans le code spécifique < 0.6) pourraient démarrer à partir d’un état de la BC, sans besoin d’utiliser le code spécifique de vérification des blocs.
Je me rappelle bien des opinions déjà exprimées (“Vous avez lancé trop tôt”, “Une seule monnaie dans les 20 première années”, etc.) : pas la peine de relancer ce débat. Je demande juste si ce choix est acceptable pour vous. Nous avons bien compris, par ailleurs, que ce genre de problème risque de se poser à nouveau bien des fois…
En fonction de la réponse à cette demande, notre collectif devra donc choisir, assez vite, entre :
- Rejoindre la future monnaie de prod, et abandonner le nom “Sou”. Une monnaie un peu plus grande n’est pas incompatible avec les fondement de notre projet (avoir une économie plus juste sur notre territoire de vie), mais la conséquence principale est :
- En changeant de nom de monnaie, nous devrons refaire tout le travail de communication que nous avons fait depuis 2 ans. Pour vous, cela n’éveille sans doute rien. Je comprends que vous vous en foutiez. Ici, pourtant, le nom “Sou” commence à être entré, peu à peu, dans la tête des gens. Les contacts avec les acteurs locaux (associations, journaux, petites insitutions, entreprises) sont grandement facilité par cette communication. Nous avons pu établir la confiance avec eux. Nombreuses sont les personnes qui souhaitent participer à cette monnaie, une fois stabilisée (environ 500 personnes, mais cela augmente constamment).
- Notre interrogation est donc (je ne vous demande pas spécialement d’y répondre, je fais juste état) : comment gérer un changement de nom, tout en gardant la confiance et l’adhésion suscitée (qui est notre trésor - tout est facilité grâce à elle) ?
Je sais que de nombreux projet changent de nom. Nous nous demandons juste comment nous y prendre au mieux pour ne pas refaire tout le travail de pédagogie.
- Maintenir un fork de Duniter, en spécialisant au besoin pour le Sou. Cette une solution plausible, dont je pourrais me charger, avec un cout en temps important, sans parler de l’investissement technique. Cela aurait un impact sur les outils connexes développés (Cesium, ElasticSearch API, GChange, Duniter App) qui se trouveraient aussi forkés. Etant moi obligé de maintenir le fork Duniter, je n’aurais sans doute plus le temps de maintenir ces applications clientes compatibles avec le Duniter “original”. C’est sans doute moins grave, car de nouveaux développeurs arriveront pour cela, en plus de nouveaux logiciels clients.
En cas de réponse positive à notre demande, les conséquences à moyen terme restent identiques, mais simplement nous aurons un délai supplémentaire pour nous décider.
Nous n’avons encore rien décider pour l’avenir, donc. En effet, nous avons fait le choix, dans notre collectif, de décider les choses ensemble pour garder une groupe uni. Un groupe uni est (selon nous) une vraie force pour agir localement, en tenant bon dans le long terme. Tant pis si cela prend plus de temps (inertie du groupe oblige) pour choisir la bonne route. Je sais que ce choix est discutable du groupe, mais c’est le notre. Par ailleurs il n’est gérable que pour un petit groupe, comme le notre (15 membres actifs actuellement).
Je joue le jeu de vous confier ces états d’âme, au risque de susciter des moqueries.
Je rappelle toutefois que je n’ai jamais prétendu avoir raison, mais plutôt revendiquer le droit de faire ce que je crois être juste, à partir de ce que j’ai compris, et au risque de se tromper.
J’aimerai donc avoir vos opinions constructives et si possible bienveillantes (comme chacun de nous le mérite !).
EDIT : un autre choix pour nous est possible : Utiliser la monnaie de prod unique, puis travailler pour faire un peu comme ColorCoin : étiquetter certaines unités afin qu’elle circule dans une communauté plus restreinte (territoire, etc.).
Dans ce cas, c’est vraiment du long terme (ce qui n’est pas pour me déplaire), car aucune outil technique n’a encore été développé dans ce sens.
