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 practices for overlay and sharing networks. Game theory is a very interesting topic, and can lead us to choose better strategies based on the problem environment, rules and possible odds (or rewards) you can get from each possible strategy.
Unfortunately, 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. Fortunately, 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 familiarized with this situation: One of the students disappeared 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 evaluation with a good status (behind the schedule), two choices are left to mentors:
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:
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 suggestion, 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 evaluation, 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 equipment for testing 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 choice, here are the odds:
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.