Product SiteDocumentation Site

1.3. Debian プロジェクトの内部の仕組み

Debian プロジェクトによるたくさんの最終結果は、経験豊富な Debian 開発者によるインフラ整備作業、Debian パッケージに対する個人または共同作業、そしてユーザからのフィードバックの同時進行により成り立っています。

1.3.1. Debian 開発者

Debian 開発者には公式プロジェクトメンバーとしてのさまざまな責任があります。Debian 開発者はプロジェクトの方針に重大な影響をおよぼします。一般に Debian 開発者は最低 1 つのパッケージに対して責任がありますが、時間に余裕がありそうしたいと思えば、多数のチームに参加することでプロジェクト内でより重い責任を負うことも自由にできます。
パッケージメンテナンスは比較的厳格に管理された活動で、明確に文書化されており、もっと言えばルールが決められています。事実上、パッケージメンテナンスに関連するルールは Debian ポリシーの定めるすべての基準と適合します。幸いなことに、パッケージメンテナンスの作業を手助けする多くのツールが存在します。それゆえ、開発者は担当パッケージに固有の作業やたとえばバグ修正などのより複雑な作業に集中することが可能です。
Debian プロジェクトの重要な要素である Debian ポリシーはパッケージの品質と Debian ディストリビューションの完全な相互運用性の両方を確保するための規範を定めています。Debian ポリシーのおかげで、Debian は巨大であるにも関わらずその一貫性を保っています。Debian ポリシーは不変の原則というわけではなく、 メーリングリストに寄せられた提案を練ることで絶え間なく進化しています。関係者全員からの同意を得られた修正は承認され、編集責任を持たないメンテナの小集団がこれを文章に反映します (この小集団ができることは、上に挙げたメーリングリストのメンバーである Debian 開発者から同意を得られた修正を反映させることだけです)。現在寄せられている修正の提案を読むにはバグ追跡システムをご確認ください。
Debian ポリシーはパッケージングの技術的側面の大部分をカバーしています。Debian プロジェクトの大きさは組織の問題を引き起こします。この種の問題は Debian 憲章に即して対処されます。Debian 憲章は組織体制と意思決定の手段を定めています。これは言い換えれば、組織的な管理システムと言えます。
Debian 憲章はいくつかの役割と役職、併せてそれぞれに対する責任と権限を定義しています。特筆すべきは Debian 開発者は一般決議に投票することで最終決定を行う権限を常に持っているということです、重大な変化 (基本文書に影響をおよぼすような変化) を起こすには特定多数の 4 分の 3 (75%) が投票すること必要です。しかしながら、Debian 開発者は会議で自分たちを代表し、さまざまなチーム間の連携を確保する「Debian プロジェクトリーダー (DPL)」を毎年選びます。リーダーの選挙は常に活発な議論になります。リーダーの役割は何かの文書で正式に定義されているわけではありません。なぜなら通常、リーダー職の候補者はその役割を自分自身で定義し、それを提案するからです。実際のところ、リーダーの役割には開発者からの共感を得るように、メディアに対する代表者として働くこと、「内部」チーム間の連携をとること、プロジェクトに対する包括的な指導を提供すること、が含まれています。そして、DPL の見解は大多数のプロジェクトメンバーから暗黙のうちに容認されています。
具体的に言えば、Debian プロジェクトリーダーは本当の意味での権力を持っています。さらに、賛否同数の場合にはリーダーの投票が決定票となります。その上、リーダーはまだ誰の権限下にもなっていない案件に判決を下したり、自身の権限の一部を委任したりすることが可能です。
Debian が始まって以来ずっと Debian プロジェクトは止まることなく Debian プロジェクトリーダーに先導されてきました。現在までに DPL の職に就いた人は 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 です。
Debian 憲章では「技術委員会」もまた定義されています。技術委員会の本質的な役割とは、ある技術的な事柄に関して関係する開発者の間で合意に達しなかった場合に、その技術的な事柄の決裁を下すことです。また技術委員会の他の役割として、責任を負っている決定で間違いを犯す開発者に対する顧問役があります。ただし、技術委員会は問題になっているグループの一員から参加するように求められた場合のみ議論に参加するということに注意しなければいけません。
最後に、Debian 憲章では「プロジェクト秘書」の役職も定義しています。プロジェクト秘書はさまざまな選挙と一般決議に関連する投票の運営に責任を負っています。
「一般決議」の手続きは Debian 憲章の中で最初の議論期間から最後の開票まで詳細に説明されています。より詳しい情報は以下のページを参照してください。
たとえ Debian 憲章の規定する民主制が名ばかりのようなものであったとしても、毎日の現実は全く違ったものです。なぜなら Debian は当然ながらフリーソフトウェアにおける能動主義 (do-ocracy) のルールに従い、物事はそれを行った者がどのように行うかを決めるからです。問題に対処するさまざまな方法のそれぞれの価値を議論することは多くの時間を無駄にする可能性があります。つまり議論の結果最終的に選ばれるのは、現実的かつ要件を満足できる最初に提案された解決策になることでしょう…。このような解決策は、一人の有能な人物が時間をかけて努力しなければ、導き出されるものではありません。
Debian プロジェクト内で自分の地位を高めるにはたった一つの方法しかありません。すなわち、何か有益なことをして、それがうまくいったことを示すことです。多くの Debian「管理」チームはチーム内メンバーからの推薦で新メンバーを採用します。つまり、これまでの貢献が効果を挙げており、本人の能力が証明されているボランティアを好むということです。これらのチームの作業は公開されており、新しい貢献者がその作業を観察し手助けを開始するのに特権を必要としません。そのため、Debian は「業績主義」と言われています。
この効果的な運営方法のおかげで「重要な」Debian チーム内では貢献者の品質が保証されています。この方法は決して完璧ではありませんし、時々この運営方法を受け入れられない人もいます。チーム内で採用されている開発者の選択基準は少し気まぐれかもっと言えば不公平なものに見えるかもしれません。その上、チームから受けられるサービスに関して全員が同じ定義を共有しているとも限りません。新しい Debian パッケージを含めるのに 8 日間待たなければいけないのは受け入れがたいという人もいれば、なんの問題もなく 3 週間気長に待つという人もいます。そんなわけで、いくつかのチームが提供する「サービス品質」には常に不満の声が上げられています。

