13 ms·

I think it's actually an understandable strategical move from Mozilla. They might loose some income from Google and probably have to cut the staff. But to keep

I think it's actually an understandable strategical move from Mozilla. They might loose some income from Google and probably have to cut the staff. But to keep the development of Firefox running they want to involve more people from the community and GitHub is the tool that brings most visibility on the market right now and is known by many developers. So the hurdle getting involved is much lower. I think you can dislike the general move to a service like GitHub instead of GitLab (or something else). But I think we all benefit from the fact that Firefox's development continues and that we have a competing engine on the market.

fhd2 1y ago
In my experience, most contributors who are deterred from contributing because they can't use GitHub aren't particularly valuable contributors. I'm sure there's exceptions, but I haven't seen any for non-trivial open source projects I've been involved in. I might even argue that it could be good to have a slightly higher bar to deter low quality one time contributors.
- nicman23 1y ago
  "gatekeeping good" no.
  - 7bit 1y ago
    They are everywhere. It's like a plague.
  - bigstrat2003 1y ago
    Declaring gatekeeping to be always and forever bad is an unhelpful, untrue thought-terminating cliche. A wide variety of situations can be described as "gatekeeping", and while some are nonsense some are very good to keep. It's bad if we say "you must be 6 feet tall to be a doctor", because that has nothing to do with being a good doctor. But requiring that doctors get a medical degree and pass certification requirements is also gatekeeping, and it would also be insane to do away with it. Any time you call gatekeeping bad for its own sake you are engaging in a gross oversimplification, and should stop.
- berkes 1y ago
  You just showed the poster-child of gatekeeping that is harming Open Source. Every contributor is valuable, it's in the name, the definition of "contribute". Any bar to entry is bad, it certainly never is the solution to a different problem (not being able to manage all contributions). If anything, in the longer run, it will only make it worse. Now, to be clear, while I do think GitHub is currently the "solution" to lower barriers, allow more people to contribute and as such improve your Open Source Project, the fact this is so, is a different and other problem - there isn't any good alternative to Github (with broad definitions of "good") why is that and what can we do to fix that, if at all?
  - sneak 1y ago
    Not all PRs are created equal.
    - berkes 1y ago
      And that is good. Diversity, here too, is of crucial importance. It's why some Open Source software has sublime documentation and impeccible translations, while the other is technically perfect but undecipherable. It's why some Open Source software has cute logos or appeals to professionals, while the other remains this hobby-project that no-one ever takes serious despite its' technical brilliance.
    - myfonj 1y ago
      Also don't forget that not all contributions are done through PRs or are actual code changes. There are folks that do tests, make MREs, organise issue reports, participate in forums … they all are also contributing: their time and efforts.
  - int_19h 1y ago
    This is just blatantly wrong on so many levels. Proposed contributions can in fact have negative value, if the contributor implements some feature or bug fix in a way that makes it more difficult to maintain in the long term or introduces bugs in other code. And even if such contribution is ultimately rejected, someone knowledgeable has to spend time and effort reviewing such code first - time and effort that could have been spend on another, more useful PR.
- lpln3452 1y ago
  Contribution isn’t driven by a desire for rewards, but by goodwill. Friction only gets in the way. If the friction is worth it, fine - but what exactly is being lost by moving the repository to GitHub?
  - Aachen 1y ago
    > what exactly is being lost by moving the repository to GitHub? Alternatives to github We lament Google's browser engine monopoly, but putting the vast majority of open source projects on github is just the expected course to take. I guess we'll repeat history once microsoft decides to set in the enshittification, maybe one day mobile OSes replace Windows and they're strapped for cash, who knows, but it's a centralised closed system owned by a corporation that absolutely adores FOSS I don't mind any particular project (such as this one) being in Github and I can understand that Mozilla chooses the easy path, they've got bigger problems after all, but it's not like there are no concerns with everyone and everything moving to github
    - deleted 1y ago
      [deleted]
    - deleted 1y ago
      [deleted]
    - lpln3452 1y ago
      Did you ever use the alternatives before GitHub took off? GitLab? It was awful. Slow, and paying for that kind of experience felt like a bad joke. It's much better now but it was borderline unusable back in the day. Or SourceForge, before Git was mainstream? Also terrible. GitHub succeeded because it quickly established itself as a decent way to host Git - not because it was exceptional, but because the competition had abysmal UX. Unlike other lock-in-prone services, moving a Git project is trivial. If GitHub loses its advantages due to enshittification, you just move. Case in point: Mozilla hopping on and off GitHub, as this article shows.
      - Philpax 1y ago
