Jun 06, 2018

古代のブラウザ戦争の歴史:MD5ハッシュ化された投稿の機密解除

Robert O'Callahan氏(Mozilla内では愛称の「roc」でもっぱら通っていたようです)が1月に公開されたブログ記事をえっちらおっちら勝手に訳してみました。多分誤訳してる所があると思うので、間違いを見つけた人は指摘して頂けると幸いです。

roc氏はFirefox以前から長くMozillaに関わっておられていた重鎮中の重鎮の一人で、現在もFirefoxの日本語入力関係のコードを手がけておられる中野さん曰く、「何かGeckoで分からん事があったらとりあえずrocに聞けば答えが返ってくる」みたいな、Mozillaの低レイヤ周りの生き字引とも言えるような方です。roc氏は2016年にMozillaを退職されたのですが、最近になって、回顧録的に上記リンク先のブログ記事を公開されました。10年くらい前の、WebKitが登場してきてめちゃくちゃ持て囃されてFirefox(Gecko)から一気に人気をかっさらい始めた時期の、ライバルのキラキラした様子を横目で見ながら、クソコードの山だったGeckoにそれでも関わり続けないといけなかったやるせなさから来る、ヤケクソな感じが吐露されていて興味深いです。

「ブラウザ戦争」と題されていますが、これはIE6の牙城を崩すべくFirefoxやChromeやOperaが競っていた頃の、第二次ブラウザ戦争と言われたり言われなかったりする物の事です。MosaicとNetscapeとIEが争ってた頃の方は第一次ブラウザ戦争で、そっちはそっちでまためちゃくちゃ面白いので、「マイクロソフトへの挑戦 ~ネットスケープはいかに してマイクロソフトに挑んだのか~」や「Webの創成」あたりを読むといいと思います(どっちも絶版ですが)。


2007年から2008年はMozillaにとって興味深い時期でした。 市場において、Firefoxは健闘しており、IEの牙城を着実に崩しつつありました。 その一方で、技術面においてはそううまくいっていませんでした。 WebKitが性能面と機能開発の迅速さで私達を追い越していたのです。 Geckoが設計上のミスと技術的負債に悩まされている一方、WebKitはOSS開発者達の心を掴んでいました。 私達はGoogleがWebKitベースのブラウザを開発中だという事も、それがWebKitの市場シェアの少なさという問題を解決するだろうという事も知っていました。 私は強い懸念に囚われ、しばらくの間、MozillaはGeckoを捨ててWebKitに全面移行する事に挑戦するべきだという意見を持っていました。 私がこういう事を大声で言うとプロジェクトに深刻なダメージがあるだろうと思い、私はこの事をごく少数の人にだけ話していました。 公的には、私は不公平な攻撃からGeckoを擁護していましたが、私自身の全体的な判断と矛盾しないように気を配っていました。

私だけがGeckoについて悲観的だった訳ではありません。 Mozilla内部では、「Mozilla 2.0」というお題目を掲げ、自動リファクタリングツールによる分析のような、私達の技術的負債を減らすための近道になる方法を求めて、かなりの時間を費やしていました。 Mozilla外部においては、ライバル達はエンジン開発の面で私達を早急に追い越す事を目指していました。

蓋を開けてみると、私達はほとんどすべての事について間違っていました。 私達は銀の弾丸を見付ける事はできませんでしたが、ただただ大変な頑張りによって、Geckoはライバル達を驚かせる程度には地位を保っていました。 また、時間の経過と共にWebKitの弱みも明らかになってきました。その場凌ぎの省略によって性能は底上げされ、いくつかの互換性テストの上で優位に立ってはいたものの、それらは同時にWebKitにとって技術的負債にもなっていました。 GoogleはWebKitプロジェクトを加速させましたが、AppleとGoogleの軋轢は問題をも生み、最終的にはBlinkというフォークが生まれる結果となりました。 Firefox 57への市場の反応は、FirefoxOSに対する誤った投資という大きな迷走の後においても、Geckoが今日においてもまだ競争力を持ち続けている事を示しています。

ここでの1つの教訓は、内部にいる人は古いコードベースに基づく見通しから、過度に悲観的になり得るという事です。 献身的で有能なスタッフの長年に渡る働きは奇跡を生む事があり、その一方で、あなたのライバル達は彼ら自身で問題を生み抱え込んでしまう事もあります。

もう1つの教訓として、2007年から2008年にかけて私はIE(そしてFlash、WPFも)を倒す事に過度に集中しており、全てのオープンソースのブラウザがたった1つのエンジンの実装を共有する事になったとしても、それはWebにとってそれほど大きな問題ではないと思っていました。 でも今では私はすっかり意見を変えました。 エンジンにおいてより多くのコードを共有する事は、不具合の共通化までをも招くため、真に独立した実装を持ち続ける事は非常に重要なのだと。

私は、Brendan(訳註:Brendan Eich。Netscape時代からの古参でJavaScriptの開発者だが、同性婚反対の運動への寄付がきっかけとなって2014年にMozillaを追われた)や他の人達が、私の意見を取り入れなかった事によって、Mozillaを誤った道へと導くという過ちを私に犯させずに済ませてくれた事に、非常に感謝しています。 もしそうなっていれば、それは誰にとっても大きな災いだったでしょう。

鬱憤ばらしと、記録を後世に残す事を意図して、私は2007年から2008年にかけて、私の考えを説明する4つのブログ記事を書き、それらのMD5ハッシュだけを公開していました。 Firefox 57のリリースの成功の余波がある今は、それらのブログ記事を無害な状態で機密解除するのにちょうどいい時と言えるでしょう。 くれぐれも、私は既に意見を変えているという事を心に留め置いておいて下さい。

2007年1月21日機密解除

今日のブログ記事は非常に興味深い内容なのですが、残念なことに、今それを公開すると深刻な悪影響がありそうです。 しかし、将来のある時点において、私は今日それを書いたという事を証明できるようにしたいと思います。 なので、単にec06b3461cf0eaf3d3e4d7a2e429bddbというMD5ハッシュ値だけを公開しておきます。 :-) <!-- So, let me just say that its MD5 hash is