1.3.2. ユーザの積極的役割

読者の皆様の中には Debian プロジェクト内で働く人の中でも特にユーザに言及する必要があるのではないかと感じる方がいらっしゃるかもしれません。これはごく当たり前の感覚です。なぜなら Debian プロジェクトではユーザが重要な役割を果たしているからです。「受け身」の状態から一歩進んで、Debian の開発版を使い、バグ報告を提出して問題を指摘するユーザもいます。さらに深く立ち入り、重要度「wishlist」のバグ報告を提出することで改善案を投稿したり、「パッチ」と呼ばれるソースコードの修正を投稿するユーザもいます (補注BACK TO BASICS パッチ、修正を送る方法」をご覧ください)。
加えて、Debian の提供するサービスに満足している数多くのユーザが彼ら自身の手でプロジェクトに貢献をしたいと思っています。プログラミングに関する専門知識のレベルが十分でない人は翻訳や文書のレビューを行うことで手助けを行うことを選ぶかもしれません。このような作業を行うために各言語に特有の問題を議論するためのメーリングリストがあります。
ユーザの行動の仕方によって、上で述べたすべての貢献の仕組みはさらに効果的なものになります。孤立したユーザの集合体から一歩進んで、ユーザ間の交流が数多く起こるコミュニティこそが本物のコミュニティなのです。ユーザ議論用のメーリングリストである では素晴らしい活動がなされています (第 7 章「問題の解決と関連情報の探索ではこの件に関して詳細に議論しています)。
ユーザは自分に直接影響をおよぼす技術的な問題について互いに助け合ったり、技術的な問題を抱える誰かを助けたりするだけでなく、Debian プロジェクトに貢献するための最良の方法を話し合い、Debian プロジェクトを前進させる手助けをしています。このような議論はしばしば改良を提案するものとなります。
Debian は自己アピールによる普及キャンペーンに資金を使わないため、Debian のユーザは Debian の普及に重要な役割を果たし、Debian の評判は口コミで伝わることが保障されています。
この方法は極めてうまくいきます。なぜならフリーソフトウェアコミュニティのあらゆる層に Debian の支持者がいるからです。すなわち、地域の LUG「Linux ユーザグループ」が企画したインストールパーティ (ベテランユーザが新しいユーザにシステムのインストールの補助を行うワークショップ) から、Linux などについて取り扱う大きな技術会議のアソシエーションブースにまで、Debian の支持者がいるということです。
ボランティアがポスター、パンフレット、ステッカーなどのプロジェクトの宣伝に役立つ資料を作っています。この宣伝資料は誰もが利用できるようにされており、Debian はウェブサイトでこの宣伝資料を無制限に提供しています。

