関連トピックスと質問

このセクションではこれまで論じた原則に関連する話題と質問を採り上げるつもりだ．

なぜ投票を行わないのか？
「Producing Open Source Software」ではプロジェクトのメンバーにコンセンサスが得られないときにのみ Karl Fogel は投票を奨めている． これは実際の生活の場に根ざした良識ある妥当で首尾一貫したやり方だと思う．ではなぜ私がこれまで述べてきたごじゃごじゃ面倒な手続きを取らずに投票で決定を強引に通すということをやらないのか？

• 投票を行うには先ず投票者を選定しなくてはならない．当面の問題に関して投票権のある人々を部署によって決めなくてはならないのだ．説明責任のあるグループとそうでないグループに分ける、そしてそのグループのメンバーが大雑把に言って同質であるなら直ぐ投票に持っていっても良いであろう．その典型的な例は中心的な貢献者たちに見られるであろう．彼らは大体同じように幾つかのプロジェクトを経験し中心的貢献者として認められている．

  しかしながら多くの場合その境界はどこで引けばよいか明快ではない．例えばある特定の決定について中心的貢献者だけではなく、一般の貢献者にもまったく貢献していないエンドユーザーにも説明する責任があると仮定してみよう．一般の貢献者やエンドユーザーには投票権があるのだろうか？そうだとしても彼らの１票は中心の貢献者と同じ重さでよいのだろうか？この答えは必ずしもはっきりしているわけではない．論争解決の簡単な手段が却って問題になってしまう．

• 第２には投票を行うということには投票の結果を尊重するという前提がである．その為には投票を監視し投票結果を確実なものにするには公式な正当性を備えた統治機構の中で公式な正当性を備えた指導者達を前提にしなくてはならない．このことは多くのオープンな共同プロジェクトにおいて真実である．しかし全てが全てというわけではない．

例えば Apache project は大体似たようなバックグラウンドと専門性を備えたボランティアによって設立され彼らは比較的公式の 統治機構 を発展させ公式の 投票システム を備え、非営利の Apache Foundation の許で活動している．

一方、 Mozilla プロジェクトは企業スポンサーのオープンソースプロジェクトとして始まった．公式の統治機構は備えていず、主要な参加者（最も著名な人物としては Mitchell Baker、また私自身もそこに含まれるが）はオープンソースプロジェクトの中心であるテクニカルエリート集団の一部ではないが、テクニカルエリートのみならず、むしろ幅広く様々なバックグラウンドと知識を持った一般の貢献者やエンドユーザーに対して説明責任を有すると認識している．このような環境で論争の解決手段として投票をおこなうことは Apache project でのようにストレートに上手く効果的に機能するとは思えない．

問題を投票に賦すことが良い結果を生むと言うことはあり得る．しかし上で議論したようにその投票が正当性を持ち拘束力を持つには様々な点を考慮しないとならない．

反対意見の役割
ここまで私はオープンで共同のプロジェクトにおいて反対者が存在する中でリーダーが如何に決定を行いそれを正当化するかという観点から書いてきた．しかし私は異なったものの見方、特にリーダーの決定に賛同しない活発に反対キャンペーンを展開するような反対意見というものも有益だと考えている．

セキュリティー情報に関して私のやったことを書いたが、反対意見（プロジェクトの内外を問わずに）をセキュリティーホールやその他の複雑なシステムの問題の発見してそれへの攻撃を行おうとしている人々と比較することは実り多いということが分かった．どちらもシステムを壊すという点で共通している．両方とも基本的に個人の（「反骨精神」による）挑戦である．両方の建設的な行為と悪意ある行為の境界は曖昧である．

偶々反対意見に遭遇したとして最も有効な対処の仕方は何であろうか？一つは出来る限りたくさんの反対意見を集めてその一つ一つに反論をしていくことだ．この極端な Fuzz testing （訳者注：ソフトウェアーのテスト））例は政府の公聴会で見ることが出来る．しかしソフトウェアー相手ではなくもっともろい人間相手であってランダムな反対意見には絶えられる者ではなく答えはないよとばかりに肩をすくめるしかなくなるだろう．

反対意見の側の一番強い攻撃は間違いなくシステムそのもの（即ちプロジェクトのリーダーシップとその決定）に対するもので最も被害が大きい．私に言わせればこういう被害はリーダーが上に書いた「説明責任」、「透明性」、「相互関係」の原則を知らないか反対だからだと思う．その為反対意見の側が公開されていないが反対の考えを持っている人たちの中から支持者を募ることが出来てしまうのだ．

話をプロジェクトリーダーに戻そう．反対意見が近くにあると苛立たしいが長い時間で見るとプロジェクトを健全に保つための批評的役割を持っているとと思う．脆弱性の対策を考えているときと同じに有効な反対意見によってリーダはどの点で決定のプロセスを改善すべきか分かったりする．「説明責任」、「透明性」、「相互関係」に照らして改善していけば反対意見も反対者の存在するコミュニティーの中で決定を下しその正当性を保証出来る良いリーダーの助けとなるのである．

Mena Trott がブログの 消費者のいうことに耳を傾ける で恐ろしい批評家も批評されている人が熱心にその批評に耳を傾けるならその人の心を打つといっている．だからこそ反対意見に真剣に耳を傾けることが大切なのだ．セキュリティーバグの発見や報告と同じに外部からより内部からの批判の方が生産的である．彼らはプロジェクトの中の盲目のチアリーダーなんかではなくそうであって欲しくないしまたその必要もない．

結論と参考文献

以上私はオープンで共同のプロジェクトにおいて如何に反対者に対処するか、人気のないかも知れない決定を如何に効果的に下せるかについて私見を述べてきた．ここまで読んでくれたのだったらこの文章が似たようなプロジェクトのリーダーやその参加者あるいは単ある観察者のあなたに少なくとも興味を引く有益なものであってくれたらと願っている．

