GitLab

Executive Summary

The fedeproxy project started early 2021 to improve interoperability between software forges so that a Free Software developer can participate in any project, regardless of the forge where it is hosted. The ideal situation would be if all software forges were federated, but this is a very ambitious undertaking and an incremental approach can be more effective immediately. The user research is based on ten interviews with Free Software developers conducted between March and May 2021. They were analyzed by six Free Software developers and the outcome is the following recommendations:

• Focus on multi forges issues. Developers manually add links in issues or commit comments to keep track of related issues that are located on different forges. They rely on their memory or conventions to connect the two. Fedeproxy can automate this workflow and provide activity notifications when it is lacking.
• Leverage the desire of developers for a decentralized and federated ecosystem. Although developers have agreed to the terms of service of centralized forges, they are unhappy about it. Making it easy for them to participate in fedeproxy would allow them to help making it happen sooner rather than later.
• Create a User eXperience, not a User Interface. Developers use the UI of the forge on which their project is hosted on a daily basis and are reluctant to use another UI. The UX provided by fedeproxy by must be embedded in the UI they currently use.

Methodology

Create a user-focused how-and-why question based on the initial idea for the project

1. The initial idea is an online service that allows a user to interact with a software project hosted on one forge while using another forge.
2. The meaningful activity is to develop software.
3. How and why are multiple forges used in the development life cycle of a given software?

Find participants

There are three personas (Free Software developer, Forge developer, Forge maintainer) and there needs to be at least three interviews for each persona.

Free Software developer

They are either serious hobbyists or professionals who participated in software development for several years. They have used more than one forge, simultaneously or because they had to migrate a project from one forge to another. The software they develop have dependencies to other software for which they either track issues related to features/bugs or provide patches.

Forge developer

They work (or worked) on a forge software. They are involved in defining new features, figuring out the user needs, either as independent contributors or as a company employee. They use the forge on which they are working on a daily basis, i.e. dogfooding. They have a good understanding of the User Interface and how it is defined as well as the backend supporting it. They are involved in release management, know how to analyze integration test failures and are conscious of the trade-off involved in maintaining backward compatibility.

The developers working on forges that have developed a strategy to lock-in their users such as SourceForge, GitHub or GitLab enterprise are not considered. Their ultimate goal is either to prevent their users from using multiple forges or to only support one migration path: from other forges to their own. As a consequence their input would be strongly biased to favor their own needs: it would obscure the needs of the users instead of revealing them.

Forge maintainer