- rendaw 1y ago
  How can you judge the quality of people who don't contribute? They don't contribute, so what's there to judge?
  - fhd2 1y ago
    Not possible, but I have a comparison between projects on GitHub and projects not on GitHub (and generally more ceremony). A lot more contributions on GH, but the majority of them ignored guidelines and/or had low code quality and attention to detail. Just my anecdotal experience of course.
- arp242 1y ago
  I spent quite some time writing a patch for FreeBSD and Linux a few months ago, including getting to grips with their contribution process. Both patches have been ignored thus far. That's okay, I understand limited resources etc. etc. Will they ever be merged? I don't know. Maybe not. I'm okay with all of this, it's not a complaint. It's how open source works sometimes. But it also means all that time I spent figuring out the contribution process has been a waste. Time I could have spent on more/other patches. So yeah, there's that. It's certainly true that making the bar higher will reduce low-quality contributions, because it will reduce ALL contributions. (aside: FreeBSD does accept patches over GitHub, but it also somewhat discourages that and the last time I did that it also took a long time for it to get reviewed, although not as long as now)
  - struanr 1y ago
    Although I have certainly created pull requests before that have been ignored so not sure GitHub solves this problem.
    - arp242 1y ago
      GitHub PRs don't solve anything about that, but I wouldn't have to spend (waste) time figuring out the contribution process. At least I learned a few things writing the patches. I learned nothing of value dealing with git email or Phabricator. It's just work of the boring and tedious kind.
      - elric 1y ago
        Many projects have rules about what kinds of pull requests they accept. You would still have had to familiarise yourself with those rules, as well as the usual things like coding style, testing policies, etc.
        andybak 1y ago
        Surely the claim being made is that the overall effort was increased in this case. That makes sense to me. I guess you can debate "but by how much?" but it seems fairly clear that there is more friction than there would have been via Github PRs
- Philpax 1y ago
  I can say that I've chosen not to bother when submitting a fix requires me to stray away from GitHub, and doubly so when it doesn't use a PR/MR workflow. There are only so many hours in the day, and I don't have the patience to deal with unconventional workflows when there are other things I could be doing with my time. For projects that I'd be interested in being a long-term contributor to, this is obviously different, but you don't become a long-term contributor without first dealing with the short-term, and if you make that experience a pain, I'm unlikely to stick around. A big part of this is the friction in signing up; I hope federated forges become more of a thing, and I can carry my identity around and start using alternate forges without having to store yet another password in my password manager.
  - Handler9246 1y ago
    Sad we're at a stage where people don't contribute to free software projects because the service it's hosted on isn't the proprietary, corporate giant. "Friction in signing up" being a big part for you is also weird, considering basically all free software GitHub alternatives (Gitea, GitLab, Forgejo) support SSO via GitHub.
    - encom 1y ago
      Requiring a Microsoft account, and handing over my phone number is extreme friction in my book.
      - BenjiWiebe 1y ago
        Just checked, and it looks like my GitHub account is not linked to my Microsoft account, nor does it have my phone number. I just signed out and started the signup flow. It allows me to use an email on my own domain, and I got as far as verifying my email before I canceled the flow, and there hadn't been any requirement for phone number of Microsoft account yet.
- 7bit 1y ago
  So, you're saying that because they don't know to use A they are likely to also don't know enough to contribute to B? Being a good coder has absolutely no correlation to being good at using Mercurial.
  - bigstrat2003 1y ago
    > Being a good coder has absolutely no correlation to being good at using Mercurial. No, but being a good coder is strongly anti-correlated with being unable or unwilling to figure out Mercurial.
- arichard123 1y ago
  Hang on. If they are deterred, then by definition they are not valuable contributors. They have not contributed. If they have contributed, they were not deterred.
- pornel 1y ago
  The barriers may keep out low effort submissions*, but they also keep out contributors whose time is too valuable to waste on installing and configuring a bespoke setup based on some possibly outdated wiki. * contributors need to start somewhere, so even broken PRs can lead to having a valuable contributor if you're able to guide them.
