Quelle forge pour les services publics ? Forgejo, Tangled (AT Proto) ou autre chose : appel à expertise

Bonjour à toutes et tous,

Avec le lancement récent de la forge open source néerlandaise basée sur Forgejo, et les réflexions en cours à la DINUM sur une forge publique interministérielle, c’est le bon moment pour creuser collectivement la question : quelle architecture de forge correspond vraiment aux besoins d’une forge publique ouverte aux citoyens, aux entreprises, et aux contributions extérieures ?

Le contexte

Les Pays-Bas viennent de soft-launcher leur plateforme nationale de code open source (lien), et en France, la discussion avance : forge d’infra, forge privée sur GitLab ou Forgejo, et pour la forge publique interministérielle, un travail de coordination est à prévoir (notamment au Conseil logiciels libres).

La distinction est importante : une forge publique n’est pas une forge interministérielle.

Une forge publique a vocation à accueillir des contributions venant de l’extérieur de l’administration, comme des citoyens, la société civile, les entreprises, ou d’autres gouvernements. Cela change radicalement les exigences en matière d’identité, de gouvernance et de passage à l’échelle.

Ce qui est intéressant avec Forgejo, c’est son orientation vers la fédération : pouvoir ouvrir les contributions extérieures sans avoir à gérer leurs comptes en central. Une forge publique sans fédération, c’est potentiellement une forge qui reste fermée sur elle-même et qui est donc vouée à l’échec dans sa mission d’ouverture.

Une piste à explorer : Tangled, construit sur AT Proto

J’aimerais qu’on creuse ensemble une alternative moins connue : Tangled, une forge git construite sur AT Protocol (le protocole ouvert derrière Bluesky).

Ce qui m’interpelle dans cette approche pour une forge publique :

  • Identité portable et décentralisée : chaque contributeur·rice possède son identité, indépendamment de la forge, ce qui est particulièrement adapté à un public extérieur à l’administration
  • Passage à l’échelle « by design » : AT Proto est pensé pour des réseaux à grande échelle avec indexation distribuée, ce qui pourrait mieux répondre aux ambitions d’une forge ouverte au grand public
  • Effets de réseau complémentaires : soutenir une forge sur AT Proto, c’est aussi soutenir l’écosystème de réseaux sociaux décentralisés en cohérence avec les valeurs du numérique public
  • Interopérabilité potentielle avec d’autres outils construits sur le même protocole

La question qui se pose : est-ce que cette approche est suffisamment mature pour un déploiement institutionnel à vocation publique ? Quels sont les risques, les manques, les forces ?

Ce qu’on cherche

On fait appel à votre expertise sur plusieurs angles :

  • Technique : comparaison des modèles de fédération (ActivityPub/Forgejo vs AT Proto/Tangled), maturité des projets, gouvernance
  • Institutionnel : quelles contraintes spécifiques aux administrations publiques ? souveraineté des données, hébergement, conformité
  • Stratégique : vaut-il mieux converger sur Forgejo avec le mouvement européen en cours, ou explorer des alternatives à plus long terme ?
  • Retours d’expérience : est-ce que certains d’entre vous ont déjà expérimenté Tangled ou contribué à des projets AT Proto ?

Toutes les perspectives sont bienvenues, y compris celles qui nous diraient qu’on fait fausse route ! :slightly_smiling_face:

D’un point de vue stratégique, il me semble plus judicieux de s’impliquer dans l’écosystème du Fediverse plutôt que dans celui de Bluesky : on sait que la fédération de Bluesky est toute relative dans les faits, que son financement repose majoritairement sur des VC, etc.
Par ailleurs, il me semble que l’on se trouve à un moment charnière où la rapidité d’exécution pèse : je pense qu’il serait préférable de tirer partie des opportunités de mutualisation avec des partenaires européens pour rapidement aboutir à des effets tangibles d’une démarche en phase avec les valeurs que nous portons.

2 « J'aime »

Hello !

Sur ce sujet mon instinct et qu’il faut faire simple. Se lancer dans des protocoles de fédération complexes ou des projets pré-alpha est le meilleur moyen de ne rien sortir à la fin.

Je pense que notre boussole unique devrait être la présentation de jolis repos sur code.gouv.fr/[administration]/[projet]. Probablement en mirroir d’autres forges, elles-mêmes publiques ou privées. Envoyer sur les forges sources pour les contributions. Faire office de backup global, officiel, des projets, qui durera et pourra éventuellement devenir le primaire en cas d’interruption des autres forges (privées ou github).

On est très contents de Forgejo à l’ANCT. C’est performant et l’UX reste familière.

1 « J'aime »

