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]]."]]"""]]

* Link ID:

hurd

* Group Name:

GNU Hurd

* Home Page URL:

http://hurd.gnu.org

* Public Email:

bug-hurd@gnu.org

* Description:

The Hurd project is a loose community of people sharing a common interest in
developing the Hurd kernel, which is the official kernel of the [GNU operating
system](http://gnu.org).

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. (More than half
of the 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/).

* Why is your group applying to participate? What do you hope to gain by participating?

The primary goal of course is to find and introduce new long-term contributors
to the project.

Aside from that, it is a way to make progress with tasks that require an amount of
focused work, that is hard to do for volunteers working in their spare time
only.

Also it is a good possibility to get valuable input from new people, as well as
spreading technical and other knowledge about the Hurd among actual and
potential contributors. More generally, participation should help raising
awareness among people who might know about the existence of the Hurd, but
otherwise having very little idea what the project is all about, and how its
progress is.

Last but not least, we hope the participation will have a positive effect on
our community -- new impulses, increased communication etc.

* What is the main public mailing list for your group?

bug-hurd@gnu.org, see http://lists.gnu.org/mailman/listinfo/bug-hurd

* Where is the main IRC channel for your group?

\#hurd on freenode.net

* What criteria do you use to select the members of your group? 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.

* Has your group participated previously? If so, please summarize your involvement and any past successes and failures.

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

The 2006 participation was mostly a failure. After some intitial work
(available in CVS), the student disappeared -- moving to another country and
other personal issues from what we heard.

The 2007 participation was a considerable success. The student was very bright
and dedicated. We got some code, as well as a lot of ideas, which we continued
discussing after the end of GSoC, and he intends to put into code as well in
the future.

In 2008 we participated as an organisation on our own for the first time. This
turned out extremely beneficial: Not only did it give us much better
possibilities to find and select good students, as we hoped. We also get a lot
more applications, mostly of good or excellent quality.

We ended up with four slots. (We didn't request more, because we were not sure
whether we would be able to mentor them properly, and generally didn't want to
overdo it on our first "full" participation.) There was also a fifth student,
who worked on his project in spite of not getting a slot.

All five students were pretty successful, most of them completing or almost
completing the original goals -- some even exceeding them. Even our weakest
student, after serious struggling in the beginning, did quite well in the end.

Two students are still regularily working on the Hurd -- not as much as we
hoped of course, but probably as much as can be realistically expected...

All in all, the participation was a considerable amount of work, but it was
definitely worth it :-)

* If your group has not previously participated, have you applied in the past? If so, for what sort of participation?

--

* What license does your organization use?

GNU General Public License (GPL)

* What is the URL to the ideas list of your organization?

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

* What is the main development mailing list for your group?

bug-hurd@gnu.org, see http://lists.gnu.org/mailman/listinfo/bug-hurd

* What is the application template you would like contributors to your organization to use.

[[student_application_form]]

* What is your plan for dealing with disappearing contributors?

The plan is mostly to avoid that happening in the first place. For that, we
will be particularily careful with the selection of the students: Making sure
that they have no other 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, so that we get partial results at least if someone disappears.

* What is your plan for dealing with disappearing members?

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 contributors to interact with your 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 before the end of the student selection process, 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 the selection, the regular contact will be kept up: We require the
students to participate in weekly IRC meetings, where we ask the students
actively about the work they do, problems they face, decisions they take etc.
Furthermore, we will ask them to hang around on IRC most of the time while
working on their projects, so we keep in close contact.

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

After the program we continue the regular meetings, still discussing the
projects: The application of the code created, future directions etc.

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

We will try to invite all participating students to a conference afterwards,
where we will discuss the projects, as well as other Hurd-related topics. We
hope this will motivate them to follow up on the work they have done during the
program, and generally help keeping them involved.

* Please select your backup group administrator.