Some insights on Google Summer of Code

Some insights on Google Summer of Code

Yesterday Google announced Summer of Code 2012 program that will run for the 8th time and attract hundreds of students from around the world to improve free and open source software. We've collected some insights for you.

With GSoC, Google aims to introduce students to open source software projects, help the teams to ensure continuity of their respective projects by bringing them new contributors. Last year over 1K of students participated in the program.

How it works

There are four parties in GSoC:

  • a student who writes code during the summer;
  • a mentor who helps him with technical questions, monitors and controls the process;
  • an organization that is basically the software team;
  • Google, who have the final decision on deliverables and makes payments.

First Google chooses what organizations will be participating. This year the company will be accepting applications by potential organizations from February 27 to March 11.

Then Google decides how it distributes project slots across organizations. For that they review applications from potential student who this year should be submitting them between March 26 and April 6. The list of participants/projects will be announced on April 23.

The coding phase starts (May 21), stops for a mid-term evaluation in July and resumes same month to end on August 20 with results announced a week later.

Just like before, Google will pay a 5K USD stipend to each student and 500 USD to each organization for a successful project. For an extensive FAQ please refer to this page.

Who participates in GSoC?

Here are just some organizations in the multimedia production domain that participated in past GSoC instances:

  • KDE (Krita, digiKam)
  • Blender Foundation
  • Yafaray
  • darktable
  • GIMP
  • Inkscape
  • Scribus
  • Audacity
  • Ardour
  • Mixxx
  • PiTiVi
  • FFmpeg
  • VideoLAN

As you can see, pretty much every major player in the domain took part. Some organizations owe a huge chunk of new code to the Google Summer of Code program, and some applications would probably be considerably less advanced if it wasn't for Google.

Just some notable past GSoC projects for GIMP:

  • new tools: Perspective clone, Healing tool, Cage transform, Warp Transform
  • editing text on canvas and rich formatting of the text
  • hardware-accelerated rendering and processing with GEGL

...or Inkscape

  • SVG Filters and UI for them
  • PDF importing and exporting
  • Live Paths Effects
  • performance improvements

...or Blender:

  • camera tracking
  • COLLADA improvements
  • multiple game engine improvements

Thinking about participating?

Why it's good for students:

  • you will understand remote team work better;
  • you will improve your coding skills;
  • you will be able to do some interesting research work;
  • you will be financially backed for working on your favorite project.

Or, to quote Eilidh McAdam who worked last year on Visio support in LibreOffice:

I feel like I've learned more here than I did at university! How to integrate with a remote team (the main thing is communication, same as if it wasn't remote), how much perfectionism can hold you back and the importance of getting some sort of results. I also learned some new ways of thinking about program structure.

Why it's good for organizations:

  • it's a great way to get new contributors and thus ensure continuity of your project;
  • most likely you have a list of cool ideas you never had the time to implement;
  • you just love when people suggest interesting ideas and write the code.

Does it actually work? Yes, I know quite a few organizations where past students became regular contributors and GSoC mentors. Hugin, Blender and Inkscape are among those organizations.

As someone who has been participating in the program since 2007 as a primary and a backup admin (Hugin, Scribus, OpenICC, darktable, Audacity) I think I can share some observations you might find useful, if you consider applying as either a student or an organization.


It doesn't really matter that officially you start conversations with potential mentors only in March. Go back to your favorite projects and discuss it now. If they haven't heard of GSoC, tell them. The sooner you hook up with the team, the better you understand each other, the more chances you have to succeed.

Pick a project that you really love, with hugs and kisses. Do you want to have a baby with that organization? Even better! Being passionate about the project is 1/3 of the success. And in some cases you can make GSoC a part of your scientific research. Talk to you mentor at university about that.

The next 1/3 of your success is truly understanding your fortes and your weaknesses and being able to deliver the final product. That means you've got to have skills and a relevant background. Programming with a new toolkit (GTK+, Qt) is probably OK, programming in a new language absolutely isn't.

And the last 1/3 is planning. I'm certain that you are going to revisit your schedule as you code. Pretty much everyone has to. It's not a problem. Just make sure you go through the schedule with your future mentor until you both agree about scope, sequence of actions etc.

