Before considering students for the Google Summer of Code, we ask that they provide a patch against the current codebase. Admission to the program is competitive, and some candidates may perceive the patch as part of the competition. It is not. The competition is at the proposal level, but you need a patch for your proposal to be considered. Why do we ask for a patch?
Think of it this way: when you take a taxi ride from the hotel to the airport, you trust somebody you don’t know. However it’s not blind trust: some simple and implicit observations give you good reasons to trust the driver: if he can knock at your door, he must have the vehicle to get there and the skills to drive it. Furthermore, while he’s loading your luggage into the trunk, you get a chance to observe his vehicle and his behavior. By the time you start the journey with him there are still no guarantees that he won’t get lost or have an accident, but at least you know that he has the basic tools (the car) and the basic skills (he drove it up to your door). You have done your due diligence.
Similarly, you need to quickly build the same level of trust with our community. Do you have the tools it takes to hack into the code? and do you know how to use them? When a contributor uploads a patch to our mailing list or to our tracker (preferred, but to make sure you get noticed please post a link on the mailing list too) he builds instantaneously the same level of trust that the unknown cab driver builds with every new customer: he implicitly shows that he has the tools (hardware, operating system, internet connection, coding environment, repository access) and that he can use them for basic operations.
This is just the beginning of the journey, not the destination. It is a task designed to show basic proficiency. We will not choose our student based on this task. We will choose her based on her proposal. But we won’t consider her proposal if this task is not done, because what use is a driver who promises to get us to the airport if he can’t pull up around the corner and park in front of our door?
My recommendations for the patch, at this point:
- Get yourself the right tools. Ubuntu, Windows, OS X, almost any platform will get you there. Some are easier than others. When in doubt, ask on the mailing list.
- No inspiration? Check Bruno’s suggestions.
- Get it done and out of your way quickly, so that you can focus on your proposal in the little time left before the deadline.
What you should not try to do is something like this patch by 2008 student Tim (likely 2009 mentor). It is very nice, but it was done after a Summer of Code, not before. Those who started early like Lukáš have had plenty of time to establish a deeper relationship with the community, and produce some big patches. If you are starting just now, you need to focus. The deadline is April 3. You can impress us between the moment you get the patch done and the application deadline, April 3. And if you need help, ask. We’re here to help you. Good Luck.