Debian developers have various responsibilities, and as official project members, they have great influence on the direction the project takes. A Debian developer is traditionally 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.

Package maintenance is a relatively regimented activity, very documented, or even regulated. It must, in effect, comply with all the standards established by the Debian Policy. Fortunately, there are many tools that facilitate the maintainer's work. The developer can, thus, focus on the specifics of their package and on more complex tasks, such as “squashing“ bugs.

Retningslinjene, en vesentlig del av Debian prosjektet, slår fast normene som sikrer både kvaliteten på pakkene og perfekt samvirke i distribusjonen. Takket være disse retningslinjene, forblir Debian konsistent til tross for sin gigantiske størrelse. Disse retningslinjene er ikke skrevet i stein, men utvikler seg stadig takket være forslag formulert på e-postlisten debian-policy@lists.debian.org. Endringer som det er enighet om blant alle interesserte parter, blir akseptert og tas inn i teksten av en liten gruppe vedlikeholdere som ikke har noe redaksjonelt ansvar (de bare fører inn de endringer det er enighet om blant de Debian-utviklere som er medlemmer av den ovennevnte listen). Du kan lese aktuelle endringsforslag på sporingssystemet for feil:

Praksisen dekker i stor grad de tekniske aspektene ved pakkingen. Størrelsen på prosjektet gir også organisatoriske problemer. Disse er også håndtert i Debians vedtekter. De slår fast struktur og hvordan beslutninger tas. Med andre ord, et formelt styringssystem.

Vedtektene definerer et antall roller og posisjoner, alle med ansvar og myndighet. Det er spesielt verdt å merke seg at Debian-utviklere alltid har den endelige beslutningsmyndighet i en avstemning om oppløsning, mens et kvalifisert flertall på tre fjerdedeler (75 %) av stemmene er nødvendig for vesentlige endringer (for eksempel avgjørelser med innvirkning på grunnlagsdokumentene). Utviklerne velger årlig en «leder» til å representere seg i møter, og sikre intern koordinering mellom ulike grupper. Før dette valget er det alltid en periode med intense diskusjoner. Denne lederrollen er ikke formelt definert i noe dokument: Kandidater for denne oppgaven foreslår gjerne sin egen definisjon av lederoppgaven. I praksis omfatter rollen å representere i media, koordinere mellom «interne» grupper, og gi generelle anbefalinger til prosjektet, innenfor det som utviklerne kan forholde seg til. DPLs synspunkter er implisitt godkjent av flertallet av prosjektmedlemmer.

Helt konkret har lederen reell myndighet. Stemmeretten deres gir utslaget ved stemmeliket; de kan beslutte om det som ikke allerede er under noen andres ansvar, og lederen kan delegere deler av sitt ansvar.

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, Jonathan Carter, and Andreas Tille.

Statuttene definerer også en «teknisk komité». Denne komiteens vesentlige rolle er å bestemme i tekniske anliggender når de involverte utviklerne ikke kommer til enighet seg imellom. Ellers spiller denne komiteen en rådgivende rolle for alle utviklere som ikke klarer å ta en beslutning der de er ansvarlige. Det er viktig å merke seg at komiteen bare involveres når den blir bedt om det av en av de berørte partene.

Til slutt definerer vedtektene rollen som «prosjektsekretær», som er ansvarlig for organiseringen av avstemmingen ved de ulike valg og plenumsvedtak.

«Plenumsvedtak»-prosedyren (GR) er gitt i beskrevet i vedtektene, fra den innledende diskusjonsperioden til den endelige telling av stemmene. Det mest interessante aspektet ved denne prosessen er at ved stemmegivning, må utviklere rangere de forskjellige valgmulighetene, og vinneren blir valgt med en Condorcet method (mer spesifikt, Schulze-metoden). For videre detaljer se:

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 puts into it.

Dette er den eneste måten å vise sin verdi på: Å gjøre noe nyttig, og vise at man har fungert godt. Mange av Debians «administrative» grupper er selvrekrutterende og foretrekker frivillige som allerede effektivt har bidratt og demonstrert sin kompetanse. Åpenheten rundt arbeidet med disse gruppene gjør det mulig for nye bidragsytere å følge med og bistå uten noen spesielle tillatelser. Dette er grunnen til at Debian ofte blir beskrevet som et «meritokrati».

This effective operational method guarantees the quality of contributors in the “key” Debian teams. This method is by no means perfect, and occasionally there are those who do not accept this way of operating. The selection of developers accepted in the teams may appear a bit arbitrary, or even unfair. Furthermore, not everybody has the same definition of the service expected from these teams. For some, it is unacceptable to have to wait eight days for inclusion of a new Debian package, while others will wait patiently for three weeks without a problem. As such, there are regular complaints from the disgruntled about the “quality of service” from some teams.

Man kan lure på om det er relevant å nevne brukere blant dem som bidrar innenfor Debian-prosjektet, men svaret er et klart ja: De har en avgjørende rolle i prosjektet. Langt fra å være «passive» kjører noen brukere utviklingsversjoner av Debian, og sender regelmessig feilrapporter for å melde om problemer. Andre går enda lenger og sender inn feilrapporter med ideer til forbedringer, med alvorlighetsgrad «wishlist». Noen brukere sender til og med inn rettelser til kildekoden som kalles «patcher» (se sidefelt Seksjon 1.3.2.3, «Å sende fikser»).

$ diff -u fil.old fil.new >fil.patch

$ patch -p0 fil.old <fil.patch

Helt fra starten av har Debian vært organisert rundt begrepet kildepakker, hver med sin vedlikeholder eller gruppe av vedlikeholdere. Mange arbeidsgrupper har dukket opp over tid, noe som sikrer administrasjon av infrastruktur og organisering av oppgaver som ikke gjelder en enkeltpakke (kvalitetssikring, Debian-retningslinjene, installerer og så videre). De siste i rekken av grupperinger har vokst opp rundt delprosjekter og blandinger.