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 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.

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:

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.

Đặc biệt là, người lãnh đạo có quyền hành thật sự; lá phiếu của họ quyết định kết quả hòa; họ có thể đưa ra bất kì quyết định nào mà không cần quyền hạn của bất kì ai khác, và có thể ủy thác một phần trách nhiệm của họ.

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.

Hiến pháp cũng định rõ một “Ủy ban kỹ thuật”. Vai trò chính của ủy bàn là quyết định các vấn đề kỹ thuật khi các nhà phát triển có liên quan không đạt được một thỏa thuận chung. Về phương diện khác, ủy ban này đóng vai trò cố vấn cho bất kì nhà phát triển nào thất bại trong việc ra quyết định với thứ mà họ đang chịu trách nhiệm. Cần lưu ý rằng họ chỉ tham gia khi được mời vào bởi một trong các bên kể trên.

Cuối cùng, hiến pháp định rõ vị trí của một “thư ký dự án”, người sẽ phụ trách việc tổ chức các cuộc bầu phiếu liên quan đến nhiều cuộc bầu chọn và bỏ phiếu toàn diện.

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.

Đó là cách duy nhất để đạt được tín nhiệm: làm một thứ gì đó hữu ích và chứng minh rằng nó hoạt động tốt. Nhiều nhóm “điều hành” Debian hoạt động bằng cách kết nạp, ưu tiên những người tình nguyện đã đóng góp một cách hiệu quả và chứng minh được năng lực của họ. Tính chất public của công việc cho phép các cộng tác viên mới quan sát và bắt đầu giúp đỡ mà không cần đặc quyền nào. Đó là lý do mà Debian thường được mô tả như một “chế độ trọng dụng nhân tài”.

Phương pháp hoạt động hiệu quả này đảm bảo chất lượng của các cộng tác viên trong team “chính” của Debian. Phương pháp này chưa thực sự hoàn hảo và thỉnh thoảng có những người không chấp nhận cách thức hoạt động này. Việc lựa chọn các nhà phát triển được chấp nhận vào nhóm dường như khá tùy tiện, hay thậm chí không công bằng. Hơn nữa, không phải ai cũng có chung định nghĩa về dịch vụ mà các team đó trông đợi. Vơi nhiều người, thật không thể chấp nhận được khi phải đợi 8 ngày để thêm vào một package Debian mới, trong khi những người khác có thể đợi 3 tuần mà không có vấn đề gì. Giống như vậy, còn nhiều lời phàn nàn giận dữ khác về “chất lượng dịch vụ” từ một vài team.

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 Phần 1.3.2.3, “Sending fixes”).

$ 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.