- Aachen 1y ago
  Am I understanding you correctly that using github instead of a more obscure system where you might need to register a fresh account and find where the buttons are etc. raises the bar for contributions and so it's good to use github? Somehow I think you're holding the difficulty scale backwards!
- deleted 1y ago
  [deleted]
madeofpalk 1y ago
I absolutely gave up on trying to contribute a patch to Firefox because the combination of both gh and phabricator was too much for me. I struggled to understand how the two interacted with each other, and I didn't know how to 'update my branch/pr' and I eventually just gave up.
kgwxd 1y ago
Anyone that couldn't overcome those "hurdles" shouldn't even be filing bug reports, let alone modifying code.
noobermin 1y ago
I get moving to Github being a change but I'd imagine the real story is the move from mercurial to git, although I'd guess the the social considerations might have influenced the technical decisions.
lolinder 1y ago
With GitLab specifically as an alternative: GitLab made it very clear a few years ago that they weren't particularly interested in hosting large-scale free projects when they introduced the Open Source Program as the only path to using GitLab for FOSS. I've heard over and over again that this process is painful and not worth the effort, and it has a bunch of extra requirements that would likely be dealbreakers for Mozilla [0]: * "the Open Source Project does not, and does not seek to, generate profit from the sale or licensing of the Open Source Software to which the Open Source Project relates, or the sale of any services related to such Open Source Software;" * "The Open Source Project agrees not to (nor to authorize any third party to): ... (b) modify or create any derivative works of the GitLab Software ... (d) copy ... the GitLab Software" That last part is especially problematic for everyone: in order to use GitLab.com for a FOSS project you have to renounce your right to modify (or authorize others to modify) or to copy the FOSS version of GitLab. This might have just been lawyers adding boilerplate without thinking it through, but that in itself is evidence of a major problem at GitLab. So, GitLab is out. Aside from GitLab Mozilla could have chosen maybe Codeberg, but with the entire point being to remove barriers to new contributors it makes sense to go with the option that almost all such possible contributors are already on. [0] https://handbook.gitlab.com/handbook/legal/opensource-agreement/ https://handbook.gitlab.com/handbook/legal/opensource-agreem...
WhyNotHugo 1y ago
The move to GitHub is quite disappointing. For a foundation wanting to push an open Internet and open source, moving to a proprietary forge which stands against all its core values reflects very poorly on the entire community.

fhd2 1y ago

In my experience, most contributors who are deterred from contributing because they can't use GitHub aren't particularly valuable contributors. I'm sure there's exceptions, but I haven't seen any for non-trivial open source projects I've been involved in. I might even argue that it could be good to have a slightly higher bar to deter low quality one time contributors.

nicman23 1y ago
"gatekeeping good" no.
- 7bit 1y ago
  They are everywhere. It's like a plague.
- bigstrat2003 1y ago
  Declaring gatekeeping to be always and forever bad is an unhelpful, untrue thought-terminating cliche. A wide variety of situations can be described as "gatekeeping", and while some are nonsense some are very good to keep. It's bad if we say "you must be 6 feet tall to be a doctor", because that has nothing to do with being a good doctor. But requiring that doctors get a medical degree and pass certification requirements is also gatekeeping, and it would also be insane to do away with it. Any time you call gatekeeping bad for its own sake you are engaging in a gross oversimplification, and should stop.
berkes 1y ago
You just showed the poster-child of gatekeeping that is harming Open Source. Every contributor is valuable, it's in the name, the definition of "contribute". Any bar to entry is bad, it certainly never is the solution to a different problem (not being able to manage all contributions). If anything, in the longer run, it will only make it worse. Now, to be clear, while I do think GitHub is currently the "solution" to lower barriers, allow more people to contribute and as such improve your Open Source Project, the fact this is so, is a different and other problem - there isn't any good alternative to Github (with broad definitions of "good") why is that and what can we do to fix that, if at all?
- sneak 1y ago
  Not all PRs are created equal.
  - berkes 1y ago
    And that is good. Diversity, here too, is of crucial importance. It's why some Open Source software has sublime documentation and impeccible translations, while the other is technically perfect but undecipherable. It's why some Open Source software has cute logos or appeals to professionals, while the other remains this hobby-project that no-one ever takes serious despite its' technical brilliance.
  - myfonj 1y ago
    Also don't forget that not all contributions are done through PRs or are actual code changes. There are folks that do tests, make MREs, organise issue reports, participate in forums … they all are also contributing: their time and efforts.
