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.

Het onderhoud aan pakketten is een behoorlijk gedisciplineerde bezigheid, uitgebreid gedocumenteerd of soms zelfs door strenge regels vastgelegd. Het komt erop neer dat het onderhoud moet voldoen aan al de standaarden die zijn opgesteld in het Debian Beleid (Debian Policy). Gelukkig zijn er veel gereedschappen die het werk van de onderhouders vergemakkelijken. De ontwikkelaar kan dus focussen op de specifieke eisen van het pakket en de meer complexe taken, zoals fouten (bugs) oplossen.

Het Beleid, een essentieel element van het Debian Project, bepaalt de normen die de kwaliteit van de pakketten en een perfecte interoperabiliteit van de distributie verzekeren. Dankzij dit Beleid blijft Debian consistent ondanks haar gigantische grootte. Dit Beleid is niet in steen gebeiteld maar evolueert continu dankzij voorstellen ingediend op de policy@lists.debian.org mailing lijst. Amendementen waarmee alle betrokken partijen akkoord gaan worden geaccepteerd en toegepast op de tekst door een kleine groep van onderhouders die geen redactionele verantwoordelijkheid dragen (zij voegen enkel de aanpassingen toe waarmee de Debian ontwikkelaars die lid zijn van bovengenoemde lijst akkoord zijn gaan). De huidige amendementsvoorstellen zijn te volgen op het fouten volg systeem:

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.

specifiek heeft de leider echter autoriteit; hun stem lost gelijke-stemmingen op, ze kunnen iedere beslissing nemen welke niet al onder de autoriteit van iemand anders vallen en kunnen delen van hun verantwoordelijkheid delegeren.

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.

De grondwet definieert ook een "technische commissie". de essentiële rol van deze commissie is beslissingen nemen op technisch niveau wanneer de betrokken ontwikkelaars het niet eens kunnen worden waarvoor zijn verantwoordelijk zijn. Het is belangrijk te vermelden dat zij enkel optreden nadat ze zijn gevraagd door één van de partijen in kwestie.

Tenslotte, de grondwet definieert de positie van "project secretaris" welke de leiding heeft over stemmingen in verband met de verschillende verkiezingen en algemene resoluties.

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.

Dit is de enige manier om je strepen te verdienen: Doe iets nuttigs en toon aan dat je goed gewerkt hebt. Vele Debian “beheerders” team werken door coöptatie, verkiezen vrijwilligers die reeds effectief hebben bijgedragen en hun competentie hebben bewezen. De publieke aard van het werk van de teams maakt het mogelijk voor nieuwe bijdragers om te observeren en te beginnen met helpen zonder enige specifieke privileges. Dit is waarom Debian vaak wordt omschreven als en “meritocracy”.

Deze effectieve operationele methode garandeert de kwaliteit van de bijdragers binnen de “key” Debian teams. Deze methode is zeker niet perfect en occasioneel zijn er diegene die niet akkoord gaan met deze manier van werken. De selectie van ontwikkelaars geaccepteerd in de teams kan arbitrair of zelf oneerlijk lijken. Verder heeft niet iedereen dezelfde definitie van de te verwachten service van deze teams. Voor sommigen is het onacceptabel om acht dagen te moeten wachten voordat een nieuw Debian pakket word toegevoegd, terwijl anderen geduldig zonder probleem drie weken kunnen wachten. Als dusdanig zijn er regelmatig klachten van ontevreden mensen over de “kwaliteit van de service” van sommige teams.

Men kan zich afvragen of het relevant is om de gebruikers te noemen onder hen die binnen het Debian project werken, maar het antwoord is een volmondig ja: ze spelen een kritieke rol binnen het project. Verre van "passief" te zijn, gebruiken sommig gebruikers ontwikkel versies van Debian en rapporteren regelmatig bugs om problemen aan te geven. Andere gaan zelfs verder en stellen ideeën voor ter verbetering, door een bug rapport met een niveau van "wishlist" in te dienen, of door het zelf indienen van correcties aan de bron code, “patches” genoemd in (zie Paragraaf 1.3.2.3, “Inzenden van reparaties”).

$ diff -u bestand.oud bestand.nieuw >bestand.patch

$ patch -p0 bestand.oud <bestand.patch

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.