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, 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.

The Policy, an essential element of the Debian Project, establishes the norms ensuring both the quality of the packages and perfect interoperability of the distribution. Thanks to this Policy, Debian remains consistent despite its gigantic size. This Policy is not fixed in stone, but continuously evolves thanks to proposals formulated on the debian-policy@lists.debian.org mailing list. Amendments that are agreed upon by all interested parties are accepted and applied to the text by a small group of maintainers who have no editorial responsibility (they only include the modifications agreed upon by the Debian developers that are members of the above-mentioned list). You can read current amendment proposals on the bug tracking system:

La Normativa cubre en detalle los aspectos técnicos de la creación de paquetes. El tamaño del proyecto también genera problemas de organización; estos son tratados por la Constitución Debian («Debian Constitution»), que establece una estructura y los medios para tomar decisiones. En otras palabras: un sistema formal de gobierno.

Esta constitución define cierta cantidad de roles y posiciones además de las responsabilidades y atribuciones de cada uno. Es particularmente importante notar que los desarrolladores Debian siempre tienen la autoridad máxima en cuanto a decisiones mediante sus votos a resoluciones generales, en ellas se necesita una mayoría calificada de tres cuartos (75%) de los votos para realizar modificaciones significativas (como aquellas que tendrán impacto en los documentos fundacionales). Sin embargo, los desarrolladores eligen un «líder» cada año para representarlos en reuniones y asegurar la coordinación interna entre varios equipos. Esta elección es siempre un período de discusiones intensas. El rol del líder no está formalmente definido en ningún documento: los candidatos al puesto generalmente ofrecen su propia definición para el mismo. En la práctica, el rol de líder incluye ser representante frente a los medios, coordinar equipos «internos» y dar una guía general al proyecto con la que los desarrolladores empaticen: la visión del líder («DPL» por sus siglas en inglés) son aprobadas implícitamente por la mayoría de los miembros del proyecto.

Específicamente, el líder realmente tiene autoridad: sus votos deciden votaciones empatadas, pueden tomar decisiones sobre aquello que no esté a cargo de alguien más y pueden delegar parte de sus responsabilidades.

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, Mehdi Dogguy, Chris Lamb and Sam Hartman.

La constitución también define un «comité técnico». El rol esencial de este comité es tomar decisiones en asuntos técnicos cuando los desarrolladores involucrados no llegaron a un acuerdo entre ellos. De lo contrario, el comité tiene un rol de consejero para cualquier desarrollador que no tome una decisión en una cuestión de la que son responsables. Es importante notar que el comité sólo se involucra cuando alguna de las partes así lo solicita.

Por último, la constitución define la posición de «secretario del proyecto» quien está a cargo de organizar las votaciones relacionadas a las varias elecciones y resoluciones generales.

The “general resolution” 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:

Aún cuando la constitución establece una democracia aparente, la realidad diaria es muy diferente: Debian sigue naturalmente las reglas de una «do-ocracia» (el gobierno de los que hacen) en el software libre: es aquél que hace las cosas el que decide cómo hacerlas. Se puede desperdiciar mucho tiempo discutiendo los méritos respectivos de varias formas de abordar un problema; la solución elegida será la primera que sea tanto funcional como satisfactoria... que saldrá del tiempo que una persona competente invirtió en ella.

Esta es la única forma en que ganará sus insignias: haga algo útil y muestre que ha trabajado bien. Muchos equipos «administrativos» en Debian funcionan por cooptación, prefiriendo voluntarios que ya han realizado contribuciones palpables y demostrado ser competentes. La naturaleza pública del trabajo de estos equipos hace posible que nuevos colaboradores la observen y empiecen a ayudar sin ningún privilegio especial. Esta es la razón por la que Debian es normalmente descripto como una «meritocracia».

Este método de operaciones es efectivo y garantiza la calidad de los contribuyentes en los equipos «clave» de Debian. Este método dista de ser perfecto y ocasionalmente algunos no lo aceptan. La selección de desarrolladores aceptados en los grupos puede parecer arbitraria o incluso injusta. Lo que es más, no todos tienen la misma definición de los servicios esperados de estos equipos. Para algunos es inaceptable tener que esperar ocho días para la inclusión de un nuevo paquete en Debian, mientras que otros esperarán pacientemente por tres semanas sin problemas. Por ello, regularmente hay quejas sobre la «calidad de servicio» de algunos equipos por aquellos que están descontentos.

One might wonder if it is relevant to mention the users among those who work within the Debian project, but the answer is a definite yes: they play a critical role in the project. Far from being “passive”, some users run development versions of Debian and regularly file bug reports to indicate problems. Others go even further and submit ideas for improvements, by filing a bug report with a severity level of “wishlist”, or even submit corrections to the source code, called “patches” (see Sección 1.3.2.3, “Sending fixes”).

$ diff -u archivo.antiguo archivo.nuevo >archivo.patch

$ patch -p0 archivo.viejo <archivo.patch

$ git clone https://salsa.debian.org/youruser/debian-handbook/
Cloning into 'debian-handbook'...
remote: Enumerating objects: 20838, done.
remote: Counting objects: 100% (20838/20838), done.
remote: Compressing objects: 100% (4510/4510), done.
remote: Total 20838 (delta 16316), reused 20809 (delta 16307)
Receiving objects: 100% (20838/20838), 139.41 MiB | 131.00 KiB/s, done.
Resolving deltas: 100% (16316/16316), done.
Checking out files: 100% (1351/1351), done.
$ editor file
$ git add file
$ git commit -m "Correct typo in chapter 3"
[buster/master ca5a0039] Update chapter 1
 1 file changed, 98 insertions(+), 54 deletions(-)
$ git push
Username for 'https://salsa.debian.org': youruser
Password for 'https://youruser@salsa.debian.org': yourpasswd
Enumerating objects: 96, done.
Counting objects: 100% (96/96), done.
Delta compression using up to 2 threads
Compressing objects: 100% (80/80), done.
Writing objects: 100% (80/80), 456.23 KiB | 3.83 MiB/s, done.
Total 80 (delta 59), reused 2 (delta 0)
To https://salsa.debian.org/youruser/debian-handbook.git/
   18e0e26c..ca5a0039  buster/master -> buster/master

Debian ha estado organizado, desde sus comienzos, alrededor del concepto de paquetes fuente, cada uno con su encargado o grupo de responsables. Con el tiempo, han aparecido numerosos equipos de trabajo asegurando la administración de la infraestructura, la organización de tareas que no son específicas a un paquete en particular (control de calidad, normativa de Debian, instalador, etc.), con los últimos equipos creciendo alrededor de subproyectos.