My forgefriends development strategy 2022-2023

Bonjour,

It has been 18 months since forgefriends started, with a Python code base. A year ago the decision was made to move to Go instead and start from scratch, primarily to take advantage of the existing Gitea codebase. Although a Python forge exists (https://pagure.org), it is not actively maintained. Go is also better because it can be used as a library to implement Python or Ruby packages, which would help with the inclusion of forgefriends within existing forges. A year later I still think this was a good move, despite the time it took me to learn Go (and I’m still learning) and re-implement what already existed in the Python codebase.

Back then I did not know much about the Gitea project and after some observation and discussions with as many people as I could, the relationship between Gitea and forgefriends was set to be as follows:

  • forgefriends is a long standing fork of Gitea
  • forgefriends is published as a docker image
  • continuous efforts are made to contribute every aspect of forgefriends to Gitea
  • only federation proxying remains in the forgefriends codebase because it is not in the Gitea scope

The first two are easy, the last two less so and a strategy was devised based on the following assumptions:

  • Gitea is a community project led by volunteers and no company support
  • Given enough funding some of the current Gitea maintainers are willing to work on implementing some aspects of federation within the Gitea codebase
  • The current Gitea maintainers would be willing to review the architectural changes required to implement federation
  • Architectural changes could be implemented with baby steps over an extended period of time
  • The level of test coverage could be improved to guard the code contributed to Gitea against regressions
  • The communication with the Gitea owners and maintainers happens in a friendly and inclusive environment

The implementation of this strategy went as follows:

As can be expected, the reality challenged the assumptions made a year ago, as follows:

  • Gitea is a community project led by an affinity group (i.e. people who get along). Some of them derive an income from Gitea and are in the process of raising funds to create a service company based on Gitea (I was told privately by one of the owners)
  • Funding is not a motivation for Gitea owners or maintainers to work on federation
  • Architectural changes do not happen in Gitea, either via baby steps or otherwise, unless they are authored by one of the owners/mergers. And even then it is a very rare occurrence. (not counting purely syntactic refactoring related to moving a module in a subdirectory, etc. which happen routinely)
  • A large number of pull requests (particularly bug fixes) are merged with either no tests or very limited testing, the frontend has no tests at all. As a consequence, improving test coverage is an uphill battle.
  • Gitea owners are generally unresponsive (they are busy with things that interest them, which does not include federation) on all communication channels. Some Gitea maintainers/mergers are responsive on federation related topics. There is no CoC or mediation and friction drives away people who are not part of the affinity group.

My strategy gradually adjusted over time to take these new assumptions into account and could be summarized as follows:

  • forgefriends is a long standing fork of Gitea
  • forgefriends is published as a docker image
  • A large part of the work required for federation (the F3 file format) is developed as an independent package and proposed as a single pull request to Gitea, as a new feature that does not require architectural changes. Similar pull requests could be developed for ActivityPub but it is more challenging. It will be worth thinking about it more if there is funding. Otherwise it will happen if a volunteer is motivated and in a way that they prefer, whatever that is and this is what @Dodecahedron is currently engaged in.
  • A grant application was sent, identical to the one sent last year but with beneficiaries who have worked on a volunteer basis to further federation (@gusted, @Dodecahedron, @6543 and myself). I will do the required administrative work to add new beneficiaries, if more are interested.

This strategy is simpler and compatible with the fact that architectural changes in Gitea are out of reach for people outside of the affinity group, which is the primary roadblock of the previous strategy. In a nutshell forgefriends keeps being a long standing fork but instead of contributing gradually whatever it can in Gitea, large parts of the work (F3 for instance) are published as independent packages. The integration in Gitea is a pull request that depends on the package. The pull request has a smaller code footprint and no architectural requirement. And mabye a better chance of being accepted and merged.

I wasted about half my time because I made incorrect assumptions a year ago. But I don’t feel too bad about that because those assumptions were based on a rather superficial observation of the Gitea project. And since I tend to hope for the best rather than starting with a minimalist approach, I’m bound to discover that the reality does not match what I imagined. I hope my current strategy is more aligned with the reality and will not be significantly challenged in the next year.

Comments and thoughts are very welcome