How to start contributing to open source?
I have never contributed to open source but would like to start doing so. I believe this will make a huge difference in landing big tech jobs. Would like some references, steps, directions for beginners to get started in this journey.
Discussion
(7 comments)- 20a month agoMid-Level Software Engineer at Startup Company
Hello :) I've recently made several contributions to
react-native-video, even making it into the top 100 contributors list, and I was in the same position as you—never having contributed to open source before. Here's a repeatable approach I found helpful:Find a Feature You Need 🎯
I recommend you start with a feature you personally need. For me, it was the ability to handle
webvttsubtitles in mobile video players for overlaying data. I say this because, before I had contributed, it just seemed like there was SO much that could be done. Do I start with a bug? Oh, okay look, an issue for "first time contributors, thats me!; omg I have no idea whats going on?!".
Narrowing it down to a feature that I needed gave me both clarity and the motivation to get it done.Engage with the Community 💬
Check if the project has a community platform like Discord or Slack. I found valuable guidance on Slack for
react-native-video. They also might have a twitter/github discussions/reddit. Point is, they will likely have some method of communication, find it, and then join the party 🎉!Dive into Contribution Guidelines 📄
Refer to the project's
contributions.mdfor an overview of contribution expectations and how to get started. This can be hit or miss; but, its a good starting point.Set Up Your Development Environment 🛠️
1. Fork and Clone: Fork the project and clone it to create an isolated environment. I personally did it like this because it just felt like too much, there was so much going on so I needed a way to remove some of the noise and drill down to what I wanted to change.
2. Experiment: Start with small changes in your forked copy, ensuring changes affect your project. For example, you just look at a class initializer that you know is going to fire and do a print statement. This helped me to learn how dependencies are built, pointed to, and managed overall.
3. Understand the Basics: Grasp the basic structure and coding patterns of the project. In my case, I needed to understand the flow from react native -> native; so, I just tried to make the absolute most basic function that would be called in react native and do something on the native side.
Learn by Doing 📚
Build a simple version of the feature in a standalone project. For example, I created minimal video players in Swift and Java to understand how they integrate with React Native. Depending on your feature, this could be quite intense method; but, I think the goal is just to get a sense of how does this thing work under the hood? Like, if this library didn't exist, how would I even do this?
Implement the Feature ✨
Figure out how to add your feature in the standalone project before applying it to the actual project. I did it this way because I wanted to have a reference point. Essentially, okay, here is a project where I know the feature is working as intended and now I just need to get it in this project but following their abstractions. So for example, they might have a way they do their events, like okay all events go here. So just slap yours in there and follow their patterns go with their style and I think it'll smooth things out.
Follow Contribution Protocols 📝
1. Communication: Engage with maintainers if unsure about procedures. I was able to get valuable feedback and even highlight some bugs as I went through the project. Normally you might have to dig to find who the active maintainers are if it isn't explicitly stated somewhere.
2. Observation: Look at successful PRs for guidance on branch management, commit history, and PR structure. My thought process was, okay these PRs get merged, if I just copy how they did it, I can find success too.
3. Documentation: Include a detailed PR with a summary, explanations, and visual proofs(screen shots/video).
Final Touches 🛁
1. Linting: Ensure your code meets project standards by running provided linter scripts.
2. Await Review: Be prepared for feedback and possible revisions. For this, I would refer to Alex guide on communication. I had some healthy back and forth before I was able to get my features merged.
Note on Rejection and Feature Requests 🚫
Your PR might not always align with the project's direction. Consider starting with a feature request issue, indicating your interest in implementing it.
You can take a look at the PR I made here
Hope this helps!- 4
a month agoTech Lead @ Robinhood, Meta, Course HeroI especially love the first piece of advice of "Find a Feature You Need 🎯". You will write the best code when you have a genuine, organic need for it. If I had the time for open-source, I would definitely start with repos I use myself in my own side projects and look for features/APIs that would level up my side project apps.
This philosophy is similar to what I recommend for side projects where you should just build stuff that you yourself would use: [Masterclass] How To Come Up With 100k+ Users App Ideas You Can Build For Free
If you use open-source libraries at your job and notice a gap, that's another opportunity to submit an open-source PR and it has double impact as it helps both your job performance and your portfolio for interviewing!
In general, I always recommend doing things for noble reasons (e.g. "I use this library and know that this feature would add a lot of value for its developer community") instead of ulterior motives ("I want to submit a PR quickly into this library to impress FAANG").
In terms of action items, the best route may be to start with side projects and then seeing if any open-source needs arise.
- 121 days agoSenior Software Engineer at Upstart
Engage with the Community...Check if the project has a community platform like Discord or Slack
This is one of two keys. "Discord Driven Development" is a prime contribution model in 2023+. The second key is: You actually need to care about the project. Tips for that:
- Build something you are passionate about or that solves a real issue for you. It's not true that you need to contribute to large existing codebases to make a "legitimate open source contribution." If you build something you are a contributor. You can make your own backlog and grow your own community. That's not less impressive than the alternative, it's actually more impressive.
- Contribute to a project that you already use and love, or alternatively: Use the project you are considering contributing too. You will understand the technical pain points, implementation approaches, and high-value added features much more effectively.
With those two keys, everything else will sort itself out. Specifically, when you talk to the community to understand what they actually want and one of two things will happen:
- They will be awesome (Wow thanks so much for being willing to help! Here's what we're thinking, or did you want to propose something? We can even get on a call if it helps.)
- They will not be awesome (Slow or no response, elitist or grumpy or unwilling to mentor - "this is too complicated for you" etc)
The second outcome is also great: You have learned to go elsewhere. Don't get stuck in the pitfall of trying to contribute to a specific project.
Another minor tip that I'm surprised not to have seen elsewhere is to keep an eye out for GitHub issues labeled "good first issue" and try to get involved in Hacktoberfest or FreeCodeCamp which are both OS-noobie friendly.
It's worth checking out the OS 101 guide from Open Sauced:
https://opensauced.pizza/blog/open-source-101-a-beginner's-guide-to-getting-started
I also maintain ladderly.io which is open source and we have a bunch of open issues:
- 12a month agoSoftware Engineer @ Some University
Hi,
I contributed to Microsoft Windows Terminal Open Source Project for about 7 months. Legends say (Alex) that if you land 5 big PR's they'll give you a job.
"You got no recent work experience". A recruiter told me they rejected me cause I had no recent experience. Open Source can help get your resumé running with fresh experience.
I build a feature to Enable Unfocused Acrylic in Microsoft Windows Terminal A deeply sought after feature request upvoted by ∼ 100 people:
- Demo: https://www.linkedin.com/posts/jaswir-raghoe_microsoft-activity-7111062782527033344-yMEw?utm_source=share&utm_medium=member_desktop
- Issue: https://lnkd.in/eNDTBUrV
- PR: https://lnkd.in/e8qdUXQu
How I got into Open Source Software and started with Windows Terminal
It's hard for me to believe that the Windows Terminal had no unfocused Acrylic for about 3 years. Like it was waiting for me to get back.
I was there when Microsoft announced the Windows Terminal Open Source project in 2019. Only in 2023 after a 3 year career break I started looking into Open Source as a way to get my resumé running again with fresh experience. After a recruiter told me they rejected me cause I had no recent experience.
After trying out XUnit which didn't work out I started looking at some Open Source projects from Big Tech. This and Chromium Web Browser were projects that appealed to me. Ended up working on this. People here were more like me a workhorse: responded quickly, added much value, also setting a high bar for quality! This was refreshing after trying some other collaborations that didn't work out.
Connection
I think you need to get along with one of the maintainers not sure how to say it in English but in Netherlands we have this word "klik" it means you just get along with someone. These Big Tech repos can often be very daunting, so you'll naturally have lots of questions. I tried a bunch of open source projects, but in the Windows Terminal Project I had a "klik" with one of the maintainers this helped out a lot in getting up and running
How To Get A Big PR
I started with a small PR in a certain area of the codebase this helped me land the big PR, because I already had experience with this area of the code base the big PR became easier.
I haven't been able to get a Referral at Microsoft, they mentioned they wanted to see a longer track record of contributions. But with the AI boom and all, I have instead changed my focus on AI. And I don't regret it.
Doing a PR to Big Tech Open Source was good for my confidence. And is good to have on my resume. Mostly it thought me more about what developers at Microsoft are like, and that they weren't as impressive as I had expected.
- 1a month agoTech Lead @ Robinhood, Meta, Course Hero
Just to clarify for others reading the thread: There's no magic number when it comes to # of PRs and whether you get an interview. I just imagine the minimum where it may happen is 5, but you probably need a lot more like 25+.
As the stories have mentioned, work on an open-source repo you're passionate about and go from there ☺️. Don't think about the potential job opportunity.
- 0a month agoSenior Software Engineer [OP]Taro Community
I guess my question was also about, how do you identity such open-source repos. Is it by just scanning some projects we use at work and pick something that makes sense. Or is there any other approach that people generally take to identify. There are tons of open source repos, as a starter I dont know where to look and identify.
- 1a month agoTech Lead @ Robinhood, Meta, Course Hero
There are many organic hops you can make to an open-source repo:
- You simply use the product as a consumer - This is what Jaswir did. A lot of products are just entirely open-source instead of isolating a specific component and exposing that. Telegram is another great example: https://github.com/telegramdesktop/tdesktop
- You use the repo for side projects - Every side project is guaranteed to use an open-source library at some point as it's not worth it building complex infra from scratch on your own.
- You use the repo for work - This one is trickier, especially if you work at a big company where they prefer to do everything in-house. But it's possible, and I actually think this is the best case due to the double-dip I talked about in another comment.
If you're a senior engineer, you have certainly come across tons of open-source repos organically across your career. You just need to spend some time back-tracking to figure them out.