始に短く断ったがここに書いたのは他で見つけた色々な考えを適用したものである．特に Amy Gutmann と Dennis Thompson の共著の Democracy and Disagreement という本からである．この本はアメリカの政治という文脈で書かれている．だが他の文脈でも適応可能であると示唆してあって私は Mozilla や他のオープンで共同のプロジェクトに当てはめられると考えた．

実際私は彼らのアプローチは伝統的な政治（あるいは他のどんな形態の組織）以上にオープンで共同のプロジェクトに適用出来ると思って論を進めてきた．オープンで共同のプロジェクトが真に成功するためには出来るだけ広く広がるように人々を惹き付けなくてはならない．プロジェクトは大きな部分を一般の貢献者に頼っているからである．それはバグやその他の欠陥の発見や修正、製品の仕様の変更、製品の採用促進等々においてでである．

そういうプロジェクトは強圧的力や企業のように金銭的動機で団結を計ったり人気がないかも知れない決定を受け入れさせたり出来るわけがない．オープンで共同のプロジェクトへの参加者は価値観を共有している（宗教団体や似たようなボランティア組織）よりも似たような技術的興味と能力を備えているのかも知れない．

従って意味ある仕事をするのに（役に立つ高品質の大きな市場を持つソフトウェアの開発と促進のように）適正な規模を確保するためにオープンで共同のプロジェクトは重要な問題と直面しそれを克服していかなくてはならない．それは価値ある貢献者をプロジェクトの外に放り出したり（これから加わるかも知れない将来の価値ある貢献者を失望させたり）するやり方ではなくプロジェクトを色々な価値観を持った人々が居心地よく一緒に仕事が出来物事に好奇心を持ち驚きを感じるような環境にしていくことで無ければならない．Gutmann/Thompson は本の中で他にはないようなアプローチでこの問題を扱っていると私は思う．

対称的に伝統的な政治組織では取るに足らない少数者が多数（例え小さな数であろうと）に取って換わるということがよくある．それは必ずしも強圧的な力によるとは限らない．少数者が家族であってそうなる等である．しかしそのような国や政治組織で支配者を取り除いて多数の原則を貫くの難しい．そういうところのリーダーは Gutmann/Thompson の勧めを採用する必要も動機もないであろう．

以上で充分であろう．今後興味があるのなら Gutmann/Thompson の内容を自由に発展させて貰いたい．政治哲学を勉強していないとかなり難しい本ではあるが１章から３章の重要なところをざっと読むだけでも良い．またこうしたことに本当に興味があるなら Gutmann/Thompson の考えについてのエッセーを集めて編集した Deliberative Politics: Essays on Democracy and Disagreement という本を読むのも良いであろう．

意見の相違を前にしての意思の決定

どうやってこれを行うのだろうか？以下で論じる３つの原則に従って行うことが重要だと思う．

説明責任
第一の原則は説明責任である．誰が、誰に対して、何故、何について？自称の意思決定者や意見の相違を解決しようとする者は自分の行う決定に関して説明責任があって、それを広くネットにそ投げかけるということだ．「広くネットにそれを投げかける」ということは例を示すと、CA certificate metapolicy の３．を見て貰うと、私は説明責任について真剣に考えたつもりだが、我々が誰に対してまた何故説明責任を持ち Mozilla や CA のユーザーを越えた人々や組織に対しての説明責任を熟慮したつもりだ．

何故そうするかというと一つにはその特定の決定が誰を対象にしているかがはっきりし、またその過程で異議の影響力や異議のある者達の同盟の動きを最小限にとどめることが出来るからである．それに自分の行った決定をもっと広い文脈で眺めることが出来るしそこから決定に対して良い影響を受けることが出来る．特に特定の人物がその決定をどう受け止めたかを見てその人に対する評価を再検討してどうすればその人を説得出来るかの参考に出来る（下の第三の原則を見て貰いたい））．結局、決定の過程にどれだけ透明性が必要かの判断材料になる（下の第二の原則を見て貰いたい）．

透明性
第二の原則は透明性ということである．決定の過程をそれに誰が参加するか、誰がその過程を少なくとも観ているかの両方の意味でどれだけ透明であるかということだ．一般的に意思決定の過程は出来るだけ透明である方がよい．特に説明責任のある全ての対象に対して透明である必要がある．（その範囲は説明責任の範囲によって幾らでも広がり得る．）出来るだけ透明にすべきだと言うことは以下の幾つかの理由による．

• あなたの決定で影響を被る人たち（即ち説明責任の対象となる人々）が決定の場にいない状況を望むかも知れない．だがもしそういうことをすれば本格的な論争が始まり、不信と独裁の非難が渦巻くであろう．そういう人々を意思決定の課程に参加させることによってそうしたことは最小限に納めることが出来るのだ．（それにどうやってそういう反対者を特定出来るのだろうか．説明責任を果たすことをおいてない．）
• 透明性はこれから行おうとしていることの欠陥を早期に発見させてくれる．ソフトウェアーの開発でもバグは最初に見つけるより後から見つける方が高くつくのだ．
• より一層透明にするということはいわば「観客の前で演じる」機会を与えてくれる．言い換えると公開性はあなたのやり方が「サイレントマジョリティー」に影響を与えあなたへの賛同者を募ると言うことにもなる．つまり透明性と議論の公開性（下の第三の原則を見て貰いたい）という両方の機能を持つのである．サイレントマジョリティーを自分の側につけておくことはいよいよ決定を下すとき重要な役割を果たす．それでも少数の不満を持つものはいるであろう．しかしその不満の影響力も共鳴者を見いださなければ限られたものとなる．

相互関係
第三の原則は恐らく最も重要であろうが説明が一番難しい．それは相互関係である．それはあなたの決定を賛同しない者も場合によっては受け入れられるような形で正当化してみせる必要があるということである．他の言い方をすると「他人があなたにして貰いたいようにする」である．