ec06b3461cf0eaf3d3e4d7a2e429bddb

:-). -->

(訳註:以下、ハッシュ化されていた文章。この原文のMD5ハッシュ値が上記日付で公開されており、この原文からでなければこのハッシュ値は得られないという事実から、この原文は後追いで書かれた物ではなく確かにこの時書かれた物だという事が証明される。実際の所は、Internet Archiveで確認できる最古のバージョンは2013年4月6日付なので、Internet Archiveを証拠として採用する限りにおいては、少なくともこの日までにはこの原文が書かれていたという事が言える。)

今までもこのブログで述べてきましたが、私が目指している事は、FlashやWPFのようなプロプライエタリ製品の対極にある、オープンで標準技術に準拠した、インターネット上のコンテンツやアプリケーションのプラットフォームとしてのWebの推進です。 これを実現するためには、それらの目標に積極に取り組むベンダー(達)のブラウザが、市場で大きなシェアを獲得する必要があります。 それには、透明性があり、もし状況が悪化してもフォークすることができる、オープンソースのブラウザが望ましいでしょう。 私が以前にも述べたように、Firefoxはこの目的のための手段に過ぎず、他の手段もあり得ます。 例えばSafariのような他のブラウザも有力な手段でしょう。

現時点で私にとっては、GeckoよりもWebKitの方が、最終的にはその目的により貢献してくれそうです。 私達は多くのエネルギーをGeckoの内部的な改善のために費やしてきて、実際に前へ物事を進歩させるための余力があまり残っていません。 WebKitは私達より速く進んでいるようだし、助けになる新しい開発者を連れてくるのにも苦労していないようです。 もしこの傾向が続くのであれば、特にGoogleがWebKitに開発者を投入し続けてWindows用のWebKitベースのブラウザを宣伝していくのなら、それは勝利することでしょう…… そしてこれは恐らく実際に起こり、最終的には、Webにとって良い事となるでしょう。 私は、これが現実に起こる事だと強く信じています。

もちろん、この信念に照らし合わせると、私は何をするべきだろうか? という1つの疑問が浮かびます。 私がFirefoxの開発に参加し続ける事は、得策でもあり、また必要でもあると思っています。 得策というのは、それをする事が現在私の収入源であり、ニュージーランドで家族を育て、ここで強力な開発チームを作るという、私の人生における他の目標にとっての助けとなるからです。 しかし、WebKitが私達に追いつき追い越そうとしている間も、WebのためにはFirefoxを停滞させない事もまた必要です。 今現在、私達はWebの利益のために最大限活用しなければならない、決定的なマインドシェアと市場シェアを持っています。 WebKitがいつ主導権を握る準備ができるのか(特にWindows上で)は私達には分からず、それまでの間は、私達はIEとの戦いを続けなくてはなりません。 もし私が去る事でこのプロジェクトが弱体化すれば、私はWebKit以上にMicrosoftを利する事になってしまうでしょう。 長期間に渡りIEをライバル不在の状態にしておく事は、Netscape 4からFirefoxへの転換の間の失敗を繰り返す事に等しいです。 Firefoxが死に体だと世間から思われるだけでも、Firefoxを弱体化させ、そのような真空状態を招くでしょう。

さらに、Geckoに依存している幅広いコミュニティがあります。 組み込み技術者、XULアプリ開発者、拡張機能の作者、Web制作者、そしてそれらのユーザー達は、Geckoが突然墜落すれば行き場を失ってしまいます。 もしWebKitが勝てば、WebKitは自然とそういった人達を惹き付け、私達の元から去らせるでしょう。 それが移行の過程で起こり得る最良のあり方で、Webを前に進める最も安全な方法です。

残念ながら、私は思っている事を気軽におおっぴらに言えません。今の所は。 言えば、前述したように、私の目的に反する形でFirefoxにダメージを与え、Webの発展に悪影響を及ぼすでしょう。 私は、思っている事をごく少数のMozillaの重要なメンバー(私に最も近しく親しい人達)にだけ共有しました。 それが今私にできる事のすべてです。 もし私の予想が当たり、WebKitがFirefoxからオープンソースのWebブラウザの旗印を奪い去ったとしたら、私はその時やっとこの記事を公開できるでしょう。

2007年12月1日機密解除

もう一つのタイムカプセルです :-)

(訳註:以下、ハッシュ化されていた文章)

Geckoは負け馬だ

Web機能、性能、コードの量(訳註:ここでは、Geckoのコード量が無駄に多く、WebKitはコンパクトであるという意味)、そしてコードの品質において、GeckoはWebKitの後塵を拝しています。 HTML5 SQL(訳註:Web SQLの事だが、2010年に廃止され、現在はIndexedDBが取って代わっている)、HTML5ドラッグ&ドロップ、ダウンロード可能なフォント、CSS Transformとアニメーション、CSSメディアクエリ、CSSのbox-shadowtext-shadowtext-stroketext-overflowdisplay: compactdisplay: run-in、CSS3の枠線と複数の背景、SVG画像、(Androidのような)モバイル向けのtwo-passレイアウトとフレームの平坦化(訳註:子フレームの内容を親フレームの一部として展開し、ひと続きのコンテンツとしてスクロールして見られるようにする機能)。様々なWeb機能について、彼らの方が先行しています。 性能面では、ほとんどすべてのサードパーティ製のJS/DOM実行およびページ読み込みの性能テストで私達は負けており、時には相当引き離されています。 私達は個々のテスト項目にケチを付ける事はできますが、傾向は明らかです。 コードの量では、議論の余地はありません。 コードの品質はどうか。両方のコードをいじった人は、誰もがWebKitの方を好みます。 Geckoには大規模な作り直しが必要な部分や、誰も担当者がおらず腐り果てている部分があります。 例えばHTMLパース処理、docshell(訳註:戻る・進むと言った基本的なブラウザの機能を提供する仕組み)/履歴/戻る・進む操作のキャッシュ、フォーカス制御、nsIFrameの継続モデル(これは根本的に壊れています)、絶対配置のコンテナ、選択範囲、エディタ、フロート、フレームの構築、インラインレイアウト、XULのレイアウト(特にboxとblockが入り交じる部分)、内容領域に含まれるべきフレームのロジック、プラグイン、imglib(訳註:画像ライブラリ)、印刷、ビューの仕組み(これは削除されます)、XPConnect、DOMとネイティブのイベントの分離、組み込み用のAPIなどです。 WebKitが完璧だとは言いませんが、それに比べて私達は、壊疽を防ぐためだけに非常に多くの事をしなくてはいけません(訳註:古い部分の不毛なメンテナンスに労力を割かないといけないということ)。