- int_19h 1y ago
  This is just blatantly wrong on so many levels. Proposed contributions can in fact have negative value, if the contributor implements some feature or bug fix in a way that makes it more difficult to maintain in the long term or introduces bugs in other code. And even if such contribution is ultimately rejected, someone knowledgeable has to spend time and effort reviewing such code first - time and effort that could have been spend on another, more useful PR.
lpln3452 1y ago
Contribution isn’t driven by a desire for rewards, but by goodwill. Friction only gets in the way. If the friction is worth it, fine - but what exactly is being lost by moving the repository to GitHub?
- Aachen 1y ago
  > what exactly is being lost by moving the repository to GitHub? Alternatives to github We lament Google's browser engine monopoly, but putting the vast majority of open source projects on github is just the expected course to take. I guess we'll repeat history once microsoft decides to set in the enshittification, maybe one day mobile OSes replace Windows and they're strapped for cash, who knows, but it's a centralised closed system owned by a corporation that absolutely adores FOSS I don't mind any particular project (such as this one) being in Github and I can understand that Mozilla chooses the easy path, they've got bigger problems after all, but it's not like there are no concerns with everyone and everything moving to github
  - deleted 1y ago
    [deleted]
  - deleted 1y ago
    [deleted]
  - lpln3452 1y ago
    Did you ever use the alternatives before GitHub took off? GitLab? It was awful. Slow, and paying for that kind of experience felt like a bad joke. It's much better now but it was borderline unusable back in the day. Or SourceForge, before Git was mainstream? Also terrible. GitHub succeeded because it quickly established itself as a decent way to host Git - not because it was exceptional, but because the competition had abysmal UX. Unlike other lock-in-prone services, moving a Git project is trivial. If GitHub loses its advantages due to enshittification, you just move. Case in point: Mozilla hopping on and off GitHub, as this article shows.
    - Philpax 1y ago
rendaw 1y ago
How can you judge the quality of people who don't contribute? They don't contribute, so what's there to judge?
- fhd2 1y ago
  Not possible, but I have a comparison between projects on GitHub and projects not on GitHub (and generally more ceremony). A lot more contributions on GH, but the majority of them ignored guidelines and/or had low code quality and attention to detail. Just my anecdotal experience of course.
arp242 1y ago
I spent quite some time writing a patch for FreeBSD and Linux a few months ago, including getting to grips with their contribution process. Both patches have been ignored thus far. That's okay, I understand limited resources etc. etc. Will they ever be merged? I don't know. Maybe not. I'm okay with all of this, it's not a complaint. It's how open source works sometimes. But it also means all that time I spent figuring out the contribution process has been a waste. Time I could have spent on more/other patches. So yeah, there's that. It's certainly true that making the bar higher will reduce low-quality contributions, because it will reduce ALL contributions. (aside: FreeBSD does accept patches over GitHub, but it also somewhat discourages that and the last time I did that it also took a long time for it to get reviewed, although not as long as now)
- struanr 1y ago
  Although I have certainly created pull requests before that have been ignored so not sure GitHub solves this problem.
  - arp242 1y ago
    GitHub PRs don't solve anything about that, but I wouldn't have to spend (waste) time figuring out the contribution process. At least I learned a few things writing the patches. I learned nothing of value dealing with git email or Phabricator. It's just work of the boring and tedious kind.
    - elric 1y ago
      Many projects have rules about what kinds of pull requests they accept. You would still have had to familiarise yourself with those rules, as well as the usual things like coding style, testing policies, etc.
      - andybak 1y ago
        Surely the claim being made is that the overall effort was increased in this case. That makes sense to me. I guess you can debate "but by how much?" but it seems fairly clear that there is more friction than there would have been via Github PRs
