Barth氏によると、Debian憲章はすべての中心的存在であるべきであるが、現在はまだそうなっておらず、しかしそれにもかかわらずDebian憲章は実際に機能しているのだという。そのため改良を加える場合には、その改良が本当に状況を改善させるものなのかということを慎重に確認する必要があるとのことだ。
Barth氏は、有名なDebianのフレーム・ウォーは実はある意味ガバナンスの一形態なのだと表現した上で、Debianの現在のガバナンス体制について、次のように簡単にまとめた。「一般決議（General Resolutions）」では、特定の議題についてすべてのDD（Debian開発者）に対し投票が呼び掛けられる。ただし時間がかかり骨の折れる方法であるためあまり頻繁には使用されない。二者の開発者間で技術的な方針や決断が衝突する場合には、「技術委員会（Technical Committee）」が判断を下す。DPLには、権限を委任する権限がある。「品質保証チーム（Quality Assurance team）」には、強制的にパッケージをアップロードする権限がある。
そしてBarth氏は、どのような改善が必要だろうかと問いかけた。DebianにはDPLチームが必要なのだろうか？ 「社会委員会（Social Committee）」（なお社会委員会をテーマにした講演も後日行なわれた）や、ことによってはDPLの権限委任に関するシステムの改革が必要なのだろうか？
その次に行なわれた議論では、厳密な解釈上Debian憲章違反であるという理由で優れた作業を行なっている開発者を追放するべきではないということが提案された。
また、Debianの問題点はいくつかのインフラ・チームの決定をくつがえすことができないということだとはっきりと批判する人もいて、そのようなチームは選挙で選ばれたわけでもなく、説明/報告する義務を負っているわけでもないのにも関わらず、最終的な決定を下す権限を与えられていると指摘した。それに対してBarth氏は、確かにそうかもしれないがその一方で、そのような作業を行なっている人々の決定をDPLがくつがえすことが認められるべきではないと述べた。Debian憲章はまさにそのような理由、つまり、誰かの髪の色が気に入らないからといってその人を追放する権限をDPLに与えないために存在しているとした。
DPLのSam Hocevar氏もそれに同意し、特定の役職から外すことによってDebianプロジェクトへの大切なコントリビュータを失うリスクを冒すのはナンセンスだと述べた。
また、単に時間の余裕がないために貢献することができず、それによって問題が起ってしまっているという場合、そのような開発者は他の人々によるフレーム・ウォーに巻き込まれるよりも、静かにプロジェクトを去り代わりの人を見つけた方が良いのではないかという提案もあった。なおその提案者はDebianが試しにその開発者は「バスに轢かれた」と言ってみれば、その開発者がいなくてもプロジェクトが続行可能かどうかを判断できるのではないかという案も出した。
| SPI初の会合 |
|---|
|
DebConf 7の開催期間中、Debianを含む複数の米国のプロジェクトの法的な保護組織であるSoftware in the Public Interestが理事会を開いた。これは、理事が4ヵ国に散在している同組織にとっては初の、直接集まる形での理事会だった。 |
Hocevar氏は、直接会う形でのミーティングは有益であることが多いことを指摘し、何かを解決するためにDebian開発者たちが集まる必要がある場合には、同氏に連絡することを推奨した。開発者たちが集まる必要があるなら、Debianプロジェクトは資金的に支援することができるとのことだ。
再びガバナンスの話題に戻ると、DebConf 7では「Leading a Free Software project（フリーソフトウェア・プロジェクトの統率）」というテーマのディスカッション・セッションもAndreas Tille氏による司会で行なわれた。Tille氏は、何を/誰を/どのように統率するのかという3つの基本的な問いに答えようとした。
Tille氏は、フリーソフトウェアに取り組む動機の根底にあるものは何かと問いかけた。そして、その問いの答えとして、何か自分自身のために実現したいことがあるからだと指摘した。つまり、何かを実現するための既製のソリューションがないから、自らコーディングをする。フリーソフトウェアとしてコードをリリースすれば、同じような目的を持った仲間を得ることができるので、仕事を分割してコードの向上に取り組むということが始まる。Tille氏によると、フリーソフトウェアをリリースするということは賢明な方法であり、友人を得る方法であるとのことだ。
Tille氏は自身のフリーソフトウェアのリーダーシップの例として、バイオ・医療コミュニティ用のDebianベースのディストリビューションであるDebian-Medディストリビューションを挙げた。Tille氏によると同氏がDebian-Medプロジェクトのリーダーになったのは、プロジェクト設立のアナウンスを発行したためだという。同氏は、プロジェクトリーダーになりたくない人は、プロジェクトのアナウンスを発行するという仕事を引き受けないようにとアドバイスした。
Tille氏によると、ウェブページやメーリングリストといったプロジェクトのインフラに関する仕事を引き受けるのは、デフォルトでプロジェクトリーダーになる道を歩んでいるということだと警告した。すでにいくらか仕事をやっているからリーダーになれと言われてしまうのだそうだ。プロジェクトを前に進めるために当然必要があると思われる作業をしようとしていると、リーダーシップのある立場にさせられてしまう可能性が高い。Tille氏はこのような類いのリーダーシップを「Do主義体制」と呼んだ。すなわち実際に作業をする人がリーダーとしてプロジェクトを統率することになるということだ。
「誰を統率するのか」という問いに対してTille氏は、フリーソフトウェア開発者、すなわち個人主義者たちだと答えた。フリーソフトウェア開発者は、通常のコンピュータユーザとはまったく異なる振る舞いをするという。フリーソフトウェア開発者は、プロジェクトに没頭することをいとわず、またその一方で自分以外の人によって提示されたことを必ずしも受け入れるとは限らない。Tille氏は、開発者はリーダーシップを受け入れることを拒否することも多々あると警告した。なおそのことは彼らが着ているTシャツを見れば一目瞭然なのだそうだ。とは言え彼らは、自分が尊敬し通常はその見解に同意することのできる人のリーダーシップは受け入れるという。技術的なバックグラウンドのない人がフリーソフトウェアのリーダーとして受け入れられることがないのはそのためだとTille氏は指摘した。
リーダーシップの発揮ということに関してTille氏は、開発者に何かをするよう強制する方法は存在しないとした。そのようなことをすれば開発者は単に去ってしまうのだという。自分の実現したいことに取り組むということ以外にプロジェクトに参加する動機はない。そのためやりたくないことをやるように強制されたなら、人々はプロジェクトを去ってしまうだけであり、雇用主と従業員の関係とはまったく違う関係だとのことだ。
またTille氏は、下手なリーダーシップが原因で、プロジェクトがフォークする（通常は取るべき行動として良いものではない）というリスクもあるとした。一般的にフォークの原因となるのは開発者とプロジェクトのリーダーとの間にある意見の相違だと指摘した。
Tille氏の講演は延長されて、プロジェクトの開発者をリーダーはどのように統率すべきか（あるいはすべきでないか）についての議論が行なわれた。Tille氏は「リーダーになるためには利口でなければならない」とうまく要約した。
プロジェクトが健全に機能するためには、プロジェクトの使命の宣言、定期的な報告、必要に応じて直接会ったり電話したりする良好なコミュニケーションが重要だということで参加者は意見が一致した。
Tille氏はまた、リーダーは、みんなに対して気持ちの良い態度でいるようにと助言した。リーダーという立場にいる人は他の人々に対して厳しくなりがちであることもあるが、「正の強化」は実際に有効であるので、誰かの仕事が優れているなら「優れている」と言葉に出すようにすべきだとのことだ。また十分に考えずに即座に何かを却下することはやめ、従うべき手本と自らがなるように努めるべきだと述べた。Tille氏は、つまるところプロジェクトリーダーになるということは、強いリーダーシップを発揮するということではなく、プロジェクトをリードするという役割を果たすということであると述べた。