- Webとコミュニケーションの中核技術をいくつも生み出したMozillaは、Firefox・Thunderbird・FirefoxOS・Rust・Servoといった資産と機会を十分に生かせなかったと批判されている
- Firefoxは依然として高速で効率的な独立したFOSSブラウザーエンジンを備えており、PDF注釈やローカル翻訳などChromeとは異なる強みが残っている
- Rust・JavaScript・Thunderbird・KaiOSへと続く技術的遺産は幅広いが、Mozillaの戦略はそれらをパワーユーザー向け製品群として束ねきれていない
- ブラウザー市場ではChromium系が約4分の3近いシェアを占め、FirefoxはStatcounter基準で3%未満まで低下している
- FirefoxとThunderbirdはChromeを追うよりも、縦型タブ、ツリータブ、強力な拡張、マルチプロトコルメッセージングを前面に出した上級ユーザー向けクライアントとして差別化できる余地がある
Firefoxが今なお強い理由
- Mozillaは商用ベンダーから独立した唯一の完全なFOSSブラウザーエンジンを持つ独立組織である
- Firefoxは今なお強力で高速、かつリソース効率の高いブラウザーと評価されている
- ブラウザー内でPDFをレンダリングするだけでなく、編集・注釈も可能である
- Firefox 118はプライバシー重視のローカルなブラウザー内言語翻訳を提供する
- 一部のショートカットやナビゲーション機能はパワーユーザーにとって有用である
- 車載ソフトウェアのプライバシー問題を扱ったレポートのように、Mozillaのセキュリティ研究も依然として重要な役割を果たしている
RustとJavaScriptに残る言語の遺産
- MozillaはRustとJavaScriptという2つのプログラミング言語の歴史と結び付いている
- RustはMozillaが生み出した言語であり、主要OS全体へ広がっている
- パンデミックから6か月の時点でMozillaはRustチーム全体を解雇し、次世代レンダリングエンジンServoも中断された
- RustとServoはその後、それぞれ財団と新たな受け皿を見つけた
- Netscapeは1995年、Netscape 2.0とともにJavaScriptを導入した
- 当時の発表では開発者に「関心があるかもしれない」とされたが、JavaScriptはその後Webの中核技術となった
Thunderbirdが示す統合クライアントの可能性
- MozillaはクロスプラットフォームのメッセージングクライアントThunderbirdの開発を支援している
- 長く放置された時期もあったが、開発者たちは機能統合を継続してきた
- 2015年のThunderbird 38はLightningアドオン由来のカレンダー機能を統合した
- 2017年のThunderbird 51はInstantbird由来のIRC・XMPPチャット対応を追加した
- 2020年のThunderbird 78はEnigMailアドオンを置き換えるPGPメール暗号化を統合した
- 2022年のThunderbird 102はMatrixチャットに対応した
- 2023年のThunderbird 115はSupernovaと呼ばれた刷新UIを導入した
- Android版Thunderbirdも準備中である
- PidginとlibPurpleにはSlack、WhatsApp、Telegram、RocketChat、Signal、Mattermostなどへ接続するプラグインがある
- Thunderbirdがこれを採用・更新してChat Coreに加えれば、複数サービスを1か所で扱う汎用コミュニケーションクライアントになり得る
FirefoxOSとKaiOSに残るモバイルの機会
- MozillaはモバイルOS Boot2Geckoを開発し、FirefoxOSの名で提供したが、2016年に正式終了した
- FirefoxOSはその後KaiOSとして再出発した
- KaiOSは2018年にGoogleの出資を受けた
- KaiOSの保有側は現在も1億6,000万台のデバイスを主張している
- Finnfundはサハラ以南アフリカでの拡大を支援するため、KaiosTechに340万ドルを投資した
- GitHub上のKaiOSコードには今なおMozillaの商標が残っている
- このプロジェクトはpostmarketOSと競合または合流し得る著名なFOSSプロジェクトにはなれず、Mozillaも積極的に取り戻そうとしていない
Netscape系に残るその他の技術
- もともと「Mozilla」はNetscape Communicator由来のインターネットツールスイートだった
- ブラウザー
- メールとUSENETを含むメッセージングクライアント
- カレンダー
- アドレス帳
- Collabraから買収したワークフロー
- HTMLエディター
- この統合スイートは現在、Seamonkey Projectの形で残っている
- HTMLエディターは動的Webコンテンツの拡大で目立たなくなったが、MozillaコードベースのBlueGriffonは代表的なFOSS HTMLエディターとして残っている
- Mozilla系にはかつて音楽プレーヤーSongbirdもあった
- 複数企業が自前クライアントなしではストリーミングしづらくしている現状では、この分野にも余地があるかもしれない
- Netscape Directory Serverに由来するLDAPサーバーコードは現在、389 Directory Serverへと受け継がれている
- Red Hatは関連製品をRed Hat Directory Serverとして販売している
- Oracleも古いNetscape Enterprise Serverをいまだにサポートしている
Chromium中心に固まったWebエンジン市場
- 現代のWebは単純なHTMLページではなく、クライアントとサーバーの両側で動作するプログラムに近い
- SlackやTeamsのようなローカルアプリ風サービスも、独自のシングルサイトブラウザー内で動作するJavaScriptアプレットであり、Googleのブラウザーエンジンを使っている
- スマートフォンの70%以上はLinuxベースのAndroidで、ブラウザーもGoogleコードベースが70%以上である
- Chromeは約64%
- Edgeは5.4%
- OperaとSamsung Browserは合わせて約5%
- VivaldiとBraveもChromiumベースである
- SafariはChromium以外のブラウザーとして最大シェアを持つが、それでも20%未満である
- SafariのWebKitはChromiumのBlinkエンジンの源流である
- SafariはほぼApple OSに限定される
- LinuxではGNOME Web、コードネームEpiphanyがWebKitブラウザーとして挙げられる
- FirefoxはStatcounter推計で3%未満まで下がっている
Chromeを追う戦略の限界
- FirefoxはLinuxで支配的なブラウザーであり、Ubuntu Mantic Minotaurではデフォルトで事実上唯一の独立系アプリとして挙げられている
- Linuxユーザーは概してパワーユーザーに近いため、Firefoxがこの層を狙う余地がある
- Chromeを模倣するやり方はMozillaの成功戦略になりにくい
- Firefox 29のAustralisというChrome類似テーマはユーザーの不満を招き、Pale Moonの勢いを後押しした
- Firefox QuantumはXULアドオンを廃止し、一部ユーザーはWaterfox ClassicやBasiliskへ移行した
- Windows XPユーザーはMyPalを使っている
- MicrosoftのChromiumベースEdgeも縦型タブを提供するが、Firefoxには標準の縦型タブがない
- Firefoxでまともな縦型タブを使うには設定ファイルを触る必要がある
- Vivaldiは、Chromeより多機能なブラウザーにも市場があることを示している
パワーユーザー向けFirefoxとThunderbirdという選択肢
- FirefoxはChromeを追うより、パワーユーザー向けブラウザーという方向をより強く打ち出せる
- Firefoxが差別化できる機能は次のとおりである
- 生き残った強力な拡張機能のバンドル提供
- 縦型タブ、またはツリー構造タブを画面のどの端でも使えるようにすること
- メニューバーとショートカットの強化
- マルチスレッドダウンロードの統合
- BitTorrentサポートの実験
- Firefox Developer Editionでの実験的機能の提供
- かつてのFirefoxが持っていたカスタマイズ性の復活
- Thunderbirdは複数サービスとつながる汎用コミュニケーションクライアントになり得る
- libPurpleを採用・更新し、Thunderbird Chat Coreへ統合すれば改善の余地は大きい
- Chromeとその派生ブラウザーは一般ユーザー向けに任せ、Mozillaはキーボード中心の上級ユーザー向けクロスプラットフォームツールを作ることができる
1件のコメント
Hacker News の意見
現代のウェブ標準が事実上、Chrome の機能セットと同義になっている状況で、Mozilla の役割は一つだけだと思う。Google がブラウザを独占していないふりをできるように、『Weekend at Bernie's』のように持ち歩かれる存在だ。
iOS に別のエンジンが登場すれば、数年以内にウェブサイトは非 Chrome ブラウザをブロックし始め、一部のスキンブラウザも一緒にブロックされる可能性が高い。そうなると Mozilla は名目上の隠れみのとしても役に立たなくなりそうだ。ひどい状況で、Mozilla が抜け出す道はあまり見えない
その座はかなり前から iPhone の Safari が占めている。Firefox はデスクトップブラウザとしては一番好きだが、ブラウザ市場でデスクトップは核心ではない。デバイス全体で見ると、Edge でさえ Firefox より利用率が高い
https://gs.statcounter.com/browser-market-share
あり得るあらゆる統計を見ると、Chrome は Apple の囲いの外、つまり最近になってようやく現実的な選択肢になった Apple エコシステムを除く「自由市場」で 80% 以上を占めている
引用文の中の「Mozilla が Rust チームを解雇して Servo を殺し、Rust が Google の Go より輝いていたからではないか」というくだりは、編集段階で取り除かれるべき本当に愚かな脱線だ。特に「GoLang」という表記までおかしい
Thunderbird に対する Mozilla の関与度も誇張されている。今の関係は実質的に儀礼的なレベルだ。また、1998 年に AOL がオープンソースを約束し、4 年後にオープンソース版が出たというような記述は、約束の履行が遅れたように見せている。実際には Netscape は 2 か月でソースコードを公開し、その後の 4 年は古いコードを捨て、別の製品群の 1.0 リリースにつながる書き直しを決めるのにかかった時間だ
Mozilla がパワーユーザー層にもっと注力すべきだという点にはある程度同意するが、この記事は現代の Mozilla 組織の実際の焦点や進むべき方向を調査したというより、低 effort な雑談に近く見える
その主張を 1 分たりとも信じていないので、わざと “surely not” と書きました。「golang」は公式名称の一つで、単に「go」だと誤解されやすく検索もしにくいからです。大文字は強調で、途中に大文字を入れる表記はスクリーンリーダー利用者にも役立ちます。Thunderbird と Mozilla の関係が儀礼的だという主張には根拠が必要です。Netscape のオープンソース約束の履行には遅れがあり、4 年後に書き直した製品群の 1.0 が出たという細部は論点とは副次的です。オープンソース化の決定と Netscape 5 の書き直しを同じ時点で行ったのは非常に愚かでしたが、理解はできます。25 年前のことなので一行で流せる内容であって、ここまで重箱の隅をつつくような話ではないと思います
Rust を使っていた Servo チーム全体を解雇し、続いてドキュメントチームの大半である MDN を削減した後、CEO に昇給を与えたのが始まりだった
Mozilla が 2010 年代初頭の軌道をそのまま進んでいたらよかったのにと思う
Brendan Eich がいた頃は、目的とアイデンティティがはっきりしているように見えた。Rust になるものの誕生、PDF のダウンロードが一般的だった時代の PDF.js、Firefox OS、Google が推していた NaCl を押しのけた WebAssembly の前身 asm.js など、興味深いことが多かった。その後どうして道を見失ったのかは分からない
Tor 統合だけでも相当に急進的なプライバシー機能だし、「暗号資産じゃないか」と言うことはできても、少なくとも Google から独立して稼ぐ方法を探そうとしている。Mozilla と違って Brave は広告なしで収益化できるウェブを作ろうとしており、Mozilla は文字どおり現状にすべての売上を依存している
Google が Chrome の開発とマーケティングにつぎ込んだ数十億ドルに対抗できるところはない。Google は現代のウェブの門番であり、Apple でさえ関連性を保とうと苦労している
Mozillaの売上の90%がGoogle/Alphabetから来ているというのは、ざっくり言えば「Mitchell Bakerの給与の90%はGoogleが払っている」「Mitchell Bakerは間接的にGoogleのために働いている」という意味だ。
Mozillaは「変わった隣人」ではなく、管理された反対勢力であり、この不健全な関係を断ち切ったりGoogleの足を踏んだりすれば、CEO報酬にも打撃が及ぶだろう。Mozillaの開発者やユーザーの多くは親Google派ではないかもしれないが、ここで重要なのは見解ではなく現金だ。
Googleより多く払いたがる企業はあるし、実際に数年間Yahooがそうだった。Mozillaはいろいろな形でGoogleの足を踏み続けているが、それがMitchell Bakerの報酬に悪影響を与えている兆候はまったくない。現在のMozillaの売上に占めるGoogleの比率も90%よりかなり低いと思うが、それは論点とは別だ。
ブラウザで最も重要なのはユーザーによるカスタマイズが可能なことなので、それが制限されると非常にいら立つ。最近のFirefoxアップデートでそういうことが起きた。
Firefoxが更新された後、ブラウザ起動直後にはbookmarkletを実行できなくなった。
javascript:alert(123)のようなbookmarkletはすべてのページで、about:blankでさえ問題なく動くが、設定の「空白ページ」で起動した直後だけは動かない。通常、ブラウジングセッションの最初の手順として「TekMolがBページやCページにいなければAページへ送れ」というbookmarkletを使い、Aから始めてもう一度押してBへ、さらに押してCへ行くという流れを使っているのだが、今は壊れている。最新Firefoxのリグレッションバグのようだ。bookmarkletのJavaScriptでウェブサイトを巡回するというのは予想外だが、直るといい。まだチケットがないなら新しく上げてみるとよさそうだ。
about:newtabに設定し、「新しいタブ」は「空白ページ」に変えれば回避できそうだ。javascript:をもう使えなくするあの「改善」にやられて、関連するJavaScriptを包んだdata: URLで回避できた。<https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_...>
ただしFirefoxがだいたい10バージョンほど上がるたびにこれが壊れて、また解決策を探さなければならない。
RustとGoを比較するあの主張は理解できないし、特に両者は目的が完全に違う。Rustはシステムプログラミング、Goはクラウドサーバー側に近いからだ。
GoがRustとは非常に異なる用途で使われるという点も理解していないようだ。だからServoが中止された理由をそちらに求めるのは、かなり奇妙に見える。
システムプログラミング、つまり多数のシステムコールを扱う仕事を多くやってきたが、Goでも十分うまくいく。ハードリアルタイムシステムのようなものを作るのでないなら、Goを排除する理由が分からない。
RustがGoを「脅かす」という言い方は意味が曖昧だ。GoogleがGoへの外部貢献に依存しているわけでもない。
数年前にMozilla HQを訪れたが、場所も人々も良かった一方で、組織がアイデンティティ危機と惰性に同時に苦しんでいるという印象が強かった。
Bakerは運営者としては優秀で、Mozillaは今も堅実な収入を上げているが、Mozillaが既存の余裕に頼って生きるのではなく、新しく拡張された意味へ進化するには、外向きで先手を打つ技術ビジョナリー型の人物が切実に必要だった、あるいは今も必要だと思う。公平を期すなら、BakerもMozillaの継続するミッションについてブログに書いている。
https://blog.lizardwrangler.com/2023/03/31/a-quarter-century...
それでも市場シェアを伸ばし進化するには、もっと積極的で公開されたアプローチが必要に見える。
本人の無能のせいで実際に仕事を生み出している多くの人々を解雇することになった後、さらに200万ドルが必要だと判断した人物だ。
Chrome が Firefox にあれほど勝った理由について、標準的な答えが1つ、あるいはいくつかあるのか気になる
Chrome は、Firefox のタブ1つがブラウザ全体を固まらせていた時代に、タブごとのサンドボックス化をしていたと記憶しているが、それが平均的なユーザーにものすごい差をもたらしたのかは意外でもある。Firefox が記憶よりずっと頻繁にクラッシュしていたのかもしれないし、Chrome がリリース当時ずっと速かったのかもしれない。私は Firefox の UI を最小化して Vim 風にしてくれる拡張機能 Pentadactyl のために、2016年ごろまで Firefox を使っていて、それを維持するために LTS Firefox を動かしていた気がする。懐かしい。ニューヨークにいるからか、周囲には今年 Arc に移った人が多く、どこまで行くのか楽しみ
[1] https://en.wikipedia.org/wiki/Pentadactyl
オープンソースで、Google なしでも簡単に動かせて、Web 標準に従わなかったり独自標準を作ったりしていた Internet Explorer に対抗する巨人だった。そして本当に良かった。技術者たちが今のように Google と Chrome を見るようになるまでには、何年もかかった。Chrome リリース当時に HN で最も多く票を集めた投稿はこれ
https://news.ycombinator.com/item?id=291946
そのときは、乗り換えがかなり簡単で当然のことに感じられた
検索結果ページではなく、入力欄が1つだけある、あの空白の白いホームページだった。ちなみに、その枠が Google 製品以外に提供されたことは一度もない
私が Firefox を設定してあげた人たち、両親や非技術者の友人は、結局みな Chrome に乗り換えた。理由を聞くと「Google がそのほうが良いと言っていたから」と答えた
一般ユーザーを動かすうえでは、実際の利点と同じくらい、こうしたやり方が大きく影響したのだと思う
人々が XUL/XPCOM の喪失を惜しむ理由は理解できるが、それを Chrome をまねるためだったかのように言うのは誠実ではないように見える
それらの技術を取り除いたことで、マルチプロセスの Firefox が可能になり、安定性が強化された。ここや他の場所のコメントを見ると、むしろその変更が人々をブラウザに戻らせた要因の1つだった。WebExtensions を導入したり始めたりしたのも理にかなっていたと思う。Chrome がすでにあまりに大きな認知度を持っていたため、まったく新しいものを出すのが難しかったからだ
Chromium のテキスト選択の挙動は妙で鈍く、他のどこでも見たことがない方式なので、いつも Firefox、あるいはそれ以前は Opera Presto を好んでいた。これは Electron アプリを見分ける方法でもある。しかし Firefox は本当に遅く、XUL から離れることはそれを直す重要なステップだった。ただ、Firefox が「X のほうが人気があり、X が Y をしているのだから、私たちも Y をすべきだ」という罠に陥ったようには感じる。現在のユーザー層がいる理由は、まさに Y ではなく Z をしているからだという点を忘れたように見える。ただし、それは別の問題だ
私の場合も、同期的な拡張 API のせいで数秒ずつ固まることがあった。XPCOM の削除、マルチプロセスへの移行、非同期 WebExtensions への移行は、技術的に絶対に必要だった。今は性能が良い
Mozilla は WebExtensions の開発が始まった後、開発者に XUL 拡張をマルチプロセス対応にするよう求めた。Firefox 57 で XUL 拡張を無効化し、XUL はその後、段階的に削除された
示唆すらしていないし、このコメントを読んで眉が帽子を持ち上げるほど上がった。そんな考えは聞いたこともない。私がどこで、XUL の削除が Chrome をまねるためだったと書いたのか指摘してほしい