Checklist for FreeBSD Administrators to Run a Successful Google Summer of Code

Setup ideas page

The ideas page is used by google to evaluate possible mentor organizations, and by students to choose which organizations to apply to. This page should include specific project ideas, as well as proposal guidelines and other administrative details for the students.

Example Proposal Guidelines Section of Ideas Page

Students are responsible for writing a proposal and submitting it to Google before the application deadline. The following outline was adapted from the Perl Foundation open source proposal HOWTO. A strong proposal will include:

Please note: in the past, a significant number of proposals have been received that consist solely of copies of ideas from our ideas list. Proposals of this sort are rejected without further onsideration. A strong project proposal will consist either of a detailed original proposal or a significantly elaborated proposal from the idea list, and must reflect the necessary background work to understand the problem and possible solutions. Special attention is paid to proposals where the student has identified appropriate members of the community in advance and worked with them to develop their project idea prior to submitting the proposal.

Note, this is not the canonical location of this text. Whatever guidelines are agreed upon above must be checked into www/en/projects/summerofcode.xsl. One of our goals is to help students write better proposals without setting an impossibly high bar that prevents participation.

Apply to Google to participate

When the ideas page is ready, we need to submit an application to Google to participate in the program. This took place in March for the 2008 program. For the 2009 program, we used SummerOfCode2009Application.

  1. What is your Organization's Name?

The FreeBSD Project

  1. What is your Organization's Homepage?

  1. Describe your organization.

The FreeBSD Project is a large, mature, and yet relatively tightly nit organization. The FreeBSD Project began 15 years ago in 1993, but is based on the work at Berkeley CSRG with open source revision history going back 30 years to 1978.

There are currently over 300 developers with write access to the main revision control system, and hundreds more with access to our Perforce servers for experimental and third party development (this is also where our summer of code students have worked in previous years).

We have an active mentoring program to bring all new developers into our community, not just those that we introduce to FreeBSD through the GSoC. There are hundreds of mailing lists, blogs, irc channels, and user groups all detailed on our main website.

FreeBSD offers a complete operating system in which students can work, not just a kernel or specific userland stack. This allows for interesting work that spans the userland/kernel boundary, and allows students to build up and package complete modified FreeBSD operating system CDs/DVDs to distribute as ISOs for testing, for example.

  1. Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating?

We are interested in introducing new students to open source software development. In particular, we've identified many dozens of potential proejcts for students in the areas of unix operating system development, modern concurrency problems, security research, filesystems, and more.

We hope to gain relationships with new talented students that could potentially continue to become longer-term open source developers with the FreeBSD Project.

  1. Did your organization participate in previous GSoC years? If so, please summarize your involvement and the successes and failures of your student projects. (optional)

We've participated in all three previous Google Summer of Codes, and have mentored 58 students in total over the three years. We've learned a great deal about setting student expectations appropriately, finding appropriate mentors and dealing with AWOL students and/or mentors. Where generally applicable, we've tried to evangelize these best practices at the summer of code mentor summit and program wikis.

In general each year we've had quite a bit more promising student proposals and willing mentors than spaces were allocated to us, and so we were able to be extremely picky and I think this is reflected in the high success rate of our students.

At least 8 of our former students continue to work on FreeBSD as full fledged committers. Many others are currently in Ph.D. programs, some pursuing a similar line of FreeBSD related research to their SoC projects. We've also had quite a few join industry such as Google (3), Oracle, Cisco, etc.. and found startups based on open source technologies (

  1. If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)? (optional)


  1. What license does your project use?


  1. URL for your ideas page

(A separate is ready to be published as soon as we are accepted into the program).

  1. What is the main development mailing list for your organization?

<hackers AT FreeBSD DOT org>

  1. Where is the main IRC channel for your organization?


  1. Does your organization have an application template you would like to see students use? If so, please provide it now. (optional)

(Adapted from Perl Foundation proposal HOWTO)

Name: Email: Phone: AIM:

Project Title:

Possible Mentor: (optional)

Benefits to the FreeBSD Community: (a good project will not just be fun to work on, but also generally useful to others.)

Deliverables: (It is very important to list quantifiable results here e.g.)

* "Improve X modules in ways Y and Z." * "Write 3 new man pages for the new interfaces." * "Improve test coverage by writing X more unit/regression tests." * "Improve performance in FOO by X%."

Project Schedule: How long will the project take? When can you begin work?