どこだったら私達の方が先行しているでしょうか? Web機能ではJavaScript 1.7とE4X、ごく僅かなDOMの機能、いくつかの文字描画と国際化対応、アクセシビリティ対応がそうです。 ページ読み込み時のメモリ消費の点では私達の方がマシなようです。 私達はWebの互換性について語りますが、私はそれはほとんど完全に市場シェアの問題だと思っていますし、WebKitはその地位に辿り着こうとしていて、恐らくGBrowser(訳註:Google Chromeのこと)が世に出れば、それが決定打となるでしょう。

無論、私達は現在後れを取っている様々な部分を最終的には修正する事ができるでしょう。しかし、その間彼らはそこに立ち止まってはくれません。 私達は彼ら(Apple、Google、Qtの人々、そしてより見通しの良いコードに支えられて成長を続けているオープンコミュニティ)が進むより速く前に進んで、時間の経過と共に追いつけるでしょうか? 私は無理だと思っています。

私はよく考えます。 もしFirefoxがWebKitベースのブラウザによって叩き潰され、Mozillaが引きずり下ろされたら、それは悲しい事で、私達はAppleかGoogleで働く事になるでしょう。 人生なんてそんな物です。 BrendanとMitchel(訳註:Mitchell Baker。Mozilla FoundationとMozilla Corporationの会長)は「それは受け入れ難い結末だ」と私を説得しましたが、私は、MozillaがGeckoに賭け続けるのは大きな間違いで、私達は進路を変えなくてはならないのだと確信しています。

より良い賭け

私達がFirefoxや残りのすべてのXULエコシステムをWebKitの上で動かせたと仮定します。 これはMozillaが生き残る事を容易にするでしょう。というのも、これによって他のブラウザがFirefoxに対して持っている競争上の強みがなくなり、私達はブランド、組織の目的、ユーザーコミュニティ、オープンソースコミュニティ、拡張機能コミュニティ、XULアプリのコミュニティといった独自の強みに集中できるようになるからです。 そしてそれはWebにとっても大いに喜ばしい事です。 一つに統合された私達のマーケットシェアは、IEにしがみつく抵抗勢力に立ち向かうための強力なテコとなります。 Web開発者達はたった1つのブラウザエンジンだけを対象にすれば良くなり、より幸せになれます。 組み込み技術者達は、どの実装を選ぶかという難しい選択をする必要はありません。 そして最も重要な事として、オープンソースのブラウザのコミュニティとその支持者達が単一のコードベースに基づいて協力しあう事で、IEやその他のWebの競合相手に比べてより速く進歩を遂げられるでしょう。

2つのオープンソースのエンジンがあるという事が標準化団体にとってメリットがあるのは事実ですが、彼ら自身用のWebKitの亜種を持つ利害関係者達がまだ複数居続けますので、私は問題無いと思います。 競争がある事の利点についても同様です。 長期的に見て、WebKitの派生物による支配はオープンなWebを実現するための合理的な最適解になり得るでしょう。あくまで私見ですが。

目的に向かって

私達はXULとXPCOMという基盤(XBL、おそらくはXBL2をも含む)を移植し、WebKitで壊れていたり欠けていたりするその他の細かい部分を埋める必要があるでしょう。 困難な問題ではありますが、(GeckoがWebKitに追いつくために必要な努力とは異なり、)時間の経過と共に問題が大きくなっていくという事もありません。 実際には、WebKitがより多くの機能を持つようになり、バグの修正が進んでいく事で、問題は小さくなっていく事でしょう。

バグ修正や、XULのボックスレイアウトやXBL2など、いくつかの私達の取り組みはうまくいけばWebKitに正式に取り込んでもらえるでしょう。 もしAppleが私達を嫌ってパッチを受け入れなければ、それは彼らのオープンソースコミュニティ(あるいは彼ら自身が抱え込んでいるWebKitに関わる人達)に対して格好が付かないでしょう。 いずれにせよ、私達はwebkit.orgのSVNリポジトリの外にいる他のWebKitの利害関係者達と、分散型のソースコード管理システムを使って成果を共有し合う事ができます。

もちろん、私達はこの事に取り組んでいる間も、Geckoを動かし続ける必要があるでしょう。 Geckoおよび将来のXUL-WebKitに付加価値をもたらすであろうプロジェクトは多数あります。 例えばGL cairoのバックエンド、プロセス間で共有できるプロファイルとNecko、外部プロセスのプラグインなどです。 そしてもちろん、そこにはあの酷いXPCOM/XPConnectは含めません。 他にもGecko 1.9.1や将来のバージョンに向けて進行中の作業が多数あります。

私達は、XULコミュニティが移行を生き延びられる事を確実にしなくてはなりません。 幸いな事に、私達は各メジャーリリースにおいて常にテストと修正が必要でした(訳註:回帰テストが充実しているので、WebKitに載せ替えた後も互換性を維持しやすいだろうという事?)。 また、WebKitへの移行計画は、(特にGBrowserが姿を現した時の)WebKitが勢いを増していく中での沈没の危機から来るパニックへの対抗材料にもなると思っています。

これは言うまでもなく、組織的にやるのが困難な事です。 統制は失われ、大きな路線変更に伴うリスクや痛み、恐怖、不確実性などがもたらされます。 しかし、いかなる困難にも私達は立ち向かえると、私は信じています。 そういうのが無いと、Mozillaでやる事らしくないでしょう! :-)

2008年6月5日機密解除