これは正確に同じというわけではないが「己の欲せざるところ、他に施すことなかれ」の黄金律を思い起こさせる．これはまた Karl Fogel の「聖戦」に関する忠告にも似ている．

次のような例が一番分かりやすいかも知れない．脆弱性は修正されるまで、そして出来れば永久に公表しない方がよいと考えている人に、私が Mozilla のセキュリティーに関する方針を正当化するという場面を想像して貰いたい．私は Security through obscurity（脆弱性を隠すことでセキュリティーを確保する）は上手く働かないと考えている．ソフトウェアーベンダーにとってもセキュリティーのバグを隠すのはは良くないことであり、完全に公開することこそバグの修正を確実に出来るやり方だと考える．こういう考えは私の価値観では受け入れられるものであっても彼らの価値観ではない．

その代わりに次のように議論を進めるのがよいかも知れない．セキュリティーのバグは極秘扱いにしてもそれを尊重しないで世界中に情報をばらまいてしまう連中がいる．それだったら極秘扱いの方針もへったくれもない．また一方で多くのそれほど独善的にこだわらない人たちがいて（彼らは脆弱性の発見に寄与してくれるのだが）彼らなら少なくとも修正されるまで脆弱性の存在を黙っていることに協力してくれる．

だがもし彼らの公開しないという決定が自由にいかなる意味でも我々の押しつけ無しになされるなら彼らは前にも増して協力的になり、またそういう相互協力関係こそ将来に渡って続くものである．（例として Robert Cialdini の commitment and consistency を参考にして貰いたい．）以上からいって正しいやり方は脆弱性は極秘扱いにする、但し脆弱性のリポーターには明確に伝える．彼らが必要に応じて「うっかりばらす」のはありとする、といったところだろう．

こういった論の進め方は論争相手の価値を尊重することでありそれを無視したり（更に悪いことに）侮辱したりすることの対極にある．そしてこうであれば今後我々の決定がどんなであれ受け入れてくれる可能性は増してくる．例え渋々であっても受け入れるようになってくれる．

これが相互関係という原則が良いと思う第一の理由であるが理由はこれだけではない．

• 例えば、相互関係の原則にかなうような行動はもっと上で挙げた「観客の前で演じる」ということにも通じるのである．決定を公正でオープンに行うように努めるだけではなく他者の意見と価値に敬意を払っているのである．こうして決定に不満を抱いて我々を無慈悲な独裁者と糾弾してくるようなことは一層減少していくはずだ．
• 結局我々が他者の価値を真摯に理解してそこから何かを汲み上げるように話を進めていくなら場合によっては当初の人間だけで決めたものより良いものが出てくる可能性がある．Mozilla のセキュリティーバグに関する方針もこの例である．Asa Dotzler と（または） Mitch Stoltz （この人物のことはよく覚えていない）がバグのレポーターに公開のボタンを押して貰うという賢い考えを思いついたのだ．これはバグの公開に関して両方の考え方を満足させるものである．

  （セキュリティーバグの完全な公開を主張する人は相互関係の原則と照らしてどう正当化していくか残された課題だが読者に考えて貰いたい．ヒントとして私のブログ “Full disclosure: for and against” を見ると良いかも知れない．）（筆者注：短ければこれも訳そうかと思いましたがこれまた長い長い）

当面の問題

目的は決定を行うこと、「stick（我慢する？）」になるような不承不承でも最終的には受け入れられ後々ぐちゃぐちゃな論争の場と化してしまわないような決定を行うことである．

目的が何かを成し遂げることだと仮定してみよう．失敗の可能性も含めて様々なやり方があるとする．一つの可能性は、ある決定が「paralysis by analysis（情報過多による分析不可能）」という言葉で表現される終わりのない話し合いの場にに嵌り込んでしまうことだ．この話し合いが例え礼儀正しく行われたとしても何も決まらない状態に陥ってしまう．ソフトウェアーの言葉で言えば無限ループに陥ってしまうのだ．

こういった議論の果てに本当に内部抗争になってしまうこともある．注意していないとプロジェクトの団結にとって脅威になるし将来的にはプロジェクトの発展の妨げとなる．誰かがやめていったりある人の参加を拒んだり最終的にプロジェクト自体がクラッシュして燃え上がってしまう．

結局プロジェクト内部の論争が外部のプロジェクトをも巻き込んでしまうことがある．例えば競争相手と目されるプロジェクトが論争に入り込んでくる．そうなると内部の団結は問題でなくなる．一般に社会的組織は外部からの攻撃を受けると自動的に内部の団結は強くなるからだ（これを circle the wagons シンドロームという）．しかし反射的な防御行動が積極的に潜在能力を発揮するのではなくむしろ閉鎖的で悪くするとメンバーをプロジェクトの攻撃へと向かわせてこれこそ最後に待っている決定的な損失である．

従ってオープンで共同のプロジェクトのリーダーに課されるものは

• プロジェクトの議論の無限ループに陥らないようにし、決定を下せる状態を作る
• 現在あるいは未来の仕事に損害をもたらすかも知れない内部抗争からプロジェクトを守る
• 外部の世界に対してプロジェクトを代表して、プロジェクトの目的と価値を正当化しその一方で内部と外部の相互影響から未来を生産的で最大限に可能性のあるものだということを示す

私はあるべき姿のあるいは将来あるべき姿のリーダであれば自然とプロジェクト内での威信は備わり上に掲げた目的も上手く成し遂げられると信じている．

価値の重要さ

私の考えだと共同プロジェクトに於けるまともな論争はたいていの場合価値観を巡って行われる．ある場合は「正しい correct」か「間違っている incorrect」で、別の場合は「善 good」か「悪 evil」かで、その中間に「正義 right」か「不正義 wrong」かある．

少なくとも英語の right と wrong には２重の意味があってそのどちらかに傾いているのである．そしてかなり厳しい論争だと争点がこれらの意味のどちらに傾いているかについても一致することが出来ない．

