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.

Политика, существенный элемент Проекта Debian, определяет нормы, гарантирующие качество пакетов и операционную совместимость самого дистрибутива. Благодаря Политике Debian остаётся упорядоченным несмотря на свой гигантский размер. Политика не зафиксирована в камне, но постоянно развивается благодаря предложениям, формулируемым в списке рассылки debian-policy@lists.debian.org. Улучшения, с которыми согласны все заинтересованные стороны, принимаются и добавляются в текст небольшой группой сопровождающих, у которых нет редакторских прав (они лишь добавляют изменения, которые были утверждены разработчиками Debian, которые являются участниками указанного списка рассылки). Вы можете прочесть текущие предложения улучшений в системе отслеживания ошибок:

Политика описывает большую часть технических аспектов процесса создания пакетов. Тем не менее, размер проекта приводит к возникновению в том числе и организационных проблем; эти проблемы решаются с помощью Конституции Debian, которая определяет структуру проекта, а также средства принятия решений. Другими словами, это формальная система управления проектом.

Конституция определяет ряд ролей и должностей, а также ответственности и полномочия каждой их них. Особенно следует заметить, что разработчики Debian всегда имеют полномочия принятия окончательного решения путём общего решения, в котором для внесения существенных изменений (например, изменения основополагающих документов) требуется квалифицированное большинство из трёх четвёртых (75%) голосов. Тем не менее, ежегодно разработчики выбирают «лидера», который представляет проект на различных мероприятиях и гарантирует внутреннее взаимодействие между различными командами. Эти выборы всегда представляют собой период интенсивных обсуждений. Роль лидера проекта Debian (DPL) формально не определена ни одним документом, кандидаты на этот пост обычно предлагают своё собственное видение этой должности. На практике роль лидера предполагает представление проекта средствам массовой информации, координацию между «внутренними» командами, общее управление проектом, в котором участвуют и разработчики (взгляды DPL имплицитно принимаются большинством членов проекта).

Как правило, у лидера имеется реальная власть; его голос разрешает ситуации с равным числом голосов; он может принимать любое решение, которое пока ещё не относится к полномочиям кого-либо ещё, а также может делегировать часть своей ответственности.

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.

Также Конституция определяет «технический комитет». Основная роль комитета заключается в разрешении технических вопросов в том случае, когда участвующие в обсуждении разработчики не могут достичь согласия. Кроме того, этот комитет играет совещательную роль для любого разработчика, не способного самостоятельно принять решение по какому-то вопросу, за который он отвечает. Важно отметить, что комитет включается в работу только в том случае, когда его к этому приглашает одна из сторон дискуссии.

Наконец, Конституция определяет должность «секретаря проекта», который несёт ответственность за голосование в ходе различных выборов и общих решений.

Процедура «общего решения» (GR) полностью подробно описана в конституции, от первоначального периода обсуждения до окончательного подсчета голосов. Самый интересный аспект этого процесса заключается в том, что когда дело доходит до фактического голосования, разработчикам приходится ранжировать различные варианты голосования между ними, и победитель выбирается с помощью Condorcet method (точнее, метод Шульце). Более подробную информацию см.:

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.

Звёздочки можно заработать только одним способом: нужно сделать что-то полезное и показать, что оно хорошо работает. Многие «административные» команды Debian действуют методом кооптации, предпочитая добровольцев, которые уже внесли оптимальный вклад и доказали свою компетентность. Публичность работы таких команд позволяет новым участникам наблюдать за работой и начинать оказывать помощь без каких-либо специальных привилегий. Вот почему Debian часто описывается как «меритократия».

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.

Возникает вопрос, уместно ли указывать пользователей среди тех, что работают в Проекте Debian. Ответ на этот вопрос определённо положительный: пользователи играют в Проекте критическую роль. Будучи вовсе не «пассивными» пользователями, некоторые из них используют разрабатываемые версии Debian и регулярно сообщают об ошибках и проблемах. Другие пользователи идут ещё дальше и предлагают свои идеи улучшений, отправляя отчёты об ошибках уровня "wishlist" или предлагая исправления исходного кода, называемые «заплатами» (см. боковую панель Раздел 1.3.2.3, «Отправка исправлений»).

$ diff -u старый.файл новый.файл >файл.заплаты

$ patch -p0 старый.файл <файл.заплаты

Debian с самого начала был организован вокруг концепции пакетов с исходным кодом, у каждого из которых имеется свой сопровождающий или группа сопровождающих. Со временем для обеспечения администрирования инфраструктуры и выполнения задач, которые не связаны с каким-то отдельным пакетом (контроль качества, Политика Debian, программа установки и т. д.), появились многие рабочие команды, последние из которых вырастают вокруг подпроектов и смесей.