Google Summer of Code 2009 Wrap-up

Attending the Google Summer of Code Mentor Summit feels like the perfect time to finally write the wrap up of this year's Google Summer of Code. So, what did we learn in our third year of participation?

We had 5 students funded by Google to work on Tor over this summer, plus 1 more for The Electronic Frontier Foundation. We had to pick these 6 out of 32 applications, which was a pretty hard process for us. In retrospect, there were at least 2 more students that we'd really have wanted to work on Tor but that we were not able to pick. Fortunately, they stuck with the project anyway, writing a neat relay monitor and helping reimplement Tor in Java for mobile devices.

Does that mean we should have asked Google for more slots than 5+1? Definitely no. 5 students are the limit for the Tor project. We did make the mistake of asking for too many slots and mentoring too many students in 2008, and we have learned our lesson. It was good to have 5+1 slots—even 4+1 would have worked fine. The limiting factor simply is mentoring time. Even this year, some of our mentors bit off more than they could chew. Mentoring takes more time than one would expect: answering students' questions, keeping track of their code, deciding whether they are still on track or need more help, etc. At the same time, the mentors' schedules are already overfull, communication is hard while traveling, unexpected things happen in life, and so forth. So, in order to compensate for these situations, we need backup mentors to step in and help out. That doesn't allow for accepting even more students.

Another lesson we learned this year is that both students and mentors need to become more open with respect to letting the world know about their progress. Having to write up status reports every week or two is a great way to avoid surprises. Students know that, but it still takes time and effort to write status updates. Mentors know that, but they feel they already know how far their students have got. Organization admins know that, but they can only appeal to their students and mentors so often and then need to trust them to do the right thing. This is bad. The lesson learned should be that students that do not write three status report before mid-term or final evaluation automatically fail. Sounds harsh, but it might have avoided having to fail one of our students at this year's final evaluation.

So much about learning lessons. What did our students achieve in their summer projects? We asked all of them to write up their experiences in a blog post. Read more about Kory's, Chris's, Sebastian's, and Runa's Summer of Code of experiences. We are really happy to see that all four of them stick with the Tor project and keep on contributing code. Kory is working next on the implementation of hidden services in a Java version of Tor. Chris keeps sending us patches for libevent that fix problems with Windows. Sebastian helps in diagnosing and fixing bugs in Tor and does a good share of user support. Runa helps us set up a new virtual machine hosting our translation portal.

In retrospect, we think that one of the main motivating factors for our students to stick around in our community is the fact that we met with them in person. We met Chris (who worked on Polipo) and Damian (who worked on the relay monitor) at this year's Privacy Enhancing Technologies Symposium in August in Seattle, WA, USA. A few days later we met Sebastian at Hacking at Random in the Netherlands. Roger and Jake met Kory in person in September in Philadelphia. Only Runa we did not meet in person, but we hope to see her at the Chaos Communication Congress in December in Berlin, Germany.

Thank you, Google, for the Summer of Code program! We really appreciate being part of it!