Google Summer of Code — my take

So it has been a week since I reviewed 32 Google Summer of Code proposals for FreeBSD. If you don’t know anything about it, try to see Google’s Google Summer of Code website. In short it’s a sponsored action that lets students spend their summer (8 weeks) hacking Open Source projects, learning new stuff, helping the community, growing as programmers and engineers and additionally – earning some additional money.

Organization gets $500 for accepted project. Students gets $5000 for accepted project. In the middle of the deadline (midterm) students receive 50% of their expected compensation: $2500. The rest comes at the end.

Since this was my 1st GSOC as a mentor and administrator, I decided to give a short summary regarding what I think about GSoC:

1. It’s a very valuable program for young people, who otherwise would have gone unnoticed.

2. It’s a good boost in the community. GSoC gave some more life in Open Source, since even if not for the pure technical joy (at first), people decide to hack stuff for fun and profit (in the middle-east countries $5000 for 2 months of work is pretty damn good)

3. It’s a good give back from Google, who tends to steal lots of valuable people from the community. Young people bring some more fresh air into the projects, and sometimes are valuable in terms of providing feedback to the project from the point of view of newcomers.

Due to the point no. 3 I feel FreeBSD Project should pick projects smartly. Basically we don’t want to stretch Google’s generosity too much. As I mentioned before, students get $500 for the proposal acceptance. Thus, if FreeBSD picks more projects, Google needs to spend more AND people from FreeBSD community must spend more time on mentoring and coordination.

This is big responsibility that comes with a lot of work.

So, yes, we all do agree Google is very rich. However, we don’t want to accept proposals that which we know are not quite right. Don’t get me wrong, it’s not that proposals get declined due to political reasons or our laziness. I do know that some proposals for another Google event, Google Code-In, were very good. However the amount of coordination that went into the event basically overwhelmed the value that they were bringing.

In Google Code-In, sometimes I also saw right away that attitude of the participant wasn’t great. We had cases of Linux users applying for FreeBSD projects and working on FreeBSD still now knowing, that FreeBSD isn’t Linux.

Google Summer of Code is different. This is more serious event, since you have older people working on projects. People are older and smarter, projects are bigger and prices are bigger too.

We expect more from you. You have a chance to work with highly experienced people, have fun and get some bonus points in your resume, so please spend some time on your proposal and ideas.

Perform research on the topic. Learn as much as possible before applying (please, please, learn the basics of the project X; if you apply for project X, use Google or Wikipedia and read page about X 10 times). Look what previous proposals looked like; compare your proposals with it. Figure out what people from previous years of GSoC did. Is their work available? Do you want to work on stuff that other people started, but didn’t finish? Look what other people do nowadays. Is your project aligned with their work? Is there an overlap? What’s the interest in your project? Are other people are willing to review your work? Do you have any competition?

These questions seem easy, but they might be a key for understanding:

• If you really want to work on your project? There are a lot of things (devil is in the detail) that can be overlooked and your project may not be as fun as you initially think. Try to do your best to analyze the project from the ground-up. Maybe try to ask more experienced people. Do your best to figure out, what will really have to be done to accomplish your project.
• Will you find an interest in your project? It is more motivating when your project is interesting to more people; at least more than 1 person (you). Basically, it is much better to see people giving you feedback and pushing you to actually work on The Thing.
• Will you be able to find a mentor? Problem with projects like The FreeBSD Project is that a lot of people from the project are full-time professionals with limited amounts of time. Sometimes, you may find really bright idea, but you’ll be unlucky due to all the Important People and Smart Individuals with an expertise in the area being busy developing Next Big Thing or just working on their contracts. Pick people who happen to be regularly present on the FreeBSD mailing lists and try to pick those who work in an area that overlaps with your project.
• Will the work be useful after you finish it? Nothing more to add.

Don’t get me wrong - if I had submitted the proposal it wouldn’t have been perfect either. However, I think I’d more or less know the field. So once again: mistakes are fine, but if you didn’t analyze the case deeply enough, it may turn out that your proposal is declined.

I think the reason people submit bad proposals is because they think the acceptance rate is close to 90% successful. Indeed, it has success, but it’s not like 90% successful. Let make it 10% success. Or 5%.

But remember that working on the project is just like a normal job: you have assumptions, you have requirements imposed by your proposal, and you have some hints, but you also have a lot of work you must do by yourself.