Although forgefriends may appear to be nothing more than a set of patches on top of the Gitea codebase (which it is), both projects differ in a number of areas, technical and organizational. They are listed below and the rationale for the forgefriends approach is explained, with links to documents that provide more details when available.
When two Free Software projects are technically very similar, the organizational differences may become the defining reason for a particular person to have more frequent interaction with one project or the other. Do you feel strongly about testing and feel more comfortable when this is a requirement? Is a very popular project more motivating to you than a rather confidential one? Have you been subject to abuse in the past and feel vulnerable when a project does not have a code of conduct? etc.
Back in 2021 the decision was made to base forgefriends on Gitea because it contains most of the code required to implement a forge federation proxy. A set of changes are rebased on a weekly basis and this strategy is a good match: the effort is manageable.
Gitea is used by tenths of thousands of people and organizations and developed daily by half a dozen people, forgefriends is not used by anyone and developed daily by at most two people.
Gitea is packaged for various operating systems and hardware architectures, forgefriends is only released as a container image.
The opinionated choice made by forgefriends is practical: there is not enough workforce to create more than one release.
Elections are held once a year in Gitea to decide on the owners of the project. Forgefriends has no hierarchy or delegation of power.
There is no documented decision making process or governance in Gitea. In forgefriends they are documented in dedicated category of the forum.
The importance of a well structured governance for the forgefriends community is explained in detail in the A guide to forgefriends governance. The most important problem it solves is explained as follows in the “tyranny of structurlessness”:
“For everyone to have the opportunity to be involved in a given group and to participate in its activities the structure must be explicit, not implicit. The rules of decision-making must be open and available to everyone, and this can happen only if they are formalized.” (Jo Freeman)
Changes to Gitea are routinely merged without tests, all forgefriends changes are required to be associated with a test.
Gitea testing code coverage is around 50% in the backend and close to zero in the frontend. As a long standing fork with only a handful of users, forgefriends entirely relies on automated tests to verify there is no regression when rebasing against the latest main branch of Gitea.
In addition to this practical motivation to write tests in the Gitea codebase, the forgefriends community advocates that tested code is easier to review, more robust and less stressful to work with.
Gitea is somewhat transparent, forgefriends is radically transparent.
In forgefriends, although not part of the governance, principles of radical transparency became a tradition over time. It essentially means that there are no private discussions, everything is held in public. The only exception is private information about organizations or individuals, which are redacted. There are no private chatrooms, forum categories, or documents.
It means that forgefriends authors do not agree that forgefriends ever becomes proprietary software. But Gitea authors, by choosing the MIT license, agree that Gitea is relicensed as proprietary software and they also agree that it is relicensed as copyleft software, which AGPLv3+ is.
It is sometime argued that the MIT license, by allowing relicensing as proprietary software, is beneficial to the project because the people and organizations that relicense it will contribute back, one way or another. In the particular case of Gitea, it did not happen since the inception of the project, over six years ago. There only is one company known to distribute a proprietary version of Gitea and it contributed two dozen patches and donated around one thousand USD.
Gitea relies on services running proprietary software, forgefriends only relies on services running Free Software.
While the Gitea distribution does not require any proprietary software to run, participating in the Gitea development requires using proprietary services such as Discord or GitHub. Participating in the development of forgefriends does not require using any proprietary services.
The Gitea project infrastructure is not Infrastructure as Code, forgefriends runs on an instance of Enough.
For a Free Software project to be alive, three conditions must be met:
- people with the skills and motivation must be around
- the code and build scripts for each release must be available under a Free Software license (as stated by the AGPLv3+ license)
- the infrastructure sustaining the development must be affordable
Even though the concept of Infrastructure as Code gained popularity over the years, it is still uncommon. One of its benefits is the ability for a Free Software project to be forked effectively. What good is a fork when the entire production pipeline is so difficult (or expensive) that it is practically impossible to create a new release, let alone run the CI that ensures the continuous testing of the codebase?