SourceSpy

How (and why) Contribute to Open-Source Projects?

Part 1: Why do I need it?

In the world of software development, contributing to open-source software projects is now an important part of one's professional growth. It's no surprise then that hiring managers are starting to recognize open-source developers. And why wouldnt they as these contributions are a clear evidence of their commitment to the craft.

Beyond the hiring manager exposure developers multiple advantages:

Skill Building: You'll tackle real-world problems in open-source projects, which can improve your coding skills.

Networking: Working with different developers on these projects helps you make connections and learn from others.

Portfolio Boosting: Your contributions showcase your coding skills and experience, which can impress potential employers.

Practice Oboarding: practice developer onboarding routine when you get hired in a new company.

Part 2: What project do I work on?

It is important to note that you should leave big project contributions to the future self. Yes, it looks good on your resume but chaces of your pull request being accepted by big project mafia are small. More over, it will be harder to do a quality work on a big project.

Let your ambitions rest and start with something small, something you are familiar with. Many people are weary of open-source games, but those make great first contributions. You are more likely to understand the code and project maintainers will be happy to a new contributor.

Be careful here - make sure the project is active. You dont want to spend hours building a fix that will never be merged into the main branch because the project is dead.

Often contributions do not have to be significant. A simple update to an image resource or portion of documentation will do just fine. Your goal is to contribute something and take the credit!

Part 3: How do I start?

Learn project structure. Use the following steps to familiarize yourself with the project in general:

First: learn what application does. Look at screenshots. If binary files are available, download and run them.

If you fail to run it, dont get frustrated as it might not be your fault! Quite often maintainers provided unclear instructions or never tested the code on your platform.

Here is an important rule for your first contributions - fail fast. This will save you time but get your results you need.

Second: look for documentation. Collect architecture diagrams, module dependencies, build sequences and specifications might end up being useful in the future. Just knowing they exist might help you down the road.

Third: start looking at the code. Find modules, packages, build scripts, unit tests, entry points, size of the code base. Keep a pen and paper handy - record your findings and draw diagrams. This step is important - dont end up in situtation when your contribution rejected because it does not account for a portion of functionality.

Forth: fork, compile and run. This sounds easy but in reality this could be one of the most time-consuming parts (as configuration, installation and platform scpecifics are often hard to manage).

At any point of this process feel free to give up and switch to a different product. You are here to create "a" contribution, not save the world.

Part 4: What do I contribute?

Bugs and first contribution suggestion are typically noted in the project documentation - start there.

Always introduce yourself to the maintainers, ask for help. This will ensure you are not taking on something difficult (saves you a ton of time) but also establishes professional connection.

Simple and obvious bug fixing might be a perfect candidate there is a much higher chance you can do it well. But also it wouldn't take too much time.

Part 5: How do I contribute?

Now its your turn to grind. Roll up your slives and run town the rabbit hole.

Experiment first by making obvious changes. Run the code, observe the results. Then change something and see your changes take affect. Does it work?

Now get to the job of getting your task done. Fix it. Test it. Make sure it is well-documented. You know the drill.

Submit a pull request and ask maintainers for an advise.

Part 6: Now what?

Update your resume and linkedin profile. If you project is not big/important enough, simply write that you contributed to open-source projects.