Contributing to Open Source Can Change Your Life - Here’s How to Do It

Love how short yet detailed this is, not a 10-20 minute to an hour video, not a whole lecture/series, just straight to the point

I agree, if I could start my journey over I would jump straight into Open source and treat that as my ‘projects’ vs building things on your own. Because not only are you contributing but you’re also working with others as a team. Most definitely will look good on your resume and you will for sure meet mentors and high name tech contributors and even get paid through open source. Would encourage anyone starting out to prioritize open source over building things or a portfolio for a job

I think you forgot step 0 when contributing code: Leave a comment on any issue you want to fix, state clearly that you would like to contribute a solution, and ASK(!) if a maintainer is there and willing to review/accept your work. It usually doesn't take long to get a response, gives you a general sense of the pace at which the repo operates, and saves you from contributing to dormant projects. For the first PR it will take a couple of days to set up a dev environment, get familiar with the tooling, understand the test-suite, etc. Nothing takes the wind out of your sails faster than putting in those days of work just to see the PR sitting there for months with no feedback and no merge. So before you start, make sure you have talked to maintainers (like me) before you airdrop a PR. We don't want your work to sit around and collect dust, but unfortunately, most of us have to split our time between the project and a regular job. Having clear communication on this from the start goes a long way in having fun with open source :)

It’s a wonderful feeling to find a bug in a piece of software you use and to submit a pr resolving that bug!

Honestly, I think the more feedback you get on your PRs, the better. That means people doing code reviews care enough about you as a contributor that they’re willing to spend time going over your authored PR. It gives that much more meaning to your PR when it’s eventually approved and merged. And you can say, “I’ve contributed something meaningful to this project!”

"Someone else's code is their temple. Don't walk in with your muddy shoes on." Well said!

Timestamps for those interested: 0:00 - Why contribute? 0:44 - Finding a project and an issue 1:33 - Read the rules 1:46 - Form the project, make a branch 2:03 - Feeding the YouTube algorithm 2:08 - Make your changes 2:23 - Push your changes 2:28 - Open a PR that resolves the issue 2:47 - Monitor and receive feedback gracefully 3:05 - Signing off

"Github is the new resume". No it's not. Hardly anyone looks at github projects when hiring.

I tried. And here's the thing. I submit the pull requests, the other developers copy the change, generate their own pull request and approve their own pull request rather than approving mine. It's kind of fool's gold.

this video changed my mind about open source projects, i never knew that it was so easy to contribute, thanks dude!

I'm a hobby programmer and I'm really interested in contributing to open source, but I'm very intimidated. This was super encouraging. Thank you!

Oh yeah, getting into Linux and fixing small bugs and annoyances in the programs I used, or even just reporting them, that's how I got started.

I started my journey with open source in 2019. Gradually I made my career in open source and now working for an Open Source company. The best part is ypu get to contribute to projects freely. There are lot of talented developers and almost every open source developer is passionate about their work. ❤️

Superb video. But, let me share this here knowing it can uplift someone that comes across it. Effective financial management made me rich and it is all you need if you want to build a strong financial future tomorrow. I started with 1000USD, 3 years ago I invested in a diversified stock market and fast forward to now I am worth 500000USD and am currently finishing my 8 unit apartments. I'm only 35 years old. Diversified stock investments have always proven to be very profitable, especially with the help of experts.

Also, just remember to check whether the project is still active or not by checking the latest pull request date and also ask the owner before solving an issue, the issue might already be assigned to someone or for any reason they may not accept your PR so prepare for that as well just in case.

Great advice! Can’t believe I never thought to look at the dependencies of a project to find other projects to contribute to. Love that suggestion!

I would've never clicked if it wasnt that short. Great Video!!

Submitting tickets, well written, researched and with reproduction steps, can also be really helpful to maintainers or to yourself. I have first hand experience at finding bugs or missing features in a framework I use at work, write professional tickets (what's the issue, severity, why it's an issue, expected behavior, tracing the origin of the issue in the source code if possible, providing code/pseudo code when a PR isn't an option) and get notification of a patch within a week on totally open source projects. That's also a good skill to have and you can use it at interviews if you can show multiple tickets and their resolution time compared to other tickets or average closing time in a project.

love this video because 1. On point 2. Time saver 3. Insightful

I try to make bug reports instead of providing the actual solution, to keep the (minor) contributor count low so that license-wise there are no problem if someone decides to change it (I seriously had people hit me up if changing the license was ok, because I added one DLL the repository). And I seriously had one dude complaining about my bug report, that I wasn't fixing it myself and that I suck for being a security researcher who just posts bug reports on open-source projects so that they can use the unfixed bugs in their reports to say open-source sucks (of which none is true). I legitimately just had a wrong free bug when running the code "casually". I provided reproducible steps, test files, everything. In the end I fixed it in the same manner as the rest of the code has been fixed at a similar line of code, created a pull request and it still hasn't been merged. (~6 hours wasted, plus a giant "f u" in my face) Another time, I added a feature I wanted, created a pull request and basically got a "won't merge", because it simply doesn't fit the idea of the maintainer of what the project should look like. (Neither would there have been any grounds to make this feature fit, because it's nature was just not fitting) Other times I create a pull request with the message: "Please test before merging" and it gets merged so fast that it can't possibly have run through any tests. Other times it takes 2 years before my pull request gets accepted, despite it literally being just a fix where someone accidentally had swapped x and y (or rather u and v). And now to the worst offender, which is my professor at uni, wants me to rebase my 60+ commits (among which are also commits of colleagues) into 4 big commits that are actually features that rely on each other, rewrite history that way and screw up authorship of files and cause me a bunch of headaches and increased testing efforts when I'm already 1 year due to submission. Not just that but it eliminates the detailed description of each commit and thereby I need to change a bunch of files again and reconsider which stuff I put into the documentation and which not, while before it was very clear that certain bugs that have been fixed did not need inclusion in the documentation, but had a detailed explanation in source control. THAT'S my experience with open-source.