Hacker News Reader

Comment by floriangosse | Hacker News Reader

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.

View on HN

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.

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?

Not all PRs are created equal.

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.

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.

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.

lol go closed then

This isn't a platform issue — it's a problem with the PR system, and arguably with open source itself. If you're unwilling to spend time on anything beyond writing code, maybe keep the project closed-source.

Or, more obviously, make it open-source, and make a big fat note in the README of "I will not accept PRs, this repo is just for your consumption, fork it if you want to change it".

It's not a binary. Many projects do want PRs, but it doesn't mean they have to accept any random PR, or fawn over every contributor who creates an obviously low-effort one. It's perfectly fine to "gatekeep" on quality matters, and that does mean acknowledging the fact that not all contributors are equally valuable.

> fawn over every contributor who creates an obviously low-effort one

It's that sense of superiority that pisses me off.

Many maintainers condescendingly reply "contributions welcome" in response to user complaints. People like that had better accept whatever they get. They could have easily done it themselves in all their "high quality" ways. They could have said "I don't have time for this" or even "I don't want to work on this". No, they went and challenged people to contribute instead. Then when they get what they wanted they suddenly decide they don't want it anymore? Bullshit.

You're making the assumption that these are "high quality" projects, that someone poured their very soul into every single line of code in the repository. Chances are it's just someone else's own low effort implementation. Maybe someone else's hobby project. Maybe it's some legacy stuff that's too useful to delete but too complex to fully rewrite. When you dive in, you discover that "doing it properly" very well means putting way too much effort into paying off the technical debts of others. So who's signing up to do that for ungrateful maintainers for free? Who wants to risk doing all that work only to end up ignored and rejected? Lol.

Just slap things together until they work. As long as your problem's fixed, it's fine. It's not your baby you're taking care of. They should be grateful you even sent the patches in. If they don't like it, just keep your commits and rebase, maybe make a custom package that overrides the official one from the Linux distribution. No need to worry about it, after all your version's fixed and theirs isn't. Best part is this tends to get these maintainers to wake up and "properly" implement things on their side... Which is exactly what users wanted in the first place! Wow!

> People like that had better accept whatever they get.

FOSS maintainers are not a unified mind. The people who go "contributions welcome" and "#hacktoberfest" are somewhere near one end of the spectrum, and the folks dealing with low-effort contributions are somewhere near the other end of the spectrum.

Of course not. That's why I singled out a very specific kind of maintainer: the type who thinks himself superior to users even when they engage at their level. Guys so good they can't be bothered to do it themselves but complain when others do it.

Good maintainers may be firm but they are always nice and grateful, and they treat people as their equals. They don't beg others for their time and effort. If they do, they don't gratuitously shit on people when they get the results. They work with contributors in order to get their work reviewed, revised and merged. They might even just merge it as-is, it can always be refactored afterwards.

That's hard to do and that's why doing it makes them good maintainers. Telling people their "contributions are welcome" only to not welcome their contributions when they do come is the real "low effort".

> People like that had better accept whatever they get.

no, I am not obligated to merge badly written PRs introducing bugs just because I had no time to implement the feature myself

Let all those "bad PRs" with useful features and fixes accumulate at your own peril. You might wake up one day and find you're not upstream anymore because someone else has merged them all into a fork. I've seen it happen.

You seem to assume that in all cases such situation would be a problem.

In fact it not always is a problem. For some I would love if someone else would maintain it, for some fork is friendly and has a bit different purpose and so on.

> Just slap things together until they work. As long as your problem's fixed, it's fine. It's not your baby you're taking care of. They should be grateful you even sent the patches in.

Thank you for a clear and concise illustration of why some contributions are really not welcome.

Just about the only thing I will agree with you on is that projects should indeed make it clear what the bar for the proper contribution is. This doesn't mean never saying "contributions are welcome", if they are indeed welcome - it's still the expectation for whoever is contributing to do the bare minimum to locate those requirements (e.g. by actually, you know, reading CONTRIBUTING.md in the root of the repo before opening a PR - which many people do not.)

Making things clear and being honest about the scope and status of the project is always a good thing.

Dismissing users making feature requests and reporting bugs with a "PRs welcome" cliche is quite disrespectful and very much a sign of a superior attitude.

It's not wrong, it's just based on the assumption that the projects wants contributors.

Quite obviously, any incidental friction makes this ever so slightly harder or less likely. Good contributions don't necessarily or only come from people who are already determined from the get go. Many might just want to dabble at first, or they are just casually browsing and see something that catches their attention.

