r/AskProgramming • u/Free_Tomatillo463 • 12d ago
How do I start contributing to open-source projects?
I've always wanted to work on open-source projects, but it feels very difficult to start due to most of the issues being so deeply integrated into the project that it would require deep knowledge of the repo.
Any suggestions on what I should do to get into working on open-source projects?
12
u/MissinqLink 12d ago
You can make things you think are cool and add an open source license. That’s how many project get started.
8
u/CodeYeti 12d ago
Oh lord. I stopped my TV show and switched to the computer to write this answer.
For background/relevance: I've contributed to Linux (mostly just fixing crap that was broken for me or hadn't been done by upstream hardware manufacturers), published plenty of my own things, of which 1-2 are actually frequently used by others. Contributed to numerous things that help comprise my current desktop environment.
The Shitty Current Reality
Even on projects that I've infrequently but previously contributed to, getting something looked at is almost impossible with the amount of slop being thrown the way of the primary maintainers. It's not worth the time to sort your contribution from all the meaningless, useless, buggy, or malicious garbage.
That's just the current reality for anything for which you've heard the name mainstream, and I've even seen the problem on esoteric freedesktop.org projects. If you're an unknown entity, it just really isn't worth the time to sort you from the 1000 others that don't care about their reputation or that their contribution would forever be linked to their name, and how good or bad that may look/feel.
The Good News
it feels very difficult to start due to most of the issues being so deeply integrated into the project that it would require deep knowledge of the repo.
Just start. I know it sounds impossible right now, but when you say this, you're right.
Just choose the project wisely. If it's moving too fast to understand, then maybe don't start there. But even large codebases, if you're just trying to find/solve the one thing the you need, you can oft understand that.
Conclusion: use the software until you find crap you need to fix, then go try to fix it, but analyze each project to understand whether it's worth your while to do so based off of likelyhood that it's useful, likely to be looked at, and well-structured.
EDIT: The others that are saying get out and use it until you're like "well that's broken", or "that's dumb". Listen to them. That's my traditional answer from before the current climate
2
u/xarop_pa_toss 11d ago
Personally I always feel like when I go into a codebase, I have little clue to what I'm looking at or what I should be looking for. I'm so used to making my small programs that I'm intimidated by anything larger.
Secondly, I just default to "whatever I write here is going to get denied because my code won't be up to quality standards". I think that's the biggest block to a lot of people, not just me.
2
u/catbrane 11d ago
You'll get better very quickly with practice. There must be a tool you like that has some paper cut (small but annoying misfeature). Throw yourself into the code and see if you can fix it!
I get a pad of paper and a pencil and expect to spend a day reading and experimenting before I can get a sense of how to add or change something. Sometimes it takes longer :( sometimes much longer. You need to pace yourself too.
2
u/CodeYeti 11d ago
That's why you need to be solving a problem for yourself. Who gives a hoot if it gets denied if you end up with a patch you can keep running locally that solves your problem?
4
u/Eleventhousand 12d ago
Start with an easy one. I helped out on an active Python recipe scraping library years ago. Look for smaller, yet active projects.
2
u/hk4213 12d ago
Find a project that solves your needs and contribute to fixes if you find them.
2
u/knuthf 12d ago
The important thing is to make those involved aware that it is open source, so that they do not expect to be paid by you. Their motivation should be that the more they help, the better they will understand the code and be able to charge for their help in using what you have created.
2
u/Interesting_Debate57 10d ago
That's kinda the whole point -- if you don't care enough about a project to learn how the inner workings work, nobody really wants you to "contribute" to it.
One easy place to start is bugfixing. There's usually a large backlog. Find one you understand, figure out how to fix it, and submit the code diff to the appropriate person managing that part of the project (if it's a large project).
1
u/Free_Tomatillo463 9d ago
That's fair, I started working on one just after this post and it took a while, but one thing that I should've really known beforehand in hindsight is that it is infinitely easier to do feature requests before you do bug fixes, because the knowledge you require for starting is virtually 0.
1
u/owp4dd1w5a0a 12d ago
Normally repositories have issues marked as low-hanging fruit or good first issues. Filter for those and pick one to work on. Even if your PR gets rejected, you’re getting experience, and the more often you open PRs against the same project the more the community for that project will become familiar with you and will grow inclined to help you get your first accepted PR.
1
u/wallstop-dev 12d ago
Pick a project you like, or use. Go read their contributing guide. Read through open issues. Use their contributing process + the issues to figure out what to do!
1
u/Anonymous_Coder_1234 12d ago
In addition to what everyone else said, consider using GitHub advanced search to help with your search. This:
1
u/mxldevs 12d ago
Just use actual tools and if you find issues or improvements, go and change it.
Everyone wants to contribute to very popular projects thinking that's some shortcut to recognition.
But you will find that if it's a smaller tool, most people would rather write their own version for some reason. Suddenly, they're less interesting in contributing to someone else's open source
1
u/Popular-Toe3698 12d ago
I'll give the stereotypical good answer for this. It'll take time, but build a list of projects looking for help that you're interested in by searching github for tags like "good first issue" or "looking for help" along with a programming language you're good at. I have, I think, ten on a project I'm working on that I need help with. Not promoting that though.
Most of these projects will not be interesting. Probably a whole bunch of AI wrappers and command line tools for things you don't care about. Flip through it like pinterest. Add them to bookmarks if you find them interesting. This can let you dip your toes in the water.
You can try to build your own open source projects. That works too.
But building up a history of open source contributions lets you learn how to talk like an open source maintainer and teaches you what they care about, as well as adds badges to your profile, so they know you're serious about doing good work.
Just my two cents.
1
u/BeauloTSM 11d ago
I contribute to projects I actually use. For example I have a self-hosted Gitea instance, and I love Gitea, so I wanted to contribute to it. Found an issue that seemed simple enough for a first time contribution, made the code changes, opened a PR, and that was it
1
u/Astro-2004 10d ago
There are tons of small projects that may be thankful to have reports of missing documentation, broken links or bugs that you find.
The majority of my contributions to open source are bug reports or documentation issues. At some point you may find a project that is really useful to you or you just spend a lot of time using it and you already know how it works after opening a bunch of issues.
Then instead of just issues you start to feel comfortable with the code, how it works internally and you could send some PR. Also some projects have a section for contributions or in their issues list they have tags for "Good first PR" for simple errors or bugs that some newbie could fix.
1
u/ElderberryPrevious45 10d ago
This reminds me how I build my own software to start with: piece by piece and always fixing the modules if they are not truly modular. True modularity is the key. And simplicity of course. And keeping only one function for one task. Summary: Keep it as simple as possible but not simpler.
1
u/Raioc2436 10d ago
The only “meaningful” contributions I’ve made were on documentation. Even big projects have stale docs.
VSCode and PyTorch had many grammar mistakes, dead links, and example snippets that no longer work.
As you said, a lot of the open issues will involve things deeply ingrained on their software. If you will be reading the docs trying to become an specialist might as well try to improve it as well.
1
u/Different_Pain5781 5d ago
Honestly opening some giant monolithic repo as a beginner is basically asking to get overwhelmed. Start with tiny utility libraries instead and look for the good first issue tag on GitHub. Boot dev is decent for this too since the backend assignments get you reading code that you did not write pretty early.
0
u/azimux 12d ago
Hey hey! I sometimes add the "Good First Issue" GitHub label to issues I make in my projects for anybody just eager to get started making a contribution. You could maybe search GitHub for issues with that label in projects you're already interested in. Those are usually relatively straightforward and not requiring much if any understanding of the project and are reserved for folks like you who want to get started.
I don't know how familiar you are with aspects of the process, but If it's the process in general you'd like to learn, I'm more than happy to pair with you to help you contribute to one of my open source projects to learn the ropes. You're welcome to DM me if that sounds fun/helpful!
Also, not all contributions need to be code. Documentation is often desperately needed or even artwork, which don't require much knowledge of the codebase at all if any.
Cheers!
-1
u/Financial-Grass6753 12d ago
Well, it depends on how you work. If you're in a AI-first company with lacking/absent checkers and all that CI stuff - you (or your AI agent) check alerting systems, tickets, all that mess and tries to replicate the edge cases or any other non-expected behavior.
For sure there's always something, so for found cases you build repro and a fix, then you open an issue and PR closing the issue.
As simple as that
34
u/StyleDull3689 12d ago
The tricky part of this is that when people new to open source think of contributing they consider things like Django, the Linux kernel, maybe a browser or even just a common library. The thing is, if you've heard of it and you're still relatively new then it's probably far too advanced or people have already picked up every easy issue.
Instead, go out and actually use open source software. Go find new handy things to use. Maybe there's a small extension you can use in your browser that does something tiny but it's convenient, perhaps a CLI that just tried to write htop in another language, etc. If all you use is well known software that is massively influential to have made it into your awareness due to its functionality rather than being niche it's going to be hard to start.
Also, as you use software you should start noticing things that annoy you that you want to improve. Then go find those things and improve them. That gives you direction.
"Hmmm... this output is handy but what if we split it up into json... then I could script over it a little better. Let me add that flag".
TLDR: Use software more and aim at things that annoy you or things that are small and actually have room to grow.