Google Summer of Code! One of the best things that happened to me :D

What I intend to cover?

I plan to cover the insights and pointers that I gained, while being a part of the fantastic Open Source Programs over the world, Google Summer of Code! I won't cover the technical aspects of participating in GSoC, but rather focus on the learnings and takeaway from this program. For list of resources useful for GSoC, refer this.

For brevity, I have broken the blog into two parts - First one covering the journey leading to GSoC, and the second covering my experience with my project.

Ascending the everest; Commencing the journey

I have further broken down the different aspects of GSoC into coherent components, which would provide context while I discuss them further :P

Philosophy of Google Summer of Code

With any work that you do, it is important to understand the philosophy and its goals, that are aligned with it. Whenever you sign up for anything, you also sign up with the philosophy and the work ethics that come with it. It might be surprising, if you don't agree with it, so it's imperative to understand, what it takes to be an active GSoC contributor, and a life-long OSS contributor!

Start Early and Start Small

With any habit, it is imperative that you start small and make sure you break down things into manageable portions. While starting with Open Source contributions, there are lot of things that you might need to cover, in order to get equipped with the contributions. You should get aware of basics, such as basic command line env, git, and debugging. Note that these are necessary to be learnt eventually, but not at the start. You can learn them eventually. Here are some resources -

  • https://missing.csail.mit.edu/
  • https://www.udacity.com/course/version-control-with-git--ud123

Learn it as you go

The best part of Software Engineering is that, no one knows everything! Everyone learns as they practically use the tools, and Open Source is no different than that. Knowing basics about the different aspects of Software Engineering is important, once you know them, it is easier to extend your knowledge to your tech stack.

I found this quite useful for visualising the requirements -

  • https://roadmap.sh/

Its about the community

Open Source holds it charm due to its community. The idea of OSS exists because of the voluntary and passionate work the mentors and contributors do. So it becomes natural to have high expectations from them. However, it is fair to understand and respect the fact that it is voluntary work, and no one is accountable. People mentor out of interest and folks should respect that.

Another aspect is about the learning and working on your field of interest. For instance, if you are involved in AI research, and get hold of an organisation with fantastic community to learn, it is the best opportunity. The mentors and contributors are equally competent, and the peer group will help you in growing your knowledge and develop industry standard with your research. If you happen to participate due to GSoC, and not because of learning, you miss an opportunity to expand your knowledge and networking.

GSoC is a result of community, and not the other way round. People who participate out of interest and learning vision, are bound to enjoy the process more, than people who want to participate in GSoC. Community provides the context of the program, and without context, the program is mere body without soul.

Being active in the community

GSoC requires you to be active in the community you are contributing to. It does not mean that you have to lurk at the mailing lists and communication channel all the time, you can also choose to review the issues, pull requests and discuss the proceedings with the contributors, while helping out others to onboard with the process.

Everyone likes to work with a person, who has been active and involved with the community. It is also beneficial for improving your soft skills such as, how to ask the right question, how to navigate through common issues, and how to be a better contributor.

This also provides you a first hand experience of working remotely, with minimum physical hinderance, and enabling you to utlise the plethora of online resources.

Having a sound technique

Having a sound technique in cricket is of paramount importance!

Having a strong and dependable technique will help you work on your ideas more, rather than focussing on churning code. GSoC isn't supposed to be a program where you churn code, but an event to develop your software engineering skills, rather than programming skills. Sure, you should have decent programming skills, because if you don't have them, it would become difficult to work with the strengths and weakness of the programming language.

For instance, Golang has a nice abstraction for goroutines, and helps to write concurrrent code much more easily. The same is difficult to write in C++/Java, because you need to manage the overhead of using threads. So having a working knowledge of the programming language that you plan to use is important, as it would help you to demarcate what is possible, and what is not.

