[[!meta copyright="Copyright © 2010, 2011, 2013, 2016 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? Literally only half a handful works on the core of the system in their free time, and another half of handful helps with [[Debian GNU/Hurd|hurd/running/debian]] and [[hurd/running/Arch_Hurd]] packaging. Also, an additional half of 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 workforce -- which matters a lot. This also answers the question "[[How_come_the Hurd still can't 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]]. As *el_presidente* commented on : > Developers, developers, developers, developers. > > They are the people that matter at this point in time.