Philpax 1y ago
I can say that I've chosen not to bother when submitting a fix requires me to stray away from GitHub, and doubly so when it doesn't use a PR/MR workflow. There are only so many hours in the day, and I don't have the patience to deal with unconventional workflows when there are other things I could be doing with my time. For projects that I'd be interested in being a long-term contributor to, this is obviously different, but you don't become a long-term contributor without first dealing with the short-term, and if you make that experience a pain, I'm unlikely to stick around. A big part of this is the friction in signing up; I hope federated forges become more of a thing, and I can carry my identity around and start using alternate forges without having to store yet another password in my password manager.
- Handler9246 1y ago
  Sad we're at a stage where people don't contribute to free software projects because the service it's hosted on isn't the proprietary, corporate giant. "Friction in signing up" being a big part for you is also weird, considering basically all free software GitHub alternatives (Gitea, GitLab, Forgejo) support SSO via GitHub.
  - encom 1y ago
    Requiring a Microsoft account, and handing over my phone number is extreme friction in my book.
    - BenjiWiebe 1y ago
      Just checked, and it looks like my GitHub account is not linked to my Microsoft account, nor does it have my phone number. I just signed out and started the signup flow. It allows me to use an email on my own domain, and I got as far as verifying my email before I canceled the flow, and there hadn't been any requirement for phone number of Microsoft account yet.
7bit 1y ago
So, you're saying that because they don't know to use A they are likely to also don't know enough to contribute to B? Being a good coder has absolutely no correlation to being good at using Mercurial.
- bigstrat2003 1y ago
  > Being a good coder has absolutely no correlation to being good at using Mercurial. No, but being a good coder is strongly anti-correlated with being unable or unwilling to figure out Mercurial.
arichard123 1y ago
Hang on. If they are deterred, then by definition they are not valuable contributors. They have not contributed. If they have contributed, they were not deterred.
pornel 1y ago
The barriers may keep out low effort submissions*, but they also keep out contributors whose time is too valuable to waste on installing and configuring a bespoke setup based on some possibly outdated wiki. * contributors need to start somewhere, so even broken PRs can lead to having a valuable contributor if you're able to guide them.
Aachen 1y ago
Am I understanding you correctly that using github instead of a more obscure system where you might need to register a fresh account and find where the buttons are etc. raises the bar for contributions and so it's good to use github? Somehow I think you're holding the difficulty scale backwards!
deleted 1y ago
[deleted]

madeofpalk 1y ago

I absolutely gave up on trying to contribute a patch to Firefox because the combination of both gh and phabricator was too much for me. I struggled to understand how the two interacted with each other, and I didn't know how to 'update my branch/pr' and I eventually just gave up.

kgwxd 1y ago

Anyone that couldn't overcome those "hurdles" shouldn't even be filing bug reports, let alone modifying code.

noobermin 1y ago

I get moving to Github being a change but I'd imagine the real story is the move from mercurial to git, although I'd guess the the social considerations might have influenced the technical decisions.

lolinder 1y ago

With GitLab specifically as an alternative: GitLab made it very clear a few years ago that they weren't particularly interested in hosting large-scale free projects when they introduced the Open Source Program as the only path to using GitLab for FOSS. I've heard over and over again that this process is painful and not worth the effort, and it has a bunch of extra requirements that would likely be dealbreakers for Mozilla [0]: * "the Open Source Project does not, and does not seek to, generate profit from the sale or licensing of the Open Source Software to which the Open Source Project relates, or the sale of any services related to such Open Source Software;" * "The Open Source Project agrees not to (nor to authorize any third party to): ... (b) modify or create any derivative works of the GitLab Software ... (d) copy ... the GitLab Software" That last part is especially problematic for everyone: in order to use GitLab.com for a FOSS project you have to renounce your right to modify (or authorize others to modify) or to copy the FOSS version of GitLab. This might have just been lawyers adding boilerplate without thinking it through, but that in itself is evidence of a major problem at GitLab. So, GitLab is out. Aside from GitLab Mozilla could have chosen maybe Codeberg, but with the entire point being to remove barriers to new contributors it makes sense to go with the option that almost all such possible contributors are already on. [0] https://handbook.gitlab.com/handbook/legal/opensource-agreement/ https://handbook.gitlab.com/handbook/legal/opensource-agreem...

WhyNotHugo 1y ago

The move to GitHub is quite disappointing. For a foundation wanting to push an open Internet and open source, moving to a proprietary forge which stands against all its core values reflects very poorly on the entire community.