Merci pour le lien! Faire des dossiers de financement me donne des sueurs froides 
mais je vais voir avec https://heptapod.net/ s’ils sont motivés.
Pour archive on m’a indiqué:
De mon coté je ne suis pas trop convaincu par le projet parce que:
- Ça invente beaucoup de choses et que j’aime plutôt les projets minimalistes
- C’est hébergé sur GitHub ce que j’ai du mal a réconcilier avec l’objectif du projet
Tu veux fédérer des forges d’un même type ou de différents types ? Si c’est le second cas cela risque d’être compliqué à cause des différences de fonctionnalités.
Est-ce que tu as déjà une idée de la couverture que tu désires avoir en terme de fédération ?
1 « J'aime »
Exactement!
C’est le genre de projet dans lequel je pourrais facilement me noyer en essayant de faire quelque chose d’universel. Mais peut-être que je peux faire quelque chose qui permette à GitHub et à un GitLab (version libre) de se parler. J’en ai besoin tout de suite et j’en aurais besoin (malheureusement) pour les années à venir donc c’est motivant.
Et comme couvrir toutes les forges (i.e. de l’antique SourceForge à Gitea en passant par Savannah ou GitHub) pour toutes les fonctionnalités (i.e. issues, merge/pull requests, CI, etc.) demande un travail d’entretien constant, ça pourrait combiner de façon heureuse un besoin personnel et un travail rémunéré.
Que cela soit sur Github ou Gitlab, il y a comme limitation le non support de plugins. Par contre, tu pourrais imaginer passer par leurs APIs respectives pour effectuer des synchro, d’autres mécanismes seront probablement nécessaires comme les webhooks.
Si tu veux pouvoir en vivre, la meilleure approche je pense serais d’en faire un SaaS autour d’un projet open source pourquoi pas.
1 « J'aime »
Je vais faire une demande de financement (en tant que personne physique) aux organismes ci dessous. Par transparence je publierait intégralement ici histoire que d’autres puissent s’en inspirer. C’est aussi dans l’espoir de donner envie à d’autre de faire la même chose parce que, il faut le dire, c’est tellement plus difficile quand on a pas le moindre exemple.
Pour commencer voici une description du problème et de la solution. Je travaille demain sur la roadmap. Les commentaires sont les bienvenus mais comme j’ai un intérêt financier à y travailler j’aurais mauvais jeu de me plaindre de le faire seul 
Executive summary
Subdomain: Service Portability
Rationale: Fedeproxy facilitates the portability of software projects and helps them move freely from a software development hosting service (also known as forge) to another.
Project summary
An online service to federate forges. The software projects hosted on one forge are synchronized in real time with their counterparts on other forges, via the W3C ActivityPub protocol. Developers can freely use the forge of their choosing while contributing to the same project. It operates independently from the forges and serves as an incubator with rapid prototyping to research the best user experience.
Relevance
fedeproxy relates to the DAPSI call and especially responds to the Service portability subdomain regarding service providers hosting software development (also known as forges) and the ability of organisations and developers to seamlessly move software projects as a whole (i.e. including issues, users, code etc.) from one forge to another.
Technical challenges and barriers
Most Free Software projects are hosted on proprietary online services (called forges) that do not provide an export/import feature flexible enough to allow them to move easily (GitHub, SourceForge, etc.). Although the code repository can easily be moved from one service to another, other essential components such as pull or merge requests, issues, developer accounts, continuous integration, etc. cannot and the project, as a whole, is trapped. This has many negative consequences:
- Fragility: When a service shutdown the development history and the community is lost, even when the code itself is preserved
- Censorship: A project may be unexpectedly blocked by the company because an embargo is imposed on a country where a contributor resides
- Lock-in: It may take years for some projects to manually migrate from one forge to another, as demonstrated by Gitea, a Free Software forge that started with code on GitHub and has not completed the migration after three years
- Exclusion: Users who do not agree (for ethical or practical reasons) to create an account on the forge are effectively excluded from participating in the development of the projects it hosts
- Vulnerability: Developers are required to trust the service provider with the integrity of the repository or the releases. For instance service providers could have used collision attacks to transparently modify the content of a commit.
- No interoperability: the API is not normalized and does not use open standards for most of its content. For instance it is only possible to export/import from GitHub to GitHub Enterprise.
Idea and objectives
Software forges became popular twenty years ago and the barriers appeared at the same time. The recommended solution at the time was for each forge to implement an export/import feature, which did not happen because proprietary services have a vested interest in locking their user in and exporting projects is contrary to this objective. Although it could have been implemented by Free Software forges, it did not happen either because it is an « all or nothing » solution: the project has to move all at once and the migration tool has to be perfect at the time it happens because there is no turning back. It may not be the only reason why it is still impossible to move a project as a whole from one forge to another but there is no denying, twenty years later, that it may be time for another approach.
There are two ways to move information regarding a project from one forge to another:
- import/export: an « all or nothing » approach where the project is moved to one forge and deleted from another
- federation: a two way communication between two forges where all actions happening on one forge is copied over to another
The number of forges publicly accessible multiplied by at least two order of magnitude since 2001 and they would benefit from being federated. But no forge software supports it, although a data model was developed in 2019 a few years after the creation of the W3C ActivityPub protocol. Popular services such as mastodon or PeerTube appeared in the past five years: a source of inspiration for the implementation of federation in the context of forges. Although a full featured implementation is a very ambitious undertaking, it does not need to be complete to be usable. For instance, the federation of issue comments could be the only feature available while other are implemented. In addition, it is practical to experiment on federation with a proxy based on the forges API (or even web scrapping) before attempting a native integration.
The proposed incremental approach to forge federation is to:
- implement a federation proxy for each forge, which exposes the ActivityPub based protocol with a model similar to forgefed and translates it into the native forge API. Such a proxy needs credentials to interact with the forge API but can be run independently.
- implement a standalone forge federation service whose sole purpose is to connect the federation proxy of each forge after obtaining the credentials required to carry out actions
An example use case could be:
- The fedeproxy service runs with a proxy for GitLab and a proxy for GitHub
- The project Ceph exists on GitHub
- I run a self-hosted GitLab instance
- I ask the fedeproxy service to federate the Ceph project from GitHub with my GitLab instance
- I browse the issues of the Ceph project on my GitLab instance
- I comment on an issue on my GitLab instance
- My comment is copied over to the GitHub Ceph project by fedeproxy
- A GitHub user answers my comment which fedeproxy copies over to the Ceph project that resides on my GitLab instance
The ultimate goal of fedeproxy is to become obsolete, once all forges natively implement federation. It will become common place for a software project as a whole (i.e. code, issues, merge requests, CI, etc.) to exists simultaneously on multiple forges, with developers working together but using different forges. To get there, the fedeproxy should be considered the first step of experimentation and incubation of federation features that are destined to land in the code base of each forge, eventually.
An example could be:
- The fedeproxy service implements a proxy for GitLab that translates ActivityPub comments into the new issue note API call
- A native implementation is written as a contribution to the GitLab native federation effort and proposed as a merge request
- After the native GitLab implementation is released, the fedeproxy code can be removed because GitLab natively supports the federation of issues comments
Project outcomes
- A federation proxy for GitHub and another for GitLab which implement the ActivityPub protocol using a common vocabulary and data model to:
- Create issues and add comments
- Create pull / merge requests and add comments
- A self-hostable service (named fedeproxy) enabling a user to:
- Authenticate on a GitLab instance and on a GitHub instance
- Request the federation of a project residing on both GitHub and GitLab
- A community of developers relying on fedeproxy (either online or self-hosted) on a daily basis
- Contributions to Gitea and forgefed to define a federation data model and vocabulary
- Contributions to GitLab towards the implementation of federation between GitLab CE instances
Added value
- The fedeproxy server and its functionalities bootstrap the work towards a full featured forge federation.
- Proposes a novel approach to incrementaly improve the data portability of software projects between forges.
- Provides a working implementation that allows developers to experiment and use the service on a daily basis.
- Makes future work to improve data portability easier because developers can focus on adding a new functionality and reuse the fedeproxy architecture.
- Collects real world feedback on proposed data models and vocabulary and helps them mature into a standard.
- The fedeproxy server is an incubator for the implementation of federation features with an independent life cycle that is not constrained by the life cycle of the forges it connects.
Socio-economic impact
Promotes the concept of federated development
Most developers work on Free Software in a centralized way and do not see the benefit for decentralization and federation. Implementing federation and using it for practical purposes is a way to discover use cases and imagine new ones. It can ultimately be a motivation to advocate for the generalisation of federation in software development. For instance, it is currently extremely difficult for a developer who do not have a GitHub account (because, for instance, they live in Iran) to participate in the development of the projects that are hosted there. This developer could use fedeproxy and their own GitLab CE instance and become an active part of the community.
Improved durability of the software projects
Organizations are routinely impacted by the disapearance of forges which translates into a loss of value and money. For instance, if a software appliance contains software originating from a defunc forge, it will need an update to get it from another location, assuming the developers managed to migrate in time. Even if they did, past issues and merge requests would have to be migrated manually and the chances that they are permanently lost is high. By continuously duplicating issues and pull / merge request on GitLab and GitHub (redundancy is another way of looking at federation) on two forges, fedeproxy improves the chances that they are recovered, thus saving value and money for all organizations depending on the impacted projects.
Scale out forge federation development
By providing a minimal infrastructure and a few features, fedeproxy demonstrates that the development towards a full featured forge federation scales out, meaning that it can be conducted by many independent actors working on many independent features. By contrast, implementing an import/export feature working between forges is best developped by a single team because it needs to accurately represent all aspects of a given project at the time it is used. The scale out and incremental approach to forge federation is locally cheaper although it is much more expensive as a whole. For instance, a skilled developer could contribute a new feature within a week, a cost that even the most modest organization can afford. The sum of all those efforts is much higher than what would be needed to implement an export/import feature but it is distributed over a longer period of time and among many actors. It is therefore more likely to make progress and succeed.
Licensing
fedeproxy will be released under the AGPLv3 license. The code contributed to existing code bases will be released under licenses compatible with their own licenses.
Commercial exploitation
fedeproxy is a non-commercial project but with a relevant contribution to the internet community.
Project Planning
User research
Forge federation is a new idea and its implementation would benefit from a user centered design that requires user research.
- Prepare the research
- Find participants among software developers, organizations and forge maintainers
- Prepare the research sessions
- Create an intercept interview sript for software developers, organizations and forge maintainers
- Conduct interviews with the participants
- Organize an affinity mapping session to collect emerging themes
- Analyze the results and write a report with recommendations for the implementation of the user experience.
Infrastructure
While conducting user research, the building blocks can be implemented in parallel.
- Create a self-hosted development environment for fedeproxy (with a GitLab CE forge and the associated CI)
- Create a website presenting the project and the roadmap
- Create fedeproxy module a Django based server relying on the federation module for ActivityPub and
- Define a data model and vocabulary based on forgefed and GitLab import/export
- Create fedeproxy GitLab, a module based on the fedeproxy module using the GitLab API for creating and commenting on issues and merge requests
- Create fedeproxy GitHub, a module based on the fedeproxy module using the GitHub API for creating and commenting on issues and pull requests
- Create extensive end to end integration tests
- Create a reference documentation including instructions for self hosting
User experience
After the infrastructure is fully functional but can only be run with the integration tests, the roadmap for implementing the desired user experience is defined. Attempting to predict the outcome of the user research and how it will be implemented would be contrary to the primary objective of user research.
- Define the user experience roadmap for interacting with the fedeproxy server based on the recommendations from the user research report
- Create a fedeproxy server to enable users to connect the fedeproxy GitLab together or with the fedeproxy GitHub
Distributing and operating the service
- Setup a fedeproxy server including both fedeproxy GitLab and fedeproxy GitHub
- Add monitoring and intrusion detection
- Publish fedeproxy server, fedeproxy GitLab and fedeproxy GitHub
- As a container image usable with a oneliner
- As packages published on PyPI
- With self hosted documentation
Advocacy and feedback
- Reach out to users software developers, organizations and forge maintainers to foster a community of users
- Actively seek feedback from users
- Reach out to GitLab implementors and submit merge requests relevant to simplify the implementation of fedeproxy GitLab
- Reach out to Gitea to implement a federation data model and vocabulary
Milestones
U: User Research, I: Infrastructure, A: Advocacy, O: Operations
- U1: Prepare the user research, prepare the research sessions, create an intercept interview sript; M1
- U2: Find the user research participants; M1
- I1: self-hosted development environment and website; M1
- U3: Conduct interviews with the participants; M1,M2,M3
- I2: fedeproxy module, fedeproxy GitLab and fedeproxy GitHub, extensive end to end integration tests, documentation; M1,M2,M3
- A1: Reach out to GitLab implementors and submit merge requests relevant to simplify the implementation of fedeproxy GitLab; M2 to M9
- A2: Reach out to Gitea to implement a federation data model and vocabulary; M2 to M9
- O1: Publish fedeproxy software on a monthly basis; M2 to M9
- U4: Affinity mapping, result analysis, user research report; M4
- U5: Define the user experience roadmap based on the recommendations from the user research report; M4
- I5: Create the fedeproxy server; M5,M6,M7
- O2: Create a hosting environment for running the fedeproxy server; M5
- O3: Run the fedeproxy in production; M7
- A3: Reach out to software developers, organizations and forge maintainers; M8,M9
- A4: Seek feedback from users and modify fedeproxy accordingly; M8,M9
The team
Team composition
| Name of the person | Role in the project | CV | Entity |
|---|---|---|---|
| Loïc Dachary | Developer | https://blog.dachary.org/cv/ | Individual |
| Pierre-Louis Bonicoli | Developer | http://libregerbil.fr/CV_Bonicoli.pdf http://libregerbil.fr/Contributions.pdf | Libregerbil |
Loïc Dachary
In 2001 Dachary raised concerns about centralized proprietary forges and worked with the Free Software Foundation to setup, install and maintain the Savannah forge. He also contributed to the GNA! forge, until 2017, when it shut down. In the recent years Dachary published software to migrate software projects from GitHub to GitLab and infrastructure as code including GitLab deployment Ansible playbooks as well as end to end integration tests for a Django based API server including the automated installation of a GitLab server for the duration of the test.
In 2018 Dachary closed his GitHub account for ethical reasons and has since been unable to participate in Free Software projects hosted there. The federeration of forges would allow him to reconnect with these projects.
Pierre-Louis Bonicoli
Libregerbil is a french Free Software service provider founded in 2015 by Pierre-Louis Bonicoli, a Python developer with 10+ years of experience. In 2020, Libregerbil improved the support of GitLab within Zuul, a continuous integration project and added support for the Fuga OpenStack provider to the Enough project. Libregerbil has a long track record of contributions to the Ansible project. Bonicoli runs a redmine instance and mades some minor contributions to the codebase.
Team motivation
Loïc and Pierre-Louis would both use fedeproxy and contribute to its development if it already existed, on a volunteer basis, because they need it for their day to day work. But the initial effort to create fedeproxy from scratch cannot conveniently be done on a volunteer basis and requires funding. In addition, because Libregerbil is a Free Sofware service provider, the expertise developped while creating fedeproxy may generate additional income in the future, if a market for the development of federation features emerges.
Value for money
| Entity | Name of the person | Person months |
|---|---|---|
| Loïc Dachary | 4.5 | |
| Libregerbil | Pierre-Louis Bonicoli | 4.5 |
| Total | 9 |
The costs are calculated on the basis of a 3,000€ net income per month per person, which is well below the average salary for a developer residing in Paris France. The net salary is approximately 55% of the gross salary (retirement plan, social security, unemployment fund etc.) paid by the company. The company overhead is 20% (administration, management, accounting, etc.). The total is rounded to the lowest thousand.
| Cost category | Libregerbil | Loïc Dachary | Total Amount (€) |
|---|---|---|---|
| Personnel | 29,000 | 29,000 | 58,000 |
| Total | 29,000 | 29,000 | 58,000 |
4 « J'aime »
Si tu veux Support Self Hosting a déjà fait une demande à NlNet pour YunoHost. Je dois pouvoir retrouver le dossier. (on en a même fait 2 mais on a pas eu la 2ème).
1 « J'aime »
Ce serait vraiment top de publier la demande publiquement. Évidement je comprends les réserves qu’on peut avoir: ça rend plus facile à une personne peu scrupuleuse de soumettre un dossier très similaire en douce et couper l’herbe sous le pied.
En tout cas j’aime bien l’idée d’un outil de fédération de forges, je pense qu’il y a un marché et que donc c’est économiquement viable.
1 « J'aime »
Pour archive la découverte du jour:
Dont le lien avec la fédération des forges n’est pas immédiat, il faut aller aux pages suivantes:
Autre découverte du jour (mais dans la catégorie 
). A défaut de s’orienter vers un standard, ça donne un format JSON dans lequel exprimer les données (issues, merge request etc.) qui fait une alternative à forgefed.
https://docs.gitlab.com/ce/user/project/settings/import_export.html
Publier ce dossier après une période d’embargo, ça peut le faire non ?
1 « J'aime »
Je rentre de congés, et remercie et félicite grandement Loïc de ce partage. Je m’engage, au nom de Framasoft, à publier ce qu’on a envoyé à NLNet le mois dernier (pour PeerTube et Mobilizon). La forme sera à l’arrache, par contre… 
Sinon, ben je regarde le contenu de la réponse de Loïc, et je suis vraiment impressionné par la qualité de ta réponse (vraiment, et j’en ai rempli du scrogneugneu de dossier de sub, avant qu’on se dise à Framasoft qu’il fallait arrêter avec ces conneries). Bravo. Vraiment.
1 « J'aime »
Après relecture des guidelines pour DAPSI et en observant les 11 projets financés l’année dernière pour la première des trois vagues (les deux autres c’est cette année et l’année prochaine), je n’arrive pas a comprendre pourquoi les projets ont été sélectionnés ni pourquoi autant n’ont pas produit de code (ou alors c’est bien caché, j’ai cherché). Ce n’est pas très grave que je ne comprenne rien mais je suis surpris.
- Alias, project, code
- Checkpipe Charlie, no project, no code
- DIP, project, code oyd-pia2, service-pi2
- DOMI, project, no code
- DPella, article, no project, no code
- IDADEV-P2P, project, no code
- OpenPKG, project, code
- OpenXPort, project, no code
- ORATORIO, project, no code
- PROV4ITDATA, project, code
- UI-Transfer, no project, no code
1 « J'aime »
La deadline n’est peut être pas encore atteinte ? Pour YunoHost on est toujours en train de coder les features de notre dossier… Notre deadline est début septembre. C’ets lié au fait qu’on a aussi plein de chose à faire à côté des feature listées dans le dossier.
Par contre si il n’y a pas de projet du tout, je n’ai pas d’explication.
1 « J'aime »
Attention c’est DAPSI et pas NLnet: la deadline c’est fin d’année calendaire, donc terminé, plié, fini, emballé 
Bonjour Loïc.
Logilab est intéressée par ce sujet de fédération de forges.
Nous soutenons actuellement le développement de https://heptapod.net/ et serions susceptibles de soutenir le développement d’un mécanisme de fédération qui s’appliquerait à cette forge (et donc à gitlab).
En matière de modèle de données, je trouverais vraiment bien d’utiliser les roues déjà existantes que sont https://en.wikipedia.org/wiki/DOAP et les ontologies doap-* de la page https://ontologi.es/ (doap-bugs + doap-changesets + doap-tests + doap-deps).
Pour information, nous employons déjà ces ontologies dans des scripts internes qui permettent de générer un graphe de connaissance de nos projets (produit en extrayant les informations via l’API gitlab en python). Ce graphe RDF peut ensuite être exploré avec les outils habituels du web sémantique et être utilisé par d’autres scripts, qui génèrent des tableaux récapitulatifs ou des Merge Requests de mise à jour automatique des dépendances.
Nous avons envisagé de nous lancer dans l’écriture d’une extension de cette forge qui échangerait ces données via ActivityPub et permettrait de se brancher sur le fediverse, mais nous avons pour le moment donné la priorité à d’autres projets.
A ta disposition pour discuter de tout ceci si tu le souhaites.
1 « J'aime »
Merci pour ces références que je n’avais pas trouvé 
Aujourd’hui je travaille à la mise en forme de la proposition DAPSI afin de la finaliser demain et de l’envoyer mardi. Ce sera essentiellement une reprise de ce qui est déjà sur ce forum.
Avec grand plaisir. Pour les besoin de soumissions du projet et aussi parce que cela serait un peu envahissant pour le forum des chatons, je viens de déposer le domaine fedeproxy.eu pour y placer tout ça. Sans surprise ce sera une communauté horizontale comme celle de Enough. Courant de semaine prochaine j’y mettrais un GitLab, un site web et un discourse avec tout ce qui se trouve ici.
Ce qui se passera ensuite dépend, tout comme pour Logilab, de la force de travail disponible. Sachant que je commence à travailler chez Easter-Eggs le 1er fevrier, j’imagine les scénarios possibles suivants:
- Le projet est refusé, j’ai la flemme et rien ne se passe après l’effort initial de formalisation du projet (qui valait le coup même si ça ne va pas plus loin, AMHA). Je serais assez déçu de moi même mais ce ne serait pas la première fois. Et surtout je serais encore dans l’incapacité de contribuer à des projets qui sont prisonniers de GitHub et je continuerais à vivre dans la frustration.
- Le projet est refusé mais j’ai le minimum d’énergie pour avancer sur la roadmap que je publie sur fedeproxy.eu et que j’utilise pour, enfin, contribuer aux projets qui sont prisonniers sur GitHub. Il y a peu de chances pour que j’ai la force de travail nécessaire pour faire en sorte que d’autres puissent utiliser ce que je fais. Mais peut-être que d’autres personnes ayant plus de talent et/ou d’énergie amélioreront/referont mieux des trucs plus génériques.
- Le projet est financé et je plonge dedans à mi-temps avec @pilou jusqu’à la fin de l’année, avec la bénédiction de Easter-Eggs (soit c’est eux qui reçoivent l’argent et me salarient, soit c’est moi qui reçoit l’argent et qui réduit mon temps plein à un mi-temps, peu importe).
1 « J'aime »
Avant que j’oublie un grand merci à la personne qui restera anonyme (sauf si elle veut bien dire qui elle est), coutumière de l’examen de projet Européens (c’est à dire de l’autre coté de la barrière). Elle a relevé quelques problèmes de forme et en particulier permis de clarifier comment s’articulent les parties Added values et Project outcome. D’ou une discussion qui pourrait se résumer comme ça:
- Moi: voila, pour que l’outcome soit mesurable et réaliste j’ai mis que la communauté rassemblée d’utilisateurs de fedeproxy sera au moins de deux utilisateurs quotidiens (et encore je m’avance hein, parce que moi c’est sur mais je sais juste pas qui d’autre et ça va être chaud de trouver) et au moins 10 utilisateurs occasionnels (ça c’est facile, je n’ai aucune doute qu’il y ait des curieux régulièrement pour tenter le coup)
- Elle: Tu veux dire des gens qui développent fedeproxy ou bien des utilisateurs du service (auto-hébergé ou pas) ? (ajouter une note d’incrédulité)
- Moi: non, l’audience des utilisateurs. En développeurs, pour de vrai, il y aura @pilou et moi mais les probabilités qu’une troisième personne saute dans le bateau sont vraiment faibles. C’est bien pour ça que le projet n’existe pas encore d’ailleurs, si tu veux mon avis.
- Elle: mais … enfin… ça va pas passer du tout. Tu as 50 millions d’utilisateur sur GitHub et tu veux convaincre que ça vaut le coup de passer neuf mois pour le bénéfice d’une douzaine de personnes ? Tu vois que c’est pas hyper vendeur ou bien ?
Je ne cache pas que c’est un gros soulagement qu’elle ai posé la question parce que, évidement, il y a de quoi rire si on regarde le projet sous cet angle. Et a bien le relire… c’est tout a fait une interprétation possible. Donc je travaille a rédiger différemment pour que l’ambition véritable expérimentation et preuve que ça peut marcher soit claire au lieu du rêve de fin de soirée du genre on va libérer 50 millions de personnes de GitHub, on est les rois du monde 
Pour clore voici le descriptif complet du projet et la mise en forme pour la soumission à DAPSI en ODT. Toute remarque est la bienvenue, bien sur. Le projet finalisé et le travail qui suivra sont disponibles sur le forum fedeproxy: