Os desenvolvedores Debian tem várias responsabilidades, e como membros oficiais do projeto, eles têm grande influência na direção que o projeto toma. Um desenvolvedor Debian é geralmente responsável por pelo menos um pacote, mas de acordo com seu tempo disponível e vontade, eles são livres para se envolverem em numerosas equipes e projetos, adquirindo, assim, mais responsabilidades dentro do projeto.

Manutenção de pacotes é uma atividade relativamente organizada, muito documentada ou mesmo regulamentada. Deve, de fato, obedecer todas as normas estabelecidas pela Política Debian. Felizmente, existem muitas ferramentas que facilitam o trabalho do mantenedor. O desenvolvedor pode, assim, se concentrar nas especificidades do seu pacote e em tarefas mais complexas, tais como correção de erros.

A política, um elemento essencial do Projeto Debian, estabelece as normas que asseguram a qualidade dos pacotes e interoperabilidade perfeita da distribuição. Graças a esta Política, o Debian permanece consistente apesar de seu tamanho gigantesco. Esta Política não é cláusula pétrea, mas continuamente evolui graças às propostas formuladas na lista de discussão debian-policy@lists.debia.org. As alterações acordadas por todas as partes interessadas são aprovadas e aplicadas ao texto por um reduzido grupo de mantenedores que não têm qualquer responsabilidade editorial (eles somente incluem as modificações acordadas pelos desenvolvedores do Debian que são membros da lista acima referida). Você pode ler as propostas de alteração em andamento no sistema de rastreamento de erros:

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.

Especificamente, o líder tem autoridade real; o voto dele resolve votações empatadas, ele pode tomar qualquer decisão que não esteja sob a autoridade de alguém e pode delegar parte das suas 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, Neill McGovern, Mehdi Dogguy, Chris Lamb, Sam Hartman, and Jonathan Carter.

A Constituição também define uma "comissão técnica". O papel essencial desta comissão é o de decidir sobre questões técnicas, quando os desenvolvedores envolvidos não chegaram a um acordo entre si. Caso contrário, esta comissão tem um papel consultivo para qualquer desenvolvedor que não consegue tomar uma decisão para o quai é responsável. É importante notar que eles só se envolvem quando convidados a fazê-lo por uma das partes em questão.

Finalmente, a Constituição define a posição de "secretário de projeto", que é responsável pela organização dos votos relacionados às várias eleições e resoluções gerais.

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.

Esta é a única maneira de obter reconhecimento: fazer algo de útil e mostrar que funciona bem. Muitas equipes "administrativas" Debian operam por cooptação, preferindo voluntários que já contribuíram efetivamente e provaram sua competência. A natureza pública do trabalho dessas equipes faz com que seja possível a observação e ajuda por parte de novos contribuintes, sem a necessidade de privilégios especiais. É por isso que o Debian é frequentemente descrito como uma "meritocracia".

Este efetivo método operacional garante a qualidade dos contribuidores nas equipes Debian "chave". Este método é de forma alguma perfeito e, ocasionalmente, há aqueles que não aceitam esta forma de operar. A seleção dos desenvolvedores aceitos nas equipes pode parecer um pouco arbitrária, ou mesmo injusta. Além disso, nem todo mundo tem a mesma definição do serviço esperado das equipes. Para alguns, é inaceitável ter que esperar oito dias para a inclusão de um pacote novo, enquanto outros vão esperar pacientemente por três semanas sem nenhum problema. Como tal, há queixas regulares a partir de descontentes com a "qualidade de serviço" de algumas equipes.

Alguém pode se perguntar se é relevante mencionar os usuários entre aqueles que trabalham dentro do projeto Debian, mas a resposta é com certeza "sim". eles desempenham um papel fundamental no projeto. Longe de serem "passivos", alguns usuários executam versões de desenvolvimento do Debian e regularmente apresentam relatórios de bugs para indicar problemas. Outros vão ainda mais longe e apresentam ideias de melhorias, mediante a apresentação de um relatório de bug com um nível de gravidade "wishlist", ou mesmo apresentam correções no código fonte, chamadas de "patches" (remendos em português) (vejaSeção 1.3.2.3, “Enviando correções” ).

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

$ patch -p0 file.old <file.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.