1.3.3. チームとサブプロジェクト

Debian は最初からずっと、ソースパッケージの概念を中心に組織化され続けており、ソースパッケージにはそのメンテナとメンテナのグループがいます。多くの作業チームは長い時間をかけて生まれ続けており、最近サブプロジェクトの周りで成長している最新の一連のチームとともに、インフラの運営および特定のパッケージに依存しないタスク (品質保証、Debian ポリシー、インストーラなど) の管理を保証しています。

1.3.3.1. 現存する Debian サブプロジェクト

人それぞれ好みの Debian があります! サブプロジェクトは Debian を特定のニーズに適応させることに興味を持つボランティアのグループです。特定の領域 (教育、医療、マルチメディア制作など) を対象としたプログラム群の選定にとどまらず、サブプロジェクトは既存パッケージの改良、不足ソフトウェアのパッケージング、インストーラの適応作業、特定文書の作成などにも従事しています。
以下は現存するサブプロジェクトを一部抜粋したものです。
  • Debian-Junior。これは Ben Armstrong によって作成され、子供向けに魅力的で使いやすい Debian システムを提供しています。
  • Debian-Edu。これは Petter Reinholdtsen によって作成され、学問の世界向けに特化したディストリビューションの作成を重視しています。
  • Debian Med。これは Andreas Tille によって作成され、医療分野に特化しています。
  • Debian Multimedia。これは音声およびマルチメディア制作を取り扱います。
  • Debian-Desktop。これはデスクトップを重視しデフォルトテーマのアートワーク作成の調整役を務めています。
  • Debian GIS。これは地理情報システムのアプリケーションとユーザの面倒を見ています。
  • 最後に Debian Accessibility。これは障がいのある人々の要求に合致するよう Debian を改良しています。
Debian サブプロジェクトの数は時間が経過するに従って増え続け、Debian サブプロジェクトの良さに対する認識を改良し続けることは間違いありません。既存の Debian のインフラはサブプロジェクトを完全にサポートしているので、実質的にサブプロジェクトが真の付加価値を上げるための作業に集中することを可能にしています。サブプロジェクトは Debian プロジェクト内で開発しているため Debian との同期について心配することはありません。

1.3.3.2. 管理チーム

