- Manganin est une forge Git moderne sans compromis, développée en Zig, qui vise à repenser la collaboration au lieu de reproduire le modèle classique de GitHub
- Les contributeurs doivent être cautionnés par des membres existants pour pouvoir créer des issues et des PR, avec un arbre de cautionnement (vouch tree) qui permet de suivre les chaînes de responsabilité par utilisateur afin de protéger le temps et l’attention de l’équipe centrale
- Conçu avant tout pour l’auto-hébergement, le projet élimine les formats de données propriétaires et la dépendance à un fournisseur, en stockant toutes les données sous forme de fichiers texte ordinaires de Git tout en exigeant un minimum de matériel
- Il est possible d’exiger aussi un cautionnement pour cloner les dépôts, afin de bloquer les bots non autorisés et les scrapers d’entraînement de modèles sans JavaScript, redirections ni ralentissements
- Avec un workflow local-first, les issues peuvent être rédigées et modifiées hors ligne dans l’éditeur de son choix, puis synchronisées via Git, afin de réduire les frictions et désagréments du modèle GitHub traditionnel
Une structure de contribution fondée sur la confiance
- Manganin est une forge Git écrite en Zig
- Son nom vient d’un alliage de manganèse et de cuivre dont la résistivité électrique reste relativement stable malgré les variations de température
- Le nombre de lignes de code dans une PR n’est pas forcément proportionnel à sa qualité ni à l’effort fourni, et le temps comme l’attention des mainteneurs open source se raréfient encore davantage à cause du burnout
- La résonance sur les réseaux sociaux amène même des personnes qui n’ont jamais réellement utilisé un projet à avoir des opinions très tranchées à son sujet
- Dans l’arbre de cautionnement, un nouveau contributeur doit être cautionné par un contributeur existant
- Le garant promet que l’utilisateur qu’il cautionne respectera les règles du projet
- Un utilisateur cautionné obtient le droit de contribuer au projet, notamment en créant des issues et en soumettant des PR
- Pour chaque utilisateur, il est possible de remonter la chaîne de responsabilité jusqu’au sommet de l’arbre, et les personnes ayant cautionné un utilisateur qui perturbe volontairement le projet peuvent elles aussi en subir les conséquences
- L’objectif est de créer un environnement de haute confiance en liant le niveau de confiance à l’ampleur du temps pouvant être gaspillé à l’équipe centrale
- Le projet prend comme point de comparaison la structure des utilisateurs de lobste.rs, où même les sujets difficiles sont en général discutés poliment et où les blocages restent rares
Auto-hébergement et propriété des données
- Une architecture centrée sur l’auto-hébergement évite les formats de données propriétaires et la dépendance à un fournisseur, tout en limitant au minimum les besoins matériels
- Les opérateurs possèdent directement leur environnement de déploiement et leurs données, lesquelles sont stockées dans Git sous forme de fichiers texte ordinaires
- Il est possible de n’autoriser le clonage des dépôts qu’aux utilisateurs cautionnés afin de bloquer les bots non autorisés et les scrapers d’entraînement de modèles
Repenser le modèle classique des forges Git
- Alors que la plupart des forges Git existantes proposent des fonctionnalités similaires, Manganin cherche à apporter de la diversité à l’écosystème du contrôle de source avec un nouveau modèle de collaboration
- Au minimum, l’objectif est d’offrir un modèle original pour les développements futurs et, au mieux, de devenir un outil capable d’accélérer le développement des projets open source existants
- GitHub occupe une place si importante dans le développement logiciel qu’il est presque devenu synonyme de Git
- Forgejo et Codeberg ont été conçus comme des remplaçants drop-in de GitHub, mais Manganin vise un hébergement de code source basé sur Git qui ne soit pas prisonnier de choix de conception vieux de plusieurs décennies
- Le projet imagine un flux où les issues sont créées et modifiées hors ligne dans l’éditeur de texte préféré de chacun, puis synchronisées de façon Git native et local-first à l’aide d’outils éprouvés existants
- À chaque étape de la conception et de l’implémentation, l’objectif est de rester prudent afin de réduire les frictions et désagréments créés par le modèle GitHub, et de proposer de meilleures réponses aux problèmes de workflow courants
- La finalité n’est pas l’outil lui-même, mais le fait de se mettre au service des utilisateurs
Aucun commentaire pour le moment.