←back to thread

848 points thefilmore | 1 comments | | HN request time: 0s | source
Show context
floriangosse ◴[] No.43970232[source]
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.

replies(6): >>43970680 #>>43971628 #>>43971800 #>>43972174 #>>43972919 #>>43983811 #
fhd2 ◴[] No.43970680[source]
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.
replies(11): >>43970739 #>>43970819 #>>43970821 #>>43970824 #>>43970955 #>>43971022 #>>43971133 #>>43971148 #>>43971264 #>>43971283 #>>43971354 #
berkes ◴[] No.43970739[source]
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?

replies(4): >>43970756 #>>43970880 #>>43971139 #>>43971646 #
fhd2 ◴[] No.43971139[source]
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.

replies(1): >>43971529 #
1. arp242 ◴[] No.43971529[source]
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.