path: root/community/gsoc/organization_application.mdwn

[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled
[[GNU Free Documentation License|/fdl]]."]]"""]]

* Organization Name:

GNU Hurd

* Description:

The mission of the Hurd project is to create a general-purpose kernel suitable
for the [GNU operating system](http://gnu.org), which is viable for everyday
use, and gives users and programs as much control over their computing
environment as possible.

When the Hurd was originally started in 1990, it was the last missing major
component for a complete GNU system. Today Linux and other free kernels are
available to fill this gap, and the combination of GNU and Linux (often
[incorrectly](http://www.gnu.org/gnu/why-gnu-linux.html) called just "Linux")
is in wide use. However, the Hurd is still interesting due to its unique
design, better fitting the GNU philosophy than traditional monolithic kernels
like Linux.

The GNU GPL guarantees that all users of software published under this license
get the legal permission to adapt the software they are using according to
their wishes, and also get the source code and other tools necessary to put
this permission to use. However, in traditional operating systems, the kernel
and related low-level system software are protected from normal users, and
cannot be easily modified; only the system administrator has power over these.

The Hurd offers special mechanisms that allow any user to change almost all of
the system functionality he uses, without affecting the rest of the system, and
thus easily (at runtime) and without any special permissions.

This ability to run subenvironments more or less independant from the rest of
the system, can be classified as a very sophisticated [lightweight
virtualization](http://tri-ceps.blogspot.com/2007/10/advanced-lightweight-virtualization.html)
approach.

To offer these possibilities, the Hurd uses a true multiserver microkernel
architecture. That makes it quite unique: The Hurd is the only general-purpose
multiserver microkernel system in development today that is nearly ready for
everyday use, and offering almost perfect UNIX compatibility. (About 65%
of all packages in the Debian repository are available for the Hurd.) All other
existing true microkernel systems are either research projects not nearly
complete enough for actual use, or limited to embedded systems and other
special purposes, or both.

Marcus Brinkmann and Neal Walfield from the Hurd project are working at the
bleeding edge of microkernel operating system research. They have been in
contact with the most distinguished researchers in that field from the
[L4](http://l4hq.org/) and
[EROS](http://www.eros-os.org/eros.html)/[Coyotos](http://www.coyotos.org/)
microkernel operating system groups, and have written a couple of [research
papers](http://walfield.org/).

* Home Page:

http://hurd.gnu.org

* Main Organization License:

GNU General Public License (GPL)

* Why is your organization applying to participate in GSoC 2010? What do you hope to gain by participating?

The primary goal of our participation is of course to find and introduce new long-term contributors
to the Hurd. We are trying to optimise for this in our student selection
process, our mentoring approach, and our choice of project ideas.

The mentor-student setup, together with the period of focused work during the
summer session, also offer a unique opportunity for kick-starting innovative
new projects apart from mainline development, which are hard to fit in among
the normal day-to-day development work. This is particularily important for the
Hurd, as innovative uses are crucial to show the benefits of the unique
architecture. Several such projects came into being through the GSoC program
over the past years.

Last but not least, GSoC participation always yields a lot of valuable input from new people, and helps
spreading technical and other knowledge about the Hurd among actual and
potential contributors. It has a very positive effect on
our community -- new impulses, increased communication, etc.

* Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.

In 2006 and 2007,
we participated under the umbrella of the GNU project, getting one slot each
year.

In 2008 we participated as an organisation on our own for the first time. This
turned out extremely beneficial: with the better visibility, we got a lot
more applications (more than 20), mostly of good or excellent quality.

In 2009, we were rejected as an organisation, so we participated under the GNU
umbrella again.

While the 2006 student disappeared midway, in all the later years all of our
students were successful -- even including one who worked on his project in
spite of not getting an official slot. Half of them are regular Hurd contributors now.

Selecting the most promising students, as well as suitable mentors, turned out
to be the most tricky part of GSoC participation -- but we learned our lesson
after the first failure: we didn't have any students that didn't meet our
expectations since then, and we also believe our mentoring is exceptionally
good now -- one project that was in serious trouble, turned out well after all,
due to effective mentor intervention.

* 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.

2008: 4/4

(+1 inofficial in 2008)
(under GNU umbrella: 2006: 0/1; 2007: 1/1; 2009: 1/1)

* 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?

http://www.gnu.org/software/hurd/community/gsoc/project_ideas.html

* 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.

bug-hurd@gnu.org ( http://lists.gnu.org/mailman/listinfo/bug-hurd )

* What is the main IRC channel for your organization?

\#hurd on freenode.net

* 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.

[[student_application_form]]

* What criteria did you use to select the individuals who will act as mentors for your organization? Please be as specific as possible:

The most important criterium is that the person is involved in the project for
some time, knowing the ways; so he can actually instruct the student; and if
there are tough technical questions he can't answer himself, he knows whom to
ask.

It's also important that the mentors are reliable and helpful, so the students
won't be left on their own with any problems they face.

* What is your plan for dealing with disappearing students?

The plan is mostly to avoid that happening in the first place. To this end, we
are particularily careful with selection of students: Making sure
that they have no other major obligations during that time; that they are motivated
enough; that they actually have the necessary skills to complete the task; that
they fit in our community.

Also, we will make sure that we are constantly in contact with the students --
asking about progress, discussing technical issues, etc. -- so we can act in
time if things go wrong.

If a student disappears in spite of that, there is little we can do. Of course
we will try to contact him and find out what the problem is; whether the
project can perhaps be scaled down, or at least wrapped up to bring it in a
state where it is useful even if not finished.

We will also try to limit damage by insisting that students regularily check in
their work to our source repositories, so that we get partial results at least if someone disappears.

* What is your plan for dealing with disappearing mentors?

As our mentors all have been with the project for some time, the risk of them
disappearing is not too big. If one of them disappears nevertheless, it's not a
problem for us: we have enough mentors, and someone else will take over.

We will encourage the students to keep discussions public as much as possible,
keeping private conversations with the mentors to a minimum, so the transition
should go smoothly.

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

We try to make it very clear that we expect the students to get into regular
contact with us early during the student selection process already, and won't
consider their applications otherwise. This way we know that the students are
able and willing to communicate with us in the first place.

After selection, the regular contact is kept up: we require the
students to participate in IRC meetings up to twice a week, where we ask the students
actively about the work they do, problems they face, decisions they take, etc.
Furthermore, we ask them to be available on IRC while working on their
projects, so we can communicate easily.

We also require the students to join our main development mailing list, so any
design questions, etc. can be discussed there. We encourage them to take
part in other conversations, not directly related to their projects, as well.

After the program we continue the regular meetings, discussing the further
development of their original projects; as well as new projects, after the
original ones are done.

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

In addition to keeping up the regular IRC meetings,
we try to invite all participating students to meet us at conferences afterwards,
where we discuss the projects, as well as other Hurd-related topics. This should
keep them motivated to follow up on the work they have done during the
program, and generally help keeping them involved.

* Is there anything else you would like to tell the Google Summer of Code program administration team? :

* Backup Admin (Link ID):