例えば、Richard Stallman のエッセイ “free software” vs. “open source” ではソフトウェアーのライセンスについての決定ををモラルの問題と見ている．一方でプラグマティックに考える見方もあるわけでこちらの方は「right」を「有効な」、ないしは「適切な」という意味で使っている．同様に標準の純粋主義者だったら単なる技術的ミスによる内容の不適正をそれ以上の道義的問題としてみるかも知れない．

もし大部分の意見の相違が価値観の相違に基づくとしたらどんな解決策があるのだろうか．第１は、往々にして論理一本槍でまくし立てたりしてしまうが少なくとも私に言わせれば論理だけでは意見の相違を克服するには不十分だということである．論理的議論では公理が鍵となる．しかし数学の王国を越えると（恐らく数学においてもそうなのだろうと思うが）公理には様々な価値という機能が含まれるのだ．

第２は、多くのあるいは大多数の意見の相違には誰もが満足する唯一の真実の答えなど当然存在しないということだ．そこで我々がすべきはより小さな目標を設定することだ． stick (取り敢えずのちょっとの我慢？)となるようなやり方で意見の相違をはっきりと解決させるのだ．不満を持つ人々がその不満を持続させない様にしてやるのだ．そして皆が一緒に新しいことをやっていけるようにする．その結果古いのではなくまた新たな意見の相違が生じて来るというわけだ．

マイクロソフトは資金についても人材についても充分に備えているし、多くの人が何故それが重要かを思い出させているのだから CSS2 を完全にサポート出来ないはずはない．それなのに何故やらないのであろうか．私の考えだと根本的理由は CSS2 の完全なサポートが独占者にとって利益にならないからだ．充分にサポートすると Web のバリアーが低くなる．それは独占者には脅威になる．

この観点から見ると CSS2 を中途半端な実装でおいておく意味がはっきりしてくる．あなたはサポートしていると主張することが出来る（多くのジャーナリストはあなたの主張を信じるだろう）．あるいはまた標準の機能をを実装していない（更に悪いことにバグだらけの実装をした）ものは誰も使わないと主張することも出来る．事態を変えるにはマイクロソフトに半標準のブラウザがどれほど始末に負えないかを思い起こさせ、標準サポートのブラウザを使うようにすることだ．

もう一つの理由は IE を素晴らしいものに作りすぎるとそれ自体が Windows の競争相手になってしまうからだ．モーダンブラウザはプラットフォームになりうるアプリケーションなのだ．HTML、JavaScript、CSS、DOM の組み合わせは開発者に Windows や Linux や Mac に変わって Web を目指すプラットフォームと受け取られているのだ．

この記事は Mozilla project でボランティアとして（今は Mozilla Fundation の常任理事（executive director）として）プロジェクトの方針作成という個人的経験から出てきたものである．その仕事は起こりえる問題についての対処としても、問題がどう対処されるかについて意見を異にする人々にも受け入れられものという意味でも妥当なものではないかと思う．その過程で私は方針にどうしても賛同出来ない人が存在するという環境で私自身の問題への対処方法を発展させてきた．

オープンソースプロジェクトにおけるリーダーシップの考察としては Karl Fogel の Producing Open Source Software という分厚い本と比べたら私の論考など色褪せてしまう．とはいうもののプロジェクトのリーダーシップにだけ的を絞った点は幾分利があるかも知れない．それに短いし．（以前、Karl Fogelとは仕事をした仲だが未だ彼の本を全部読んでいないことは許して欲しい．）本稿でオープンソースプロジェクトにおけるリーダーシップの問題を更に一般的な流動性のあるメンバーやグループからなり、そのメンバーやグループが異なった考えを持っており圧政の存在しない比較的弱い非公的な管理構造を持つ組織のリーダシップとして考えてみたい．

ここで述べられている考えは決して私のオリジナルなものではなく他の人々の考えを取り入れたものである．参考にしたものは最後のセクションに書く．

何故私はこれを書いたか

上記の通りこの数年私は Mozilla プロジェクトで仕事をしている（それ以前はもっとフォーマルな環境で仕事をしていた．）．私は開発者として参加したというよりオープンソースの開発における方針づくりやビジネスの面に興味を持ってのことだった．特にプロジェクトが決定や方針に明らかに根強く反対する者が存在する場所で如何に決定が行われ方針が決まるかに興味を抱いた．

私は経験の結果プロジェクトが成功裏にこれを成し遂げるにはどうしたら良いかの明確な考えが浮かんできた．Mitchell Baker （Mozilla Corporation の CEO であり長年の Mozilla プロジェクトのリーダー）の the community and decision-making への答えという形で Ian Grigg のコメント you can’t tell someone how to be a good leader はリーダーの役割は本質的に、「コミュニティー」が最終的に出した決定を確定し実行することにあると書いている．

私は Ian の意見を尊重するがこの場合２つの面で間違っていると思う．私が同じコメントで指摘したように マーケットが価格に収束する様にはコミュニティーは一つの決定には収束しない と思っている．リーダーはそうした収束を促す以上のことが要求される．コミュニティーがよりよい決定を導き出すようにリーダー、少なくともオープンソースプロジェクトに於けるリーダーには指針となる何らかの原則が必要である．

私のコメントはプロジェクトで relicensing the Mozilla source code や Mozilla セキュリティー・バグに関する指針 や Mozilla CA 認証 などなどに携わった経験に基づいたものだ．最初に断って置くが下で論じるような対処方法は時間と努力を必要とするものである．だがそうした過程を経た決定は殆ど持続出来不平の種を残さずひっくり返そうとする試みの芽にもならない．私の考えでは時間を掛ければ恐らく効果を発揮するとというだ．

