What you’re missing is that they’re not just making a choice for themselves, but for anyone who might want to post or comment on an issue, etc. As @Licaon_Kter put it a few comments back;
Developers can do that just as effectively on a code forge that doesn’t lock-in and DataFarm anyone using it, nor misuse their contributions to “train” MOLEs.
Because it doesn’t affect the user’s in any way.
F-Droid takes the source code and compiles it to make sure that nothing is added or removed from the source code and that this can be verified through reproducible builds.
… unless they want to participate in any way in the project that forges the software, instead of just being a disengaged consumer. Sometimes even then, they’re still affected. If that project uses GritHub, and hosts their homepage on GritHub Pages and their releases on their GritHub project, they may need to run proprietary JavaScript just to read about the app, and download a copy to install.
In most cases now, they have to run proprietary JavaScript from GritHub to browse or search Issues, or even just to read Issue discussion. If they want to open an Issue or comment on an existing one, or submit a merge request, this definitely requires running nonfree JS. For that they also need a GritHub account, which forces 2FA, and applies all sorts of Dark Patterns to try to DataFarm the person in the process of setting it up.
If the project uses other GritHub components like docs, roadmap, forum, kanban board or components post, they may need to run nonfree JS to browse any of those, and to login with an account to post in the community forum or add a tile to a kanban board (eg for feature requests).
In the discussion on GitLab about whether to re-add the Amethyst Nostr app to the F-Droid repo, @Licaon_Kter mentioned that an anti-feature flag was added to Amethyst simply because a person installing it was required to read the ToS hosted on GritHub before using it. In hindsight I agree with the logic of this. Although as I’ve written elsewhere, some of the anti-feature flags are a bit broad brush, and need to be split into a number of more nuanced and descriptive flags.
need a GritHub account, which forces 2FA
I just logged in to Github literally a minute ago and it does NOT require 2FA unless you set up that option in your settings. Just the usual ugly javascript.
I don’t know what do tell you. That doesn’t match my experience, either on desktop or mobile. Maybe it varies depending on factors like what browser you’re using, what country you’re in, what ISP provides your net connection?
Being forced to run nonfree JS to use a code forge ought to be enough to convince any developer who cares about software freedom to move their project elsewhere.
As a normal user without organisations and stuff, you might not.
Once you start doing more advanced stuff… you’ll be asked
That’s interesting. Explains why it’s never asked me. But I’m not a coder, don’t own any repos, only thing I do on GH is read and post issues and comments and occasionally search through source code looking for things that are easy to find.
As for Gitlab, I hate them because they will not display one single pixel to you unless you enable javascript. (See screenshot, that was trying only to view the F-droid page.) I disable JS entirely by default, only enable on sites I need to view which won’t work without it. (EDIT: I spelled f-droid “f-droid” which is why I got the 100% blank page. When I re-spelled it “fdroid” I got an ALMOST blank page with an F-droid icon and could not do anything else.)
Nice thing about Github is that if I just want to quickly check the homepage, issue or release page for a repo, I can do all of that without JS.
Bad thing about Github: Microsoft and minor UI annoyances.
I think that we have much bigger issues than that we should focus on.
What is the problem with 2FA?
You can do 2FA with fully Libre Apps like Aegis
This is a different issue, because they force you to open the website to run the software.
It also very easy to avoid by just keeping a local copy of the ToS