Every projects needs some form of gatekeeping at some level. But it's unclear to me whether the solution is to avoid platforms with high visibility and tools that are very common and familiar. You probably need a more sophisticated and granular filter than that.

> Many might just want to dabble at first, or they are just casually browsing and see something that catches their attention.

You can easily craft an email for that. No need to create a full PR.

"Crafting an email" in the format required by many email-based projects is hardly easy for the average user, who's most likely using a webmail service that does not have much control over line wrapping and the like. Accepting patches in attachments (instead of the email body) helps with this, but naive users can still easily get caught by using HTML email, which many project maintainers love to performatively turn up their noses at.

It is not wrong.

For one, it's semantic: It's only a contribution if it adds value to a project.

What you probably mean is that "not everything handed to us is a contribution". And that's valid: There will be a lot of issues, code, discussions, ideas, and what more that substract, or have negative value. One can call this "spam".

So, the problem to solve, is to avoid the "spam" and allow the contributions. Or, if you disagree with the semantics, avoid the "negative value contributions" and "allow the positive value contributions".

A part of that solution is technical: filters, bots, tools, CI/CD, etc. Many of which github doesn't offer, BTW. A big part is social and process: guidelines, expectations, codes-of-conduct, etc. I've worked in some Open Source projects where the barriers to entry where really high, with endorsements, red-tape, sign-offs, wavers, proof-of-conducts etc. And a large part is simply inevitable "resources". It takes resources to manage the incoming stuff, enforce the above, communicate it, forever, etc.

If someone isn't willing to commit these resources, or cannot, then, ultimately, the right choice to make is to simply not allow contributions - it can still be open source, just won't take input. Like e.g. sqlite.

In spirit, I agree.

In practice, if you get dozens of PRs from people who clearly did it to bolster up their CV, because their professor asked them or something like that, it just takes a toll. It's more effort than writing the same code yourself. Of course I love to mentor people, if I have the capacity. But a good chunk of the GitHub contributions I've worked on were pretty careless, not even tested, that kind of thing. I haven't done the maintainer job in a while, I'm pretty terrified by the idea of what effect the advent of vibe coding had on PR quality.

I feel pretty smug the way I'm talking about "PR quality", but if the volume of PRs that take a lot of effort to review and merge is high enough, it can be pretty daunting. From a maintainer perspective, the best thing to have are thoughtful people that genuinely use and like the software and want to make it better with a few contributions. That is unfortunately, in my experience, not the most common case, especially on GitHub.

In my experience low-quality PRs aren't that common, but I do agree dealing with them is annoying. You can't just tell people to go away because they did spend their spare time on it. On the other hand it's also garbage. Sometimes it's garbage by people who really ought to know better. IMHO low-quality issues are the bigger problem by the way, a problem that existed well before GitHub.

But I just don't see how GitHub or a PR-style workflow relates. Like I said in my own reply: I think it's just because you'll receive less contributions overall. That's a completely fair and reasonable trade-off to make, as long as you realise that is the trade-off you're making.

> Every contributor is valuable, it's in the name, the definition of "contribute".

No. I definitely seen people who created multitude of misleading bug reports, flood of stupid feature requests. I personally did a bit of both.

There are people who do both repetitively, fill issue reports without filling requested fields. Or open issue again when their previous report was closed.

I got once bug report where someone was ranting that app is breaking data. Turned out (after wasting my time on investigating it) that user broke data on their own with different software, through its misuse.

There were PRs adding backdoors. This is not a valuable contribution.

There were PRs done to foment useless harmful political mess.

Some people pretend to be multiple people and argue with themselves in pull requests or issues (using multiple accounts or in more bizarre cases using one). Or try to be listed multiple times as contributor.

Some people try to sneak in some intentionally harmful content one way or another.

