How to get selected for GSoC: Unfolding my story at LibreOffice

I decided to write this post to help people understand the value of open standards and motivate them to contribute to open source. Google Summer of Code, popularly abbreviated as GSoC, is a program that aims to bring more student developers into open source software development. I was selected for GSoC’17 at LibreOffice(LO).

I have contributed to four big names in Open Source since last year, namely: LibreOffice, Mozilla, Fossasia and OpenMRS. Each one is unique and best at what they do. I will provide you with a walkthrough of my complete journey to explain what I did to be selected for the best open source office suite organization.

Choosing the right organization

The most important and crucial decision for GSoC is your choice of organization. Getting selected for GSoC is not the only thing — you want to put your time and effort in the project that adds value to your existing knowledge and where your code will have maximum impact.

Moreover, GSoC is not just about the amazing stipend and the three months of code — it is more about the bond between you and the community. Most GSoC students are given commit access to the project they are working on, which comes with great responsibility. You’re now one of the maintainers of the project and the community trusts you. In a recent interview, Linus Torvalds — the creator of Linux kernel and Git Version control system, said

“You shoot off a lot of small patches until the point where the maintainers trust you, and at that point you become more than just a guy who sends patches, you become part of the network of trust.”

It was mid-January when I started exploring the organizations participating in GSoC. My tech stack includes Java and Android. My choice of LibreOffice was based on the intersection of the these factors —

• Is the project interesting? Is it challenging?
• The tech stack — what new things would I learn?
• The size of org, quality of code , and the impact they have in the open source world
• What after GSoC? What is your future with the org? Are they active only during GSoC period?
• Healthy competition — you wouldn’t want to contribute just because your competitor is sending more patches than you, but because you would genuinely like to support the project.

I also wanted to go for the big and the less mainstream organizations — LibreOffice fit all of my criteria. I chose LO’s Android Client as my project. The tech stack for LibreOffice Android mainly includes C/C++ and Java. I chose this project to overcome my fear of native code.

I would like to mention one thing here: if you want to learn a new programming language, start contributing to an open source project written in that language. It is a much better and faster way of learning, rather than following some online course. I would recommend going through this article describing an unconventional way of learning a new programming language.

One last thing to take care of, as the popular saying goes…

“Do not put all your eggs in one basket.”

Do have a backup. When you’re starting early, you don’t know whether the organization you are contributing to will be selected for this year’s GSoC or not.

For those who are unaware, yes, Google selects the organizations that will be participating in GSoC. Just because an organization participated last year doesn't mean it will be selected this year. This rarely happens though.

However, it is recommended not to go with more than two organizations. You may not get sufficient time to contribute and write a high quality proposal for all of them if you choose more than two.

I chose Mozilla as my second organization because it's a very newcomer friendly community. Mozilla is one of the largest open source organizations and most of us are already using its most popular product — Firefox. Firefox is available for all platforms, including Android, so I chose Firefox for Android as my project.

I learned how to use JavaScript in Android, built web extensions for Android browsers, played with Firefox’s native code, and much more. My journey with Mozilla was a really exciting and productive one. I’ll write a post completely dedicated to my experience with Mozilla soon.

One more tip! Both of the organizations I chose don’t appear when you search for the ‘Android’ tag on the GSoC website. However, they did have Android projects on their idea list. Many organizations do not list tags on the SoC website for every project they have. By diving deep into the org idea list, you can filter the first wave of students in the running for projects intersecting with your tech stack.

Contributions and Pre-Proposal Phase

This is when you explore your project, identify bugs, enhancements, submit patches, and interact with fellow developers and mentors.

After a successful LibreOffice build, you need to set up Gerrit — a code review tool used by many big open source projects, including AOSP (Android Open Source Project). The pros of contributing to LibreOffice includes familiarity with Gerrit workflow as well. Personally, I find Gerrit better than Github workflow. This gist explains the differences beautifully.

