The primary skill needed to work well with Plan 9 or related projects is an ability to think creatively about problems. While the Unix lineage of all these tools is clear, we do a number of things differently. Students should be prepared to be working in a somewhat unfamiliar - but very exciting! - environment.
If you're working on Plan 9 itself, your project will almost certainly be done in C. We use a dialect of ANSI C with a few restrictions, a few extensions, and a more limited pre-processor. If you're good with ANSI C, it'll be an easy transition. There is a tiny bit of assembly in the platform support; if you're working on a port you may need to be able to handle that.
For Inferno, the kernel is written in C while all the applications are written in Limbo, a high-level language vaguely similar to C (and an ideological ancestor to Go). If you're familiar with C or other C-family languages, it should be a relatively easy learning curve. If you're looking to work on a project for Inferno and are not already familiar with Limbo, you should get at least a high-level familiarity while preparing your application to GSoC and be prepared to be reasonably proficient before the start of the coding period.
Skill requirements for other projects will vary with the specifics. For example, v9fs will require C work in the style used by the Linux kernel, while 9p/styx servers in other languages could be done entirely in those languages. If a project on our ideas page has particular skill requirements beyond these, we'll list them there.
Over the course of the summer, students will be engaged in a project with their mentor that is designed to be educational, productive, and fill a summer. To ensure that this goes well, students should be prepared for the following:
- Students are, of course, expected to follow all Google's rules for the program, and to have read the Student Handbook. This includes filling out the midterm and final evaluations in a timely manner.
- As with GSoC generally, our students are expected to be working on their project more or less full-time. In particular, this means you are unlikely to be successful if you have other intensive commitments, like an unrelated full-time job or extensive travel plans.
- Students will be expected to be in regular contact with their mentors. You should discuss exactly what this means with your mentor, but it likely means every day or two initially. This daily(-ish) contact needn't be particularly in-depth, but should indicate what you've been doing since the last such contact. Lines from a changelog or commit messages would be great to include here, but discuss the exact form with your mentor.
- You'll be epxected to make a weekly report every Monday to the plan9-gsoc mailing list. This should give a reasonably detailed account of what you've done over the past week. You needn't give line-by-line code review, but it should be enough so that casual readers of the list know what you've been up to.
- Students must keep their code in a publicly-available place, with updates every day or so reflecting the current state of things. Don't worry: if it doesn't compile for a few days nobody's going to hunt you down, but we need to be able to see what you're working on to make sure you're not heading off in unproductive directions. This year, acceptable repositories are limited to mercurial repositories on bitbucket or a contrib directory on sources, the main community 9p server. Discuss with your mentor which option works best for your project.
- Each student will be assigned a backup mentor. This mentor may not have much day to day interaction with you, but will be following along in case they're needed. Keep them in the loop by CC'ing them on any mail sent to your mentor (and not sent to the plan9-gsoc list).
- In the unlikely event that your mentor becomes uncommunicative or unresponsive, let your backup mentor and organization admins know right away.