物事が間違って進行してしまう場合（最近の フィード・アイコンの議論のように）、何かの理由で私自身が自分の原則に従わないときだ．これを書く理由はだから一つには私自身が自分の立てた原則を思い起こすようにと他の人も私がそれを忘れているようだと思ったら急いで思い出させて貰いたいからである．

問題空間を明瞭にする

先に行く前に我々が解決しようとしているこの特定の問題の領域を明確にしたい．上手く説明するには本稿のタイトル「handling disagreements in open collaborative projects（オープンで意見の相違のある共同のプロジェクトの取り扱い）」を掲げてそれを徹底的に脱構築していくことではないだろうか．

• 「共同のプロジェクト」といったときそれは何か具体的なものを作成するために自由に一緒に仕事をする多数の人間を含んだプロジェクトのことを言う．伝統的な宗教団体や社会団体のように共通のゴールを目指すというより共通の価値として表現されたものの回りに集まる必ずしも自由に選択されたものではない団体は含めない．
• 「オープン」というときそれは潜在的に誰にでも開かれ新しい人々の参加が可能で生産的であるそういう構造を備えた共同のプロジェクトを指す．例を挙げるなら、オープンソースやフリーソフトウェアーの開発プロジェクト、必ずしも FOSS ライセンス が無くとも公的なソフトウェアー開発プロジェクト、Wikipedia の様に Commons-based peer production を通して別のタイプの製品を目指すプロジェクトなどである．
• 「意見の相違（disagreements）」はプロジェクトがらみの抗争でプロジェクト参加者同士の場合と参加者と外部のものとの間で持ち上がることもある．
• 「対処する（handling）」は意見の相違を氷解（resolve）させるという意味ではなく文字通り handling （操縦する）という意味で言っている．

Mitchell Baker は最近オープンソースプロジェクトの管理（governance）に関して幾つかの面白い記事を掲載した．記事は沢山あるがなかでも the "community" and decision-making と leadership vs. coordination を読んで彼女の考え方を知って貰いたい．Chris Messina が彼女に続いて自分の考えを the future of open leadership で展開している．その中で次の文、

が私の琴線に触れ私は急いでファイルの中から以前の私の考えを述べた handling disagreements in open collaborative projects を引っ張り出してきて公開することにした．

ビル・ゲイツの引退声明以降のマイクロソフト内での事態の進行は極めて速い．何の予告もなく６月２１日に Martin Taylor が去っていったのだ．

この最初の変化の意味するところは進行の速さからいっても極めて重要だということが分かる．Martin Taylor は１３年のキャリアを持つ Senior VP で Steve Ballmer べったりの人物である．彼は残念なことに「Get the Facts」という反オープンソースのキャンペーンの責任者としてでインターネットで名を馳せた人物だ．

インターネット上で Linux その他の無料ソフトのドキュメントでメインフレーム上の Linux が Windows より１０倍も高くつくといったようなマイクロソフトの宣伝を読んだことのある人は多いであろう．どれだけの人がこの高くつくというキャンペーンの影響を受けたか知りたいものだが．

時間を追っての Martin Taylor 退社の推移

• ７月１５日：ビル・ゲイツがチーフ・ソフトウェアー・アーキテクトの地位を Ray Ozzie に譲る
• ７月２０日（火）： Martin Taylor は Windows Live と MSN のヴァイス・プレジデントとしての地位にある
• ７月２０日（火）：マイクロソフトはプレス発表で フランスでは有名な MSN メッセンジャーを新しいWindows Live メッセンジャーに入れ替える旨を Martin Taylor の言葉として伝える．
• ７月２１日（水）： Martin Taylor の辞任

簡単にいってしまえばこういうことだ：
Ray Ozzie が マイクロソフトの「Live」の責任者になったということだ．数日間は Martin Taylor がその任に当たっていたが彼には２つの欠陥があった．

• Steve Ballmer の「家来」であるという点
• オープンソースの開発者から完全に信用を失っているという点．

Martin Taylor を緊急に排除することで Ray Ozzie は以下のメッセージを発したに等しい．

• 私がマイクロソフトの「現代派」のボスだ．
• 自分の回りに「守旧派」の文化に染まった Steve Ballmer の手下がいることを好まない．
• オープンソースの全てのコミュニティーとの間に事態の沈静化、平和を望む．マイクロソフトは全ての過酷な戦闘を停止して協力関係に入りたい．

ボス達の抗争は始まったばかりだ！
Martin Taylor は最後の犠牲者ではない．

この戦闘図を見ると 2004年１１月９日こそがオープンソースの D-Day だと云うことが明らかだ．Steve Balmer がワシントン州 Redmond （マイクロソフト本社の所在地）の掩蔽壕に身を隠さない限り我々は戦いを止めはしない．

前回私は Mozilla Fundation の活動の分野として重要な３つを特定した．即ち、プロジェクトの管理、オープンソースと Mozilla のソフトウェアーの開発促進、オープンでアクセスフリーなプラットフォームとしてのインターネットの開発である．今回はこの広い分野を Fundation の特定の活動と結びつけてみようと思う．また全てなすべき活動ではあるが優先順位が必要である．今まで活動のランク付けはしたことがなかった．

A．Mozilla Fundation は便利なオープンソースのインターネットソフトウェアーを人々の手に届けなくてはならない．Mozilla Fundation は Mozilla Corporation の技術と製品開発に関する一部をこれまで代表してきた．Fundation は Mozilla Corporation の次の意味で活動をよく監視する必要がある．

• Mozilla プロジェクトへの参加とプロジェクトの健全なダイナミズムの促進．
• エンドユーザーへの製品の配布
• 製品及び／あるいは技術の配布で（a）インターネットへのオープンでフリーなアクセスを可能にすること、（b）他のものがソフトウェアーを作ったり我々の仕事を更に拡張していけるようにすること．

B．以上に加えて Fundation が直接担うべき活動がある．

