Iβm working on a project to help beginners get started on contributing open source projects.
Itβs called First Contributions
...
For further actions, you may consider blocking this person and/or reporting abuse
Hi Roshan,
what blocks me from contributing to open source projects is a really good question!
My first blocks consisted of fears (i.e. to be negatively judged by others).
"fears and solutions" (there may be better names for the topic for sure) will be a good topic to add at the bottom.
I imagine some points like
Such points would help first-time-contributors to overcome such fears and just start right away based on your simple but effective list :)
What usually stops me are experiences in the past of simple PRs sitting unreviewed for months on end. I don't have a ton of free-time, so I get anxious thinking about spending several hours creating a worthy PR, just to have it completely ignored by the package author.
I'm not entirely faulting the package author, as I'm certain they're busy with their own work, but it certainly is a frustrating experience. I don't know how to fix it either.
I understand this. I've been there too. I guess the only way out of this is to check if the project is still active before submitting pull request. Like checking the date of the last commit, commenting on the issue and starting a conversation going before putting in effort to make changes and submit pull request.
Although I think, that developing the source for a PR is also a good exercise in working with unknown code and worth the while (if it isn't tooooo time consuming). And if the code is presumably dead, you could adopt it, if you feel to.
I've had this as well. When you try and contribute to solve a problem in the code, but the maintainer has silently decided not to work on it any more. I ended up fixing a bug that was in the bug tracker. There was no way to commit except save the patch against the bug. There is stayed without being committed or even reviewed. The means the last version was two years old. You are left building your project against your internal fork. At no point did the maintainer offer to hand it off to people who continued to actively develop against it.
My other pet peave is the way projects expect their users to log into their bug tracking system in order to report a defect. Several times I've found issues, tried to report them, only to give up.
Another variant of this problem is having defects closed as 'won't fix', or 'duplicate', only to find a stream of people reporting the same issue over years. Showing disinterest in users issues is a good way to also discourage deeper involvement such as contributions.
My biggest challenge is to find a small enough project that I can contribute to. Most projects I see around are huge projects that would take weeks for me to understand what's going around.
I'm a game developer and it's kind of hard to embed myself into non-game-engine projects. In this step it becomes very important to find a very clear setup document that would bypass the struggle of even being able to run the project as it is.
Iβm pretty new to coding so what blocks me is not really knowing what Iβm doing. I wouldnβt want to mess up someoneβs code and then theyβre upset. So for me itβs learning how to contribute to an open source project in the first place.
You wouldn't be messing up anything. You can't directly make changes to others' projects. You can suggest changes called pull requests. It's the maintainers discretion to accept that change or not.
Oh good Iβll have to start. I hear itβs a great way to learn.
Figuring out how the different licenses work, how they might affect my research in the future, how it might affect my company, and how it might affect my future projects is always a confusing thing to navigate. It is not something I want to directly deal with when contributing code.
My biggest blocker is the fact that when I get assigned to a new project at work, it always takes me a few weeks to really figure it out--where everything is, what the goals of the project are, what unwritten conventions might exist around a given piece of code, why things are the way they are. In the open source world, that's a lot of time and effort to put in for what usually ends up being a one-off contribution to someone else's project.
Definately not the technical part. Some were more abandoned than alive, some didnt even had a contributing file on how to setup the project (and I did a PR with it), some have their own strict vision on the project (which u dont find until they reject your PR).
Problem is that there are too many open source projects, but obly a few really looking and have time to manage contributors.
Juniors from what I saw were afraid and thinking they are not worthy or just think is too complicated.
This is a very important point. Also something we wanna tackle as part of this effort. We're trying to reach out to more project maintainers to make their project easier to contribute to.
I guess one of the important things is to have conversations with maintainers before submitting pull request. That way you can avoid working on abandoned projects and requesting changes maintainers are not on board on.
Well blockers for me are mainly the fact that if I want to make a good contribution to the project, I'll have to look around the codebase to get a feel for what they're doing. Even cloning and playing around with it, and that takes time cuz I'm not the type that has an intuitive feel for how software works.
I can say that my experience with OSS has been a great one overall in comparison to other stories I've read but yeah I'm trying to level up my skills in some technology to make better contributions to a project, cuz just fixing typos on the docs or the Readme won't cut it for me.
Like many others, the only reason I didn't contribute at first was the anxieties of being judged, or otherwise irrationally thinking I didn't have what it takes. But everyone else can talk of that. I'm beyond those days now; here's what stops me nowadays:
I personally am turned off very fast when the CONTRIBUTING.md is overly complicated. Take Atom's for example... I don't have time for that. At the same time I'm sure there are reasons to have such complex instructions. Maybe it's just me.
A lot of other projects can seem really unwelcoming to contributors, too. For example, I don't have ANY motivation to get involved with Git nor the Linux kernel, because of Torvalds' attitude towards his developers (just look at this)
Another reason, in some projects there appear to be little to no quality control on pull requests, i.e. the maintainers seem to accept literally anything, causing so many problems with the codebase/project that it feels overwhelming to bother contributing.
Time. Between learning stuff for job, managing time spent on job and then having some left for life (relationship, religion, my own projects which end up being deleted) I have no time to find the project that I might contribute to. Last time I tried to find a project which could potentialy have some code that needs bug fixing or additional feature I found only JS projects which required me to download them and check what are they actually about. Would love to contribute to Java/C# projects or even Groovy/Scala but latter are things I would like to learn not what I can actually contribute.
I generally feel confident enough in my abilities as a developer to make good contributions to open-source. What gives me pause is getting well-acquainted enough with a medium-to-large-sized project to make useful contributions. In a word, time.
Time.. Or lack thereof
In one word: Time!
For me, it's mainly domain knowledge, setup, response rate / attitude.
Helpless maintainers and helpless community will block you in every way you want to contribute.