By the way, don't hesitate telling your mentor that you have problems meeting your deadlines. We are not monsters, we don't habitually bite (unless you specifically ask for it). Our common goal is to do some great work and have fun. Rescheduling and reprioritizing your work is OK as long as you are open and communicate all the time.

Oh, and one more thing: slaving away in a bedroom while everybody else is having a good time isn't always fun. When you plan the summer timeline, put a short vacation in there somewhere. Usually it's around mid-term evaluation which happens in mid-July.


First of all, make it a rule that anyone who wants to participate should submit a couple of small patches. Google doesn't demand it, but you should, and I really mean it.

Students can have best intentions, but they might be just not up to the task. Some organizations learned that the hard way, having assigned students who then disappeared or failed to deliver what they promised.

Having patches from your potential students means that:

  • you can evaluate, if they really have skills for the tasks they chose;
  • you can see how they communicate, whether they understand the culture in your project;
  • you simply make sure that they have the build system ready by the time coding phase starts.

The latter isn't a joke. I've seen two projects in the past where both students spent a whole month setting up a build system and understanding how things worked, and that was during the time they were supposed to be actively writing actual code. You really want avoiding that.

The two patches rule won't give you a 100% guarantee that the student won't disappear: there's always a chance, even with people who have been in the community for long enough to be trusted. However it'll bring you much closer to a good understanding which students you really want to work with.

Not every student will agree to this rule. In that case do your best to explain why you have that rule in the first place.

If you can, arrange a phone or Skype interview with potential students. It really helps making your choices, especially when you have a high student/slot ratio.

Also, make sure that your mentors really have the time to follow the work of their future students. I know some projects (such as darktable) that were so lucky that they basically had to just keep an eye on a Git repository where students slaved away and wrote really high quality code. But in some cases your mentor is to spend an hour or two every day.

Make it a rule that all development happens in a public repository, and the student doesn't keep things in a private branch too long. Let them know that it's OK to commit code that doesn't look beautiful as long as it gets better and keeps coming. Otherwise you just lose control of what's happening.

A friendly advice is to use some sort of decentralized version control system such as Git or Bazaar. It makes merging GSoC branches to main development branches far, far easier than in case of SVN.


Alexia from the GIMP team contributed this part of the article:

Don't take a student that hasn't come forth, presented his project ahead of time, hasn't shown deep interest in the plan and hasn't built the development version before even applying. They won't work out.

If the student is not communicating and hasn't delivered on midterm goal, flunk'em. Being nice is good and all, but if it's not working, then it's not working. If the student is communicating and is making at least satisfactory progress, then letting something little pass is OK.

Keep everybody in the loop. Make sure communication happens in a public channel. Students seem to think they just need to communicate with their mentor. This severely limits their ability to get things done and reduces quality of their work. Most projects have some role distribution and projects often cross expertise boundaries.

Have a design phase when the basic structure is established.

Keep a hand on what is going on and sort blocks quickly. Students sometimes get stuck on something and spend too much time trying to sort it out on their own. I encourage my students to ask in aforesaid public channel as soon as they have been stuck for more than 15 minutes. If it's a trivial thing, it gets sorted fast, if not student could have been stuck on it for days, now it may take a few hours for a seasoned developer or mentor to see. This is also why public repository is essential. Everybody needs easy and fast access to the code.


Over last several years Google Summer of Code has become a major part of some rather well-known projects. If you treat it right, you're going to have tons of fun, great experience, useful new features in your favorite application and a valuable line in your CV.

Personally I expect this summer of code to be exhausting in terms of projects I'll have to follow and report on :) I've no doubt that we are going to see some really exciting development to benefit all of us.

Was it useful? There's more:

2 Responses. Comments closed for this entry.

  1. Kevin Brubeck Unhammer 05 February 2012 at 6:07 pm

    Thanks for the writeup :)

    Note that even with patch requirements, you can have less-than-ideal contributors; e.g. the smart, but lazy, hit-and-run contributor who within the first two weeks creates a module that works fine on its own for a limited test case, then never bothers with the tough problems of getting it integrated and testing on real-world problems … I’m not sure how to avoid that, other than focusing on integration and handling real data from an early stage (also, I guess, ensuring that the challenges are interesting enough for that kind of student).

  2. I have read several excellent stuff here.
    Certainly worth bookmarking for revisiting. I wonder
    how much effort you place to make the sort of magnificent informative website.