i, quaid

Back in the fall of 2009 I wrote a report that looked back on the Fedora Project’s five-years of involvement in Google Summer of Code (GSoC.) One glaring truth was that year-over-year we had not gotten any larger – eight students in 2005 to ten students in 2009. Similarly, our own Fedora Summer Coding had eleven funded students in 2010.

Is there a natural reason we have leveled off just shy of a dozen student projects? Is that all we really want done? All we are prepared to support?

The conclusion I’ve come to is that this is the level we get for the effort put in. Other projects that have more student slots simply have more people organizing as administrators, as well as mentors — more people making more smart decisions. They seem to be drawing from a common set of open roadmaps. Maybe the project-wide experience has made it so people actually watch out for opportunities to include students in the roadmap.

By contrast to what I’ve seen in Fedora, projects such as the Apache Software Foundation (ASF), GNOME, and KDE routinely have three to four times as many student slots. There are numerous reasons why, but I think a core part of it is this:

• The KDE project has a huge idea list this year – 120 as of this writing. Last year they got 46 student projects accepted to run for the summer.
• While GNOME’s page for this year is still a bit short as of this writing, they go through a vetting process for ideas and 2010’s idea page was 30 strong, well-organized ideas.
• Apache had 39 projects in 2010 and 32 in 2009, and some of them must have come from big project lists such as this list of 70+ project ideas in 2009.
• By contrast, Fedora’s idea page this year just grew to 20 items without organization. Past years are similar, such as thirty for 2010, fifteen for 2009, and thirty for 2008 all poured on to the page with a jumble of qualities. No vetting for quality and commitment of the mentors. Hard ground for much seed to get purchase.

So we have fewer ideas out there on average, and they are jumbled on the page with no organization against project wide goals or a roadmap.

What part do idea pages play?

From what I’ve seen, Google assigns student slots based on the interest students show in a project. More ideas, more coordinated marketing across the teams, and more work to get students’ attention generates more applications. That seems to be an important factor in determining how big a project can scale for students.

To make that attention happen requires commitment from each mentor and sub-project team they are associated with. To get a winning application, an idea might get three or four or ten that don’t quite make it. Mentors have to work fairly with all the students, trying to improve applications (within reason), and making decisions in the end to pick three dozen from an original of perhaps two or five hundred applications. Not much problem though when you’ve got a hundred mentors reviewing.

I reckon that a well organized and large pool of ideas comes about best when there are enough people working on making that happen. Subsequently, that becomes enough people to actually manage the increased program size, the applications, the mentoring, and so forth. Thus, the ideas page becomes a fair representation of how ready a project is to scale to what size.

If some folks in Fedora would really like to see our GSoC program be two-times, three-times, or even four-times the size that it has been, I put all this out there in hopes that it helps.

(Numbers in this post that are not linked back to the source originated from queries to Melanage at http://code.google.com/soc for the year specified in the statistic.)