Debian developers have various responsibilities, and as official project members, they have great influence on the direction the project takes. A Debian developer is generally responsible for at least one package, but according to their available time and desire, they are free to become involved in numerous teams and projects, thus acquiring more responsibilities within the project.

Utrzymywanie pakietów jest działalnością poddaną pewnym ograniczeniom proceduralnym, które są dobrze udokumentowane lub nawet regulowane. W rezultacie, aktywność, którą często określa się terminem „opieka nad pakietami" (stąd określenie „opiekun pakietu" — ang. package maintainer) musi być zgodna ze wszystkimi standardami ustanowionymi przez Politykę Debiana (ang. Debian Policy). Na szczęście jest wiele narzędzi, które ułatwiają pracę opiekunów pakietów. Twórca może więc skupić się na specyfice swojego pakietu, i na innych, bardziej złożonych zadaniach, takich jak śledzenie i likwidowanie błędów.

Polityka, zasadniczy element Projektu Debian, ustanawia normy zapewniające zarówno jakość pakietów, jak i doskonałą interoperacyjność dystrybucji. Dzięki swojej Polityce, Debian pozostaje spójny, niezależnie od gigantycznego rozmiaru. Ta polityka nie jest niezmienna, lecz podlega ewolucji dzięki propozycjom, formułowanym na liście dyskusyjnej [email protected]. Poprawki, uzgadniane przez wszystkie zainteresowane strony, są akceptowane i wprowadzane do tekstu Polityki poprzez małą grupę opiekunów, niemających odpowiedzialności wydawniczej (wprowadzają oni tylko te poprawki, które są uzgodnione przez twórców Debiana — członków wyżej wspomnianej listy). Bieżące propozycje poprawek można przeczytać w systemie śledzenia błędów:

The Policy provides considerable coverage of the technical aspects of packaging. The size of the project also raises organizational problems; these are dealt with by the Debian Constitution, which establishes a structure and means for decision making. In other words, a formal governance system.

This constitution defines a certain number of roles and positions, plus responsibilities and authorities for each. It is particularly worth noting that Debian developers always have ultimate decision making authority by a vote of general resolution, wherein a qualified majority of three quarters (75%) of votes is required for significant alterations to be made (such as those with an impact on the Foundation Documents). However, developers annually elect a “leader” to represent them in meetings, and ensure internal coordination between varying teams. This election is always a period of intense discussions. The Debian Project leader's (DPL) role is not formally defined by any document: candidates for this post usually propose their own definition of the position. In practice, the leader's roles include serving as a representative to the media, coordinating between “internal” teams, and providing overall guidance to the project, within which the developers can relate: the views of the DPL are implicitly approved by the majority of project members.

Szczególnie, lider ma rzeczywistą władzę. Głosy liderów mają moc wiążącą; lider może podjąć dowolną decyzję, której wykonanie nie jest już w mocy kogoś innego i może delegować część swoich obowiązków.

Since its inception, the project has been successively led by Ian Murdock, Bruce Perens, Ian Jackson, Wichert Akkerman, Ben Collins, Bdale Garbee, Martin Michlmayr, Branden Robinson, Anthony Towns, Sam Hocevar, Steve McIntyre, Stefano Zacchiroli, Lucas Nussbaum, Neill McGovern, Mehdi Dogguy, Chris Lamb, Sam Hartman, and Jonathan Carter.

Konstytucja określa też „komitet techniczny". Zasadniczą rolą tego komitetu jest decydowanie o sprawach technicznych w sytuacji, gdy twórcy nie mogą ze sobą dojść do porozumienia w jakiejś kwestii technicznej. Mówiąc inaczej, komitet odgrywa rolę doradczą, gdy twórcy nie udaje się podjąć decyzji, za jaką jest odpowiedzialny. Warto zapamiętać, że komitet techniczny angażuje się tylko wtedy, gdy jest poproszony, aby być jedną ze stron potencjalnego konfliktu.

W końcu, konstytucja określa stanowisko „sekretarza projektu", który jest odpowiedzialny za organizację głosowania, związanego z różnymi wyborami i rezolucjami ogólnymi.

The “general resolution” (GR) procedure is fully detailed in the constitution, from the initial discussion period to the final counting of votes. The most interesting aspect of that process is that when it comes to an actual vote, developers have to rank the different ballot options between them and the winner is selected with a Condorcet method (more specifically, the Schulze method). For further details see:

Even if this constitution establishes a semblance of democracy, the daily reality is quite different: Debian naturally follows the free software rules of the do-ocracy: the one who does things gets to decide how to do them. A lot of time can be wasted debating the respective merits of various ways to approach a problem; the chosen solution will be the first one that is both functional and satisfying… which will come out of the time that a competent person put into it.

Jest to jedyny sposób, aby zasłużyć sobie na szacunek: zrobić coś pożytecznego i pokazać, że się pracowało dobrze. Wiele „administracyjnych" zespołów Debiana działa za pomocą kooptacji, preferując wolontariuszy, którzy już efektywnie przyczynili się do czegoś i potwierdzili swoje kompetencje. Publiczna natura pracy tych zespołów sprawia, że nowi współpracownicy mogą obserwować tę pracę i mogą zacząć pomagać bez specjalnych przywilejów. Z tego powodu Debian jest często określany mianem „merytokracji".

Ta efektywna metoda operacyjna gwarantuje jakość współpracowników w „kluczowych" zespołach Debiana. W żaden jednak sposób metoda ta nie jest doskonała i okazjonalnie ujawniają się również ci, którzy nie akceptują tego sposobu działania. Dobór twórców, akceptowanych w zespołach, może wydawać się trochę arbitralny lub nawet nieuczciwy. Co więcej, nie każdy ma te samą definicję służby na rzecz innych, oczekiwaną przez te zespoły. Dla niektórych nie do zaakceptowania jest fakt oczekiwania przez osiem dni na włączenie nowego pakietu Debiana, natomiast inni cierpliwie czekają na to samo przez trzy tygodnie, bez problemu. Tak więc, pojawiają się regularne skargi ze strony „niezadowolonych" na temat „jakości usług" tych zespołów.

Można się zastanawiać, czy warto zaliczać „zwykłych" użytkowników do tych współpracowników, którzy działają wewnątrz projektu Debian. Odpowiedzią jest definitywne TAK: odgrywają oni kluczową rolę w tym projekcie. Niektórzy użytkownicy, będąc dalekimi od bycia „pasywnymi", uruchamiają testowe wersje Debiana i regularnie wypełniają raporty o błędach, wskazując na problemy. Inni idą jeszcze dalej i przesyłają pomysły ulepszeń wypełniając raport o błędzie zawierający „listę życzeń" lub nawet przesyłają poprawki kodu źródłowego, zwane „łatkami" (ang „patches"). Zobacz pasek boczny Sekcja 1.3.2.3, „Wysyłanie poprawek”.

$ diff -u plik.stary plik.nowy >plik.łata

$ łata -p0 plik.stary <plik.łata

From the start, Debian has been organized around the concept of source packages, each with its maintainer or group of maintainers. Many work teams have emerged over time, ensuring administration of the infrastructure, management of tasks not specific to any package in particular (quality assurance, Debian Policy, installer, etc.), with the latest series of teams growing up around sub-projects and blends.