Gaining the most real-world experience from your Open Source software contributions

If there is one thing I regret from my early days of learning about front-end development, it is not getting involved with an open-source project. Even if your skillset is intermediate at best, I feel it is important to get a ‘real world’ feel of the work of a software developer to overcome imposter syndrome. It gives you the option to test your aptitude and learn from other team members within the project.

Note: If you’re a complete beginner in coding then I still feel just doing a free crash course in the basics and building some small projects with them is first priority. Then try out contributing to open source.

I had my own problems with imposter syndrome in which I managed to conquer significantly. Juggling an unpaid internship with the final months of my diploma was my first big challenge which helped me with this. I had deadlines from both my diploma and the internship. This was challenging, especially when dealing with different tech stacks from each. While it helped me with my confidence, the whole experience thought me to avoid taking on too many work tasks with deadlines, at least when starting out.

This story leads me to the key advantage of open source as an alternative.

You can create your own deadlines!

Open Source allows you to work task by task. There is no employer making excessive demands and checking up on you. Relying on contributing to Open Source puts you in a situation where your whole contributions are open for the world to see. Employers and recruiters will be able to see your progress. You put the pressure on yourself to keep adding to your GitHub contributions page.

Based on my own experiences, here are some key soft skill tips and guides to take into consideration when deciding to contribute to open source applications.

1. First find the right first open source project for you

Start with a project that has a lot of reported issues, not too many contributors, and generally has a lot of work to be done. Projects with a lot of good first issues tags would be easier to start with.

I previously contributed to Material UI, a popular UI library for React. It was a fun experience in which I gained a lot of real-world, team-based experience with Git and GitHub. However, when working on good first issues, I felt I was being spoon-fed too much, as the suggested changes were shown clearly without being able to figure it out for myself. When it came to reporting issues or enhancement ideas, I found it hard to add anything relevant. My issue reports were ofter closed as they weren’t needed. Regardless, it is a very good open-source project to start with if you can find issues to fix.

Google search projects with the stacks you want to learn. If you want to find something recent, search the current year. For example, you might search “React Graphql based Open Source 2020”.

2. Decide on commercially used / corporate based projects OR strictly not for profit projects.

I preferred to find open source projects that would show up as ‘commercial’ experience on my CV, in where it was at least partially designed to make money or help others generate money. A lot of recruitment agencies are always on the lookout for commercial experience.

For me though, I think both none profit and commercial projects can provide equally important technical experience. It’s not my intention to stigmatize non-profit applications too, but for people looking to get their foot in the door of a company, having commercial experience is of sole importance, unfortunately. This is just from my own experience when dealing with recruitment agencies. I still think working on none profits is a satisfying activity.

Note: Look out for Open-source software with an MIT license. This usually means it can officially be used for commercial use under the MIT license agreement.

3. Start with the easier, less urgent issues and utilize your other skill sets.

Whatever days you have to spare, work on something, but don’t burn yourself out. Pick up as many small good first issues if you can before working on bigger issues. Report new issues you find and give ‘user experience’ feedback on the site. Choose feature requests and enhancements that are not too urgent.

If you have other invaluable skill sets that might help the project, ask the team if it would be of any use to them. Video tutorial building, blog writing or graphic design skills can be very useful for Open-Source projects. You can still learn about the project doing this kind of work.

4. Communicate well with other contributors and employees

The first open-source project I contributed to was more a learning experience than an invaluable work experience. At the time, it didn’t have a lot of contributors and its online community wasn’t too strong. The issues were more challenging without a good community. If you find yourself in this issue, you should move on to another open-source project with a better community.

Open source projects with a strong chat and communications platform with a lot of members can help you learn from other experienced developers and help you be the most productive.

If you’re unsure if a particular issue is relevant, ask before creating it. When creating a new Pull Request, ask your colleagues for any tips on where to find the files to work on if the issue doesn’t say so. However, don’t bother your team too much, and don’t expect them to spoon-feed you everything. Keep good relations with them as they have other work to do. If you find yourself stuck in the PR, don’t give up on it. Try and learn about how the files and project work. Read the Readme files and documentation. Try to ask questions that the documentation doesn’t give answers to.

If your colleagues appear to be busy while you’re at a roadblock with a PR, work on another issue and come back to it later.

5. If you need a temporary regular job, pick a monotonous, boring one

This is common advice for aspiring writers and artists but I think it’s very applicable to open source contributors and aspiring software developers as well. After all, everyone has bills to pay.

After I finished my diploma, I went back to my old factory job, just for the sake of having work while looking for a tech job. During this time I started contributing to open source on the side to gain experience. You might think my open source contributions were my side hustle, but I put more energy into open-source work than I did with the bill-paying job in which was repetitive and didn’t require a lot of brain energy. This meant I wasn’t too burnt out to work on an open-source project and I was able to reflect on the work I did for open source projects during my regular jobs. I was lucky to have this balance especially as I did three 12 hour shifts in my side job leaving me four days to do open source work.

Open-source contributions can get you as close as possible to the real-world experience of a software developer, but you need to create the tasks and deadlines yourself.

The following are some useful links to help you get started:

First Contributions ~ As the name entails, it is designed for new developers to learn how to contribute to a repository. Beyond that, there is not much to learn from it.

Awesome Open Source ~ A large catalog of open source projects to choose from, all under various categories. If you have a tech stack or career in mind to follow, this might be a good place to start. For example, if you’re looking for a React based front end developer type role, just search for it in the search engine.

Hackernoon ~ A useful blog, providing news on new projects being built and to help find out about new trends.