←back to thread

848 points thefilmore | 2 comments | | HN request time: 0.43s | 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 #
int_19h ◴[] No.43970880[source]
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.

replies(5): >>43971030 #>>43971106 #>>43971168 #>>43971533 #>>43983703 #
dgb23 ◴[] No.43971533[source]
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.

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

replies(1): >>43973714 #
2. LegionMammal978 ◴[] No.43973714[source]
"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.