Hacker News Reader

Comment by newswasboring | Hacker News Reader

Does anyone else find the sentiment of this post a bit... gatekeep-y? The way I read it, the author discourages people from just going out and trying to contribute to a random project. The reason given is because you would be bad at it as you don't know anything. But then the author gives the example of maintaining an AUR package and they got it to work because they needed it. From my point of view both these paths lead to the same result, a person arrives at a project with objectives they don't have the skills to build. (Unless the argument is to only try to contribute when you have all the skills needed, and that is just straight up gatekeeping).

Edit: Spelling and typos

View on HN

I think you are misunderstanding his rationale and message.

The message, the way I read it, isn't just that you don't know the random project, but you don't really care about it. He says to not just bring a brick, but to build a great school. The AUR example is relevant, because it is a problem you (he) cares about and continues to nurture, not just add a brick/PR and leave.

It's not gatekeepy because it doesn't say "don't contribute". It says "contribute to something you care about and want to succeed, where you will put in more effort than just a one-off, for the sake of the project and not for the sake of learning".

Most projects can find use for a junior developer contributing consistently if the dev will learn the project and domain. It's not gatekeeping.

The difference between those examples is that the author already had experience with that software package, and presumably already knew at least a little bit about what taking on maintainership of its packaging would entail.

A drive-by contributor who "wants to get into open source" will often have no experience with a particular project, and may not even have used the software before. People like that don't have the necessary context to start contributing, and their first (and sometimes only) PR is more likely to be counter-productive noise.

I don't get this. People who don't use the software can't hack on it? Since when did software engineering not get repetitive? I have contributed to langchain, for example, without ever doing as much as an "import langchain" outside of debugging. I feel like people are making a heuristic out of negative recall bias here. And why I am so concerned is, it destroys an entire gateway into open source. An entire gateway which is pretty common for people from developing countries. They don't have local mentors, open source would probably be the first time they will have access to real programmers (I've personally been there).

I found the article to be terrible, and his school building analogy falls flat on its ass. Both junior and senior developers can and should contribute to open source, for a variety of good reasons and there are good ways to go on about it.

I don’t think the article is terrible, but it does lean on that analogy a little bit too much IMO. It is worth inspecting where schools and programs differ.

If you could clone a school essentially for free, and also a poorly constructed school was not at risk of killing a bunch of kids, I guess we’d be much less skeptical of amateurs building schools.

I do think people write programs best when they are the primary audience, so the idea of just, like, going around with the explicit intent of finding open source projects to contribute to seems a bit misguided. But the stakes are not very high. If nothing else I imagine most open source projects must be able to ignore non-useful contributions, right?

I think you missed the point, and didn't actually read (or, more charitably, understand) what the author said. Your last sentence is actually a good summary of the article!

The problem is when someone wants to contribute primarily because they think it will be good for their resume, or even just for a more amorphous "I feel like I should give back" type reason. These sorts of motivations often result in contributions that end up being a drag on a maintainer's time, with little upside. People coming at it from this angle usually don't become dedicated contributors who grow and improve over time. They become a time and energy sink.

I've unfortunately witnessed this firsthand many times in my 20+ years of open source involvement.

It's more that I don't agree with what he considers the four or so proper ways to contribute. I also know of longstanding and highly valued contributors who started out in ways the author disapproves of.

why are we inspecting the intentions of the contributor so much? Why do we need to show this piousness in our reasons to get a PR merged? Don't you see the unnecessary barrier here?

Edit: Changed author to contributor as it can be confused as the author of the article.

Did you read the last 2/3 of the article?

I don't know that gate keeping is the right word, but I think it's doing a lot in the way of speaking for a number of projects (near infinity) that the author can't possibly represent. I comaintain a piece of infrastructure software that is fairly complicated - it fits the analogue of a commercial building. Setting some arbitrary bar for when to commit would frankly put just a few of us ever working on the project. When newcomers have a thing they want to do we spend a while talking it out in issue comments, then we modify that strategy on the actual PR as needed. To be quite honest, there are parts of this codebase I forget the nuance about all the time, so I'm really only a step or two more familiar than someone that knows the language and can write to the problem they desire to fix at any given time.

Most of my job is reasoning about, "should this feature be in this project" and maintaining some bar for quality in merges. I can always push the latter along if worse comes to worse.

Reply on news.ycombinator.com