Est-ce que tu pourrais en dire un peu plus ? En quoi elle est relative ?

J’ai vu qu’il y a de plus en plus de projets qui se construisent dessus en Europe, avec ou sans VCs, et ça a l’air de bien marcher :

Cet article donne aussi pas mal d’exemples intéressants, qui ont l’air d’élargir les possibilités de la fédération actuellement possible sur ce que je perçois sur Forgejo :

Par contre, ça peut être un vrai sujet important, mais je pense qu’il faut quand même anticiper et peser le potentiel dans 5 ans de partir sur un truc qui peut être plus facile à débloquer immédiatement, et quelque chose qui nous permet d’aller plus loin et d’être plus interopérables dans 5-10 ans.

PS: et pour info, Tangled est basé en Finlande

Merci @sylvinus ,

Merci pour ton retour. Plutôt d’accord avec ton intuition.

Au niveau de l’intégration continu, c’est aussi performant Forgejo ?

J’ai la réponse à cette question, j’ai fait une formation aux deux protocoles en interne. Tu peux lire cet excellent billet de blog de Christine Lemmer-Weber, qui a contribué à ActivityPub, ici : How decentralized is Bluesky really? -- Dustycloud Brainstorms

2 « J'aime »

Merci @quota_atypique , je vais me pencher sur l’article qui a l’air hyper complet :slight_smile:

Hésite pas si tu as des questions !

1 « J'aime »

Sur le point des VCs, cette remarque de Matija Šuklje (juriste de référence, que je considère comme source d’information fiable ) :

I see Bain Capital involved which does not have a good FOSS track record.

Source : Matija Šuklje : « @YvanDaSilva@hachyderm.io I see Bain Capital invo… » - TOOTSI

2 « J'aime »

Je ne suis pas pour les VCs en général, mais si on regarde au-delà de Bain, ils ont quand même des investisseurs comme Marten Mickos (ancien PDG de MySQL) et Thomas Dohmke (ancien PDG de Github avant que Microsoft commence à « enshittifier » Github), donc il y a quand même des gens qui ont un bon track record

https://www.crunchbase.com/organization/tangled-6149

Sur la question de la CI, j’en profite pour reposter cet article Web engine CI on a shoestring budget de l’équipe Servo d’Igalia.
Avec le passage suivant :

The first [advantage] is that we build on top of the native CI service of the Git forge. So in this case, it’s GitHub and GitHub Actions. It could be Forgejo and Forgejo Actions in the future, and we’re working on that already.

Il y a un écosystème très intéressant en train de se construire autour de Forgejo : je pense qu’il serait mieux de monter dans ce train plutôt que d’attendre les promesses d’un écosystème (celui de Twitter) qui nous a déjà emmenés là où on ne voulait pas aller.

2 « J'aime »

Bonjour à tous, @Jaime m’a invité à donner mon avis, un grand merci à lui.

Je (co-)gère plusieurs Forgejo (dont deux gros: https://git.lix.systems et https://git.afnix.fr) avec plusieurs systèmes de CI/CD ± complexes (Buildkite, des runners Nix natifs durcis).

Forgejo est chouette mais en forge « ouverte », il souffre d’un certain manque de performance et de dette technique, notamment contre l’invasion de scrapers. Quelques exemples concrets:

  • Forgejo n’a aucun concept de high watermark pour la gestion des archives Git, un scraper peut remplir le disque en demandant toutes les archives de toutes les révisions (si on stocke des repos avec plein de révisions et qui contiennent pas mal de choses, ça peut grossir vite).
  • Forgejo peut facilement se deadlock en lançant plein de processus git (blame, etc.) qui sont très coûteux et empêchent le traffic légitime.

En ce moment même, on peut voir la charge.

On réfléchit à des techniques d’anti-abuse effectives par exemple ici: Public view of AFNix | Zulip team chat puisqu’Anubis/go-away/reaction/etc. sont pas forcément très efficace tout seuls.

Pour les projets les plus matures, je crois beaucoup en le fait que https://www.gerritcodereview.com/ pour seulement le code review, c’est vachement bien. Mais c’est un workflow exigeant (utilisé par nVidia, Golang, etc.) — c’est pas mutuellement exclusif avec du Forgejo comme on peut le voir ici sur lix-project/lix: A modern, delicious implementation of the Nix package manager, focused on correctness, usability, and growth — and committed to doing right by its community - Lix Systems qui utilise Gerrit pour le code review.

Dans tous les cas, je pense que Forgejo est probablement la meilleure option mais ils ont besoin d’aide sur le développement technique, il faudrait parler avec leurs core developers.

2 « J'aime »

Merci pour ce retour d’expérience hyper riche @rlahfa