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:
It’s a very valuable program for young people, who otherwise would have gone unnoticed.
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)
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:
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.