@Attilax My 2 cents :
En tant que développeur, je ne vois pas de scandale à ne pas pouvoir vivre de la ML.
Je serais embêté que ma subsistance dépende de mes contributions à l’écosystème Duniter/Ǧ1. En effet, dans un tel cas, je serais en conflit d’intérêt : plus je suis indispensable à la ML, plus je sécurise ma subsistance, du coup, les développements allant dans un sens d’ouverture, pour rendre le projet robuste au aléa individuel sont en conflit avec mon besoin de subsistance.
En étant bénévole (gratifié, mais pas rémunéré), ce qui me motive, c’est de servir une utopie, une vision monétaire et de société qui me plais, c’est de me sentir utile à forger le monde dans le quel j’aimerais vivre. Plus encore que de m’y sentir utile, c’est considérer qu’avec mes compétences, c’est là que j’ai le levier d’action le plus important pour pousser le monde vers mes idéaux.
Cela signifie-t-il que je ne souhaite pas de soutien monétaire pour ce que je fais ? Non.
En effet, plus je peux vivre sans me soucier de ma subsistance, plus mes besoins s’élèvent dans la pyramide de Maslow pour aller vers l’accomplissement de soit : pousser le monde vers mes idéaux, donc selon ma vision actuelle, contribuer aux monnaies libres (qui se résume à l’écosystème Duniter/Ǧ1 aujourd’hui)
Du coup, comment me permettre de servir mes idéaux sans me placer en conflit d’intérêt sur le style de contribution à apporter ?
Par du soutien plutôt que de la rémunération. (En gros diluer la conditionnalité du flux monétaire assurant ma subsistance).
Ceci étant dit, c’est bien théorique tout ça.
Comment capter un flux monétaire non négligeable en restant aligné avec mes valeurs ? Et comment répondre au mieux à mes besoin de subsistance avec ?
En vrac :
- un caisse pour les développeurs, c’est cool mais viens avec l’insécurité de gouvernance : qui décide qui en fait partie ou non. De ce que j’en perçois, ce n’est pas formalisé, mais ça m’a l’air d’être du consensus, reste qu’en pratique c’est celui qui à les code du compte qui à le dernier mot. Bref, ça me semble un bon outil, mais l’avoir comme seul source de monnaie me semble peu sécurisant, ce qui m’amène à inciter à compléter cela par des don ad hominem. (mais les don ad hominem ont aussi le travers de diriger les flux monétaire vers les meilleurs communicants et non les plus gros contributeurs technique, et apporte leur conflit d’intérêt de clientélisme, bref, pour moi ce n’est pas l’un ou l’autre mais un équilibre entre les deux qui me semble le plus adapté.)
- UNL ou ML ? Idéalement, ML, mais plus particulièrement pour des dev pouvant subvenir à leur besoin en ML dès aujourd’hui. Du coup, pourquoi pas des complément en UNL (Liberapay : (dev) (moi) ), pourquoi pas des proposition de change ML/UNL à taux avantageux réservé aux dev, si cela fait sens pour ceux qui propose ces change (ça me semble être une bonne pirouette pour fournir des UNL aux dev qui en on besoin tout en les allimentant en ML).
- comment augmenter le flux de don ML ? Façon Humble Bundle, ou Hello Asso : avec une interface de paiement incluant par défaut une pourcentage de don à des caisses spécialisé (ou des comptes de developpeurs). Cela fait parti de mes projet de développement dans la mise en place de G1Billet, mais en en faisant un module indépendant, donc utilisable pour tout autre projet comme module d’interface de paiement. Je pense notament à le proposer à 2 niveaux :
- au niveau d’une instance de client Ǧ1, avec une configuration par défaut des bénéficiaires de pour boire défini par l’administrateur de l’instance.
- au niveau de G1lien, comme intermédiaire à disposition des utilisateurs avec le mode opératoire suivant : je configure mon intermédiaire comme client par défaut pour les g1lien de paiement, et je le configure pour augmenter ma transaction des pourboire de mon choix. Enfin, je lui indique le client de paiement final qui transmettra la transaction aux nœud duniter. Ensuite, a chaque transaction utilisant G1lien, celle-ci sera automatiquement augmenté des pourboires que j’ai choisi, tout en me laissant libre de les réajuster à ma guise lors de chaque transaction.
On pourrait du coup se retrouver avec plusieurs phase d’ajout/ajustement de pourboire : au niveau de l’outil qui propose la transaction (exemple gchange), qui définirait un premier lot de pourboire proposé par l’administrateur de l’instance de l’outil (gchange dans mon exemple), ensuite un g1lien est généré et les pourboires que l’utilisateur à peu y intégrer sont ajoutés. Enfin, le client de paiement choisi par l’utilisateur peut lui aussi avoir sont lot de pourboire proposé par l’administrateur de l’instance (cesium par exemple). PS : je ne recommanderais pas ergonomiquement d’avoir 3 phases de pourboire pour chaque transaction, mais seulement les 2 premières, la 1ère si présente, proposant systématiquement l’ajustement des pourboire y compris leur absence, et la 2ème, géré par l’utilisateur, pouvant être automatisé d’une coche pour ne pas freiner le processus de transaction, enfin le client final pouvant faire un récapitulatif de la transaction avec ces montants et bénéficiaire avec des coche pour annuler les lignes non souhaitées avant la validation finale.
Y’a plus qu’a ! (et au moins pour l’interface, je compte bien m’y coller d’ici peu)
PS : ce dernier système façon Humble Bundle ou Hello Asso peut bien sur servir à bien d’autre choses que rémunérer les développeurs : financer une caisse de sécu/chômage/retraite, une instance rémuniter, ou tout autre service à financement collectif (assurance pour des colis, pour des annulation de covoiturage, financement d’un groupe local…).