Software Designing skills develop, once you spend reading the codebase and the design decisions taken. Design docs are a great place, where they discuss about the different approaches to solve the problem, and choose the one that is practical and feasible. You can develop your taste and understanding about why some components are designed in such a manner. Here is an example for this -

You eventually need to make a proposal for your GSoC project, so you get an opportunity to think and exercise your software designing skills. The mentors are always happy to help you out with this process, so don't be afraid to approach them.

GSoC provides you with the opportunity to spend your summer develop these skills, as you can use this opportunity to learn from the mentors and online resources. It is not imperative to have these skills before(because GSoC was designed to help you cultivate these skills!), but you should strive to work and develop the taste eventually.

Choosing projects and organizations

Choosing organisations is important more than choosing project. Unless you are experienced to choose a project, organisations play an important role for learning. For folks who are participating for the first time, it is important to choose organisations that facilitate mentorship. You are not only commiting to the project, you are also signing up for a work culture which might suit you or not, depending on the goals.

For example, if you plan to work with Kubernetes as a GSoC organisation, be ready to work on your own with little hand holding. Kubernetes is an advanced organisation where the problems they solve using Open Source requires more idea and experience. Open Astronomy, on other hand, helps onboarding new participants with more mentorship and guidance.

All these are personal opinions and might be biased, so choose the ones which are beginner friendly, and you would enjoy the journey!

There is the balance of choosing an easy project with more competition, and choosing a tough project with less competition. So the choice is yours.

Sprints are a way to go

While this is not scalable, I personally find sprints an important tool to develop any skills at start of your program. You should choose an issue that you want to solve, and sprint through them to solve it. When you impose a time crunch, you come up with innovative ideas to solve your problem, and instead of having a sophisticated approach, you come up with a practical and simple approach. This makes sure you have a proof of concept to work with, and iterate on the process more.

Proof of Concepts

Proof of concepts are an effective way to test out your hypothesis. @thealphadollar has a good account on this.

Let's say you have an approach to solve your problem, and you have designed your approach and different components. You might know which components are tricky to work with, and might not know if the behaviour is supposed to be what you planned to be.

Here is an example of a problem statement and how I came up with a solution. This problem was really tricky for me to work with, as I encountered this for applying for a startup in my second year. Although I didn't solve it, because I didn't had much knowledge to work with. Fortunately, after a year and a half, I finally managed to formulate an approach for it. This was a perfect example for proof of concept, as I had multiple iterations before arriving at the final solution :P

Proof of concepts are a best way to test out your hypothesis, and make sure your assumptions are correct/works in a behaviour that you expect. Often, it is possible that you might not know how a component can be designed using an existing design, which is not known at present. The best way is to design a solution from scratch, and iterate on the process, rather than working on your project with your approach, only to realise that the approach is not feasible.

Getting selected, or not

I intentionally kept this at last, because after all this is a possibility, and you should accept it. Rejections can happen from all sort of reasons; proposal not accepted, organisations pulled out at the last moment, projects removed at last moment due to unavailability of mentors, and so on. Surprisingly, I have had a first hand experience of all of the events, which happened to my friends and OSS folks, so it's pretty realistic.

The best way is not to take this personally, but rather accept that it's a game of probability, and due to mentors having limited slots proposals can be pulled out inspite of sounding brilliant on paper. Google's main aim was to introduce you to the culture of OSS, and you having spend a couple of months, would have still gained a lot.

Working on with the community is imperative, because it helps you build your skills, and you might get an opportunity to work with your mentors with another program. One of my closest friend was working with Julia, and inspite of having solid contributions and proposal, he still didn't get a chance to work. However, because he was quite involved with the community, he got a chance to participate in MLH Fellowship.

Your contributions are quite valuable, and you can choose to work on your project if you want to. Open Source contributions are quite valuable, and if you happen to interview for Software Engineering roles later in your career, those stand out to be the most valuable aspect of your resume. Senior engineers love open source contributions, as it helps you to transparently judge a candidate with their knowledge and understanding.