• Mozilla プロジェクトのソフトウェアーの開発方法の実行について方針を与えそれをモニターすること．
• 雇用関係にない主要な貢献者を組織化していく仕組みを作りだしていくこと．
• Mozilla プロジェクトを全体として健全で活気あるものにするための仕組みを作りだしていくこと．
• オープンソースの取り分け Mozilla 製品の採用の支援活動に参加していくこと．
• オープンソース一般に重要な次の活動に従事すること．（a）特許関係の事柄（b）オープンソースの危険や恐れに関しての議論（c）政府機関のオープンソースソフトウェアー採用の促進．
• フリーでオープンなインターネットへのアクセスの障害を特定し取り除くべく説明や運動を行う．
• インターネット上の技術の発展、開発に関しての消費者の声、希望を汲み上げること．
• 市民や消費者や政府に向かって何故インターネットがオープンでアクセスフリーであることが重要か、 Mozilla Fundation がこの目的のためにどのような活動をしているか、またそれを支援するために何が出来るかの説明．
• オープンな協力による配布モデルが他でもどうすれば適用するか、適用するのかどうかの議論に加わること．

とても多岐に渡る．私はこの全てで Mozilla Fundation がイニシアティブを取って進めていくといっているわけではない．ただ Fundation がどこを向いて進むべきか少しばかり明確にしておきたかっただけだ．そしてまもなくそれは始められる．

Mozilla Fundation はどのような活動をなすべきか？この問題を考えると先ず次のような３つの活動が頭に浮かぶ．それ以外にもあることは承知だがこの３つが最も本質的なものに思える．３つを先ず挙げてそれぞれについて下の方で説明する．

• プロジェクトの管理とコミュニティーのダイナミックの維持．---コミュニティーを健全に保つ為に．
• オープンソースのソフトウェアーと Mozilla の製品のプロモーション
• あらゆるプラットフォームでの技術革新、アクセスビリティーの向上としてインターネットの発展の促進

A．第一は Mozilla Fundation が Mozilla プロジェクトのホームである役割．Mozilla プロジェクトは Fundation の設立より遙か以前から存在していた．プロジェクトが立ち上がったのは1998年でそれ以来コミュニティーと自己管理、執行モデル、サブプロジェクト、たくさんのソフトウェアー、専門性、適切な実行といったものを発展させてきた．これらが法的基盤のない非公式な方法でコミュニティーと参加者によって運営されてきた．プロジェクトの管理に関しては長い間法的根拠を求めてきたが2003年７月の Mozilla Fundation の設立で実現した．Fundation はそれまでの高いレベルの組織運営を引き継ぐことが出来た．キーとなるべきリーダーはその役割を継続し、キーとなるプロセスもそのまま変わりなく引き継がれた．取り分け開発者が互いに影響しあってソフトウェアーを創り上げるプロセスが引き継がれたのだ．Mozilla Fundation はごく自然に Mozilla プロジェクトの待望の公的ホームとなりおおせた．しかしプロジェクトのホームとしての役割から明らかに何かが少しばかり抜け落ちている．

重要なのは Mozilla プロジェクトのアイデンティティーが委譲された権限の配布モデルを持つオープンソースのソフトウェアーを如何に創り出すかという点と結びついていることにある．従って Mozila Fundation のなすべき重要な役割も如何にソフトウェアーを創り出すかに向けてプロジェクトをダイナミックに健全に維持するということでもある．歴史的にその役割は Mozilla.org が担ってきたが今こそ Mozilla Foundation がコミュニティーベースでその役割を担うときである．

B．第二は Mozilla Fundation は公益法人であるので、その法人設立の条文通りの法的存在意義を持っているということだ．法人として（この場合 Mozilla Fundation のことだが ）の特別な目的、は従って、オープンソースの Mozilla Web ブラウザの採用と開発、インターネットアプリケーションの開発の促進なのである．

B．第三には Mozilla Fundation の免税要件は IRS とカリフォルニア州の認可する免税に関しての目的によって拘束されている点だ．この IRS の免税条件は次のように謳っている．Fundation の免税目的は以下の行動の執行が条件である．（１）インターネットを誰でもどこからでもどのようなコンピュータからでもアクセス出来る普遍的なプラットフォームとして維持すること．（２）インターネット（既に五億の人々の生活に影響を与えている）を技術革新していくこと．特に Fundation の免税目的は、（a）オープンソースで標準遵守でフリーの１千万人のユーザーが（課金も無料で）使用するインターネットアプリケーションを開発すること．（ｂ）Fundation の技術は内部の開発者、及びソフトウェアー開発者が使用出来標準遵守のオンラインコンテンツ、インターネットソフトウェアーを開発していけるものとする．

次回はもう少し特別な活動について書くつもりだ．

Firefox、Opera、Safari、名前ぐらいは聞いたことがあろう．どれか試してみようと思ったことがあるかも知れない．あるいはもう乗り換えているのかも知れない．どれをかは問題ではない．兎に角使ってみることだ．

．．．

主な理由は 革新とセキュリティーだ．

1990年代の末 Netscape と IE の激しい抗争の末 Web は１つのブラウザのものとなってしまった．IE が一番シェアーが高かったときそれは９５％にも上った．

こうなった原因は色々考えられるが最も支配的 OS が無料で IE を載せていたこと、Web マスターは IE だけの機能 ActiveX に頼りきり他のブラウザは考慮に入れなかったこと、更に時が経つとページのエラーチェックを IE だけですましてしまったことなどが挙げられる．

一つのブラウザ、一つの Web、．．．一つの標的

これは受け入れられることなのだろうか：一つのビジョンが Web を導いていくなんてことが．IE が一度支配を確立してしまうとマイクロソフトは殆ど IE のアップデートを行わなくなってしまった．Windows XP のサービスパック２ がセキュリティの改善を行うまで後にも先にも2001年から2004年にかけて技術の革新は殆ど行われなかった．色々な言語、取り分け Web のコアーである HTML、CSS が４年近くもの間バグだらけで放置された．

