As you may already know, Umit Project is in as a mentoring organization for Google Summer of Code 2011, and it happens that we just got through the selection process, and earlier today Google announced the winning students!

This year, Umit received 42 proposals, from 40 talented students from almost all continents in the world! We were absolutely astonished with so many talented students willing to work with us this season. So many proposals took us a long while to evaluate, and all of them involved a long process interacting with the student and assessing their capabilities, time commitments, etc.

During my last year at University, I spent about the whole year studying economics game theory, in order to make my thesis about friend-to-friend networks and best pratices for overlay and sharing networks. Game theory is a very interesting topic, and can lead us to choose better strategies based on the problem enviroment, rules and possible odds (or rewards) you can get from each possible strategy. Unfortunatelly, some games doesn’t have good odds for every player in the game, and when we can’t change the rules nor the environment that enforces the odds, we have to take the least worse strategy even when it is far from been optimal. Fortunatelly, sometimes we’re able to change the rules in order to create an environment capable of giving good odds for every player in the game (at least for fair players…).

That’s why the odds stands for: reward the fair player, and enforce bad ones to play fairly.

During this GSoC mid-term evaluation of students performance, I’ve been thinking about the odds of the game we have to play here, and realized some rules that could improve the competition quality and reduce project failures.

I know many mentors will feel familiarised with this situation: One of the students disapper for 2, 3 weeks and appear right before the mid-term evaluation saying that he is way behind the schedule because of problem x and y, and asks for a chance to continue working on the project. But, It is not possible for mentors to know for sure if he is going to do something
if he let Google pay him. This totally looks like a problem we can solve with game theory.

Here are the goals:
- GSoC is intended to help the open source community, by affording students and mentors to create and improve open source projects
- Mentoring orgs want that help, because money is what moves any project forward, and GSoC is a huge help
- Students want to have their names associated with Google, with their own killer open source software and get paid for that (money and t-shirt

And the odds:
- If a student works hard until the midterm, he receives the 2k
grant, and continues his work
- If a student doesn’t reach the midterm eval with a good status
(behind the schedule), two choices are left to mentors:
1 – Trust on student and let google pay him, hopefully that the
student is going to make until the deadline
2 – Drop student, and avoid his midterm payment

The problem is that many students are on GSoC seeking for the money only (that’s why so many are so desperate about the payment delay), and when they reach the midterm and see that they are not going to make it, the best strategy they have is begging for another chance,
get the 2k and give-up his project. This strategy is the best for him, but the worst for Google, Organizations and other students, because:
1 – Google doesn’t want to pay for nothing. Google wants more open source. That’s the main goal of the GSoC
2 – Organizations will be left without the project and the student contributions, and the mentor will have spent his time almost for nothing (almost, because the US$500 counts a lot)
3 – To accept this student, I had to dismiss another that know would give anything to be were this student stands. The bad student wasted his chance, wasted another student chance and wasted the money and time of you guys at Google for nothing.
4 – The bad student receives 2,5k for nothing and is happy because of that

Mentors also tend to choose this strategy, because there is a little chance that student is going to make it until the end of GSoC. Actually, mentors wants so much to have the project the students were allocated, that they give that chance because the strategy of dropping him is even worse than trust him.

My sugestion, based in this analysis, is to change the rules to avoid this strategy, and still
guarantee the goals of Google and Mentoring organizations. But, how can we manage to achieve that?

At midterm eval, if a student is dismissed because he didn’t made his work, the mentoring organization receives his money in order to use it to improve the software design, usability, buy equipments for testings and improve the software, offer that money as a bounty for another person that is willing to solve the problem the bad student left behind, etc. If mentors had that choise, here are the odds:
1 – Students will be afraid of don’t be aproved at midterm, and will be encouraged of working hard before it. As they want the money, they will work harder to have it.
2 – If a student still didn’t make enough to be aproved at midterm, mentors will have another strategy that is better for Google and Organization that is dismiss the student and use his money to make better open source software for the whole community, and the Google’s money served his purpose even with student failure, and mentors will have the opportunity to give another chance to a studnet he dismissed to get the bad one.

I can think about a lot of things that the project needs and can benefit with this money, and the whole community can also benefit from it instead of wasting it with an unresponsive student that wasted his chance to change something in the open source world. With this
student’s money organizations could pay for design, books, website, servers, offer the bad student’s money as a bounty to have the problem solved and a whole load of other things that the project needs.

I don’t know if the Google folks are going to agree with my point of view, but I just wanted to share my thoughts and maybe help improve GSoC rules, reducing the amount of projects that fails. Agreeing or not, Google is still rocking a lot with Summer of Code, and I only have to say thank you for the opportunity I’ve been having these years.

Cheers!