2011 GSoC Application
The FreeBSD Project
The FreeBSD Project is a large, mature, and yet relatively tightly knit 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, forums, 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.
In addition to producing an operating system, FreeBSD has incubated the development of key pieces of infrastructure which are used by other open source projects including bsnmp, jemalloc, libarchive, OpenBSM, and OpenPAM.
Main Organization License:
Why is your organization applying to participate in GSoC 2010? What do you hope to gain by participating?
First and formost, we hope to gain new developers for FreeBSD. Since we judge community members both on technical ability and ability to collaborate, GSoC offers an execellent form of introduction and evaluation. Secondly, we hope to gain new and improved functionality and a result of student contributions. Third, by participating in GSoC we increase our exposure to students and academia in general. Even student's who look at FreeBSD, but choose to apply to other projects will learn something about what FreeBSD is.
Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.
The FreeBSD project has participated in the Google Summer of Code since its inception. We have had a total of 117 projects, 105 of which passed. In each year we have had 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.
A 17 former students have become full fledged committers, several others are active contributors, and the work of many others has become part of the source and ports trees. 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, Cisco, Oracle, Slide, and VMWare and found startups based on open source technologies (rememberthemilk.com). Various FreeBSD project members have attended past Summer of Code Mentor Summits including all three members of our current admin team (Brooks Davis, Tim Kientzle, and Robert Watson).
If your organization participated in past GSoCs, please let us know the ratio of students passing to students allocated, e.g. 2006: 3/6 for 3 out of 6 students passed in 2006.
If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?
What is the URL for your ideas page?
What is the main development mailing list for your organization? This question will be shown to students who would like to get more information about applying to your organization for GSoC 2010. If your organization uses more than one list, please make sure to include a description of the list so students know which to use.
The best general mailing list to discuss project ideas on is <freebsd-hackers AT freebsd DOT org>. You may also receive useful feedback on area specific lists such as <freebsd-fs AT freebsd DOT org> for file systems, <freebsd-net AT freebsd DOT org> for networking, or <freebsd-ports AT freebsd DOT org> for ports collection related projects.
The full list of mailing lists can be found at http://lists.freebsd.org/mailman/listinfo.
What is the main IRC channel for your organization?
A relatively complete list of FreeBSD related IRC channels can be found [/IRC/Channels|here].
Does your organization have an application template you would like to see students use? If so, please provide it now. Please note that it is a very good idea to ask students to provide you with their contact information as part of your template. Their contact details will not be shared with you automatically via the GSoC 2010 site.
What criteria did you use to select the individuals who will act as mentors for your organization? Please be as specific as possible:
We select mentors from the pool of FreeBSD committers who are interested in mentoring and who we feel have done a good job in the past either mentoring with Google Summer of Code or with general project mentoring.
FreeBSD committers are selected based their technical contributions and their ability to work well with the project. Typically a contributer submits too many good changes and someone who has been working with them sponsors them for commit access. For source committers, the core team evaluates both their technical record and their record of interaction with the community through their own experience and the application submitted by the sponsor. In general we look for both technical and social maturity (we bring in a number of younger committers, but our average age is over 30). The portmgr and doceng teams perform similar functions for the ports collection and documentation projects respectively. In certain circumstances, community members who have performed extraordinary services to the project over time are also granted access to internal mailing lists.
What is your plan for dealing with disappearing students?
The first line of defense against disappearing students will be regular, mandatory status reports. We aim to have students send status reports to a central list where they can help each other and mentors and other interested developers can keep tabs on them. Along with this we will require each contributor to negotiate a detailed specification of their work schedule with their mentor which will be provided to program administrators. We will uses this combination to detect problems. If problems appear to be occurring we will attempt to contact the contributors. If they can not be contacted in a reasonable period or do not have an acceptable explanation we will cut our losses and cease contact.
What is your plan for dealing with disappearing mentors?
As with students, finding the problem is the most important thing. We will encourage mentors to interact with their contributors in a public or semi-public venue so we can keep tabs on them. We will also ask them to provide their schedules so we know when we can expect to see them interacting with contributors. We will attempt to provide a backup mentor for each project. Backup mentors may be oversubscribed, but will be expected to be aware of the project status. Additionally we will poll students periodically about their mentor contact. If it is inadequate we will ask the backup mentor to take a greater role or to take over. Additionally, we will take care to select mentors who we believe have the time and personality necessary to be effective mentors. We have been fortunate to have few problems with mentors during out time with GSoC.
What steps will you take to encourage students to interact with your project's community before, during and after the program?
We will provide contributors with a designated place to post their status reports and encourage contributors, mentors, and other community members to review and comment on their work as it progresses. This will be separate from the primary mailing lists because we have found that posting to the primary lists can be quite intimidating. By creating a separate area where expectations are set appropriately and interactions are policed by mentors and administrators we hope to achieve a higher level of participation. Once code reaches a more complete state, we will encourage contributors to seek review on the appropriate lists.
We also create a personal space about each accepted project on the 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.
Our project ideas page lists potential mentors and encourages students to contact them before the program so that we can open communication channels early.
We invite all gsoc participants to attend BSD conferences and developer summits, and thanks to The FreeBSD Foundation, are able to offer travel support to them. This allows them to present their work to the community, meet the people they've seen on the lists (and their mentor), as well as network with the community and potential employers.
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 retain system accounts and email addresses for students who are still working on FreeBSD. We will also to remind mentors to propose successful students as committers before the end of the evaluation period. While not every successful project will reflect an ideal committer, many do and we want to capture as many of those as possible.
Is there anything else you would like to tell the Google Summer of Code program administration team?
Thank you for allowing us to participate in GSoC over the years. It has been an honor to have mentored nearly 100 students and we've produced both some excellent code and some new contributors both of which have helped move the project in useful directions.