State of the Forge Federation: 2021 to 2023

June 30, 2022

Millions of Free Software developers forgot why it matters to own their tools. They know, better than anyone, how to fix and improve them. But when they choose to collaborate only via the most popular proprietary software forges, they are denied the right to use their skills and cannot work with fellow developers who are banned because they reside in the wrong country. They have been made to believe that the tools they use daily to craft their own software are out of reach. As if their software was a product that could be separated from the other software running the tests, allowing changes to be merged or bugs to be filed. But software is a process, and whoever controls it ultimately decides what the developers can do and how they communicate.

Some Free Software developers chose to use different tools, such as email and DVCS without a web interface, to collaborate in a distributed way. Many others decided to run their own Free Software forge and work in a decentralized way, improving their own tools and independently deciding who they work with. But even then, they are isolated instead of being federated with each other.

The ongoing forge federation effort is a simple proposition: online software forges must be able to communicate. It must be possible for developers to work together on the same software project regardless of the user interface they use. Just as it is possible for someone to send an email using their preferred client knowing the person receiving it will be able to read it and reply even if they are in a completely different environment. This will help developers to move away from software forges they are forbidden to change and regain control of their tools.

Is forge federation ready to be used by developers around the world? Not yet. But a growing number of people joined the effort in the past year and the first releases are expected early next year. As you read this “State of the Forge Federation”, you will understand what they have been up to and where they are going. You will also realize that there is a lot of work ahead and this may motivate you to join the effort and help forge federation become part of the daily life of every developer.

Executive summary

As of June 2022, no online forge provides federation, no software forge or proxy is available to be deployed in production (not even beta). Six software projects and two emerging standards are actively developed by at most five people on a daily basis, two are funded, the others are volunteers. A community of at most fifty volunteers, including mentors and occasional contributors have a significant impact on how forge federation is moving forward. Videoconferences and webinars are organized on a regular basis and are an opportunity for people involved in all projects to discuss. Progress reports published monthly cover most projects.

A “forge federation proxy” is a server that runs alongside an existing forge and provides it with federation features. It is a way to bring federation to existing software forges that do not yet implement it natively.

