Waving the flag: NetBSD developers speak about version 4.0

The NetBSD community released version 4. developers.

Google Summer of Code

How much did the Google Summer of Code program help NetBSD get more quality contributors, and of course, more features?

Jan Schaumann: The Google Summer of Code (SoC) program has been a great opportunity for us to indeed attract some new contributors and get new features/new code. However, I believe that our experience in the SoC has not been necessarily what outsiders of the program might expect.

Bear with me and allow me to elaborate on the history of NetBSD's participation in Google's Summer of Code for a bit.

In 2005, Google started the Summer of Code program. We were lucky enough to have heard about this project early on and were able to participate as a mentoring organization (of only 40 mentoring organizations in total in 2005). Everything happened very quickly, and the whole SoC program organization really required us to be on our toes; within a very short time, we had to put together a list of possible projects, find mentors willing to work with students, etc.

When students applications came in, we were facing well over 100 "serious" proposals (after weeding out a fair number of student applications that were simply inappropriate and/or could hardly be called an application—"Hey, I want to write leet code for the NetBSD. E-mail me!" etc.). We did not know how many projects we would get, so we ranked the applications based on a number of criteria, such as benefit of the contribution to NetBSD, availability of mentors, and probability of getting the project done within the given timeframe. In the end, we were given 8 slots by Google.

Now it may be of interest that we chose two projects in 2005 that were done by people who were already NetBSD developers with commit rights, thus not gaining us any "fresh blood" in these instances. However, the importance of these projects and the quality of the work justified that choice.

In the end, everybody was very satisfied with the outcome of SoC 2005, and we felt we learned a fair bit about the program.

In 2006, the number of mentoring organizations participating in the SoC increased to over 100. This meant, of course, that the students would be spread across more organizations, and that, quite likely, fewer projects would be allotted to us. We therefore tried to focus on applications that were more of direct benefit to NetBSD (while in 2005 we allowed and considered some projects that were somewhat more tangential).

Again, we sifted through over 100 applications of varying quality and were in the end allotted eight projects. That year, we unfortunately had two failed projects (one student disappeared after the midterm payment, another fell sick and was unable to complete his work). We also had, again, two projects that were given to students who already were NetBSD developers with commit rights.

In 2007, there were 130 different mentoring organizations, so "competition" for good student applications was up again. With more time to prepare for this SoC (we learned early on that (a) another SoC would happen and (b) NetBSD would be part of it), we decided to review our proposed student projects (which formed the basis for the overwhelming number of applications).

Our thought process was that the more accurate and precise our suggested projects are described, the more likely it is to get a student application with a high likeliness of succeeding. Therefor, we added a level of difficulty and estimated man-hours to our proposed projects. Based on the previous year's experience in particular with the failed projects, we also raised our requirements.

As a result, we received far fewer applications than in previous years, but with an overall much higher quality. Furthermore, we knew that Google would decide on the total number of slots given to a mentoring organization at least in part based on the total number of applications. (That is, by raising our standards, we somewhat hurt ourselves.) This made it very difficult for us to rank them, as many of the applications looked promising.

In the end, we were given six projects; four were by students who were already NetBSD developers with commit rights.

Looking back at the last three years, I believe that it is fair to say that our greatest benefit from the Google Summer of Code is (unfortunately) not in the number of new developers and regular contributors (two of the students in 2005 eventually became full NetBSD developers with commit rights, while others from 2006 and 2007 might still become developers but have not yet). However, we have gained a lot of cool features and new code, and a lot of the students' work has been integrated into our source tree and is now part of our regular releases.

(The work from this year's SoC may yet have to be integrated.)

It's also important to point out that e thbenefits may not be immediate. That is, at the end of the summer, the code may not yet be ready for import into NetBSD's source tree, but it may have become a foundation for other ongoing work. For example, 2005's "userfs" project later became the foundation for the 2007 " Running Kernel File Systems in Userspace" project and now offers FUSE capabilities in NetBSD.

As usual, all good things take a bit of time to mature and the benefits of SoC 2007 may only become fully obvious during the coming year.

The preparation for the Google SoC has taught us many a lesson about project management, how to align our priorities with students' capabilities, and pointed out some of our shortcomings when it comes to attracting new developers. For example, we have very high demands for quality and reliability, and technically very complex projects; both are obviously inherent of an OS like NetBSD, where it's not easy to justify a SoC slot for simpler or "more exciting" flashy low-impact projects that might be accepted in an organization with different goals.