Разработчики Debian имеют различные обязанности, а как официальные члены проекта они оказывают очень сильное влияние на направление развития проекта. Обычно разработчик Debian ответственен за хотя бы один пакет, но в соответствии с имеющимся временем и желанием он может принять участие во множестве команд и проектов, получив тем самым больше обязанностей в проекте.

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

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

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

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

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

С момента его рождения проектом последовательно руководили Иэн Мёрдок, Брюс Перенс, Ян Джексон, Вихерт Аккерман, Бэн Коллинс, Бидейл Гарби, Мартин Михльмайер, Брендан Робинсон, Энтони Таунс, Сэм Осевар, Стив Макинтайр, Стефано Дзаккироли, Лукас Нуссбаум, Нилл МакГаверн, Мехди Доггай, Крис Лэмб, Сэм Хартман, и Джонатан Картер.

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

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

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

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

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

Этот эффективный рабочий метод гарантирует качество участников «ключевых» команд Debian. Этот метод далёк от совершенства, иногда встречаются те, кто не принимает такой способ работы. Отбор разработчиков в команды может казаться произвольным или даже нечестным. Более того, не у всех имеется сходное определение того, что следует ожидать от этих команд. Для некоторых неприемлемо ждать включение нового пакета Debian в архив в течении восьми дней, хотя другие без особых проблем терпеливо ждут и три недели. Таким образом, по поводу «качества обслуживания», предоставляемого некоторыми командами, регулярно высказываются жалобы.

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

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

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

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