Growing pains for Google’s Summer of Code

As the second Google Summer of Code (SOC) winds down, most participants agree: the program, which pays selected students to work on a free or open source software (FOSS) project for three months, is a unique and exciting opportunity, but needs to continue efforts to become more organized. Those who were previously involved tend to agree that this year was less chaotic than last year. However, whether they are organizers at Google or students or members of mentoring organizations (the projects accepting students), most participants this year also see the need for more structure. Many of them also offer concrete advice about how participants can get more out of the program if it happens next year.

Part of the reason for the growing pains is the sheer size of the program. According to Leslie Hawthorn, the program coordinator, SOC accepted 630 applications this year, an increase of over 50% from 2005. The number of mentoring organization increased even more, rising to 107 compared with 40 in the first year. Although the total number of applicants was about half as large as in 2005, Hawthorn says, this is because the expectations were more clearly expressed. “We think we ended up getting fewer applications that were vaguely or poorly formed,” she says. Even so, the Google organizers had to process over 6300 applications.

Despite these scaling problems, Hawthorn and open source program manager Chris DiBona point to significant improvements in how Google organized the program this year. This year, the program was administered by a web application, rather than email. Although some applicants agreed with Rodney Thayer from The Schmoo Group, a security project, that web forms made it “hard to find a human,” Hawthorn and DiBona suggest that the switch greatly reduced the time they spent administering the project. Hawthorn also points to improvements in payment, such as paying students in three parts instead of giving them a single lump sum at the end, and allowing them to pay taxes in their own countries rather than having them deducted automatically by Google. Another improvement was a midterm assessment of students’ progress, which most agreed helped to keep projects on tracck. Proof that these changes made the program run smoother despite the increased scale is that DiBona predicts about a 78% final success rate — roughly the same as last year’s.

One improvement that will not be implemented in another SOC is an incentive program to increase the participation of female programmers. Hawthorn says that, next time, Google will make greater efforts to encourage women to apply, but would leave it up to the mentoring organizations whether they want to implement their own programs to recruit women. In addition, Hawthorn suggested that Google would “consider” funding future programs specifically aimed at women, as it did this year with GNOME’s Women Summer Outreach Program.

Although some participants say Google’s efforts to improve administration didn’t go far enough, all seem to see those efforts as steps in the right direction. “Google made several huge improvements to the program,” says Dawn Thomas, a student who participated in both years of SOC. “It became much more mature and smooth this year.” Several others made similar statements.

Student reactions

Just as Google’s organizers found themselves getting more organized, the students applying for the SOC became more focused this year. In 2006, Thomas says, echoing other returning alumni, “I was working in a more professional way.”

Part of the reason for this improvement is the tighter structure of the SOC in 2006, including many mentoring organizations having a clearer idea of the sort of students they were looking for. For instance, Bart Massey, who spearheaded Portland State University‘s sponsorship of several new independent projects, says that he tried “to focus on students who looked like they could be self-sustaining.” However, much of the reason for changes in students’ approaches to the SOC appears to be a growing body of knowledge of what to expect and how to get the most out of the experience.

Gregory Brown, who was already a contributor to Ruby Reports (Ruport) before being accepted into this year’s SOC, has codified some of his experience on his blog. Although Brown complains about several aspects of the SOC, including the lack of feedback for applications sent to the program, and suggests that mentoring organizations need to prepare earlier and define the role of mentors more clearly, he also gives concrete advice about how students should approach SOC.

“Payments are slow,” he writes. “Do not count on SOC as your primary income source for the summer.” He also notes that although, like many people, “I just sort of assumed that since it’s Google, it has to work like magic,” things were not that simple. “There are still kinks to be worked out,” he says, and urges students to be patient. Most of all, he explains that participation in the SOC is “not a small commitment.” The benefits for students, as Brown sees them, are a chance to establish or expand a project while receiving some serious credentials as a free software programmer. “As an undergraduate student,” he writes, “The completion of this program will likely be my #1 Career accomplishment to date.”

Reactions from mentoring organizations

DiBona observes that mentors and administrators were also more organized this year. “A lot of them knew [SOC] was coming,” he says, “so they prepared for the influx of people, which they didn’t have the chance to do the previous year. It made all the projects a lot more welcoming to people in general.”

Jon Phillips of Creative Commons suggests that, this year, mentoring organizations were able to build on past experience. “There’s been social practices that have been learned for helping students,” he says. For example, he suggests that, while some students may have a philosophical appreciation of FOSS, their structured university experience has not prepared most of them for FOSS development habits. Many, he says, have to be actively encouraged to commit their code regularly so they can receive feedback from peers instead of keeping it to themselves until they perfect it.

David Neary, who oversaw the GIMP’s involvement, agrees. “The danger of SOC,” Neary says, “Is that you’re taking students who are not used to working in a bazaar environment, and pairing them with developers who have that in their blood.”

To avoid such conflicts, several mentors and administrators suggest that organizations should carefully consider their resources. Overseeing an SOC student can be time-consuming, which may be why many organizations that participated last year reduced the number of applications they accepted and, whenever possible, reduced the number of students each mentor oversaw. “The primary recommendation I would make to projects participating in SOC in future years,” Neary says, “is to draw a map of the resources available, and lay out the communication channels for the project and their purpose.” At times, says Sacha Meinrath of the CUWIN Wireless Project, organizations should even be ready to shut down projects at the mid-term evaluation rather than continue to nurse them along.

Others liked the idea of the newly-implemented mentors’ and administrators’ mailing list but, like Meinrath, complained that “the signal to noise ratio was pretty low.” Meinrath suggests that, next time, a separate announcement list might help mentoring organizations get the information they need more easily.

Yet, even while seeing room for improvement, many members of mentoring organizations stated that working with students was almost as beneficial to them as to the students. Besides the obvious fact that SOC gives mentoring organization extra developers and a small influx of cash, many saw personal benefits in mentoring as well. Phillips, for one, says the experience “Helps you to connect with new ideas. But the biggest thing about being a mentor is that it helps you to firm up your ideas. Having to codify open source ”

Massey says, “I got a chance to work with some really bright students, and, once I work with them, it encourages them to work with me again.” He summarizes being a mentor as starting off as a sounding board for the students, then gradually helping them to become his equal.

Enthusiasm and corporate responsibility

If the comments of SOC participants sometimes sound overly critical, the tone and detail probably reflect the greater communication throughout the program. This year, all participants had discussions that gave them chance to develop their thoughts about what they were experiencing.

To put the comments in perspective, I should point out that my request for feedback on this years’ SOC resulted in over 20 comments in the first half hour after it was posted. A day later, the responses were over 60, and I had lost count. All respondents obviously felt that SOC had been an important experience and were eager to talk about it.

This does not mean that anyone was blind to the problems associated with SOC’s rapid growth — but neither were they blind to the program’s immense potential. Sacha Meinrath summarized many people’s reaction when he finished the story of his experience. Thanking Google for its sponsorship, he said, “I think what’s really important here is a return to the ethos of corporate responsibility. I would love to see more corporations take on this sort of thing.”

Bruce Byfield is a course designer and instructor, and a computer journalist who writes regularly for
NewsForge, Linux.com and IT Manager’s Journal.