FSF forge evaluation
From LibrePlanet
Contents
Forge Software Evaluation
Disclaimer: All of the projects we considered were good in different ways. Our decisions are based on a long list of criteria.
Blog posts:
- The FSF tech team: doing more for free software
- Coming soon: A new site for fully free collaboration
Ongoing evaluation
-
Pagure
- Pros:
- Someone else runs an instance open to free software: pagure.io
- JavaScript is not aggregated, so should be easy to support LibreJS.
- User import / export of data for issues and merge requests.
- It is possible to configure Pagure to use user namespaces for projects.
- Pagure has a web-based editor.
- As of Trisquel 10, pagure can be installed with this command: apt install -y pagure
- Command line tools are available to interact with their API. pag and pagure-tool
- Cons:
- We eventually want to make our forge work without JavaScript at all, for an A rating on the GNU ethical criteria. Depending upon which user authentication module we use, or whether we create our own, we that may require some work. We also may have to make such changes for getting issue creation to work with an A rating. For the initial B rating, LibreJS support for all of the JS is required and trivial, and it is okay if the site requires some JS to work. In terms of making the site work without JS, upstream patches are welcome: Issue 3507
- Does not support Mercurial
- Needs more research:
- Resource requirements / performance under load
- How featureful are administration interface/tools (GUI or CLI)?
- How are tools to prevent abuse? User banning is possible from GUI.
- What is the state of ease of deployment, upgrading, and debugging?
- Does not meet all points of GNU ethical repo criteria.
- How does import/export of data work?
- Pros:
-
Gitea and Forgejo
- Pros:
- LibreJS is partially supported, does not look hard to add full support.
- Someone else runs an instance open to free software: codeberg.org
- Acquired funding toward federation.
- Gitea has a web-based editor.
- Gitea has a command line tool tea.
- Cons:
- Poor usability with no JS from site (gnu criteria A): Can't make pull request. Can't attach file to issue. Can't create ssh key in user settings. Can't delete repo. Would need to add that functionality in plain HTML when no JavaScript is run.
- No user import / export of issues and merge requests. Issue 1446
- Upstream hosted on GitHub which requires running nonfree JS for signup, Issue 9303, but they seem to be very close (within a few weeks/months) to self hosting.
- Does not support Mercurial.
- Needs more research:
- Resource requirements / performance under load
- How featureful are administration interface/tools (GUI or CLI)?
- What is the state of ease of deployment, upgrading, and debugging?
- Finer points of GNU ethical repo criteria
- How does import/export of data work?
- Site-level import/export documentation
- What about user-level import/export?
- Pros:
-
sourcehut - Source
- Pros:
- Perfect usability with no JavaScript from site (gnu criteria A):
- Only has 3 static JavaScript files. Extremely easy to support LibreJS
- Someone else runs an instance open to free software: sr.ht
- User export of data. Import for issues is in development.
- GNU ethical repo criteria grade A seems like it requires minimal changes. Mailing list thread
- Bonus features: wiki, CI, supports email workflow, mercurial, AGPL-3.0-only
- Command line tools are available to interact with their API. https://git.sr.ht/~emersion/hut hut] and sourcehut-go
- Cons:
- Upstream claims it is alpha software.
- Sourcehut does not include a web-based editor.
- Additional info:
- Uses email + web for patches (aka pull requests). Completely web based pull requests are popular, however sr.ht has web features that make it much easier than plain GNU Mailman. For example it has mailto links, no need for email to accept pull requests, very simply guide for sending email patches, etc.
- Needs more research:
- Resource requirements / performance under load
- How featureful are administration interface/tools (GUI or CLI)
- Tools to prevent abuse.
- Ease of deployment, upgrading, debugging
- import/export of data
- Pros:
In all of the above:
- Pros
- Active upstream
- 2 factor authentication support
- Freely licensed
- Pros
Evaluated and not currently focused on
We evaluated 15 different forge programs that we decided not to go with. Some of the projects not listed below also seemed promising but were mainly designed for use by a single project/organization, not independent projects and open the public.
- GitLab
- Pros:
- Lots of features.
- Very popular.
- GitLab has a command line tool glab.
- Cons:
- Someone else runs an instance open to any free software: Doesn't exist for GitLab. All community run instances only accept projects/repos related to their community. Many use the nonfree ReCAPTCHA as well. gitlab.com is a nonfree version.
- GNU ethical repo criteria: gitlab.com listed as C, but has been operating at an F and will be reclassified soon because it sometimes requires users to run nonfree Google ReCAPTCHA code they have been very slowly working on moving away from for almost 2 years now, Issue 46548 Issue 21998 (Deleted) (JavaScript Trap article), which also has problems like it helps google track users and train their AI models.
- The forge we run should be something that would fit our own requirements to host as a project on the forge. There are major issues preventing that which could be solved through a fork, but we do not want to maintain a fork:
- We would not want to recommend people contribute upstream as they will be required to run nonfree software, but we don't want to maintain a fork with code that would naturally belong upstream.
- They will likely be required to run nonfree ReCAPTCHA code.
- Upstream only accepts contributions to a repo that contains the nonfree parts, so you need to download nonfree software.
- Running the test suite implies running nonfree software.
- The docs for nonfree features are part of GitLab CE. We don't want to host documentation for nonfree software so we would want to take it out. This looks to be a nontrivial effort.
- GitLab has a fair bit of code and documentation we would want to remove: It integrates with a. Nonfree software, b. Services that require running nonfree JavaScript, c. Services that are substitutes for software (SaaSS article). Integration page some of them are: Google ReCAPTCHA, Sourcegraph, Trello, Bitbucket, Akismet, YouTrack, Jira, about 10 different project services project_services. Gravatar is somewhere else. Identifying all such code and documentation, removing and maintaining that appears to be nontrivial.
- If we were to maintain a fork, a rename would be important because when you say GitLab, people think of gitlab.com which is a nonfree version of GitLab. Even GitLab CE, most instances run nonfree software or SaaSS. Renaming is nontrivial.
- We would not want to recommend people contribute upstream as they will be required to run nonfree software, but we don't want to maintain a fork with code that would naturally belong upstream.
- GitLab is a known target of spam scripts. Upstream uses ReCAPTCHA (see above), but also Akismet, which is unethical due to being a software substitute and requiring nonfree JS. Upstream is not working on an alternative to help free software users. We would be stuck developing our own anti-spam solutions.
- GitLab is quite complicated. Adding LibreJS support would be nontrivial.
- GitLab has licensing recommendations that leads thousands of developers to leave their code's licensing unclear. We would need to remove or change them. This is nontrivial. see Issue 15208 and Don't Say “Licensed under GNU GPL 2” article
- Given the current presence of nonfree/ethical problems, any fork we maintain we should expect new freedom issues and more work to correct them over time. Related: in 2019 they put on hold a plan to add more nonfree JS tracking to gitlab.com and we are grateful for that. However, nonfree JS tracking already existed and still does on gitlab.com.
- Does not support Mercurial be default without using heptapod.
- Pros:
