Getting selected in GSoC

Published on ยท 3 min read ยท 1 view ยท 1 reading right now

GSOC
OPEN-SOURCE
ASYNCAPI
Sunset
Image taken from pexels.com

So, I got selected as a student in Google Summer of Code(GSOC) ๐ŸŽ‰ under AsyncAPI organization through Postman.

I will be working on AsyncDiff which is basically a library which compares two AsyncAPI Documents and generates diff between the two.

Why was I interested in AsyncAPI?

For those who don't know what AsyncAPI is, It is a specification for defining your APIs(mainly event-driven). You can document your APIs as well as generate code from that documentation.

I have been exploring Event Driven Architectures(EDAs) for quite some time and AsyncAPI felt like the right tool for the job(as I always have been a Schema first guy).

I think the best way to contribute to any Open-Source project is to start contributing to the tools you use. So, here I was looking for contribution opportunities in AsyncAPI. What were the odds that AsyncAPI was going to apply for GSoC under Postman (Though they did apply individually, but unfortunately, were rejected ๐Ÿ˜ข ).

I started looking at their list of projects for GSoC and I choose the diff project because it had some elements of CLI, and I love CLIs.

Having selected the org of my interest, it was the time to make some initial contributions as well as write a proposal for the project.

For initial contributions, I basically wrote some missing tests, which forces you to go through the codebase in order to understand what's to be tested and how. This helped me a lot when writing my proposal.

How I approached the project?

When writing the proposal for your interested project, you should have a clear(not perfect) approach in mind.

I first looked at the summary of the project and tried finding similar tools in order to understand what will the final result. My project had some similarities to git diff, so I started exploring git diff and how it works.

When I was done with my first draft of the proposal, I asked the mentor(& maintainers of the org) for reviews. They helped me a lot in my understanding of the project as well as pointed out the important bits I was missing in the proposal.

After doing several iterations of the proposal, I was still not that confident. But the deadline for the submission was almost here. So, I did the best I could do and submitted it and hoped for the best.

After submitting the proposal

There was a long gap between submission of proposal and announcement of the result, but I wanted to pick up some issues and work on them. This will help me get more familiar with the codebase as well as interact with other folks/maintainers.

Worked on some issues(almost broke some codebase as well :p). This step also helps the project mentor see that you are consistent and do the expected work.

As I said initially in the blog, I got selected. I was really happy and ecstatic. But for those who didn't get selected, know that the main aim of GSoC is to get you started in Open-Source, you can still do it without GSoC.

Here are the main takeways from this blog:

  • Get familiar with the codebase and look at similar tools. Get proposal reviewed from the mentor.
  • Even after submitting the proposal, you should contribute to your org
  • Just keep on contributing even after GSoC
0 likes

Other articles