Многочисленные результаты, создаваемые Проектом Debian, одновременно возникают благодаря работе над инфраструктурой, выполняемой опытными разработчиками Debian, благодаря индивидуальной и совместной работе разработчиков над пакетами Debian и благодаря отклику пользователей.
1.3.1. Разработчики Debian
Разработчики Debian имеют различные обязанности, а как официальные члены проекта они оказывают очень сильное влияние на направление развития проекта. Обычно разработчик Debian ответственен за хотя бы один пакет, но в соответствии с имеющимся временем и желанием он может принять участие во множестве команд, получив тем самым больше обязанностей в проекте.
Сопровождение пакетов является относительно регламентированной деятельностью, оно хорошо документировано и даже строго регулируется. В результате, пакет должен соответствовать стандартам, устанавливаемым
Политикой Debian. К счастью, существует множество инструментов, которые облегчают работу сопровождающего. Таким образом, разработчик может сконцентрироваться на особенностях своего пакета и на более сложной задаче, например, на исправлении ошибок.
Политика, существенный элемент Проекта Debian, определяет нормы, гарантирующие качество пакетов и операционную совместимость самого дистрибутива. Благодаря Политике Debian остаётся упорядоченным несмотря на свой гигантский размер. Политика не зафиксирована в камне, но постоянно развивается благодаря предложениям, формулируемым в списке рассылки
debian-policy@lists.debian.org
. Улучшения, с которыми согласны все заинтересованные стороны, принимаются и добавляются в текст небольшой группой сопровождающих, у которых нет редакторских прав (они лишь добавляют изменения, которые были утверждены разработчиками Debian, которые являются участниками указанного списка рассылки). Вы можете прочесть текущие предложения улучшений в системе отслеживания ошибок:
Политика описывает большую часть технических аспектов процесса создания пакетов. Тем не менее, размер проекта приводит к возникновению в том числе и организационных проблем; эти проблемы решаются с помощью Конституции Debian, которая определяет структуру проекта, а также средства принятия решений. Другими словами, это формальная система управления проектом.
Конституция определяет ряд ролей и должностей, а также ответственности и полномочия каждой их них. Особенно следует заметить, что разработчики Debian всегда имеют полномочия принятия окончательного решения путём общего решения, в котором для внесения существенных изменений (например, изменения основополагающих документов) требуется квалифицированное большинство из трёх четвёртых (75%) голосов. Тем не менее, ежегодно разработчики выбирают «лидера», который представляет проект на различных мероприятиях и гарантирует внутреннее взаимодействие между различными командами. Эти выборы всегда представляют собой период интенсивных обсуждений. Эта роль лидера формально не определена ни одним документом, кандидаты на этот пост обычно предлагают своё собственное видение этой должности. На практике роль лидера предполагает представление проекта средствам массовой информации, координацию между «внутренними» командами, общее управление проектом, в котором участвуют и разработчики (взгляды DPL имплицитно принимаются большинство членов проекта).
Как правило, у лидера имеется реальная власть; его голос разрешает ситуации с равным числом голосов; он может принимать любое решение, которое пока ещё не относится к полномочиям кого-либо ещё, а также может делегировать часть своей ответственности.
С момента его рождения проектом последовательно руководили Иэн Мёрдок, Брюс Перенс, Ян Джексон, Вихерт Аккерман, Бэн Коллинс, Бидейл Гарби, Мартин Михльмайер, Брендан Робинсон, Энтони Таунс, Сэм Осевар, Стив Макинтайр, Стефано Дзаккироли и Лукас Нуссбаум.
Также Конституция определяет «технический комитет». Основная роль комитета заключается в разрешении технических вопросов в том случае, когда участвующие в обсуждении разработчики не могут достичь согласия. Кроме того, этот комитет играет совещательную роль для любого разработчика, которые не может самостоятельно принять решение по какому-то вопросу, за который он отвечает. Важно отметить, что комитет включается в работу только в том случае, когда его к этому приглашает одна из сторон дискуссии.
Наконец, Конституция определяет должность «секретаря проекта», который несёт ответственность за голосование в ходе различных выборов и общих решений.
Процедура «общего решения» подробно описывается в Конституции, описание затрагивает как период первоначального обсуждения, так и окончательный подсчёт голосов. Подробности см. на странице
Несмотря на то, что Конституция обеспечивает видимость демократии, реальность совсем не та. Естественным образом Debian следует правилам Свободного ПО, заключающимся в дуократии: тот, кто что-то делает, тот и решает, как это делать. Большое количество времени может быть потеряно на обсуждение соответствующих положительных черт различных способов решения какой-то проблемы; избранное решение будет одновременно и функциональным, и подходящим всем... что потребует гораздо большего количества времени, чем в решение этой проблемы может вложить компетентный человек.
Звёздочки можно заработать только одним способом: нужно сделать что-то полезное и показать, что оно хорошо работает. Многие «административные» команды 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.
1.3.2. The Active Role of Users
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 sidebar
BACK TO BASICS Patch, the way to send a fix).
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.
Not only do users help themselves (and others) on technical issues that directly affect them, but they also discuss the best ways to contribute to the Debian project and help it move forward — discussions that frequently result in suggestions for improvements.
Since Debian does not expend funds on any self-promoting marketing campaigns, its users play an essential role in its diffusion, ensuring its fame via word-of-mouth.
This method functions quite well, since Debian fans are found at all levels of the free software community: from install parties (workshops where seasoned users assist newcomers to install the system) organized by local LUGs or “Linux User Groups”, to association booths at large tech conventions dealing with Linux, etc.
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:
1.3.3. Teams and Sub-Projects
Debian has been organized, right from the start, 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.
1.3.3.1. Existing Debian Sub-Projects
To each their own Debian! A sub-project is a group of volunteers interested in adapting Debian to specific needs. Beyond the selection of a sub-group of programs intended for a particular domain (education, medicine, multimedia creation, etc.), sub-projects are also involved in improving existing packages, packaging missing software, adapting the installer, creating specific documentation, and more.
Here is a small selection of current sub-projects:
Debian-Junior, by Ben Armstrong, offering an appealing and easy to use Debian system for children;
Debian-Edu, by Petter Reinholdtsen, focused on the creation of a specialized distribution for the academic world;
Debian Med, by Andreas Tille, dedicated to the medical field;
Debian Multimedia which deals with audio and multimedia work;
Debian-Desktop which focuses on the desktop and coordinates artwork for the default theme;
Debian GIS which takes care of Geographical Information Systems applications and users;
Debian Accessibility, finally, improving Debian to match the requirements of people with disabilities.
This list will most likely continue to grow with time and improved perception of the advantages of Debian sub-projects. Fully supported by the existing Debian infrastructure, they can, in effect, focus on work with real added value, without worrying about remaining synchronized with Debian, since they are developed within the project.
1.3.3.2. Administrative Teams
Most administrative teams are relatively closed and recruit only by cooptation. The best means to become a part of one is to intelligently assist the current members, demonstrating that you have understood their objectives and methods of operation.
The ftpmasters are in charge of the official archive of Debian packages. They maintain the program that receives packages sent by developers and automatically stores them, after some checks, on the reference server (ftp-master.debian.org
).
They must also verify the licenses of all new packages, in order to ensure that Debian may distribute them, prior to including them in the corpus of existing packages. When a developer wishes to remove a package, they address this team through the bug tracking system and the ftp.debian.org “pseudo-package”.
The
Debian System Administrators (DSA) team (
debian-admin@lists.debian.org
), as one might expect, is responsible for system administration of the many servers used by the project. They ensure optimal functioning of all base services (DNS, Web, e-mail, shell, etc.), install software requested by Debian developers, and take all precautions in regards to security.
The listmasters administer the e-mail server that manages the mailing lists. They create new lists, handle bounces (delivery failure notices), and maintain spam filters (unsolicited bulk e-mail).
Each specific service has its own administration team, generally composed of volunteers who have installed it (and also frequently programmed the corresponding tools themselves). This is the case of the bug tracking system (BTS), the package tracker,
alioth.debian.org
(FusionForge server, see sidebar
TOOL FusionForge, the Swiss Army Knife of collaborative development), the services available on
qa.debian.org
,
lintian.debian.org
,
buildd.debian.org
,
cdimage.debian.org
, etc.
1.3.3.3. Development Teams, Transversal Teams
Unlike administrative teams, the development teams are rather widely open, even to outside contributors. Even if Debian does not have a vocation to create software, the project needs some specific programs to meet its goals. Of course, developed under a free software license, these tools make use of methods proven elsewhere in the free software world.
Debian has developed little software of its own, but certain programs have assumed a starring role, and their fame has spread beyond the scope of the project. Good examples are dpkg
, the Debian package management program (it is, in fact, an abbreviation of Debian PacKaGe, and generally pronounced as “dee-package”), and apt
, a tool to automatically install any Debian package, and its dependencies, guaranteeing the consistency of the system after an upgrade (its name is an acronym for Advanced Package Tool). Their teams are, however, much smaller, since a rather high level of programming skill is required to gain an overall understanding of the operations of these types of programs.
The most important team is probably that for the Debian installation program,
debian-installer
, which has accomplished a work of momentous proportions since its conception in 2001. Numerous contributors were needed, since it is difficult to write a single program able to install Debian on a dozen different architectures. Each one has its own mechanism for booting and its own bootloader. All of this work is coordinated on the
debian-boot@lists.debian.org
mailing list, under the direction of Cyril Brulebois.
The (very small) debian-cd
program team has an even more modest objective. Many “small” contributors are responsible for their architecture, since the main developer can not know all the subtleties, nor the exact way to start the installer from the CD-ROM.