Monday, March 3, 2014

My secret tip for GSoC success

If you are applying for Google Summer of Code, there is one thing you can do to make yourself beloved in your project (and isn't bad advice in general, either):


I don't say this in a cantankerous, "get off of my lawn" way. I mean it literally.


It is important to understand the motivations of a typical open-source developer. Most people contribute to open-source in their free time, out of joy. The time we choose to work on open source is time we could otherwise spend hanging out with friends and family, or programming for money, or reading books, or watching television, or just sleeping. We steal time from the rest of our lives because we love to code and we want to make the world a little bit better by creating great software [1].

In the open-source world, time is the coin of the realm.

Now evaluate GSoC from an OS contributor's point of view:

  • Google will pay a student to work full time on my project. Great!
  • Maybe the student will turn into a regular contributor, and stick around after GSoC is over. Awesome!
  • Maybe I can help the student become a better developer. Sounds good!

but on the other hand...

  • It will probably take as much time to mentor the student as it would take me to implement the feature myself.
  • I will have to spend that time mentoring (which I may or may not enjoy), rather than coding (which I love).
  • The student might turn out to be a dud, who sucks up lots of my time without producing anything.

Note that all of the downsides of mentoring a student have to do with its cost in time. The way to be an awesome GSoC student is to optimize the way you use your mentor's time.

Recipe for success

That brings us back to the advice of this article:


Mentors will generally be happy to give you the help you need [2]. They will point you to the documentation and code that you need to study. They will be delighted to discuss large-scale issues of code design (e.g., where do your changes fit in to the larger project?) They will be willing to review your code. All of these things are good uses of your mentor's time.

Your side of the bargain is to use the mentor's time as efficiently as possible. You need to extract the most benefit out of every interaction with your mentor.

  • If your mentor points you to some documentation, read it. Memorize it! Read other documentation that is nearby. Don't ever, ever, ask another question that is covered by that piece of documentation. If the documentation is unclear, it is OK to ask for a clarification, but then fix the documentation so that your mentor never has to answer the same question again.
  • If your mentor points you to some code, study it. Understand it. Figure out not just how but also why it does what it does. Read the other code that calls it, and the other code that it calls. Run git blame on the code and read the commit messages from when the code was implemented. If you think you have found a problem or bug in the code, fix it if you can. If you can't fix it, then at least investigate it thoroughly and write a complete bug report to the mailing list explaining what you think is wrong and where you got stuck. Add a test to the project's test suite that demonstrates the problem.
  • Don't waste your mentor's time on trivia. Follow your project's coding guidelines about submitting patches, code formatting, etc. Make your code look like existing code! If your mentor points out an error, no matter how trivial you might think it to be, fix the error and never make the same error again [3].
  • Help your mentor save time in other areas. Get involved in the project like any other developer. Help review other people's patches. Help answer user questions on the mailing list or on IRC. Write documentation and tests. Improve the project's website.

None of this is to say that you shouldn't ask for help when you need it. For example, it is a good idea to describe your plans and ask for feedback before you start coding--such high-level interactions are a very effective use of your mentor's time and will actually save time later. But remember that you have a finite budget of your mentor's time, so use it wisely!


Always keep in mind your role as a GSoC student: you are an apprentice [4]. This means you will be expected to spend some time running errands and sweeping floors. In return, you will have a great opportunity to learn from the world's best developers on a one-on-one basis, get invaluable experience, and have lots of time doing what you love--writing great code!


[1]By the way, if these are not the reasons that you want to participate in GSoC, then maybe you are in the wrong place to begin with.
[2]Indeed, you have the right to politely insist that your mentor gives you the time that you need. After all, your mentor has voluntarily signed up with the GSoC to be a mentor, and mentoring a student is, well, the basic obligation.
[3]If you think that the project should actually move its curly braces to the same line as the if statement (or vice versa), you are wrong. Seasoned developers know that there are only two important things about code formatting: all code within a project must be formatted the same way, and all debates about code formatting are a waste of everybody's time.
[4]Though ironically, you might be the only person in your project actually getting paid for your time!