Difference between revisions of "FSF forge evaluation"

From LibrePlanet
Jump to: navigation, search
(Wording)
(Add Radicle to federation section)
 
(35 intermediate revisions by 4 users not shown)
Line 3: Line 3:
 
Disclaimer: All of the projects we considered were good in different ways. Our decisions are based on a long list of criteria.
 
Disclaimer: All of the projects we considered were good in different ways. Our decisions are based on a long list of criteria.
  
https://www.fsf.org/blogs/sysadmin/the-fsf-tech-team-doing-more-for-free-software
+
Blog posts:
 
+
* [https://www.fsf.org/blogs/sysadmin/the-fsf-tech-team-doing-more-for-free-software The FSF tech team: doing more for free software]
 +
* [https://www.fsf.org/blogs/sysadmin/coming-soon-a-new-site-for-fully-free-collaboration Coming soon: A new site for fully free collaboration]
  
 
== Ongoing evaluation ==
 
== Ongoing evaluation ==
  
 
+
* [https://directory.fsf.org/wiki/Pagure Pagure] (seems most likely, its our current focus)
* Pagure (seems most likely, its our current focus)
 
 
** Pros:
 
** Pros:
*** Someone else runs an instance open to free software: https://pagure.io
+
*** Someone else runs an instance open to free software: [https://pagure.io pagure.io]
*** JS not aggregated, so should be easy to support LibreJS
+
*** JavaScript is not aggregated, so should be easy to support LibreJS
 
*** User import / export of data for issues and merge requests
 
*** User import / export of data for issues and merge requests
 
*** It is possible to configure Pagure to use user namespaces for projects.
 
*** 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. [https://pagure.io/pag pag] and [https://github.com/mikem23/pagure-tool pagure-tool]
 
** Cons:
 
** 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, [https://www.gnu.org/software/librejs/ LibreJS] support for all of the JS is required and trivial, and it's okay if the site requires some JS to work. In terms of making the site work without JS, upstream patches are welcome: https://pagure.io/pagure/issue/3507
+
*** 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, [https://www.gnu.org/software/librejs/ 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: [https://pagure.io/pagure/issue/3507 Issue 3507]
 +
*** Does not support Mercurial
 
** Needs more research:
 
** Needs more research:
 
*** Resource requirements / performance under load
 
*** Resource requirements / performance under load
*** How featureful are is are administration interface/tools (GUI or CLI)
+
*** How featureful are administration interface/tools (GUI or CLI)
*** Tools to prevent abuse. User banning is possible from Gui.
+
*** Tools to prevent abuse. User banning is possible from GUI.
 
*** Ease of deployment, upgrading, debugging
 
*** Ease of deployment, upgrading, debugging
*** Finer points of GNU ethical repo criteria
+
*** Does not meet all points of GNU ethical repo criteria
 
*** import/export of data
 
*** import/export of data
  
* Gitea
+
* [https://directory.fsf.org/wiki/Gitea Gitea]
 
** Pros:
 
** Pros:
 
*** LibreJS is partially supported, does not look hard to add full support.
 
*** LibreJS is partially supported, does not look hard to add full support.
*** Someone else runs an instance open to free software: https://codeberg.org/
+
*** Someone else runs an instance open to free software: [https://codeberg.org/ codeberg.org]
 +
**** [https://codeberg.org/Codeberg-Infrastructure/ansible-configuration Codeberg Ansible Config]
 +
**** [https://blog.codeberg.org/codeberg-launches-forgejo.html Codeberg forked gitea] into [https://forgejo.org/ Forgejo]. [https://codeberg.org/forgejo/forgejo Source]
 +
*** Acquired funding toward federation.
 +
*** Gitea has a web-based editor.
 +
*** Gitea has a command line tool [https://gitea.com/gitea/tea tea].
 
** Cons:
 
** 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 js is run.
+
*** 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. https://github.com/go-gitea/gitea/issues/1446
+
*** No user import / export of issues and merge requests. [https://github.com/go-gitea/gitea/issues/1446 Issue 1446]
*** Upstream hosted on GitHub which requires running nonfree JS for signup, https://github.com/go-gitea/gitea/issues/9303, but they seem to be very close (within a few weeks/months) to self hosting
+
*** Upstream hosted on GitHub which requires running nonfree JS for signup, [https://github.com/go-gitea/gitea/issues/9303 Issue 9303], but they seem to be very close (within a few weeks/months) to self hosting.
 +
*** Does not support Mercurial.
 
** Needs more research:
 
** Needs more research:
 
*** Resource requirements / performance under load
 
*** Resource requirements / performance under load
*** How featureful are is are administration interface/tools (GUI or CLI)
+
*** How featureful are administration interface/tools (GUI or CLI)
 
*** Ease of deployment, upgrading, debugging.
 
*** Ease of deployment, upgrading, debugging.
 
*** Finer points of GNU ethical repo criteria
 
*** Finer points of GNU ethical repo criteria
 
*** import/export of data
 
*** import/export of data
  
* Sourcehut
+
* [https://sourcehut.org/ sourcehut] - [https://sr.ht/~sircmpwn/sourcehut/ Source]
 
** Pros:
 
** Pros:
*** Perfect usability with no js from site (gnu criteria A):
+
*** Perfect usability with no JavaScript from site (gnu criteria A):
*** Only has 3 static js files. Extremely easy to support LibreJS
+
*** Only has 3 static JavaScript files. Extremely easy to support LibreJS
 +
*** Someone else runs an instance open to free software: [https://sr.ht/ sr.ht]
 
*** User export of data. Import for issues is in development.
 
*** User export of data. Import for issues is in development.
*** GNU ethical repo criteria grade A seems like it requires minimal changes. https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3C87a79fifzl.fsf%40fsf.org%3E#%3CBY4SP60PHM4J.OFO3GMYYJ3OK@homura%3E
+
*** GNU ethical repo criteria grade A seems like it requires minimal changes. [https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3C87a79fifzl.fsf%40fsf.org%3E#%3CBY4SP60PHM4J.OFO3GMYYJ3OK@homura%3E Mailing list thread]
*** Bonus features: wiki, ci, supports email workflow, mercurial, agplv3
+
*** 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 [https://git.sr.ht/~sircmpwn/sourcehut-go sourcehut-go]
 
** Cons:
 
** Cons:
 
*** Upstream claims it is alpha software.
 
*** Upstream claims it is alpha software.
*** Navigation between code & issues is difficult. In development upstream https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3C87woqgtr0s.fsf%40jb55.com%3E.
+
*** Sourcehut does not include a web-based editor.
*** No Web merge request UI. A Web merge request can be done by creating a ticket and including the forked git repo url and branch name, but this missing feature seems like a key thing we are looking for.
+
** 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:
 
** Needs more research:
 
*** Resource requirements / performance under load
 
*** Resource requirements / performance under load
*** How featureful are is are administration interface/tools (GUI or CLI)
+
*** How featureful are administration interface/tools (GUI or CLI)
 
*** Tools to prevent abuse.
 
*** Tools to prevent abuse.
 
*** Ease of deployment, upgrading, debugging
 
*** Ease of deployment, upgrading, debugging
Line 64: Line 77:
 
*** 2 factor authentication support
 
*** 2 factor authentication support
 
*** Freely licensed
 
*** Freely licensed
 
  
 
== Evaluated and not currently focused on ==
 
== 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.
 
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
 
* GitLab
Line 75: Line 86:
 
*** Lots of features.
 
*** Lots of features.
 
*** Very popular.
 
*** Very popular.
 +
*** GitLab has a command line tool [https://gitlab.com/gitlab-org/cli glab].
 
** Cons:
 
** Cons:
*** 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, https://gitlab.com/gitlab-org/gitlab-foss/issues/46548 https://gitlab.com/gitlab-org/gitlab/issues/21998 (https://www.gnu.org/philosophy/javascript-trap.en.html), which also has problems like it helps google track users and train their AI models.
+
*** 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, [https://gitlab.com/gitlab-org/gitlab-foss/issues/46548 Issue 46548] [https://web.archive.org/web/20210305144540/https://gitlab.com/gitlab-org/gitlab/-/issues/21998 Issue 21998 (Deleted)] ([https://www.gnu.org/philosophy/javascript-trap.en.html 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:
 
*** 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 randomly hit by a requirement to run the nonfree ReCAPTCHA. We do not want to take contributions that should go upstream.
+
**** 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.
**** 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.
+
***** They will likely be required to run nonfree ReCAPTCHA code.  
**** 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 (https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html). https://docs.gitlab.com/ce/integration/ some of them are: Google ReCAPTCHA, Sourcegraph, Trello, Bitbucket, Akismet, YouTrack, Jira, about 10 different project services https://gitlab.com/gitlab-org/gitlab-foss/tree/master/app/models/project_services. Gravatar is somewhere else. Identifying all such code and documentation, removing and maintaining that appears to be nontrivial.
+
***** Upstream only accepts contributions to a repo that contains the nonfree parts, so you need to download nonfree software.
**** If we were to maintain a fork, a rename would be preferable because when you say GitLab, people think of gitlab.com which is the nonfree enterprise version of GitLab. Renaming is nontrivial.
+
***** 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 ([https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html SaaSS article]). [https://docs.gitlab.com/ce/integration/ Integration page] some of them are: Google ReCAPTCHA, Sourcegraph, Trello, Bitbucket, Akismet, YouTrack, Jira, about 10 different project services [https://gitlab.com/gitlab-org/gitlab-foss/tree/master/app/models/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.
 
*** 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 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 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 https://gitlab.com/gitlab-org/gitlab/issues/15208 and https://www.gnu.org/licenses/identify-licenses-clearly.en.html
+
*** 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 [https://gitlab.com/gitlab-org/gitlab/issues/15208 Issue 15208] and [https://www.gnu.org/licenses/identify-licenses-clearly.en.html 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.
+
*** 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 [https://heptapod.net/ heptapod].
 +
 
 +
== Additional resources ==
 +
 
 +
* Federation
 +
** [https://forgefed.peers.community/ ForgeFed]
 +
*** [https://fedi.foundation/2022/09/vervis-federated-merge-requests/ Blog - Vervis Demo 4: Federated Merge Requests]
 +
*** [https://socialhub.activitypub.rocks/t/my-work-schedule-for-8-9-2022/2549 ForgeFed progress 2022-10-03]
 +
** [https://radicle.xyz/ Radicle]
 +
*** [https://hackaday.com/2024/03/16/radicle-an-open-source-peer-to-peer-github-alternative/ Radicle: A Peer-to-Peer, GitHub Alternative - Hackaday]
 +
*** [https://app.radicle.xyz/nodes/seed.radicle.xyz Source] MIT and Apache-2.0

Latest revision as of 10:56, 20 March 2024

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:

Ongoing evaluation

  • Pagure (seems most likely, its our current focus)
    • 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)
      • Tools to prevent abuse. User banning is possible from GUI.
      • Ease of deployment, upgrading, debugging
      • Does not meet all points of GNU ethical repo criteria
      • import/export of data
  • Gitea
    • Pros:
    • 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)
      • Ease of deployment, upgrading, debugging.
      • Finer points of GNU ethical repo criteria
      • import/export of data
  • 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

In all of the above:

    • Pros
      • Active upstream
      • 2 factor authentication support
      • Freely licensed

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.
      • 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.

Additional resources