Summer has come to an end and with it, Google Summer of Code (GSoC) is almost finished too. It was a wonderful experience. I have learned much from my mentors and fellow students. In this blog post I’m going to share some tips for prospective GSoC students and anyone participating in Orcasound and/or open source development.

Advice about GSoC in general

Study the GSoC site and supporting resources in detail. Every year the program changes a bit (or quite a lot, like in 2021), but you can and should look at the previous year’s site to get the idea. Hint: look at the GSoC guides repository if you want to see the latest changes even before the program is formally announced.

Go over the list of past organisations in GSoC and form a short list of ones you are most passionate about. Start early and try to get familiar with your chosen communities; you will greatly increase your chances if you contribute code/reviews/issues beforehand (some students start months before the application period), but don’t give up if you start late in the process (I hadn’t contributed to Orcasound before the GSoC). I would suggest sending a couple of proposals.

When you get into the program the most important is communication with your organisation.

Advice about Orcasound

The Orcasound organisation has projects with work for frontend and backend developers (orcasite), machine learning specialists (orcaal), someone who wants to work with hardware, and more. The community is super-friendly, communication mainly happens on Slack, and there are weekly meetings where you can introduce yourself and listen in to what others were doing. Here is the current onboarding doc where you can find more info on the organisation goals and how you can contribute.

Advice about open source

Some generic tips about working in open source (during GSoC or not):

• Work in the open, don’t keep your changes locally for a week and then push 50 commits to the repo. You can get early feedback from others and it’s just easier to discuss issues/changes if your partners can see the code.
• Split your changes into separate pull requests. If it becomes too big, try to keep 1 contained change or feature per 1 PR. For bigger projects this will prove helpful as you will be able to merge your changes faster.
• Write tests early. You can even add them before functional bits.
• Document your APIs/code from the start, especially if it’s intended for outside use.
• Set up linting and testing in your continuous integration. Every developer likes green checks on PRs!
• Knowing git(hub) basics is a must, but you might want to learn some new tricks like rebase or bisect.
• Some other helpful things that I have discovered during the summer: git hooks (and particularly pre-commit tool) and conventional commits.