全ての人間が IE を使いたかったわけではない．頑固な Netscape ファンはそのブラウザを手放さなかったり Mozilla に移っていった．Linux や Unix ベースの OS のユーザーは IE を選ぶことさえ出来なかった．Mac ユーザーは IE を使うことが出来たが Mac 版の IE はWindows 版とは別の変な動きを示し、テストにしか誰も使わなかった．

２つのことが起きた．

その一つは小さなブラウザが革新を始めたのだ．ノルウェーの小さな Opera という会社が重量級のブラウザ戦争の最中ブラウザのあり方を見直していた．ずっと後になって Netscape や IE が無料になっても Opera はシェアーウェアーで有料だった（現在は Opera も無料）．古い Netscape の副産物とも言える Mozilla は可能な限りたくさん、可能な限り正確に Web 標準を取り入れようとしてきた．NetCaptor という小さなプロジェクトが MDI を一体化させてタブブラウザを作り、Opera、Mozilla、Firefox、Safari 等に取り入れられ最後には IE 7 にも実装されることになった．

２番目にはインターネットがユーザーに優しいものいではなくなりヴィールス、トロイの木馬、スパイウェアーの跳梁する場となってしまったことだ．９０％以上の人がただ一つのプログラム（IE）を使いそれが OS と一体化されているために小さなセキュリティーホールが非常に多くのインターネットユーザーに被害を与えてしまう．代替ブラウザや他の OS は長いこと IE や Windows を越えるセキュリティーを追求してきた．2004年では Mac や Linux ユーザー、あるいは Windows でも代替ブラウザのユーザーは標的にさえならなかったので余計にセキュリティー対策を取る必要もなかった．

解決策

競争は技術の革新をもたらす．幾つかの製品が市場シェアーを賭けて争えば一方が他方より進もうとする連鎖が生じ、結果として全てのブラウザの勝利ということになる．

セキュリティーはもし一カ所だけ見ていれば良いなら対策は講じやすくなろう．しかし逆に攻撃する側から見るとこれまた容易になるのである．今現在は Web の９０％を占める IE が攻撃の標的になっているのである．だが考えてみて貰いたい．この９０％が Windows 上の IE、Firefox、Opera に更に PowerPC Macs、Intel Macs、Linux へ分散したらどうであろう．攻撃者は１０％を狙う方がよいと思うかあるいはこれらありとあらゆる組み合わせの全てを標的にしようとするだろうか．その一方で Web ページ制作者は共通の言語を使えばよく今日みたいな問題が無くなるのだ．

これから先はあなた方が自分で自分にあったブラウザを探すだけだ．

私は Web 開発者でシステム管理者だ．５歳の時からコンピュータに触れハイスクール以来インターネットを使っている．大学の時からサイトを作っている．

Windows と Linux で Firefox を主に使い、Opera は１５〜２０％そのそれぞれで使っている．Mac では Safari を９０％、Firefox を１０％位の割合で使っている．自分のサイトは出来るだけ標準に近い形で書き、graceful degradation（「優雅な退廃」ですが意味不明）のためにデザインをし考えられる全てのテストをしている．

マイクロソフトの TechEd conference の中の１セッションに「AJAX, ASP.Net and You: All About Microsoft Atlas」というのがあり、マイクロソフトの AJAX テクノロジー（Atlas と呼ばれている）が IE 以外のブラウザをサポートすることがどれだけ重要かという問題が問われた．

eWeek の記事によると、聴衆の大多数は IE と Firefox をサポートすべきだと言った．また多くが Safari と Mozilla 系のブラウザもサポートすべきだと言った．

しかし Opera もサポートすべきだと言ったのは本の少数だけがだった．

匿名希望のある開発者は「マイクロソフトはブラウザメーカーにもっと互換性を持つように圧力をかける必要がある．」Atlas について「これはその手段なのだ．Opera もそうせざるを得ないだろう．」と eWeek に語った．

別の開発者は「だが Opera をサポートする必要があるとするともう少し時間を割かなくてはならない．」と語った．

これは興味深い問題だ．Web 開発者は自分のサイトが全てのブラウザを（特に小さいブラウザを）サポートしているかどれだけ確認しなくてはならないのだろうか？

答えは Web 標準に従うということである．だが全てのブラウザが Web 標準に従っているわけではない．このことが言いたいだけ文句を言うのを妨げている．

Web 開発者は自分のサイトを IE と Firefox で確認して Opera は気にかけないのだろうか？

Opera ユーザーとしては当然「そうだ」と応えるであろう．だが結局の所 Web 開発者に自分のサイトが全てのブラウザで動くように少しの時間を割いて貰いたいとどう説得したらよいのだろうか？

Opera をサポートしないということは千５百万人のユーザーを閉め出すと言うことだ．

Opera はデスクトップブラウザとしては（今のところ）充分なシェアーを獲得していないが携帯電話やその他のデバイスではそうではない．全ての Opera ブラウザ（デスクトップ、携帯電話、Nintendo、その他のデバイス全部で）コアーの部分は同じものである．従ってデスクトップの Opera をサポートしないということはシェアーをリードしている他のデバイスの Opera もサポートしないと言うことになる．

Web は変化するものである．今のところデスクトップブラウザが web にアクセスする第一の手段であるが、携帯電話などのデバイスによるアクセスはどんどん人気を博し増えてきている．特に Opera Mini は通常 Web にアクセス出来ない携帯電話からのアクセスを可能にし誰もの手の届くところにある．

サイトの互換性の問題は確かに Opera では特にもうじきリリースされる Opera 9 では小さくなっているかも知れない．しかし未だに存在する問題である．

（以下省略）

守旧派と革新派の抗争

マイクロソフト内部には公式発表では一枚岩のようにいっているが明らかに対立する２つの派閥がある．

