A musical notation system for KOffice, a cross-platform kiosk browser, a help system editor for GNOME -- these are just a few of the projects completed in this year's Google Summer of Code (SOC) event, during which Google paid students to work on free and open source software projects. The innovations in this third year appear to have enriched the experience for participants, but not affected the project completion rate.
First, the official statistics: According to Chris Ulbrich from global communications and public affairs at Google, 905 students participated this year, an increase of almost 45% from last year. These students were selected from 6,200 applications, and interacted with 1,500 mentors in 130 programs in more than 90 countries worldwide. The program overall ran on a budget of $4 million.
In response to feedback last year from students and participants, Google introduced two changes into this year's SOC. The first was a bonding period between acceptance into the program and its official start, so that students would have a chance to get to know their mentors and the projects they were assisting. The second was mid-term and final evaluations for both students and mentors, which Google hoped would help keep students on course and provide feedback for everybody involved in the program.
Those who responded to Linux.com's request for reactions to the changes generally agreed that they improved the program.
Reactions to the bonding period were especially positive. Buddhika Lakanth Semage, a Sri Lankan student who worked on Mallard, GNOME's new document system, says, "It really helped me to get in touch with my organization and to get to know how things worked." Similarly, Arpit Jain, a senior undergraduate at the Indian Institute of Technology in Kharagpur who worked with ikiwiki, says, "I very much liked the way the community bonding period went. Hanging out in IRC sessions and talking to some of the greatest developers around was very informative."
Others, such as Hyrum K. Wright, a graduate student at the University of Texas at Austin who worked with Subversion, found the bonding period useful mainly for planning. "Although I already knew the community and my mentor," says Wright, "once we knew that I would be working on the project, we were able to spend a large amount of time doing design work during the bonding period. I think that having this time upfront helped the process to go much more smoothly, as when time came to implement the features, I was ready to run, and there weren't a whole lot of questions regarding the scope of the project."
Respondents were less personally enthusiastic about the evaluations, but recognized their potential value to the program. Semage gives a typical response when he says, "It will be more useful for Google to get ideas about how to do the next SOC and for organizations to know what went wrong or what went good with their SOC campaign this year, rather than helping students." Semage suggests that the evaluations would be more useful if both students and mentors could see what had been said of them.
In other aspects, too, the program appears to have been better organized than in previous years. Dawn Thomas, an undergraduate at the Indian Institute of Technology in Kharagpur who participated in the 2006 SOC, says, "Google is also getting better organized in terms of almost no payment delay" -- a problem that many students had complained about in the first two years.
However, despite these changes, the completion rate for projects this year continued to vary. VideoLAN, a very loosely organized project, reports a completion rate of 50%. By contrast, the Open Source Lab at the University of Oregon declared all four of its projects a success.
Overall, Ulbrich cites an average completion rate of 81%, a rate roughly the same as in 2006. Ulbrich says that Google is "happy" with the rate, especially considering the increase in the number of students.
Still, the inability to raise the completion rate seems a problem that deserves greater attention. Perhaps the constancy of the rate reflects the inevitable casualties of a large program that is run online, where it's easier for students to disappear than when they are meeting mentors face to face. Possibly, too, the variation in completion rates reflects differences in organization and experience with the SOC among mentoring projects.
Whatever the interpretation of the constant completion rate, this year's SOC was successful by another metric: The number of students who continue working in a project after the SOC is finished.
"I plan on continuing to work on the project for a long time yet," says Wright, talking about his interaction with Subversion. "SOC helped cement my interest and resolve to work on the project long-term."
Similarly, Thomas notes that his university has "already heard of many students continuing the work with their own project." Jain, for instance, says that, "Now, as I know the way, I generally hang out in lots of IRC sessions of many open source projects." In addition, Jain says, he and the other two students who worked with ikiwiki are now "working on starting a new project of our own."
In much the same way, Scott Johnson, a doctoral student at the University of Minnesota, may not necessarily continue working on Crystal Space, a 3-D software development kit for games, but his SOC experience has sparked his interest in the entire free software community. Now, Johnson says, "Being a part of this community is very important to me. I loved the experience, and I am going to start looking for job opportunities in open source development."
If these comments are as typical as they appear to be, then perhaps SOC's main legacy year after year will not be the short-term contributions to specific projects after all. Instead, SOC's real value may be in the number of people whom it introduces to the free and open source communities.