最後にこれを上梓してから、それほど変化はありません。 私達は純粋なJavaScriptの実行性能を向上させましたが、WebKitは再び先に進んでいます。 (私達はいつも現実世界のDOMとJavaScriptの組み合わせの性能で後塵を拝しています。) 私達はメモリ使用の改善を行いましたが、私達のした変更は大きい物ではなく、他プロジェクトでも容易に再現できます。 その他にあった事:

  • 私はGeckoのXMLHttpRequestの実装のコード量がWebKitの物に比べて3倍もあるという事を発見しました。
  • 私はWebKitにおけるDOM IDLバインディングのやり方を見ました。私達のやり方よりもはるかにきれい(しかも高速)でした。 XPCOM/XPConnectのせいだけではありません。 私達はDOM APIがどのようにJavaScriptに表れるかを調整するnsDOMClassInfo.cppの中にマクロ化されたC++の1万行のコードを持っており、それらは個々のAPIごとに個別のIDLで定義された独自の属性を使います。
  • Safari 3.1には、数多くの新機能が搭載されています。 同じくらいのスケジュールで私達がGecko 1.9.1に同様の機能群を実装できるとしたら、それは刮目に値するでしょう。 Gecko 1.9.1の新機能のほとんどがWebKitに既にある物だという事に注意してください。私達は遅れを挽回するのに一生懸命です。
  • Chris Double(訳註:当時MozillaのJavaScriptエンジン関係で貢献していたプログラマー。現況は氏のWebサイトを参照)がTamarin/JS(訳註:Tamarinは、AdobeがソースコードをMozillaに譲渡した、FlashにおけるActionScriptの実行エンジン。FirefoxのJavaScriptエンジンの高速化の鍵になると期待されたが、Firefoxへの搭載は2008年に断念された)の作業に関心を示してくれていましたが、どんな計画なのか、どのように作業を小さな単位に分ければいいかが明確でなかったので、どのようにすれば参加できるかを示す事ができませんでした。 それとは対称的に、有志の参加者達はWebKitのJavaScript周りで大きな貢献を果たしています。
  • Alp Toker(訳註:当時WebKitに関わっていたプログラマー。2008年2月のFESDOMでWebKit/GTK+の発表を行った。WebKit/GTK+によってWebKitのGTK+アプリケーションへの埋め込みが容易になり、アプリケーションに組み込めるWebブラウザエンジンとしての地位をWebKitが一気にGeckoから奪い去った)がやらかした大事件、WebKit/GTK+が起こりました。 その多くはWebKitの馬鹿げた誇大宣伝でしたが、核となる内容は本物でした。 Christian Persch(訳註:当時のGNOME標準ブラウザ「Epiphany」の開発リーダーの一人。Epiphanyは当初Geckoエンジンで動作していたが、WebKitに移行し、後に「GNOME Web」に改名された)のような人達は、それを使う事が非常に多くの開発とメンテナンスコストを要する事を意味すると理解した上で、WebKitのコードの方がはるかにとっつきやすいと感じたようです。
  • ここ数ヵ月間、私達はファズテスト(訳註:敢えて意地悪な操作をした時の動作を見るテスト手法)で見つかったバグを無視しており、Gecko 1.9.1の開発サイクル中もこれを続けます。 セキュリティ上の致命的なバグには大きな危険があります。私達はそれに取り組むか前進するかのどちらかを選ばないといけません。 私達は同じ理由から、コードをきれいにする計画も後回しにしています。
  • 私のSVGとHTMLの作業の一部に、getElementByIdに関連するバグの修正が含まれていました。 この作業では、2000年に書かれて以後全然メンテナンスされていない、nsXULDocumentのキチガイじみた酷いコードの中を掘り下げていく必要がありました。 経験上、Geckoで何か大きな事をしようとするとこういう事がよくあります。
  • 知っての通り、私達はFirefox 3を安定させるのに苦労しました。 これによって物事が良くなり、将来的にはテストの結果も良くなるでしょうが、WebKitはこのような長いサイクルでのコードフリーズを必要としていないようです。

これらのいずれも決定的な物ではなく、私はそれらが私達の計画にこれっぽっちも変化を与えうるとは思っていません。 過去6ヶ月間、私達はWebKitを使うという企みよりも困難な事である、モバイルと組み込みの用途に取り組んでいて、そのため私達は私達の戦略の変化に賛成する事も予見する事もできません。 しかし、そこには増強効果があるため、私は時間が経つにつれて技術の先進性が広まっていく事に期待しています。

それでもなお、Geckoの進歩を維持し続け、オープンなWebを推進し、そして強いFirefoxのリリースでIEを焚き付け続ける事は、未だに非常に重要です。 WebKitの人達でさえ、GeckoとWebKitの競争はWebにとってよい事だと言います。 それが私達のしなくてはならない事なのです。

2008年9月7日機密解除

親愛なる秘密の日記さん。

Chromeが登場した今、物事はどう変わりましたか?

ChromeがWebKitにとって大きな勝利である事は間違いありません。

  • WebKitはAppleの王国からそれ以上の物になったように見えます(そして実際そうなりました)。
  • 実行可能なLinux版(GTK?)のWebKitと、Appleの物でないMac用の実行可能なWebKitが出てくるであろう事がほぼ確実になりました。
  • WebKitのシェアを大幅に拡大させ、物事をよりWeb互換にしていくでしょう。
  • Mac、Windows、そしてLinux用の、すぐにリリースできるオープンソースのWebKitブラウザを生むでしょう。 例えば、Linuxにおけるブラウザの選択肢としてFirefoxを置き換えるかもしれません。LinuxがSplashtop(訳註:リモートデスクトップ用端末の一種。いわゆるシンクライアント)やネットブックなどを通して浸透し始めている事を考えると、これは重要です。
  • Googleの誇大広告は、貢献者達をChromeとWebKitに惹き付けそうで、これは私達への貢献者が減る事を意味します。

Googleのハッカー達がWebKitのコアに大きく貢献し始めれば、それは最大の勝利となるでしょう。 Googleはそれが現実になると約束しています。 私達はそれを目にする事になるでしょう。 GoogleがWebKitに施した変更を還元しないなら、その衝撃は消えてしまうかもしれませんが、彼らは恐らく変更を還元するでしょう。 #webkitにはGoogleとAppleの間に若干の緊張関係がありますが、それが審査を通過するかどうか、いずれにしろその結果を目にする事になります。