They are either independent system administrators or manager of an organization maintaining a forge that is either publicly available (such as https://forge.chapril.org/) or targeting a selected audience (such as https://lab.enough.community). They were involved in choosing the forge software and defining the production environment, backups, RGPD compliance, import and export policies.

Intercept interviews

The ten users willing to participate in this research answered the interviews (roughly one hour each) and were recorded. Each interview was then transcribed, proofread and sent to them for review. Some participants agreed to publish them which may prove useful in other contexts: they often contain valuable insights.

The majority of participants have (or had) links with LogiLab. This is worth mentioning and could have been avoided but that was discovered during the affinity mapping session, at the very late stage of User Research. It does not seem to introduce a bias and it was decided to not discard interviews because of that.

Affinity mapping session

The six participants to the affinity mapping session got together on the 26th of May and had a thorough presentation of the fedeproxy project and an explanation of the goal of the session. It then started with individual activities:

• Read an interview transcript
• Copy / cut sentences from the interview transcript and group them in categories
• Stick the result on a large glass surface

When all interviews were analyzed in this way, all participants got together and presented the groups of sentences they created, explaining why it made sense to them. When commonalities were discovered between groups, they were discussed, merged or renamed. In the end about twenty groups remained and there was an agreement that five of them were the most important one:

• The forge ecosystem
• The scope of a software project
• Software project import/export and migration
• Creating links between forges
• User Interfaces

Writing the report

The report is an explanation of the five groups identified during the affinity mapping by re-using the sentences extracted from the interviews to put them in context. It does not reflect the full diversity of what the interviewees said: it only focuses on these five groups.

Report

In the following the references to interview quotes are the first two letters of the directory in which the interview is stored and the line number. The majority of the interviews are transcribed in French: only the quotes were translated in English.

What is a forge? What is a software project?

The forge ecosystem

The interviewees use multiple forges for a variety of reasons but they mainly work on their software development project on a single forge. In the past years they came to experience and know about a variety of forges (GitHub, GitLab, Gitea, Phabricator, SourceHut, Heptapod, Redmine, etc.) (ref. AR, CJ, CP, DA, DO, GR, MA, NA, PO, ZA). All of them have (or had in the past) a GitHub account and they acknowledge the monopolistic position it occupies because it hosts the majority of Free Software projects (ref. ZA44) (ref. DA54) (ref. MA67) (ref. DO61) (ref. GR39). Although they are concerned and have reservations about GitHub (ref. NA93) (ref. DA45) (ref. MA64) (ref. CP57), none of them refuse to use it (ref. PO80). The Free Software forges (GitLab CE, Gitea) are considered to be quality software that can easily be installed and maintained (ref. CP19). In the past years, the number of self-hosted forges instances grew substantially (ref. GR93). However the interviewees noticed that only a few are open to the general public (ref. MA4) (ref. CP57) (ref. GR75): most of them have a specific focus (ref. CP57). For instance the GitLab CE instance of Gnome.

• CP19: "We converge towards the notion of 'I have a software component and it runs'".
• CP57: "[...] as any respectable Free Software developer trying to minimize their internal conflicts [...] you cannot be on GitHub nor GitLab.com"
• CP57: "If you look [...] for publicly available forges, there are not many."
• CP57: "[...] with my clients, I had lots of difficulties. [...]. I came to the conclusion that I had to manage my own forge."
• DA54: "I'm stuck because I can't upload on GitHub: [...] I don't have a GitHub account."
• DO61: "Nowadays if your project is not hosted on GitHub, it does not exist."
• GR39: "What made me a little uncomfortable [...] is that a GitHub project with 100 stars is automatically accepted by Open Collective. When a project is not on GitHub, there is a need to explain"
• GR75: "On our [public forge] we wanted to only accept Free Software projects."
• GR84: "I took the thing that analyzes projects and repositories and transformed 'Possible if this is git' into 'Possible if it is Mercurial'"
• GR93: "[...] there are plenty of people who self-host a [forge] instance and they imported projects from BitBucket."
• MA4: "[forge] is free and dedicated to Free Software - a Free Software project can send us a request and be hosted for free, including CI."
• MA64: "[...] people who leave Git platforms such as GitLab/GitHub for [forge] (because [...] they want their data on french servers and not American servers[...])"
• MA67: "There are things we are generally forced to do on GitHub and there also is an aura of 'most Free Software projects are on GitHub'"
• NA93: "GitHub actions for example: I don't like that feature. It feels like a trap."
• PO80: "[...] this is a GNU project that is not intended to feed the Microsoft leviathan.
• ZA44: "The ecosystem is dominated by a small number of forges that are very very big. This is a problem."

Key takeaways:

• GitHub is in a monopolistic situation
• Developers have reservations about centralized forges but use them anyway
• There exists a diversity of easily self-hostable Free Software forges
• The number of self-hosted forges instances is growing rapidly
• Only a small number of self-hosted forges is open to the general public

The scope of a software project

When a software project moves from a forge to another, it is not just about the content of the Distributed Version Control System (DVCS). Participants share the opinion that the past and present issues should also move with it: they are part of the history that helps future development. The issue tracker is also a place where users who do not contribute to the codebase can actively participate by reporting problems (ref. AR14) (ref. DA30).

When on-boarding new developers, it is useful to browse the discussions from older issues to understand how a particular part of the codebase came to be. This is also true for pull and merge requests, forums and mailing lists. Even the CI artifacts and the description of the CI: a complex pipeline that relies on features specific provided by a given forge (ref. ZA22) (ref. DA35) (ref. AM28) may be difficult to migrate to another forge that does not support them (for instance moving from Travis to GitLab CI).

The scope of what defines a software is fuzzy (ref. ZA19) (ref. PO42) (ref. CJ44) and should be considered on a case by case basis (ref. PO39). It is a web of dependencies that are not confined to the boundaries of a forge (ref. AR17) (ref. NA16) (ref. DA52). It includes every data, web service that is stored and put to work when the software project moves forward. As an example, a developer mentioned that when they want to modify a software they use on their machine "most of the time it is not installed in a way that allows modifications: the first step is to get the code. If it's a Debian package, I look into he package metadata to find the source code, if it is a Python project, I tend to look on PyPI: I rely on the package manager to locate the source code" (ref. ZA11). Another example is how the software is packaged and distributed as it often involves resources external to the forge (ref. AR20).

The forge features used by a software project as well as its scope depends on how many people work on it. Very large projects tend to use more features and some tiny projects only have a DVCS (ref. NA22).

• AR14: "[...] contributing to Free Software is not only about code, it is also creating bug reports"
• AR17: "[...] I participate in the forum to help the users of that software and, from my point of view, it participates in the promotion, the ecosystem around this software."
• AR20: "[...] there is tooling which is more or less industrialized to produce these packages [...] it is hosted somewhere, it runs somewhere [...] "
• CJ44: "But at least having the opportunity to carry over nicely the community and keep track of these multiple forks contributions, anything to facilitate the human need around the software."
• DA30: "If I had to [...] keep a software as it is [...] I would save: the codebase, issues, releases, discussions [...]"
• DA35: "[...] all that allows the CI to work (not just the results of the CI)."
• DA52: "The problem with working on both on GitHub and on a GitLab instance[...]"
• MA18: "[...] we should be able to provide CI integrated with [our forge] this year."
• NA16: "I maintain stable branches or releases in various build systems/operating systems. So I definitely see the release workflow as something that I as a developer need to be aware of and work on to improve and streamline it."
• NA22: "There are very big projects [...]. In such a project, you necessarily have the developers specializing in various components: maintenance and release are just one component of the project in that case."
• PO39: "I tend to define a very wide perimeter, in the sense that I write software to make the life of users easier[...]"
• PO42: "After two years in production, the initial discussions were forgotten. But when it is time to code they are important elements."
• ZA19: "[...] the bare minimum is not boolean: there is the code, then the code history, then issues and merge requests"
• ZA22: "[...] there are complex CI with complex configuration and loosing it would obviously be a problem [...]"

Key takeaways:

• A software project is not limited to the content of the DVCS
• DVCS and discussions around the evolution of the code (issues, merge/pull requests) are frequently considered part of the history of a software project
• The boundaries of a software project are fuzzy
• Larger projects use more forge features

Emerging themes

Software project import/export and migration

A migration is a one shot operation (ref. GR110) that consists of moving a software project from a forge to another forge. The interviewees had 10+ years of experience in Free Software development and migrated projects more than once.

In all cases part of the data was lost (users, issues, cross references, discussions on forums or mailing lists, etc.) (ref. AR70) (ref. NA87) (ref. MA58) (ref. CP59) (ref. GR24) . Data was not lost because the migration failed: the person responsible for the migration knew that it could not preserve all the data. In some cases the features of the forges were different and it was non trivial to figure out how the development workflow would change. (ref. ZA56) (ref. ZA59) (ref. AR40). These problems delayed their decision to proceed with the migration but they eventually decided to accept the loss and move on (ref. AR70) (ref. PO75) (ref. NA90) (ref. DA85) (ref. CP59) (ref. GR121). Once the migration was done, the project was sometime preserved on the former forge but there was no turning back. The data was manually reconstructed later: users created new accounts, the new issue tracker was re-populated over time, etc. The motivation to migrate a project despite the problems it creates is, for most projects, the shutdown of the forge that hosts them (bitbucket deprecation of Mercurial (ref. MA17) (ref. GR21), code.google.com etc. (ref. DA88) (ref. CP55)).

The forge maintainers and developers interviewed did not remember users complaining about data loss (ref. MA55) (ref. CP53) (ref. GR101). And they did not mention asking for help when they were considering a migration.

• AR40: "We learned things about how git works. And that it was difficult to make mirrors [with Mercurial] and to do the mapping with models that are a little different."
• AR70: "Instead of '[redacted] wrote that' it was written 'Migration bot'"
• AR70: "when Phabricator was switched of we did not keep the history of all discussions on code review. I know for discussing this with other projects that is was a blocker for their migration to something else."
• CP53: "And apparently (because I did not use it myself, users told me about it), it works well."
• CP55: "A year or two ago, there were a significant number of migrations: framagit announced they would shutdown and there were migrations."
• CP59: "In the case of a client's project I lost the users: it was not a catastrophe but it was unpleasant."
• CP59: "With GitLab CE, if you are not root on the platform, you loose the identifiers of the author of the issues."
• DA85: "[...] discussions that happened on the old forge were lost."
• DA88: "On the gna.org forge [...] despite a one year advance warning [...] they came back years later and realized their project was lost."
• GR101: "Q: Did people ask for help with the import? A: In theory that was a possibility but it never happened."
• GR110: "Once they switch from one to the other, they do an import once and for all and all developers follow."
• GR121: "Mapping users is a problem that is almost impossible to solve. [...] With BitBucket it did not work well, we finally gave up entirely [...]"
• GR21: "[...] we had to salvage projects from BitBucket because it stopped supporting Mercurial."
• GR24: "The projects often have a history dated back 10/15 years and had chaotic beginning and they often trigger rare problems."
• MA17: "We knew that would happen because they were not invested in Mercurial for a long time and their support was not incomplete."
• MA55: "The first imports were done manually but then hundreds of projects arrived and were managed by the users, not by system administrators."
• MA58: "A fundamental problem we had was: how do we map users? A user on BitBucket makes a comment and is associated with an email, an avatar, permissions: when they are imported in GitLab, these users are not known and the question 'to whom does this comment belong' is left unanswered."
• NA87: "It didn't go well. In fact, it wasn't really a "migration" at all. I just took a snapshot of the latest state and pushed that to GitHub in a commit."
• NA90: "No, the easiest thing to do was to start from clean state. I didn't try to migrate anything, and whatever was on SourceForge just stayed there."
• PO75: "The project was not active, the issues, the wiki and the user accounts have not been migrated"
• ZA56: "[...] how to map the issues that are not related to a specific project, typically elements of a road-map[...]. There is a series of things like that which are rather well managed in the Phabricator data model and that must be mapped into the more limited model of GitLab."
• ZA59: "It is a real problem because there is no equivalence between the forges, because of this conceptual difference."

Key takeaways:

• Migration always implies data and/or feature loss
• Migration lossage is not a topic that is frequently discussed
• It is not uncommon for a software project to migrate from one forge to another
• Migrations are often caused by a forge shutdown

Creating links between forges

The forges provide a wide range of services: DVCS repository (ref. ZA19) (ref. MA76), merge or pull requests, issues, CI (ref. GR154) are the most commonly used. Although integration with third party tools (chat, kanban, etc.) are available, they were only mentioned briefly during the interviews (ref. CP39) (ref. GR151). Home made scripts to perform tasks not provided by the forge out of the box (activity reports, communication with third party issue trackers) were more frequent (ref. PO110) (ref. NA52) (ref. DA109) (ref. CP49) (ref. GR84). All scripts use a REST API, a feature available on all forges. One forge (now discontinued) implemented an interface similar to ActivityPub (i.e. using data as actions concepts). The other forge services: operations (Kubernetes, OpenStack), static pages, packages registry (Debian GNU/Linux, PyPI, etc.), CD were less familiar to the participants.

The interviewees were asked to explain how they keep track of the bugs they find in the dependencies of the project they work on (for instance the python modules). They all acknowledged that they need to track dependencies between Free Software projects for that purpose (ref. ZA32) (ref. AR53) (ref. PO50) (ref. NA60) (ref. DA52). And that it is common that it leads to using a forge different from theirs (refs ZA32).

It will also happen when introducing a workaround because of a bug in a dependency. The associated commit (or the issue) will contain the URL of the corresponding bug in the dependency. But curating these dependencies and noticing when the workaround should be removed relies on self discipline. Even when two projects co-exist on the same forge, there is no convenient way to link two issues together. For instance, when a notification is received about an issue on project A, it is up to the developer to figure out that they subscribed to this notification because another issue that depends on it in project B (ref. ZA45) (ref. PO56).

Here is a list of the forge features (most popular first) for which links are curated manually:

• DVCS repositories forks (refs. AR67) (ref. PO119) (ref. NA37) (ref. NA52) (ref. DA68) (ref. DO48)
• Individual issues (ref. AR56) (ref. PO53) (ref. NA37) (ref. NA52) (ref. DA52) (ref. MA82)
• Individual pull or merge requests (ref. ZA70) (ref. NA81) (ref. GR158)

Bots can establish a link without the need for the developer to intervene and notify the developer to make an executive decision such as merging a proposed modification created automatically (ref. NA37). For example dependabot (which also exists for GitLab) curates the dependencies of a project regardless of the forge they are hosted on. (ref. AR64) But such bots are still very rare.

Mirroring DVCS repositories between forges is known to be used (ref. MA79) although just one of the interviewees mentioned using it (ref. GR145). It is the only mirroring capability in existing forges and in some cases is only partly implemented (for instance GitLab CE can push but not pull). In any case, such a mirroring implies one end is the source of truth and the other is read-only. It is different from what developers need to go through when submitting a merge/pull request for a DVCS that is mirrored on different forges.

This user research did not collect any evidence of other forge features for which developers actively create links between projects that reside on different forges.

• A32: "It often happens that by following the dependency chain [...] it leads to a forge that is not mine"
• AR53: "[...] instead of taking the stable version or the version X of that package on PyPI or another PyPI instance, we boldly point to the SHA1 of the version found on a remote Git repository."
• AR56: "There is no tooling to handle these links, it is documented, it is a convention."
• AR64: "[...] to ensure stability we pin everything and then bots suggests upgrades that can be merged on a rolling basis."
• AR67: "He does the update the version [of the dependency] must be upgraded and the monkey patch breaks."
• CP39: "External issue trackers: Gitea handles that well and I use it to connect with the Redmine of [organization]."
• CP49: "We use [the API] to produce activity reports."
• DA109: "It was a CLI tool to automate manual tasks by using the GitLab and Redmine API [...]"
• DA52: " has many dependencies. Some of them are hosted on other forges."
• DA52: "When there was a bug on with an impact on , I was forced to open an issue on the GitLab of and to keep track of it in the Redmine of with a link."
• DA68: "[...] I have a copy of the Git repository of . That allows me to manage the modifications I want to make, [...] without them being on my laptop. I would like that to be a mirror but it is not because GitLab CE does not have that functionality [...]"
• DO48: "[...] there was a component developed for a client, privately and we realize it is something generic that would make sense to publish. We ask the client for his opinion and if he agrees we do refactoring: copying pieces of code from a repository to another. There was no particular tooling, it was done manually [...]"
• GR145: "[...] we developed a Mercurial mirroring. The motivation to implement it was because we needed it for ourselves."
• GR151: "Readthedocs has a native GitLab integration: in the Readthedocs interface one can say the project is hosted on GitLab and it works [...]"
• GR154: "CI is part of what we want to develop: it is what people want nowadays."
• GR158: "[...] users [...] in our community would like to create stacked merge requests (the second merge request depends on the first) [...]""
• MA76: "[...] hg-git which is a bridge between Mercurial and Git [...]"
• MA79: "People regularly talk about having a version on [forge] and a mirror on GitHub [...]"
• MA82: "We end up having an issue tracker on GitLab that people use by mistake instead of using the official tracker of [project] [...]"
• NA37: "Issue tracking is done via Redmine and due to this "dual-forge" system, some pieces of information have to be duplicated on both forges."
• NA52: "We have some scripts to help developers automate repetitive tasks such as opening a backport issue in Redmine and opening a backport pull request in GitHub."
• NA60: "To use the RocksDB example, bugs in that dependency get fixed by applying a patch to the Ceph project's fork of the RocksDB git repo, and then triggering a new build. But since that means the fork has diverged from the upstream RocksDB project's source code, the patch has to be submitted to the RocksDB project, where it might end up being accepted in a modified form, or even rejected."
• NA85: "When I use Git to prepare a new branch for an update, and one or more downstream patches have made it into the upstream repo since the last update, I do it in such a way that Git automatically drops those patches. "
• PO110: "At April we have an ad-hoc bot to monitor the Redmine activity"
• PO119: "[...] I use the tig viewer: I add forks I know as remotes in Git"
• PO50: "[...] I stumbled on a problem with the django- dependency that is hosted on GitHub"
• PO53: "I added an hyperlink in a comment of the issue from to the issue of the django- project"
• PO56: "It is rather annoying, I check it periodically"
• ZA32: "A typical example is when a bug is discovered, not in your code but in a dependency"
• ZA45: "I want a comment in the code that allows me to understand, 6 or 12 months later, [...] if the workaround is still necessary or not"
• ZA70: "on BitBucket, I did not want to learn how to make pull requests and I sent patches attached to issues."

Key takeaways:

• Developers routinely and manually create links between projects living on different forges
• The top forge features for which links are manually created are: DVCS, issues, pull or merge requests
• There exist at least one bot (dependabot) that creates links between projects
• Mirroring DVCS between forges is frequently used

User Interfaces

Developers interact with a forge daily and the UI was a topic in all interviews. It ranges from interfaces with a low barrier on entry (such as the web interface) to those that impose a significant learning curve and a complicated setup such as a CLI. And all kind of heterogeneous tooling in between (ref. ZA11). Although there exist a few interfaces that allow interaction with multiple forges, they were not discussed. Two problems were mentioned and experienced first hand:

• Creating an account on a yet another forge is a friction that can be discouraging when it is only for the purpose of reporting a new bug (ref. ZA44) (ref. AR78) (ref. PO142) (ref. NA101) (ref. MA77)
• It is not possible to report a bug anonymously (or interact with a forge anonymously, in general) (ref. AR78) (ref. CJ44)

Developers are generally reluctant to change the user interface they use to work on a software project (ref. ZA32) (ref. PO47) (ref. PO79) (ref. NA108) (ref. DA97) (ref. MA17). To the extent that it may happen that a company is pressured by its developers to use a given forge because a number of them prefer its interface (ref. AR37) (ref. ZA51) (ref. DO16). Although it would be possible to make it so the interface of a forge mimics the interface of another, it is costly (ref. AR37).

• AR37: "The client pointed out: I have a JavaScript developer, he can do with GitHub - he did not say: he can do with Git - and he cannot contribute to your project unless he learns about Mercurial"
• AR37: "These were experiments for which we did not have a budget to finalize things, it was never completed."
• AR78: "I like [...] people who say hello 'I used the software in this way' and blockers preventing that are little stupid things like creating an account[...]"
• AR78: "I want to report a bug but there is no mail, I try to create an account and it turns out there is no button to create an account: I move on."
• CJ44: "If I want to open a mastodon bug, I have to go to GitHub and have an account there and open an issue."
• DA97: "[...] I'm very used to GitLab and it would take me time to extract myself from GitLab."
• DO16: "Obviously, the difficulty was that [this forge] was made by developers and geeks: the UX left a lot to be desired and this probably is what led to the quasi-death of it."
• MA17: "Mercurial is very good, even a little better than Git on this and this but we do not move to Git: we move to GitHub/GitLab"
• MA77: "[...] not needing to connect on five different forges to submit a merge-request to [project] would be fine with me."
• NA101: "I found that I had to first become a registered user of Gerrit in order to present it there for review. This was annoying because all I wanted to do was submit a small code change, not type my personal data into a form, click with my mouse on a button saying I agree to "terms and conditions", etc."
• NA108: "Well, actually, I do occasionally proxy for colleagues who come to me with patches for the Ceph spec file. Since the spec file is maintained upstream, these patches have to be submitted by someone with a GitHub account."
• PO142: "[What works well when using multiple forges?] The GitHub authentication."
• PO47: "[...] I used Fossil which has been a blocker to contribution: I endured Fossil and got so fed up that I stopped contributing to this particular software."
• PO79: "[...] SVN has a low entry bar for people who are not developers"
• ZA11: "If that's GitHub, I use the command line to create the pull-request, if it's GitLab, I use the web interface."
• ZA32: "[...] until recently I used a project hosted on BitBucket - which I only used for this purpose - and that was a nightmare: I was not used to do things with this forge."
• ZA44: "[...] I don't necessarily want to create an account just for the purpose of following a project hosted there [...]"
• ZA51: "The desire to proceed with the migration [to GitLab] is to take into account the needs of the developers."

Key takeaways:

• Creating multiple accounts is the primary source of friction when using multiple forges
• Developers usually have a strong opinion regarding the UI of the forge they use

Recommendations

• Focus on multi forges issues. Developers manually add links in issues or commit comments to keep track of related issues that are located on different forges. They rely on their memory or conventions to connect the two. Fedeproxy can automate this workflow and provide activity notifications when it is lacking.
• Leverage the desire of developers for a decentralized and federated ecosystem. Although developers have agreed to the terms of service of centralized forges, they are unhappy about it. Making it easy for them to participate in fedeproxy would allow them to help making it happen sooner rather than later.
• Create a User eXperience, not a User Interface. Developers use the UI of the forge on which their project is hosted on a daily basis and are reluctant to use another UI. The UX provided by fedeproxy by must be embedded in the UI they currently use.
• Do not require the user to create an account on every forge, even for the purpose of federation. Although having an account on both forges is a requirement to link two issues, it must be transparent to the user otherwise it will drive early adopters away.