Submitting your first patch is always the hardest. Trust me, it feels great when your first patch is merged to the central repository, however small it may be. When my first patch was merged to LibreOffice, I was greeted with this email, which shows that they value their contributors.

First patch merged email

After a few patches, the project code starts making sense to you, which is very important if you want to write a very good proposal. Orgs usually favor a student with a fine proposal and more contributions than one with no contributions and a well-written proposal. The proposal quality automatically improves if you have contributed to the project and understand its technicalities.

When I was writing code for LibreOffice, I had to take care of nitpicks that are usually ignored while coding personal projects. Some basic examples —

displayMessage("Your information has been sucessfully saved!"); // nit: use translatable strings!

displayMessage(getString(R.id.save_successful_message)); // Correct! Now it's easier for translators to translate this string

if(myBoolean<1){ // nit: Space after if, readability can be improved 
  doThis();
} 

if (myBoolean < 1) { // Nice, you have made the life of fellow developers a bit easier! 	  
doThis();
} 

int x = 10; // nit: If you don't want value of x to be changed later, use final
void myFunction() { 
  print(x);
}

final int x = 10; // Correct!
void myFunction() { 
    print(x);
}

For Android, while coding personal projects, we usually don't care if our code is working for lower API levels or not. If the feature is working on our device, we assume it will work on all others as well. One of my patches in LibreOffice broke the compatibility on lower API levels, which was not discovered until a fellow developer fortunately ran the app on an older device. When you’re coding for millions of users, these things become really important.

You should also try to review other fellow developers' patches. The ability to read code written by someone else is a very important quality. It also helps when you’re trying to dive into a completely new project.

During this phase, I also reached out to my mentors and asked what they would like to see in the proposal. I started writing my proposal a few days before the proposal submission phase started. It is better to submit the proposal early so that mentors can have enough time to look at your proposal and give valuable feedback.

Writing a good proposal

Your proposal is the key to impressing the mentors and making them want to select you. Most of the organizations have their own template for writing proposals. You can take a look at my LibreOffice proposal for a reference. I want to highlight some key points for writing a good proposal—

• Do include technical descriptions — “I will implement this feature” isn’t really effective unless you include ‘ How? ’
• Assume mentors are lazy — fortunately, mine weren’t, so I pestered them with a 15 page long proposal. That being said, textual content should not exceed 10 pages unless absolutely necessary.
• Include whatever makes you fit for the project — your relevant technical experience, internships, projects etc. Do not just copy and paste your CV.
• Try to add UI/UX mockups wherever relevant.
• Do not give vague timelines — For example, writing "Week 1–3 Understand the codebase," "Week 4–6 Implement the features," and "Week 7–8 Testing and Debugging" won’t really impress. Detailed and well designed timelines are very important.
• Estimate how long reviews will take — every patch in an org goes through a review process, which may take a week or so. Including it in your timeline will give a good impression that you have really wrapped your head around things in your timeline.

Above points are referred from How not to apply for Summer of Code.

Wrapping up

These are the few ideas that I think might help you get selected for Google Summer of Code. Applying for GSoC will help you get started with an open source organization and learn a lot in the process.

I will admit, contributing to open source has made me more disciplined as a software developer. Writing code to be shipped is important, and personal projects or online courses may not give us that chance. If you have any questions regarding GSoC or getting started with development in LibreOffice or Mozilla, comment below or ping me via Facebook/Email.

LibreOffice is the only community protecting open document standards. If you want to get started contributing to LibreOffice, I'd love to help. You may find the Document Foundation Wiki pages a bit monotonous and boring. In case you need some help with development, you can ask on the Freenode IRC channel #libreoffice-dev.

For an easy start, if you want to support LibreOffice Android, you can download the app from the Google Play Store and use it. You can report the bugs/enhancements you find on Bugzilla. Please make sure that the bug you find has not already been reported.