Sunday, March 20, 2011

Writing a good Google Summer of Code application

If you are a student and want to work on a Haskell project during this year's Google Summer of Code, it’s time to start thinking about which project you’d like to work on. Whatever project you chose, it’s important to think about two things: scope and impact.

The scope of the project should be such that you can actually finish it in one summer. This might seem obvious, but we’ve had several projects in the past fail because they were too ambitious. Avoid projects that have too many unknowns and thus have a high risk of failing e.g. trying to implement a new GC algorithm that performs competitively with GHC’s current GC.

I would also like to discourage work on brand new libraries. While we’ve seen a few successful libraries come out of GSoC, many others never saw much (or any) use. Creating a good API and a high performance implementation takes a lot of Haskell and software engineering experience, something most students lack, almost by definition. We don’t need yet another library of so-so quality on Hackage, there are already plenty of those (some of mine included).

The impact of the project is also important: the more people that can benefit from your work the better. The best way to have a large impact is to work on an existing piece of infrastructure (like Cabal or Hackage) or library (like text) that already has lots of users. Work on games or niche libraries don’t make good GSoC projects.

Writing a good application

Assuming that you’ve picked a project with a sensible scope and enough impact, you need to convince the Haskell GSoC mentors, a group of experienced Haskell hackers, that you’re the right person for the job. You do this by

  • appealing to previous Haskell experience (e.g. coursework and/or open source contributions), and
  • by showing that you understand the problem you’re trying to solve.

The best way to show that you understand the problem you’re trying to solve is by drafting a design. The design should be as concrete as possible. A design is not a requirements specification: don't list the features you're going to implement, explain how they are to be implemented. I’d suggest spending a day or two tinkering with the code you intend to work on. Perhaps even try to solve some small part of the real task. This will teach you a lot about the problem and help you create a much better design.

In the next few days I’ll try to post some projects I think make good GSoC projects.

No comments:

Post a Comment