良かれ悪しかれ、WebKitがGeckoを叩き潰すというここ数年来の私の予想は、決定的な事としてはまだ現実になっていません。少なくとも市場においては。 なので私は、渋々ながら、将来に希望が持てないという警報の音を再び慣らす事にします。 少し待ってください。 数ヶ月後という近い将来、Chromeがどのようにエコシステムに影響を及ぼしたのかを、私達はより明確に理解するでしょう。

依然として、最悪の場合の終盤戦がどうなるかは不明瞭です。 Geckoがますます後退し、勢いの上でもWebKitの後れを取って、Firefoxのシェアが落ち込む、といった不吉な前兆があっても、Mozillaは多分まだ数年間は、大きな財政やハッカー達の力を保ち続けているでしょう。 以下のいずれかの事が起こると私は見ています。 a) 光が失われるまでの間Geckoと戯れ続けるか、 b) (大規模な組織の縮小を行い、投資やその他の収入で生計を立てるようになって)ブラウザ業界から離れるか、 c)WebKitの上にXUL帝国を築き直すためにあらゆるリスクを冒すか。 私はもちろんc)に一票を投じています。 Hyatt(訳註:Dave Hyatt。FirefoxがPhoenixと呼ばれていた頃の開発者で、後にAppleに移籍し、SafariとWebKitの開発に携わる)や他の人達は、複数のエンジンがある事がWebのためであると主張し続けていますが、私は依然としてそれには同意しません。 WebKitのバリエーションを推すだけでも充分な競争があり、統一はWeb開発者達にとって大きな利点をもたらして、プラットフォームを前に進めるでしょう。 私が特にc)の未来が好きなのは、もしMozillaが失敗しても、WebKitがGeckoに遅れている分野において、私達はWebKitに多大な貢献をなすという功績を残して去る事になるだろうからです。

興味深い事に、私はもう落ち込んだり恐怖に震えたりという事をやめました。 Mozillaの墜落は最悪な事ですが、Webは勝利しています。 私達の計画を実行し、私にできる最善を尽くして貢献する事で、私は毎日が充実しています。 私達は既に、誇りに思えるだけの事を充分に成し遂げてきましたから、次に何が起こっても問題ではありません。 間違い無く、私とニュージーランドのチームは無事に窮地を脱するでしょう。 実際の所、私の最大の心配事は、私の事をGeckoと同じだと思われてしまうだろうという事です。 皆は、私や他のGecko開発者について、Geckoを守るために充分頑張らなかったと思うでしょう。 しかし、それは重大な懸念と言うほどではありません。WebKitやChromeの開発に従事している元Gecko開発者達(設計者達も)が称賛されているのを見てください(訳註:先に名前が挙がったDave Hyatt氏以外にも、Firefoxを立ち上げた後Googleに移ってChromeを立ち上げたBen Goodger氏等、GeckoやFirefoxに関わった後でWebKit陣営に移ってスター開発者として称えられている人は大勢いるという事)。 まぁ、それは単なる私個人の利己的な関心事です。


以上、roc氏による10年越しで機密解除されたブログ記事の勝手訳でした。

普通の技術文書に比べると、聖書由来とか故事成語とかの慣用句がガンガン出てきて、辞書やらGoogleやらに大いに頼る羽目になりました。英語が通じる所に旅行に行くくらいの事はまあできるかなという程度の英語力の自分にはだいぶ辛かったです……

本文中で何度も「GeckoはWebKitの後塵を拝している」と書かれていますが、その後の様々な改良によってGeckoの性能はかなり改善され、ARE WE FAST YET?等を見る限り、ベンチマーク性能ではそこそこいい勝負になるくらいまでのレベルになっているようです。また、Quantum何々と呼ばれる各方面での性能改善の取り組みに加え、Firefox 57での従来型アドオンの廃止に伴う(Geckoエンジンの改良の妨げになっていたであろう)古い機能の改廃も進んでいます。腐らず頑張り続けてここまで来た彼らの懸命な努力に、改めて敬意を表します。

しかし、roc氏は「Firefox 57が成功したみたいだから、今なら言っても大丈夫だろう」と判断されてこれらの記事を公開されたそうですが、実際の状況はどうかというと、少なくとも日本語圏で暮らす限りはFirefox(Gecko)の存在感は薄まる一方という印象を拭えません。特にスマホの世界では最初からWebKit(系)が事実上の唯一の選択肢でしたので、「お使いのブラウザ(Firefox for Android)には対応してません。Google Chromeをダウンロードしてください」みたいな事を言われる事もしばしばあり、その度にゲンナリしてしまいます。Firefox for Androidも、Firefox SyncでスマホとPCの間でログイン情報や履歴を共有できて楽だし、アドオンもあるので、PCでFirefox使ってる人は1回試してみる価値はあると思うのですが……

モバイルの方が主戦場になったこの時代に、今更ここから大きく盛り返すなんて事はまあ無いと思いますが、願わくば、これからもMozillaにはWeb上の中立な定点、困った時に頼れるアイツとして継続し続けて欲しいものです。

明暗が分かれた事例として、Firefox 57での従来型アドオンの廃止を主導し完遂されたAndy氏の述懐の翻訳も併せてどうぞ。

エントリを編集します。

wikieditish message: Ready to edit this entry.










