1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
|
[[!meta copyright="Copyright © 2010, 2011, 2013 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]]."]]"""]]
[[!tag faq/general faq/_important]]
[[!meta title="How many developers are working on the GNU Hurd, and why so
few?"]]
# How Many Developers?
One handful works on the core of the system in their free time, and another
handful helps with [[Debian GNU/Hurd|hurd/running/debian]] and
[[hurd/running/Arch_Hurd]] packaging. Also, an additional handful of former
developers are still available for answering technical questions, but are not
participating in the current development anymore.
In the past (that is, a lot of years ago), the FSF did pay a few developers for
working full time on the GNU Hurd. But that was for a limited amount of time
only, and evidently, it was too little for getting the system into a
competitive state. Nowadays, it's only unpaid (apart from some
[[bounties|tag/bounty]]) and free-time volunteers' work.
In contrast to the Linux kernel, there is no industry involvement in
development. For one, this is a good thing: independency; no conflicts of
interests. For another, it is also a bad thing: no dedicated full-time
manpower -- which matters a lot.
This also answers the question why [[the Hurd still does not do [...] after so
many years of development|so_many_years]].
# Why So Few?
We can only speculate. One major problem might be that the [[architectural
benefits|advantages]] are generally perceived as very abstract, with little
practical benefit. We currently don't have many tools that are actually making
use of all the possibilities.
Another reason is that it's been taking too long. Today, most people don't
believe it will ever be ready for production use, and thus would consider
involvement a waste of time. This latter point is invalid, of course, as
learning can never be a waste of time. The same holds for the [[challenges]]
raised by the GNU Hurd -- we can only learn and improve upon working on them.
For likely the same reasons there is no industry interest in the GNU Hurd: its
advantages are too abstract and incomplete for being of interest there.
As for the scientific sector, the GNU Hurd projects was rather about *using* a
[[microkernel]] intead of doing research on them, for example. But, there have
been some projects and theses done, and some scientific papers published on GNU
Hurd topics, and we're generally very interested in further such projects.
# Attracting New Faces
We're an open project: any interested party (*you*!) are very welcome to start
[[contributing]]. Mentoring is possible, too, to help you get started.
Likewise, for reaching out to new developers, we're participating in [[Google's
Summer of Code program|community/gsoc]].
|
