GSoC 2008 Student Guidelines


We want every student experience to be productive and educational, and we understand that for many students this will be a larger and more open-ended kind of project than you have previously completed. We believe that open and frequent communication is vital in helping you succeed.

Experience gained through previous Google Summer of Code efforts and other mentoring and management activities over the years has led us to establish these requirements for student participation. We understand that some students may find themselves temporarily unable to meet these requirements due to events beyond their control, such as unexpected work, school, or family demands. However, long-term failure to meet these requirements will result in removal from the program.

  • The sole storage for your GSoC work cannot be a personally-owned machine. This means that every week, or more frequently, your work must be copied to a server operated by the Plan 9 GSoC project or committed to a Google Code repository.
  • Every Sunday, by your local midnight, your project's top-level CHANGELOG file must be updated. Your mentor and the project administrators will scan for status updates at least as frequently as every Monday at their local noon.
  • Before the coding period begins, you and your mentor will agree on at least one milestone to be reached before the mid-term evaluation.
  • Your mentor will be expected to remove you from the program at the time of the mid-term evaluation unless your repository and changelog have been up-to-date and you have met the agreed-upon milestone.


  • If you aren't yet a user of Plan 9 or Inferno, please understand that these systems are fundamentally different from what you're used to. This is why we like and use them, but you should expect that getting started will require a genuine investment in reading and a willingness to do everything a different way than you're used to.
  • If you are proposing a 9P/Styx project which will not run on Plan 9 or Inferno (e.g., an embedded-system project or a Linux/BSD/*ix project), we expect your design and implementation will benefit from a healthy understanding of "the mother ship".
  • If at all possible, read up on Plan 9 and/or Inferno (see papers on the web site) and complete an installation before finalizing your application.
  • You should subscribe to the 9fans mailing list as soon as possible and commit to keeping up with it. While most GSoC-related traffic will be carried on a dedicated mailing list, discussions on 9fans will provide useful background context, and we hope that after following it for a few weeks you will chime in as appropriate.
  • Try to make it clear in your application that you understand the parts of the problem and how difficult they are. A conservative plan with some clearly achievable milestones will probably be more attractive than an all-or-none "big bang" plan.


Don't panic! We do not expect all incoming summer students to have been born knowing:

  • how to read 20,000 lines of code and see how the parts fit together
  • how to debug obscure installation problems of obscure operating systems
  • how to guess which way a piece of hardware deviates from its documentation
  • how to make and adjust a development schedule In general, when you don't know what to do next, ask somebody.

For problems related to installation, configuration, source control, and debugging tools, we recommend that you start with the #plan9 and/or #inferno IRC channels on If help is not available in real-time via IRC, we suggest sending mail to the plan9-gsoc mailing list.

For issues specific to your project, do not hesitate to contact your mentor. Furthermore, it will generally make the most sense for these communications to include both your mentor and your backup mentor.

If you feel the relationship with your mentor is not going well, please do not hesitate to contact the Plan 9 GSoC administrator. Personality conflicts do arise between well-meaning people and we will work to resolve issues as well as we can. Please realize, however, that it is important for you to get help right away: the role of the project administrator is to help you make forward progress so you can meet deadlines, not to override a mentor's correct observation that program requirements are not being met.