多くの管理チームは比較的閉鎖的で新メンバーの採用は現メンバーからの選出で決まります。管理チームの一員になる最良の手段は現在のメンバーを賢明に手伝うこと、つまり自分が管理チームの目標と流儀を理解していることをはっきり示すことです。
ftpmaster は Debian パッケージの公式アーカイブの責任者です。ftpmaster はあるプログラムのメンテナンスを担当しており、このプログラムは開発者が送信したパッケージを受け取り、いくつかの事項を確認した後にパッケージを自動的に参照基準サーバ (ftp-master.debian.org) に保存しています。
ftpmaster はまた、パッケージデータベースの中に新しいパッケージを追加する前に、Debian がこのパッケージを配布しても問題ないことを確認するために、このパッケージのライセンスを確認します。開発者がパッケージの削除を希望する場合、開発者はバグ追跡システムから ftp.debian.org「擬似パッケージ」に対してバグ報告を行い、ftpmaster と連絡を取ります。
Debian システム管理者 (DSA) チーム () は、読者の皆様の予想通り、Debian プロジェクトが利用する多くのサーバのシステム管理に対して責任があります。DSA チームは、すべての基盤サービス (DNS、ウェブ、電子メール、シェルなど) を最適に機能させること、Debian 開発者から要求のあったソフトウェアをインストールすること、セキュリティ関連の予防策を適用すること、を保証します。
listmaster はメーリングリストを運営する電子メールサーバを管理します。新しいメーリングリストを作成し、宛先が不明なメールを処理 (配送失敗通知) し、スパムフィルタ (迷惑メールフィルタ) をメンテナンスするのは listmaster の役目です。
Debian が提供する各サービスには専属の管理チームがあり、ほとんどの場合そのサービスを設置したボランティア (しばしばサービスで利用しているツールをプログラムしたボランティア) がチームのメンバーになっています。これに当てはまるケースとして、バグ追跡システム (BTS)、パッケージトラッカー、alioth.debian.org (FusionForge サーバ、補注TOOL FusionForge、共同開発における万能ナイフ」を参照してください)、qa.debian.org で利用できるサービス、lintian.debian.orgbuildd.debian.orgcdimage.debian.org などがあります。

1.3.3.3. 開発チーム、横断チーム

管理チームとは異なり、開発チームの門戸は外部の貢献者に向けてかなり大きく開かれています。Debian の使命がソフトウェアを作成することではないとしても、Debian プロジェクトは目標を達成するために特定のプログラムを必要としています。もちろん、フリーソフトウェアライセンスの下で開発されたそれらのソフトウェアはフリーソフトウェア世界の他の場所で保証されている方法を活用します。
Debian は自分用に小さなソフトウェアを開発し続けていますが、一部のプログラムは重要な役割を担っており、そのようなプログラムの名声は Debian プロジェクトよりも大きく広がっています。Debian パッケージ管理プログラムの dpkg (実際のところ、これは Debian PacKaGe の 略称で、「dee-package」と発音されます) と、任意の Debian パッケージとそのパッケージが依存しているパッケージを、更新後のシステムの継続性を保障しながら、自動的にインストールする apt (名前は Advanced Package Tool の頭字語) がそのよい例です。一方で、これらのプログラムの働きを全面的に理解するには極めて高いプログラミング能力が必要であるため、チームの規模は極めて小さなものです。
Debian インストールプログラム debian-installer の開発チームは最も重要なチームです。2001 年の構想以来ずっと、開発チームは極めて重要度の高い作業を達成し続けています。たくさんの異なるアーキテクチャに Debian をインストールできるたった 1 つのプログラムを書くのは難しいため、数多くの貢献者が必要でした。それぞれのアーキテクチャではそれぞれ異なる起動メカニズムと異なるブートローダを使っています。この作業のすべては Cyril Brulebois の指揮の下 メーリングリストで組織的に行われています。
debian-cd プログラム (とても小さい) のチームはさらにいっそう控えめな目的を持っています。数多くの「小」貢献者は自分が担当しているアーキテクチャに対して責任を負っています。なぜなら主開発者はアーキテクチャに固有のすべての細かな差異や CD-ROM からインストーラを起動する正確な方法を知ることはできないからです。
多くのチームは他のチームと一緒にパッケージングを行わなければいけません。たとえば は Debian プロジェクトのあらゆるレベルで品質を保証しようと試みます。 メーリングリストはあちこちからの提案に従って Debian ポリシーを成長させます。アーキテクチャごとの違いに対して責任を負うチーム () はすべてのパッケージをコンパイルし、必要ならばパッケージを自分たちが担当しているアーキテクチャに適合するよう書き換えます。
メンテナンスを保証する際に 1 チームの負担が大きくなりすぎないよう、最も重要なパッケージに対しては別のチームが管理しています。そのようなケースとして、C ライブラリと 、C コンパイラと 、Xorg と (このグループは X Strike Force としても知られています) の関係が挙げられます。