Availability: How many hours per week can you spend working on this? What other obligations do you have this summer?

Bio - Who are you? What makes you the best person to work on this project?

  1. Who will be your backup organization administrator? Please enter their Google Account address. We will email them to confirm, your organization will not become active until they respond. (optional)

Backup organization administrator #1: Robert Watson <rwatsoff AT gmail DOT com> Backup organization administrator #2: Nik Clayton <nik AT google DOT com>

About Your Mentors

  1. What criteria did you use to select these individuals as
    • mentors? Please be as specific as possible.

We want to see a positive track record of community engagement and high quality code, preferably going back many years.

The mentors need to be able to explain things to others, perform code reviews and other administrative tasks promptly, and work well with students. We have a formal mentoring program for all new committers to the FreeBSD Project and so the core team is well aware of the commiters that do not work well with others and they are not invited to become mentors.

Also it's very important that our mentors have realistic expectations about what a student can accomplish over the summer.

  1. Who will your mentors be? Please enter their Google Account
    • address separated by commas. If your organization is accepted we will email each mentor to invite them to take part. (optional)

<rwatsoff AT gmail DOT com>, <chris AT unixpages DOT org>, <bz+google AT freebsd DOT org>, <benno DOT rice AT gmail DOT com>, <diomidis DOT spinellis AT gmail DOT com>, <philip DOT paeps AT gmail DOT com>, <erwin DOT lansing AT gmail DOT com>, <dag DOT erling AT gmail DOT com>, <gnn AT freebsd DOT org>, <oppermann AT gmail DOT com>, <joel DOT dahl AT gmail DOT com>, <shteryana AT gmail DOT com>

  1. What is your plan for dealing with disappearing students?

We request multiple forms of contact in the application so that email delivery problems or other technology issues can be worked around early. We also request that each student maintain a blog or wiki with updates about current status. We create a wiki account for each student and so there is a canonical location for these status update, but the students have the option of just linking to their own blog if they prefer to use that rather than our wiki. We prefer this over individual snippet emails to the mentor as it allows the administrators or alternate mentors (and the community in general) to keep tabs on the student.

Every other week or so, the project administrators browse all the student blogs/wiki pages to get an update on current progress, and send nag mail to any student/mentor pairs that haven't made it easy to see what the current status of the project is. This way we're never out of contact for more than 2 weeks.

Also, we encourage all students to check in their code regularly as a work in progress, and we tell them that checked in code is needed for their mentor to properly evaluate them at the mid-term point.

  1. What is your plan for dealing with disappearing mentors?

We ask each mentor about travel plans over the summer and potential alternate mentors should real life or a work emergency come up during the summer. This combined with the use of wikis, blogs, and other public status updates makes it easy for an alternate mentor to take over in the event that the original mentor becomes unavailable.

The project administrators email all of the students several times throughout the summer to make sure they are not blocked on anything, have no access issues with the revision control system, wiki, or cluster resources, and are not trying unsuccessfully to reach their mentor.

In general however, we try very hard to select mentors that will give us the full time commitment so that this isn't an issue.

  1. What steps will you take to encourage students to interact with your project's community before, during and after the program?

We create a personal space about each accepted project on Wiki and make blog posts and newsflash entries about the projects. We also solicit individual project updates for our bi-monthly developer status reports, where these projects are reported on in the same document as our other mainstream development projects.

Students are strongly encouraged from the beginning to make use of project mailing lists and IRC and they are told that this will help make it easier for their mentor to fill out evaluation forms about what they have completed over the summer. Our project ideas page lists potential mentors and encourages students to contact them before the program so that we can open communication channels early. After the program is over we profile many of the successful projects on our website and provide the tools and support necessary for them to continue working should they desire. We never remove the perforce accounts for students that are still working on FreeBSD.

  1. What will you do to ensure that your accepted students stick
    • with the project after GSoC concludes?

We'll try to ensure that each student coordinates with the developer community through mailing lists, IRC, etc. We want to encourage the student to have many more contacts in the project beyond their immediate mentor. By learning our tools, processes, and meeting many other developers we think that we can encourage many students to continue working after GSoC concludes.

We will also continue to support the infrastructure necessary for the student to continue working. Students can keep their email forward, Perforce account, wiki account, and if necessary, login access to project compute resources to enable them to continue working.

General Checklist

SummerOfCode/Administration/AdminChecklist (last edited 2021-04-26T02:46:06+0000 by JethroNederhof)