By June 2023 it is expected that:

  • At least one public forge ( and one hosting provider ( will enable federation
  • At least one forge software project ( will publish a stable release that implements federation
  • A beta release of the forgefriends federation proxy will be published and allow users to work with federated issues and pull requests
  • The ForgeFlux federation proxy will be actively developed
  • The forgefed emerging standard defining the ActivityPub vocabulary for forges will have released its first draft
  • The first stable release of the Friendly Forge Format, a open file format to represent software projects, will be published
  • The first beta release of the Starchart forge spider will be published
  • The number of people working on advancing forge federation will double
  • Videoconferences will be organized to bring all communities together on a monthly basis
  • Progress reports will be published on a monthly basis

State as of June 2021

This is a terse inventory of the active projects and people working to make forge federation a reality as of June 2021. The Methodology section below explains how they are selected.




Here is how project and standard relate to each other:

  • fedeproxy and ForgeFlux are proxies that aim at allowing forges to communicate together even when they do not implement federation natively.
  • Pagure-forgefed is a plugin for the pagure forge that can be used to support federation.
  • Both fedeproxy and pagure-forgefed rely on the forgefed emerging standard which is an ActivityPub extension.


It is estimated that ~two people work on forge federation on a daily basis and ~five others are occasional contributors. About two mentors provide advice to people implementing forge federation and have a minor influence on how it moves forward.

What happened between June 2021 - June 2022

Software & Standards

Events & publications

State as of June 2022




Here is how projects and standards relate to each other:

  • Gitea and Forgefriends (previously fedeproxy) rely on a custom (different from go-fed) implementation of forgefed.
  • Forgefed is an ActivityPub extension dedicated to forge federation.
  • Vervis is a software forge meant to be a reference implementation of forgefed.
  • Starchart is a software forge spider designed for federated forges.
  • Forgefriends and ForgeFlux are both proxies that aim at allowing forges to communicate together even when they do not implement federation natively.


The number of active projects doubled (from three to seven). The number of people working daily on forge federation grew from ~two to ~five. The number of mentors and contributors involved grew by an order of magnitude: it went from half a dozen people to around fifty. It is estimated that mentors have a significant impact on how forge federation moves forward.

It is worth keeping in mind that at the beginning of 2021 forge federation was much less popular than it was in the previous years.

What is likely to happen by June 2023


  • ForgeFlux
    • Gitea↔GitHub Issue and Pull Request Federation
    • At least one public instance is available online for GitHub
    • Adoption of the Friendly Forge Format for migration of issues and PRs
  • Starchart
    • Implements a UX that is good enough to make it usable to explore Free Software on indie forges
    • Support crawling GitLab
    • Publishes crawled data using Git repositories instead of tarballs
    • First beta release
  • Gitea
    • Can communicate:
      • with Mastodon via ActivityPub
      • with other Gitea instances via ActivityPub and forgefed
    • Can mirror issues from Gitea, GitLab or GitHub
  • forgefriends
    • Has a defined UX, UI and the backend implementation allowing users to:
      • create federated issues and pull requests
      • close issues and pull requests
      • merge pull requests
      • comment on issues and pull requests
      • mirror projects
    • At least one person uses forgefriends daily to perform the above
    • Can mirror federated projects (vcs, issues, pull requests, comments, releases, assets, milestones, labels) from Gitea, GitLab or GitHub
    • First beta release
    • Monthly report and videoconference
    • Forge federation webinar January 2023
  • Friendly Forge Format
    • Go reference implementation package
    • First developer release


  • Friendly Forge Format
    • A User Research report is published
    • First beta release matching the Gitea migration format
  • forgefed
    • Releases its first draft

Federated forges

  • Public forges
    • will run Gitea with federation enabled
  • Forge hosting providers
    • will provide managed instances of (i) Gitea with federation enabled, (ii) forgefriends, (iii) ForgeFlux


The number of people working on advancing forge federation will double. The availability of federated features that can be installed and used is expected to have a significant impact on the motivation of developers to participate.

Methodology, scope and definitions

Instead of this document, it would be better to create a roadmap. But how can that be done when the majority of the work is done by volunteers who are not constrained by anything except what feels right to them in the moment? Only when people working towards a goal are paid staff can they be assigned tasks to complete a roadmap. It would be tempting to create a roadmap that includes everything that needs to be done to further forge federation and, a year later, tick the boxes of what was done. This is however (i) extremely difficult because there are thousands of tasks that would help further forge federation, (ii) probably useless because hundreds of those tasks are likely to become obsolete within a year, (iii) there are so few people working on federation that only a fraction of those tasks will be completed in less that twelve months.

Instead of spending weeks (if not months) creating a large roadmap, a list of the goals that are most likely to be achieved in the year to come was created. The likelihood that a given goal is reached is an educated guess, at best. It is based on what happened in the previous year, the commitment people and organizations publicly declared to further forge federation and the gut feeling of the reviewers of this document. Hardly scientific, but maybe a useful insight for the reader.


To keep this document manageable (and updatable on a yearly basis) it has a limited scope. Anything that has not be active in over a year is assumed to be unmaintained (or discontinued) and not covered. The long term vision that drives people and organizations to contribute to the advancement of forge federation is an ongoing discussion that is also not in scope.

Only software explicitly dedicated to implement forge federation is in scope. For instance the implementation of go-ap is not in scope because it implements the ActivityPub protocol which has a broader scope than forge federation and it does not include anything related to forge federation. Other examples are software designed to interface with multiple forges, for bug reports (buggregator, git-issue, etc.), pull requests, … because they help developers overcome the absence of federation between forges. They are workarounds that would not be necessary if forge federation was available everywhere.

The same goes for standards: ActivityPub is not in scope but forgefed is.

Software and standards

A software is something that is designed to be installed, run and upgraded over time: it is not a product, it is a process. People involved in the making of a software may have different methods to achieve that. For instance developers who value user centric design will start with User Research before anything else. They will also figure out the best User eXperience before implementing any kind of UI. These various preferences regarding the software development process are not compared or mentioned.

A standard is similar in the sense that it must be maintained over time, updated and released.

Releases (software and standards) are named as follows:

  • Not released when there has never been a release
  • Developer release when it is only meant for developers and not users
  • Alpha when specifications, functionalities and interfaces are in flux but can be used for a test drive
  • Beta when everything is stable and only bug fixes and minor improvements are expected
  • Stable when nothing changes, except for critical bug fixes such as security issues for software or inconsistencies for standards


In some cases the work done in the context of a software project can be useful to other projects, even though it is not a release containing software. For instance, a User Research report focused on what developers need to understand when their intended user base is using multiple forges. Such a publication is mentioned at the date it is published. And again if it is updated at a later time.


A community is a group of people, either part of an organization or an informal collective. People involved in the making of a software project or a standard are a kind of community, whether they are volunteers or paid staff of an organization. Even if they do not identify themselves as a community, they will be perceived by outsiders as a group of people brought together because they have a common interest.

Although the governance of the community associated (implicitly or explicitly) with a software project or a standard has a high impact on how it is likely to evolve in the future, analyzing such a relationship would require an extensive, case by case, analysis and is not in scope of this document.

Some communities may exist to further forge federation without being bound to a specific software or standard. For instance, a community could be created for the sole purpose of organizing a webinar every year gathering all forge federation related projects or publishing this document.

Volunteer mentors

People talking together currently have a significant influence on how forge federation makes progress. As of June 2022, there are at most five people in the world committed to create software or standards dedicated to forge federation. When they hit a roadblock, discussions with volunteer mentors can allow them:

  • to go in the right direction instead of continuing towards a dead end
  • solve a specific problem and keep going

When mentoring is not done on a volunteer basis, there are deliverables which are paid for and they can be accounted for just like modifications to standards or patches to software. That can be quantitatively measured in a way discussions between volunteers cannot. Here is an example: during weeks developers were stuck trying to figure out how to reduce the disk footprint of the go-fed package, until a mentor suggested to use go-ap and solved the problem. Another example is when the maintainer of a software provides advice on how to best use it to implement forge federation.

The contributions of mentors to the advancement of forge federation is assigned a value that is agreed upon by the reviewers of this document, based on their intuition:

  • minor when mentors hardly have a visible influence
  • significant when there is a general consensus that mentors have a positive influence
  • strong when mentors are a driving force without which progress would not happen

Forge federation is volunteer driven

People contributing to forge federation are predominantly unpaid volunteers which makes it a community effort and it can be observed (like in Wikipedia) that most of the work is done by a minority of the participants. It is estimated that around five people are working on forge federation on a daily basis and no more than fifty contribute occasionally, either by mentoring, reviewing contributions or proposing changes.

Regular events such as videoconferences or webinar play an important role in bringing people together and keeping them informed of what other projects are about.

Progress reports play a similar role and help newcomers quickly figure out what happened in the past and why, in a way that would be more time consuming if they only had videoconference recordings to listen.


Most of the globally available funding earmarked for advancing forge federation was not spent as of June 2022 because some beneficiaries did not claim it. At least two opportunities to apply for grants (150K€, 20K€+) did not raise much interest. One developer was funded to work on federation full time and another part time in the June 2021 to June 2022 period. Their work consumed significantly less funding than what was globally available. This suggests that forge federation is likely to remain a volunteer driven effort in the next twelve months.