The second edition of Google
's Summer of Code is winding down, so I figured it'd be a good time to post my (unsolicited ;-)) thoughts on what they should do next time around. Here are my starting points:
- The world will be a better place if everyone studying software engineering at college or university has an opportunity to get involved in a real open source project.
- It's no good to say, "If they want to volunteer, there's nothing stopping them," because the rational economic decision for an undergrad is to invest time in things that will earn them grades --- the network benefits of involvement in open source are too fuzzy.
- Google can't afford to give $5000 to 20,000 students a year. Even if they could, the open source community couldn't handle 20,000 newbies every September.
The solution is to give students course credit for their work on open source projects, but of course, it's not that simple. First, there has to be a quality filter: someone, somehow, has to filter out those students who would be a net drain, or open source projects will (sensibly) choose not to play. Second, someone has to evaluate the students; at most universities, this can only be done by people who have some official standing.
I think both issues can be resolved by bringing the ACM
, the IEEE
, and other professional bodies into the loop. Everybody wins:
- Students who want to get course credit for open source projects have to be student members of [name of professional body goes here], and have a GPA of [arbitrary threshold around a 'B' goes here]. If there are still too many candidates, it would be simple to restrict entry the top N students in a one-day programming competition. The professional bodies win by getting more members; the students win (even if they don't realize it right away) by becoming involved in the organization(s) that are going to shape their careers.
- Instead of giving money directly to a couple of hundred students, Google spends part of its money on a staff of 6-8 full-time ematchmakers. Google wins by lowering its recruiting costs: as I discovered at EPCC and U of T, projects like this are the best interview tool there is. I predict that if Google takes my advice, a headhunting service called "Google Jobs" will launch within two years, and become self-supporting almost immediately.
That leaves the problem of assessment. Sadly, most computer science professors don't know enough about modern software to be able to judge whether someone's end-of-term patch is worth an A or an F. However, many open source projects have at least one committer with an advanced degree of some kind or another. With a bit of prodding from [name of professional body goes here], I could see at least a few universities giving these people adjunct appointments (which are usually unpaid).
Looking at this year's sponsor organizations
, I could see 12-15 groups being willing to give this a trial run. The open source organizations win by getting (a little) more work done, and (more importantly) by growing the pool of potential committers. The universities win because their programs look more relevant (an important issue in an era of declining enrolment), and because this sort of cross-campus evaluation gives them a good way to assess the strengths and weaknesses of those programs.
Would it work? I have no idea, but it'd be fun to try. The biggest hurdle to overcome is probably Google
's well-deserved belief that Summer of Code isn't broken, and therefore doesn't need to be fixed. There's also the complementary problem of getting the attention of the ACM
and other bodies, which are not famous for their sense of adventure. Getting universities and open source projects on board would also require some work, but probably not much. As for students, I think they'd have to be beaten off in droves ;-).