性能面では、ほとんどすべてのサードパーティ製のJS/DOM実行およびページ読み込みの性能テストで私達は負けており、時には相当引き離されています。私達は個々のテスト項目にケチを付ける事はできますが、傾向は明らかです。コードの量では、議論の余地はありません。コードの品質はどうか。両方のコードをいじった人は、誰もがWebKitの方を好みます。Geckoには大規模な作り直しが必要な部分や、誰も担当者がおらず腐り果てている部分があります。例えばHTMLパース処理、docshell(訳註:戻る・進むと言った基本的なブラウザの機能を提供する仕組み)/履歴/戻る・進む操作のキャッシュ、フォーカス制御、nsIFrameの継続モデル(これは根本的に壊れています)、絶対配置のコンテナ、選択範囲、エディタ、フロート、フレームの構築、インラインレイアウト、XULのレイアウト(特にboxとblockが入り交じる部分)、内容領域に含まれるべきフレームのロジック、プラグイン、imglib(訳註:画像ライブラリ)、印刷、ビューの仕組み(これは削除されます)、XPConnect、DOMとネイティブのイベントの分離、組み込み用のAPIなどです。WebKitが完璧だとは言いませんが、それに比べて私達は、壊疽を防ぐためだけに非常に多くの事をしなくてはいけません(訳註:古い部分の不毛なメンテナンスに労力を割かないといけないということ)。どこだったら私達の方が先行しているでしょうか?Web機能ではJavaScript 1.7とE4X、ごく僅かなDOMの機能、いくつかの文字描画と国際化対応、アクセシビリティ対応がそうです。ページ読み込み時のメモリ消費の点では私達の方がマシなようです。私達はWebの互換性について語りますが、私はそれはほとんど完全に市場シェアの問題だと思っていますし、WebKitはその地位に辿り着こうとしていて、恐らくGBrowser(訳註:Google Chromeのこと)が世に出れば、それが決定打となるでしょう。無論、私達は現在後れを取っている様々な部分を最終的には修正する事ができるでしょう。しかし、その間彼らはそこに立ち止まってはくれません。私達は彼ら(Apple、Google、Qtの人々、そしてより見通しの良いコードに支えられて成長を続けているオープンコミュニティ)が進むより速く前に進んで、時間の経過と共に追いつけるでしょうか?私は無理だと思っています。私はよく考えます。もしFirefoxがWebKitベースのブラウザによって叩き潰され、Mozillaが引きずり下ろされたら、それは悲しい事で、私達はAppleかGoogleで働く事になるでしょう。人生なんてそんな物です。BrendanとMitchel(訳註:Mitchell Baker。Mozilla FoundationとMozilla Corporationの会長)は「それは受け入れ難い結末だ」と私を説得しましたが、私は、MozillaがGeckoに賭け続けるのは大きな間違いで、私達は進路を変えなくてはならないのだと確信しています。#### より良い賭け私達がFirefoxや残りのすべてのXULエコシステムをWebKitの上で動かせたと仮定します。これはMozillaが生き残る事を容易にするでしょう。というのも、これによって他のブラウザがFirefoxに対して持っている競争上の強みがなくなり、私達はブランド、組織の目的、ユーザーコミュニティ、オープンソースコミュニティ、拡張機能コミュニティ、XULアプリのコミュニティといった独自の強みに集中できるようになるからです。そしてそれはWebにとっても大いに喜ばしい事です。一つに統合された私達のマーケットシェアは、IEにしがみつく抵抗勢力に立ち向かうための強力なテコとなります。Web開発者達はたった1つのブラウザエンジンだけを対象にすれば良くなり、より幸せになれます。組み込み技術者達は、どの実装を選ぶかという難しい選択をする必要はありません。そして最も重要な事として、オープンソースのブラウザのコミュニティとその支持者達が単一のコードベースに基づいて協力しあう事で、IEやその他のWebの競合相手に比べてより速く進歩を遂げられるでしょう。2つのオープンソースのエンジンがあるという事が標準化団体にとってメリットがあるのは事実ですが、彼ら自身用のWebKitの亜種を持つ利害関係者達がまだ複数居続けますので、私は問題無いと思います。競争がある事の利点についても同様です。長期的に見て、WebKitの派生物による支配はオープンなWebを実現するための合理的な最適解になり得るでしょう。あくまで私見ですが。#### 目的に向かって私達はXULとXPCOMという基盤(XBL、おそらくはXBL2をも含む)を移植し、WebKitで壊れていたり欠けていたりするその他の細かい部分を埋める必要があるでしょう。困難な問題ではありますが、(GeckoがWebKitに追いつくために必要な努力とは異なり、)時間の経過と共に問題が大きくなっていくという事もありません。実際には、WebKitがより多くの機能を持つようになり、バグの修正が進んでいく事で、問題は小さくなっていく事でしょう。バグ修正や、XULのボックスレイアウトやXBL2など、いくつかの私達の取り組みはうまくいけばWebKitに正式に取り込んでもらえるでしょう。もしAppleが私達を嫌ってパッチを受け入れなければ、それは彼らのオープンソースコミュニティ(あるいは彼ら自身が抱え込んでいるWebKitに関わる人達)に対して格好が付かないでしょう。いずれにせよ、私達はwebkit.orgのSVNリポジトリの外にいる他のWebKitの利害関係者達と、分散型のソースコード管理システムを使って成果を共有し合う事ができます。もちろん、私達はこの事に取り組んでいる間も、Geckoを動かし続ける必要があるでしょう。Gecko*および*将来のXUL-WebKitに付加価値をもたらすであろうプロジェクトは多数あります。例えばGL cairoのバックエンド、プロセス間で共有できるプロファイルとNecko、外部プロセスのプラグインなどです。そしてもちろん、そこにはあの酷いXPCOM/XPConnectは含めません。他にもGecko 1.9.1や将来のバージョンに向けて進行中の作業が多数あります。私達は、XULコミュニティが移行を生き延びられる事を確実にしなくてはなりません。幸いな事に、私達は各メジャーリリースにおいて常にテストと修正が必要でした(訳註:回帰テストが充実しているので、WebKitに載せ替えた後も互換性を維持しやすいだろうという事?)。また、WebKitへの移行計画は、(特にGBrowserが姿を現した時の)WebKitが勢いを増していく中での沈没の危機から来るパニックへの対抗材料にもなると思っています。これは言うまでもなく、組織的にやるのが困難な事です。統制は失われ、大きな路線変更に伴うリスクや痛み、恐怖、不確実性などがもたらされます。しかし、いかなる困難にも私達は立ち向かえると、私は信じています。そういうのが無いと、Mozillaでやる事らしくないでしょう! :-)### [2008年6月5日](https://robert.ocallahan.org/2008/06/5ce9134be8a642e1fbf3b93593da33e9_05.html):[機密解除](https://raw.githubusercontent.com/rocallahan/blog-archive/master/hashed-blog3.txt)最後にこれを上梓してから、それほど変化はありません。私達は純粋なJavaScriptの実行性能を向上させましたが、WebKitは再び先に進んでいます。(私達はいつも現実世界のDOMとJavaScriptの組み合わせの性能で後塵を拝しています。)私達はメモリ使用の改善を行いましたが、私達のした変更は大きい物ではなく、他プロジェクトでも容易に再現できます。その他にあった事: * 私はGeckoのXMLHttpRequestの実装のコード量がWebKitの物に比べて3倍もあるという事を発見しました。 * 私はWebKitにおけるDOM IDLバインディングのやり方を見ました。私達のやり方よりもはるかにきれい(しかも高速)でした。 XPCOM/XPConnectのせいだけではありません。 私達はDOM APIがどのようにJavaScriptに表れるかを調整するnsDOMClassInfo.cppの中にマクロ化されたC++の1万行のコードを持っており、それらは個々のAPIごとに個別のIDLで定義された独自の属性を使います。 * Safari 3.1には、数多くの新機能が搭載されています。 同じくらいのスケジュールで私達がGecko 1.9.1に同様の機能群を実装できるとしたら、それは刮目に値するでしょう。 Gecko 1.9.1の新機能のほとんどがWebKitに既にある物だという事に注意してください。私達は遅れを挽回するのに一生懸命です。 * Chris Double(訳註:当時MozillaのJavaScriptエンジン関係で貢献していたプログラマー。現況は[氏のWebサイト](https://bluishcoder.co.nz/)を参照)がTamarin/JS(訳註:Tamarinは、AdobeがソースコードをMozillaに譲渡した、FlashにおけるActionScriptの実行エンジン。FirefoxのJavaScriptエンジンの高速化の鍵になると期待されたが、Firefoxへの搭載は2008年に断念された)の作業に関心を示してくれていましたが、どんな計画なのか、どのように作業を小さな単位に分ければいいかが明確でなかったので、どのようにすれば参加できるかを示す事ができませんでした。 それとは対称的に、有志の参加者達はWebKitのJavaScript周りで大きな貢献を果たしています。 * Alp Toker(訳註:当時WebKitに関わっていたプログラマー。[2008年2月のFESDOMでWebKit/GTK+の発表を行った](http://www.atoker.com/blog/2008/02/26/developing-hybrid-web-gtk-applications/)。WebKit/GTK+によってWebKitのGTK+アプリケーションへの埋め込みが容易になり、アプリケーションに組み込めるWebブラウザエンジンとしての地位をWebKitが一気にGeckoから奪い去った)がやらかした大事件、WebKit/GTK+が起こりました。 その多くはWebKitの馬鹿げた誇大宣伝でしたが、核となる内容は本物でした。 Christian Persch(訳註:当時のGNOME標準ブラウザ「Epiphany」の開発リーダーの一人。Epiphanyは当初Geckoエンジンで動作していたが、WebKitに移行し、後に「GNOME Web」に改名された)のような人達は、それを使う事が非常に多くの開発とメンテナンスコストを要する事を意味すると理解した上で、WebKitのコードの方がはるかにとっつきやすいと感じたようです。 * ここ数ヵ月間、私達はファズテスト(訳註:敢えて意地悪な操作をした時の動作を見るテスト手法)で見つかったバグを無視しており、Gecko 1.9.1の開発サイクル中もこれを続けます。 セキュリティ上の致命的なバグには大きな危険があります。私達はそれに取り組むか前進するかのどちらかを選ばないといけません。 私達は同じ理由から、コードをきれいにする計画も後回しにしています。 * 私のSVGとHTMLの作業の一部に、getElementByIdに関連するバグの修正が含まれていました。 この作業では、2000年に書かれて以後全然メンテナンスされていない、nsXULDocumentのキチガイじみた酷いコードの中を掘り下げていく必要がありました。 経験上、Geckoで何か大きな事をしようとするとこういう事がよくあります。 * 知っての通り、私達はFirefox 3を安定させるのに苦労しました。 これによって物事が良くなり、将来的にはテストの結果も良くなるでしょうが、WebKitはこのような長いサイクルでのコードフリーズを必要としていないようです。これらのいずれも決定的な物ではなく、私はそれらが私達の計画にこれっぽっちも変化を与えうるとは思っていません。過去6ヶ月間、私達はWebKitを使うという企みよりも困難な事である、モバイルと組み込みの用途に取り組んでいて、そのため私達は私達の戦略の変化に賛成する事も予見する事もできません。しかし、そこには増強効果があるため、私は時間が経つにつれて技術の先進性が広まっていく事に期待しています。それでもなお、Geckoの進歩を維持し続け、オープンなWebを推進し、そして強いFirefoxのリリースでIEを焚き付け続ける事は、未だに非常に重要です。WebKitの人達でさえ、GeckoとWebKitの競争はWebにとってよい事だと言います。それが私達のしなくてはならない事なのです。### [2008年9月7日](https://robert.ocallahan.org/2008/09/4a8dec89f08156ec972ddc3ff319eb01_06.html):[機密解除](https://raw.githubusercontent.com/rocallahan/blog-archive/master/hashed-blog4.txt)親愛なる秘密の日記さん。Chromeが登場した今、物事はどう変わりましたか?ChromeがWebKitにとって大きな勝利である事は間違いありません。 * WebKitはAppleの王国からそれ以上の物になったように見えます(そして実際そうなりました)。 * 実行可能なLinux版(GTK?)のWebKitと、Appleの物でないMac用の実行可能なWebKitが出てくるであろう事がほぼ確実になりました。 * WebKitのシェアを大幅に拡大させ、物事をよりWeb互換にしていくでしょう。 * Mac、Windows、そしてLinux用の、すぐにリリースできるオープンソースのWebKitブラウザを生むでしょう。 例えば、Linuxにおけるブラウザの選択肢としてFirefoxを置き換えるかもしれません。LinuxがSplashtop(訳註:リモートデスクトップ用端末の一種。いわゆるシンクライアント)やネットブックなどを通して浸透し始めている事を考えると、これは重要です。 * Googleの誇大広告は、貢献者達をChromeとWebKitに惹き付けそうで、これは私達への貢献者が減る事を意味します。Googleのハッカー達がWebKitのコアに大きく貢献し始めれば、それは最大の勝利となるでしょう。Googleはそれが現実になると約束しています。私達はそれを目にする事になるでしょう。GoogleがWebKitに施した変更を還元しないなら、その衝撃は消えてしまうかもしれませんが、彼らは恐らく変更を還元するでしょう。`#webkit`にはGoogleとAppleの間に若干の緊張関係がありますが、それが審査を通過するかどうか、いずれにしろその結果を目にする事になります。良かれ悪しかれ、WebKitがGeckoを叩き潰すというここ数年来の私の予想は、決定的な事としてはまだ現実になっていません。少なくとも市場においては。なので私は、渋々ながら、将来に希望が持てないという警報の音を再び慣らす事にします。少し待ってください。数ヶ月後という近い将来、Chromeがどのようにエコシステムに影響を及ぼしたのかを、私達はより明確に理解するでしょう。依然として、最悪の場合の終盤戦がどうなるかは不明瞭です。Geckoがますます後退し、勢いの上でもWebKitの後れを取って、Firefoxのシェアが落ち込む、といった不吉な前兆があっても、Mozillaは多分まだ数年間は、大きな財政やハッカー達の力を保ち続けているでしょう。以下のいずれかの事が起こると私は見ています。a) 光が失われるまでの間Geckoと戯れ続けるか、b) (大規模な組織の縮小を行い、投資やその他の収入で生計を立てるようになって)ブラウザ業界から離れるか、c)WebKitの上にXUL帝国を築き直すためにあらゆるリスクを冒すか。私はもちろんc)に一票を投じています。Hyatt(訳註:Dave Hyatt。FirefoxがPhoenixと呼ばれていた頃の開発者で、後にAppleに移籍し、SafariとWebKitの開発に携わる)や他の人達は、複数のエンジンがある事がWebのためであると主張し続けていますが、私は依然としてそれには同意しません。WebKitのバリエーションを推すだけでも充分な競争があり、統一はWeb開発者達にとって大きな利点をもたらして、プラットフォームを前に進めるでしょう。私が特にc)の未来が好きなのは、もしMozillaが失敗しても、WebKitがGeckoに遅れている分野において、私達はWebKitに多大な貢献をなすという功績を残して去る事になるだろうからです。興味深い事に、私はもう落ち込んだり恐怖に震えたりという事をやめました。Mozillaの墜落は最悪な事ですが、Webは勝利しています。私達の計画を実行し、私にできる最善を尽くして貢献する事で、私は毎日が充実しています。私達は既に、誇りに思えるだけの事を充分に成し遂げてきましたから、次に何が起こっても問題ではありません。間違い無く、私とニュージーランドのチームは無事に窮地を脱するでしょう。実際の所、私の最大の心配事は、私の事をGeckoと同じだと思われてしまうだろうという事です。皆は、私や他のGecko開発者について、Geckoを守るために充分頑張らなかったと思うでしょう。しかし、それは重大な懸念と言うほどではありません。WebKitやChromeの開発に従事している元Gecko開発者達(設計者達も)が称賛されているのを見てください(訳註:先に名前が挙がったDave Hyatt氏以外にも、Firefoxを立ち上げた後Googleに移ってChromeを立ち上げたBen Goodger氏等、GeckoやFirefoxに関わった後でWebKit陣営に移ってスター開発者として称えられている人は大勢いるという事)。まぁ、それは単なる私個人の利己的な関心事です。---以上、roc氏による10年越しで機密解除されたブログ記事の勝手訳でした。普通の技術文書に比べると、聖書由来とか故事成語とかの慣用句がガンガン出てきて、辞書やらGoogleやらに大いに頼る羽目になりました。英語が通じる所に旅行に行くくらいの事はまあできるかなという程度の英語力の自分にはだいぶ辛かったです……本文中で何度も「GeckoはWebKitの後塵を拝している」と書かれていますが、その後の様々な改良によってGeckoの性能はかなり改善され、[ARE WE FAST YET?](https://arewefastyet.com/)等を見る限り、ベンチマーク性能ではそこそこいい勝負になるくらいまでのレベルになっているようです。また、[Quantum何々と呼ばれる各方面での性能改善の取り組み](https://rockridge.hatenablog.com/entry/2016/11/05/020802)に加え、[Firefox 57での従来型アドオンの廃止](/latest/blosxom/mozilla/misc/2018-06-06_andy.htm)に伴う(Geckoエンジンの改良の妨げになっていたであろう)古い機能の改廃も進んでいます。腐らず頑張り続けてここまで来た彼らの懸命な努力に、改めて敬意を表します。しかし、roc氏は「Firefox 57が成功したみたいだから、今なら言っても大丈夫だろう」と判断されてこれらの記事を公開されたそうですが、実際の状況はどうかというと、少なくとも日本語圏で暮らす限りはFirefox(Gecko)の存在感は薄まる一方という印象を拭えません。特にスマホの世界では最初からWebKit(系)が事実上の唯一の選択肢でしたので、「お使いのブラウザ(Firefox for Android)には対応してません。Google Chromeをダウンロードしてください」みたいな事を言われる事もしばしばあり、その度にゲンナリしてしまいます。Firefox for Androidも、Firefox SyncでスマホとPCの間でログイン情報や履歴を共有できて楽だし、アドオンもあるので、PCでFirefox使ってる人は1回試してみる価値はあると思うのですが……モバイルの方が主戦場になったこの時代に、今更ここから大きく盛り返すなんて事はまあ無いと思いますが、願わくば、これからもMozillaにはWeb上の中立な定点、困った時に頼れるアイツとして継続し続けて欲しいものです。明暗が分かれた事例として、[Firefox 57での従来型アドオンの廃止を主導し完遂されたAndy氏の述懐の翻訳](/latest/blosxom/mozilla/misc/2018-06-06_andy.htm)も併せてどうぞ。




-->
拡張機能