Some contributors are NOT valuable. Some should be banned or educated (see https://www.chiark.greenend.org.uk/~sgtatham/bugs.html ).

This can be categorized as "spam".

Fighting spam isn't done by using unfamiliar tech, but by actually fighting the spam.

With good contributor guidelines, workflows, filters, etc.

Contributions that don't adhere to the guidelines, or cannot fit in the workflow can be dismissed or handed back.

Two random examples of things I came across in PRS recently:

"Sorry, this isn't on our roadmap and we only work on issues related to the roadmap as per the CONTRIBUTION-GUIDELINES.md and the ROADMAP.md"

"Before we can consider your work, please ensure all CI/CD passes, and the coding style is according to our guidelines. Once you have fixed this, please re-open this ticket"

That is fine, a solved problem.

Using high barrier tech won't keep intentionally harmful contributions away. It won't prevent political mess or flamewars. It won't keep ranters away. It won't help with contributors feelings of rejection and so on. Good review procedures with enough resources, help prevent harmful changes. Guidelines and codes of conduct and resources and tech to enforce, help against rants, bullying or flamewars, not "hg vs git". Good up-front communication on expectation is the solution to people demanding or making changes that can never be accepted.

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?

> 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

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.

I believe GitLab post-dates GitHub, but I otherwise agree with the sentiment.

You're right. But as far as I remember, neither GitHub nor GitLab were really mainstream at the time.

I think the real competition began around the same time.

> Unlike other lock-in-prone services, moving a Git project is trivial.

not really

just moving issue tracker and discussions is highly annoying

trying to get your users to move is likely hard and you will lose many

still, may be easy in comparison

The number of emails I get "Your website is vulnerable to clickjacking attacks, PS. how much bounty have I earned?" suggests that there are many for whom a desire for literal rewards is their sole driver.

Not to mention the AI-generated security "issues" that are reported against curl, for example, suggests there can indeed be negative value for reports, and contributions.

You're right. And that's not an issue with any particular platform, but with open source projects that accept issues and PR in general.

I don't think this is the place for a debate about the overall utility of open source.

> but what exactly is being lost by moving the repository to GitHub?

Contributors who can't use GitHub because either 1) they are fresh and can't activate a new account 2) their old grandfathered account is no longer usable or 3) their old account id doxxed and they can no longer safely contribute under the old identity.

Once you trigger phone-number verification requirement your account is globally shadowbanned and support blocked pending SMS code verification. Aside from the privacy issue it's completely blocking people in countries to which GitHub won't even try to SMS/call.

Remember that registering a second account would be violating GitHub ToS.

How can you judge the quality of people who don't contribute? They don't contribute, so what's there to judge?

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.

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)

Although I have certainly created pull requests before that have been ignored so not sure GitHub solves this problem.

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.

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.

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

Dealing with github is the boring and tedious thing, you have to run huge amount of proprietary javascript, keep up with their weird UX changes, start X11 to open a browser to render their html, overclock your CPU for a large PR review conversation to scroll without locking up your computer for minutes, constantly click "load more" since their webpage keeps hiding comments (while still lagging massively)...

Email is simple. It's just text, there's no weird javascript or html or lag. I don't have to open X11. I can just open mutt and read or write. I can type "git send-email". It's all open source, so I can read the code to understand it, and write scripting around it. It runs on any computer with ease. Even on a slow connection, it's quite speedy.

I totally agree with you about Phabricator though.

"Boo hoo I need to start X11"? Seriously?

I have some unconventional workflows. And I try not to bother anyone else with it, especially in a volunteer driven open source context. It would be selfish to do otherwise.

To be honest based on what you've written here, keeping you out of my projects sounds like a good thing. What a bunch of piss and vinegar over how other people are choosing to work in a way that works for them.

Starting X takes forever on his PDP11. Only real way to run Unix.

It's not true that you need to start X11. GitHub's UI renders pretty well under Wayland.

Use the GitHub CLI.

You can do nearly everything the website does entirely in the terminal.

So you can compile and test your changes to Firefox without starting X11 or “overclocking your CPU” but you can’t use a simple website?

In all likelihood, if the patch had been a pull request, the pull request would have been ignored as well. Much like the thousands of pull requests that are often ignored by various larger open source projects. Ain't nobody got time to triage drive-by pull requests from unknown contributors, especially on large projects.

There's no easy solution. Much like the recent curl security kerfuffle, the signal:noise ratio is important and hard to maintain.

I think the OP's point here was that if it's a PR and it's ignored: you spent a bunch of time writing a PR (which may or may not have been valuable to you, e.g. if you maintain a fork now). On the other hand, if it was an esoteric contribution process, you spent a lot of time figuring out how to get the patch in there, but that obviously has 0 value outside contributing within that particular open source project.

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.

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.

Requiring a Microsoft account, and handing over my phone number is extreme friction in my book.

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.

"gatekeeping good"

no.

They are everywhere. It's like a plague.

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.

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.

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

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.

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.

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!

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.

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

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.

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.

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

Reply on news.ycombinator.com