一方は守旧派でこのグループは９０年代の Windows と Offce での大成功を見てきた人たちである．彼らこそが毎月１０億ドルもの利益をマイクロソフトにもたらし続けているのだ．さらにこの５年以上に渡って新しい OS Windows Vista の開発に当たり、革新的な WinFS のような機能をそぎ落としながら辛い道を進んできたのだ．Steve Ballmer がそれらの成功をもたらした頭目なのだ．

革新派は Web サービス関係の「Live」に携わっている．彼らも「Windows live」とか「Office live」という名で歴史に名を残しているがこれは Steve Ballmer に押しつけられたものに違いない．
彼らは比較的小さいグループで柔軟性があり革新的である．毎月のように「ベータ」を関した製品を出している．Ray Ozzie は常に、共同のそして Web がらみの仕事に理解を示し最初に Lotus Notes ついで Groove Networks の仕事をやってきて、このグループを活性化させている人物である．

革新派にとって Wen 2.0 の世界ほど住み心地の良い場所はなく、競争相手の Google や Yahoo や eBay あるいは Amazon がずっと以前から始めて先を行っていることも分かっている．彼らは能力も熱情も持っていて恐ろしい速さでこの先行者達に追いつこうとしている．

ビル・ゲイツは今や調停する力を失ってしまっている．これから両派の抗争は激しくなり表面に出て来るであろう．
反革新とも言える Windows、Office という乳牛から今後どれだけ乳が搾れるかは不確かでこれからの５年はこの２つの対立する技術が大変な変化の中に生きていくことになる．

私の予測

来るべき数ヶ月に何が起こるであろうか．
予測は危険であるが敢えてそれをやってみることにする．

Ray Ozzie と Steve Ballmer の協力がこの先ずっと続くなんて想像出来ない．

そこで私の予想は、ビル・ゲイツが2008年の７月に最終的に去るよりも以前に Steve Ballmer はマイクロソフトを去っていく．というものである．

来年の終わりまで彼が残っているかどうかも分からない．

これは間違っているのではないかと思う．何故 Joga Companion が Mozilla の Homepage にあるのだろうか．Mozilla Corporation が作ったというのだろうか？

これが一番人気の拡張なのだろうか？私には疑わしい．この拡張の追加する機能は一番人々が求めていたものだからなのだろうか．これも疑わしい．追加された機能がブラウザに必要不可欠なものでもない．Yahoo Widgets と大して変わらないちょっとしたツールに過ぎないではないか．

Joga Companion extension だけ何で特別扱いで Firefox のホームページに置かれなければならないのだ．Mozilla.com で addons.mozilla.org にリストアップされるべきではないのか．Mozilla Corporation によって作られたからということなのだろうか．Firefox ユーザーにとって一番良いやり方なのだろうか？

Mozilla.com のトップページでは Thunderbired より上にあるっていうのはどうしたことか？

Windows 98 という OS がその生涯を終えるということはインターネット時代で始めての出来事である．確かにこの前に2001年に人気の OS Windows 95 が生涯を終えるということがあった．しかし５年前とと今ではインターネットはまったく別の場所であった．当時は今ほどワームやウィールスやトロイの木馬が跋扈していたわけではない．それに 98 へのアップグレードもずっと容易であった．98 で要求された機械の要件も 95 のと比べてさほど大きなものではなかったからだ．

従って、７月１１日以降何が起こるか誰も分からない．確実に言えることは日が経つに連れて脆弱性が新たに見つかってきて Win98、WinME ユーザーは防御策がないままますます危険な状態に置かれると云うことだ．

そこで Win98、WinME ユーザーはどうしたらよいのであろう．マイクロソフトの奨励ははっきりしている．その点私も賛成である．２１世紀にあった OS に取り替えるということである．マイクロソフトは Windows XP への乗り換えを勧めている．私は新しくリリースされた Ubuntu Linux 6.06 をお勧めしたい．インストールが簡単だし使いやすく安全だしたくさんの良いソフトウェアーがついてくる．

それでも Win 98 を使い続けるというのなら少なくともファイアーウォールをインストールし、Firefox を使うことだ．だが後になって私が警告をしなかったなんていわないで欲しい．

著者多忙につき当 blog の更新を停止させていただきます。開設以来ほとんど記事を投稿できませんでしたが、ご購読ありがとうございました。

Signature Editor は、エディタ機能が Thunderbird 2.0 に採用されたら、ルーラーと日付形式設定のみ残して実質的に開発終了するつもりです。いずれにせよ、バージョンが変われば、自動的に更新通知が届くかと思います。

Fri, Jun 16, 2006 3:00

最初に断っておくと私は Mac ユーザーで Mac の一般的選択だとブラウザは Apple の Safari である．しかし幾つかの Web サイトで問題が起きる．以前に私の書いた どのブラウザを選ぶか も読んで欲しい．Mac OSX で一般に使えるブラウザ情報を書いておいた．

Mac 用に色々なブラウザがあるのが分かると思うが私は Firefox を選んだ．一番大きな理由は拡張性とクロスプラットフォームな点だ．この２つの理由だけでなくもっと色々挙げられる．例えば、タブ機能、ポップアップのブロック、サーチエンジンの組み込み等々、これらは Safari や他のブラウザでも実現している機能であるが何と言ってもこれらの改革のリーダーは Firefox だ．では私が便利だと思っている拡張を挙げておこう．

Adblock Plus、Adblock Filterset.G Updater 、del.icio.us 、DownThemAll、Fasterfox、Foxmarks Bookmark Synchronizer、Google Calendar Notifier 、Google Notebook 、VideoDownloader （訳者注：原文ではそれぞれの拡張について短い説明が載っていますが省略）

更にもっとたくさんの拡張が利用出来それらは Firefox Add-ons で見ることが出来る．その他 Firefox に組み込めるサーチエンジンやブラウザの外観を変えるテーマなどが揃っている．