GSoC is a good entry point for contributing to open source organizations. 2016 GSoC application process begins on 14th March. This blog post is about preparing a strong application which increases your chance of being selected.
First read my previous blog post on “Getting started in open source”to have an idea on how to start contributing to open source if you are completely new to the open source. Once you start with a particular organization, you have to submit a proposal for the project you wish to do during the summer.
Where can I find the scope of the project?
Go through the organization page and the idea page on the Google Summer of Code site. You can select a project from there. Different organizations handle the communication process in different ways. Some organization ask you to get in touch with the mentors of the project while other organizations recommend more public interactions like mailing lists or IRC channels. Read through your organization page and identify the prefered method of communication. Then go ahead and find out about the functionalaties and the scope of the project.
Does my previous contributions matter in getting selected?
It depends on the organization you are applying for. Past contributions are among the several other things which will make a good application. Following is a general list of things which will be considered when rating your application. However, the weighting depends on the organization.
- Technically strong proposal
- Previous contributions
- Interaction with the community
- Helping others
- Willingness to learn
Technically strong proposal
This is your one chance to prove that you are technically sound and have the skillset which is required in the project. Your proposal should be original and convincing. It should address the expectd functionalities and scope. But you should be able to differentiate your proposal with others by adding an extra touch of creativity which will convince the mentors why you are the ideal person for the project. Different organizations handle the project proposals in different ways. Some organization asks the students to keep their proposals open. In these kind of scenarios adding something from your side which can make the project better will give you an upper hand. Even without open proposals you should make your proposal unique. But make sure you are not stepping the line by creating a proposal way different than the expected project. Copying some other person’s idea or proposal won’t help. It will affect both the proposals negatively.
In some cases organization’s asks some other non technical factors as well. Most student do not take time to answer these questions genuinly. Some tend to put answers which are directly copied and pasted from Google. Even though your techncial proposal is good, plagiarism won’t get you anywhere.
Youe previous contributions make the mentors identify your ability and willingness to contribute. It may be a small one line fix, but it matters. But problem arises with the contributions which are not required to the project, So before you make an contribution, talk it through with the community. If you are going to fix a bug, make it assigned to yourself. Otherwise some other person who is also seeking for a contribution will do the same thing and it will result in redundant work. If you are going to propose a bug fix make sure to get it approved by the community. They may suggest you some new things to add to your contribution as well. Don’t be greedy and get multiple bugs assigned to yourself. Most communities do not like this kind of scenarios. Hence it will affect adversely to your application. Always do one at a time. It will help you focus on your current work and do a better job out of it as well. It’s not the number of PRs that matter. It is the impact on your PR to the project that matters.
Interactions with the community
As I mentioned earlier, community interactions matter. The sense of community is a strong characteristic in open source. No one will blame you for asking a question which is related to the project. Community will always be there to help you. However, you have to ask better questions. If the answer you are searching for is openly avbailable, which means that you have not taken enough time to go through the project and related materials. Always keep your ommunity interactions positive. Follow the organization’s culture.
Open source is all about helping others. You should be willing to help others when working with the community. Be active in mailing lists and IRC. If you know the solution to the problems being asked, don’t be hesitate to reply back even though you are fairly new to the community.
Requirements change overtime. Your time line and proposal should reflect flexibility to adapt these changes. If the mentors ask to change your proposal about a certain point, take their advice and change it. They will always know better about the project.
Willingness to learn
This is a crucial point in GSoC. If you are a novice or intermediate skilled person , there will be a lot to learn. Always try to find the answer to your problems yourself, if you can’t find them, ask them from the community. Your mentor will not do stuff for you in the project. You should learn and do yourself. In most scenarios mentors will direct the students to answers.
What if I don’t get selected?
Don’t get demotivated. Keep contributing and apply next year. What matters is not getting selected to GSoC, but your contributions to the open source.
This article is written from my experience being a GSoC mentor last year and a conversation I had with a fellow mentor. Thank you very much Shwethambara for your insight and experience on this matter.