Google Summer of Code Mentor Summit 2009

Last weekend Google hosted their 3rd annual mentor summit, following the end of their 4th annual summer of code. The mentor summit is when a few hundred mentors gather together and participate in an unconference style conference. I went for the Pidgin project, along with Gary Kramlich and Ethan Blanton.

The conference was super cool. I got to be humbled by talking to a whole bunch of really smart open source people. Here are my notes:

On One Laptop Per Child (“OLPC”)

I’ve been wondering for a while whether the OLPC program could actually make a difference. One session, led by Bryan Berry of Sugar Labs, makes me think that it can and already has. Bryan is the co-founder and CTO of OLE Nepal, an organization helping deploy OLPC in Nepal, and creator of Karma, a framework for creating interactive activities for the Sugar environment using javascript and html5.

Seeing demos of the exercises they’ve created and hearing his first hand stories was pretty incredible. At least some schools in Nepal teach by having the teacher recite something (e.g. “one plus two is three”), and all the students repeat it and memorize. But this often fails to teach the students why one plus two is three. In one example a student was asked “what is one plus two” and they replied with “three.” But the same student was not able to answer “what is two plus one.”

Children in third world countries generally want to learn–more so than children in the US. They realize that education can help them achieve something greater in life. And computers are interesting to them. Combine students, computers, and engaging lesson plans about math, geography, etc. and the students will have a more varied education and will learn better.

On Forking Open Source Projects

Forking helps keep people motivated. It increases competition, keeps developers on their toes.

A fork could be like a “research and development” branch. People work on crazy fun new features in the forked project, and the good stuff gets merged back into the original.

The smaller the project, the more willing the maintainer should be to give people access. There is a natural inclination to be protective of your project–it’s your code, your baby. But you must be willing to give up control for there to be forward progress. This reminds me of dictator governments like Cuba/Fidel Castro and North Korea/Kim Jong-Il. The dictator is afraid to relinquish control for fear of what might happen.

Benefits of a fork? Developers have more freedom to do what they want, which allows for innovation. The best project will survive–if developers want their project to survive then they must make decisions that benefit the community at large.

Downsides of a fork? Development effort is divided. Users might not know which project to use. Distributors may not know which package to distribute; distributing both means more work.

Miscellaneous

STUN – A protocol used to determine your public IP by asking a server on the “outside” Internet

TURN – A protocol used to proxy traffic through an intermediate server. Written with SIP in mind. Increases the likelihood of being able to establish a connection to another party, but it also introduces an additional hop, which leads to lagginess, which is bad for voice/video communication.

ICE – A protocol that describes a method for establishing a direct connection with another peer. Written with SIP in mind. It uses an exhaustive algorithm to try every possible IP address for yourself in the hopes that one will work. You construct a list of your host’s IP addresses plus your public IP address determined by using STUN. This information, along with a fallback TURN server, is sent to the other party, who begins attempting to connect.

OpenAFS is under active development, and is used by some very large organizations