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, acquiring, thus, 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:

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

Конституция определяет ряд ролей и должностей, а также ответственности и полномочия каждой их них. Особенно следует заметить, что разработчики Debian всегда имеют полномочия принятия окончательного решения путём общего решения, в котором для внесения существенных изменений (например, изменения основополагающих документов) требуется квалифицированное большинство из трёх четвёртых (75%) голосов. Тем не менее, ежегодно разработчики выбирают «лидера», который представляет проект на различных мероприятиях и гарантирует внутреннее взаимодействие между различными командами. Эти выборы всегда представляют собой период интенсивных обсуждений. Эта роль лидера формально не определена ни одним документом, кандидаты на этот пост обычно предлагают своё собственное видение этой должности. На практике роль лидера предполагает представление проекта средствам массовой информации, координацию между «внутренними» командами, общее управление проектом, в котором участвуют и разработчики (взгляды 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, Mehdi Dogguy and Chris Lamb.

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

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

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:

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

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

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

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

Additionally, numerous satisfied users of the service offered by Debian like to make a contribution of their own to the project. As not everyone has appropriate levels of expertise in programming, they may choose to assist with the translation and review of documentation. There are language-specific mailing lists to coordinate this work.

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

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

Все эти механизмы участия становятся более эффективными благодаря пользователям. Не будучи собранием изолированных индивидов, пользователи представляют собой настоящее сообщество, внутри которого постоянно происходят различные взаимодействия. Мы особенно выделяем впечатляющую активность в пользовательском списке рассылки, debian-user@lists.debian.org (в Глава 7, Решение проблем и поиск необходимой информации содержит более подробное описание).

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

Поскольку Debian не тратит деньги на маркетинговые и рекламные компании, пользователи дистрибутива играют главную роль в его продвижении, распространяя славу о нём из уст в уста.

Этот метод работает весьма неплохо, так как энтузиасты Debian находятся на любом уровне сообщества свободного ПО: на вечерниках по установке (практических сессиях, на которых опытные пользователи помогают новичкам установить систему), организуемых локальными LUG (от англ. Linux User Groups - группами пользователей Linux) до стендов на крупных технических выставках, посвящённых Linux и т.д.

Volunteers make posters, brochures, stickers, and other useful promotional materials for the project, which they make available to everyone, and which Debian provides freely on its website and on its wiki:

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