--
--
- I'm Eklavya Sharma, a 3rd year CS student at BITS.
- I participated in GSoC 2016 under Zulip.
- You can find me on github: https://github.com/sharmaeklavya2
--
- Google Summer of Code (GSoC) is annual program in which Google pays university students to do a coding project for an open-source organization during the summer.
- The organizations provide mentors who guide students through the entire process.
- https://summerofcode.withgoogle.com
--
- More about the GSoC process.
- Should you participate?
- How to choose an organization?
- How to contact an organization?
- How to increase chances of getting accepted?
- Software development tips
- BITS-specific issues
--
--
- Last year around 180 organizations were accepted.
--
- Students talk to organizations and ask them for a coding project.
- Organizations have a list of projects which they want done.
- Sometimes students can also suggest projects.
--
- Students make small contributions to the organization to prove that they are skilled enough to do the project.
--
- Students write an application about the project they wish to work on, a rough plan of how they will complete the project, etc.
- Students have to submit their applications to google between March 20 and April 3.
--
- Organizations select the best students among those who applied.
- Selection rate is low:
- 19000 students registered on Google for GSoC.
- 7500 students submitted applications.
- 1200 students were accepted.
--
- Accepted students begin working on their projects from May 4 onwards.
- Mentors help students work on their projects.
--
- Feb 27 - Mentoring organizations announced
- March 20 - Student application period opens
- April 3 - Student application deadline
- May 4 - Accepted students announced
- May 30 - GSoC begins
- August 29 - GSoC ends
--
--
- You like coding and you are good at it (whatever language).
- You like learning new things.
- You want to do something real.
--
- You get to learn things you would otherwise not be able to learn.
- Getting accepted for GSoC is proof of your ability, and it can be a shining point on your resume.
- You get to meet and work with great people.
- The money ($2400 = Rs.1,64,000) and a t-shirt.
- You can brag about it!
--
- You'll spend 3 months during GSoC and at least 2 months preparing for GSoC. This might not be the best use of your time if software development isn't your primary interest.
- It can affect your grades. I missed many classes to work for my organization.
- It's disheartening to not get accepted.
--
You can participate in GSoC next year and use this year for training and familiarizing yourself with GSoC application process.
--
--
- Working on a scuba-diver monitoring program can be difficult if you don't know much about scuba-diving.
- Working on a software library can be difficult if you have never used that library.
--
- It'll be good if you know the programming language used for a project, but that might not be a requirement.
- You'll generally need to know the required technologies, especially if it's a popular technology.
- For e.g., If you have to make an android app as part of your project, you will probably be expected to already know how to build android apps.
--
- Very popular organizations (like Mozilla) have a lot of competition. Extremely skilled students participate in them.
- New organizations (those which have never taken part in GSoC before) have less competition but accept less students.
--
- Some organizations are very responsive. You'll find their forums brimming with activity.
- Some organizations are very beginner-friendly.
- Organizations which don't seem interested in mentoring should be avoided (though that's often difficult to detect).
--
- Contacting multiple organizations protects against unresponsive organizations and too much competition in some organizations.
- An organization you contact early might not get accepted for GSoC.
- Most people try 1, 2 or 3 organizations.
--
--
- Before contacting a person in the organization, make sure you know about the organization.
- You should visit the organization's website (if any) and read about the programs its developers work on.
- Introducing yourself is useful only if done at the right time.
--
- Organizations often have a forum, mailing list or chatroom where they discuss their software.
- Often developers ask for help there when they're stuck.
- Developers also discuss strategy, progress and new ideas for their program.
- Lurking on this forum can give you an idea of what's going on now.
- It also tells you how active an organization is.
--
- An organization's code repository often contains a readme and contribution guide. Read them before contacting a developer in the organization.
- Readme often tells you how to build the program from source code and run it. It's important to try that out yourself before contacting a developer in the organization.
- Most organizations use github to store their code repository.
--
- Most organizations use a web application where developers (and sometimes even normal users) can report bugs and features. Such an application is called a bug tracker.
- This is where most of the action happens.
- Each bug or feature request has a separate discussion thread. Here developers discuss how to fix the bug or implement the feature.
- Most organizations use the bug tracker that comes with github.
--
- Most organizations classify bugs by their difficulty.
- If you want to fix an easy bug but don't know how to begin, you can ask on the bug tracker.
- Avoid telling too much about yourself on the bug tracker. Just talk about the bug. For introducing yourself, you can use the mailing list or forum instead.
--
- Discussions on forums, bug trackers, mailing lists, etc. can speed up by a huge factor if done in realtime.
- This is especially important if developers in your organization live in a very different timezone.
- Most forums, bug trackers, etc. support e-mail notifications or mobile-app notifications. Use them!
- Email isn't supposed to be checked. Email should inform you when it arrives.
--
--
- You generally need to know almost exactly how to do the project before you write your application.
- To prove your ability (and gain ability if you don't have it), you'll have to make many contributions to your organization (because others will try to do the same).
--
- The earlier you start, the more time you'll have to learn required skills and make enough contributions.
- Generally people start contacting organizations even before organizations are announced.
--
-
General skills: For e.g., programming, version control, command-line, markdown, makefiles and developer general knowlege.
-
Specific skills: For e.g., programming language, web dev, android dev, desktop app dev, networking, computer graphics, distributed computing.
--
- Version control: Most organizations use git and expect you to know it well. http://www.git-tower.com/learn/ebook/command-line/introduction
- Linux: Since most projects use linux, you should be familiar with it.
- Command-line: You should at least know basic command invocation and IO redirection. http://linuxcommand.org/lc3_learning_the_shell.php
- Automated Testing: This is widely used. Learn it and try it out once so that you understand the terminology and know the basics.
--
- Most organizations have a ritual where every student who wants to apply for GSoC has to introduce himself/herself on the mailing list or forum.
- Most students also ask for further direction when they introduce themselves.
- You must introduce yourself at the right time.
- You must introduce youself in the right way to have the most impact.
--
- Tell about all your relevant skills and your interests.
- Tell about your past projects (if any).
- Your introduction should not be too small to not give enough information about yourself.
- Your introduction should not be so big that the mentor doesn't bother reading it.
- If you don't have much space, include links. But keep in mind that the mentor might not visit them.
--
- Never ask to ask.
- Ask specific questions, give all details and search the docs, bug tracker and internet before asking.
- Before opening a new issue, search for the issue in the bug tracker.
- Do as the mentor says. Don't irritate the mentor.
--
- Be aware of the organization's whitespace policy. If you use tabs instead of spaces or vice-versa, you'll be asked to fix the whitespace.
- Avoid trailing whitespace (unless absolutely neccessary).
- Only modify code which needs to be modified, so that analyzing your diff is easier.
- Write clear and descriptive commit messages and commit at right granularity.
--
--
- Most of us are used to working on projects we wrote ourselves.
- To contribute to open-source, we must know how to work on others' projects.
- Version-control is important for teamwork.
- Try sending a pull request to your friends to get an idea of the process.
--
- You don't need to know everything about the program.
- You should know what the application does from user perspective. Run it and explore its features.
- You should know what's the high level design of the program.
- You only need to know the details of the part you are interested in working in.
--
grepwas helpful. Knowlege of regular expressions was sometimes helpful.- Use a text editor which helps in fast searching and navigation.
- In an IDE, a class explorer might be helpful.
--
--
- It is not hard to do PS1 with GSoC. Many people have done it before.
- I avoided PS stations which are known for giving relatively more work.
--
- Your summer vacations will end before GSoC ends.
- It's important to tell your organization about this.
- Try to almost finish your project during vacations.