Mozilla Flux

Mozilla関係の情報に特化したブログです。

Mozillaが反ChromeのスタンスでFirefoxのマーケティングキャンペーンを展開へ

新キャンペーンの開始

Mozillaは、米国時間の2017年5月24日、"browse against the machine"と銘打ったFirefoxのマーケティングキャンペーンを開始した。Mozilla Corp.でDirector of Product Marketing, Firefoxを務めるEric Petitt氏が"Browse Against the Machine"というブログ記事で明らかにしたところによれば、このキャンペーンは、明確に反Chromeのスタンスを採用する。

キャンペーンの名称は、Rage Against the Machineというアメリカのロックバンドの名前をもじったもののようだが、最近のGoogleが機械学習に力を入れていることを踏まえているとみられる。ここでいう"the machine"はChrome=Googleの象徴であり、ユーザーを呑み込もうとする圧倒的な存在を想起させる。これに対抗しようと呼びかける形なので、訳しづらいが、あえて意訳すれば「歯車にならないためのブラウズをしよう」といったところか。

Petitt氏は、Webを支配する強大な封建領主にGoogleを喩えたうえ、Chromeは世界最大の広告会社であるGoogleにとって「8レーンの高速道路」だと主張する。つまり広告収益を最大化するための媒体というわけだ。これに対し、FirefoxにはChromeにない以下の5つの長所があるという。

  • FirefoxはChromeよりもメモリ使用量が少ない。
  • FirefoxはChromeのように特定のエコシステムに依存していない。
  • Firefoxはユーザーにデータとプラバシーに関する最大限のコントロールを付与するが、Chromeにはそれができない。
  • Firefoxは世界最大の広告会社によって同社のために作られたものではない。
  • Firefoxは非営利のMozillaによって作られており、Mozillaのミッションは企業の力を部分的に制約して健全なWebを保つことである。

また、こうしたキャンペーンを展開する背景事情として、Firefoxの性能が1年前と比べても強化されていることや、MozillaがGoogleに頼らずに健全な財務状況を維持できていることがあるとしている。

批判と擁護

Petitt氏の上記ブログ記事は賛否両論を巻き起こした。批判の焦点は、Firefoxを持ち上げるためにChromeを貶めることの妥当性にある。互いの性能を比較するのは競争のうちだが、相手のブラウザの前提から批判するとなればこれは喧嘩に近い。マーケティングのやり方を間違っているのではないか、という意見が出るのももっともだろう。

しかし、Mozillaはスタンスを改める気はないようだ。その証拠に、Vice President of Firefox Productを務めるNick Nguyen氏が、"Jumping over guardrails"なる記事を書いてPetitt氏を擁護している。Nguyen氏いわく、Googleは理想に満ちた会社で優秀な人材も揃っているが、営利企業としてユーザーの幸せと収入の増加を均衡させねばならない。これはビジネスの周りをガードレールで囲われた状態に喩えられる。だが、Mozillaはそうしたガードレールを跳び越えて、ユーザーの幸せを追求できる。歯車にならないためのブラウズをすることは、現在の選択の自由だけでなく、将来において選択するための自由に価値を見出すことなのだ、と。

他方、かつてMozilla Corp.のCTOを務めたAndreas Gal氏は、違う角度からの批判を行っている。"Chrome won"と題する記事の中で、Gal氏は反Chromeのキャンペーン自体が無意味だと論じている。Firefoxが存在感を示せているのはデスクトップだけだが、Webにおけるデスクトップは既に過去のものだし、ブラウザがコモディティ化して差別化が困難な中で、圧倒的なシェアを持つChromeに反撃する機会は残されていない、というのがその理由だ。

諸刃の剣

MozillaがFirefoxに価値を担わせる形のマーケティングを展開するのは、今回が初めてではない。今から2年半前、"Choose Independent"キャンペーンでは、Firefoxを選ぶことは、単にブラウザを選ぶだけでなく、個人の自由に賛意を示すとともにオンライン上の自立性を明るく輝かせ続けるための手段でもある、というメッセージが発信された。

このキャンペーンについて、筆者は「ブラウザが価値を担うということ」と題する記事で次のように論じた。

Internet ExplorerがWebで圧倒的なシェアを誇っていた時代、ほかのブラウザを選べること自体が、ユーザーにとっての自由だった。そして、ほかのブラウザを選ぶにあたって、いちいち動機を問われることはなかった。もちろん、ユーザーの中にはWebの自由を体現するものだと考えてFirefoxを選んだ人もいただろうが、多くは、シンプルで使いやすいとか、アドオンが魅力的だといった理由でFirefoxを選んでいたのではないか。

選択肢があるという状況自体が自由を意味し、ユーザーがさまざまな動機でFirefoxを選んでいることは、現在においても何ら変わりがない。にもかかわらず、Firefoxを選ぶことに価値を結びつけるとすれば、排他的な対外的イメージを生じることにならないだろうか。

考えてみてほしい。たとえば、Internet ExplorerやChromeやSafariを、標準でインストールされているという理由で使い続け、あるいは自らダウンロードして選ぶことは、それだけで不自由と依存を選んだことになるのだろうか。Android OSやChromiumの開発に外部から貢献したら、Googleの支配に手を貸したことになるのだろうか。もちろん、Mozillaがそのような極論を述べているわけではないが、Firefoxを選ぶことが自由と自立を選ぶことになると位置づければ、必然的に別の選択(不作為を含む)にネガティブな意味を付与することになる。

そうして生じた排他的なイメージは、キャンペーンの意図に反して、ユーザーを遠ざけることになりかねない。だからこそ、Mozillaコミュニティが価値を担い、そのような価値を実現する目的でFirefoxを開発する一方で、Firefox自体は価値中立的なソフトウェアであり続けるという役割分担が重要になってくる。

前回のキャンペーンは、Firefoxのシェアが低下したため、現に選ばれているという「事実」を提示できず、性能において競合ブラウザを凌いでいるという「機能」を提示することも難しいという状況に対応して出てきたものだといえる。それでも、Firefoxにポジティブな「価値」を結びつけるところでとどまっていた。

だが、今回のキャンペーンはChromeにネガティブな「価値」を付与しようとしている。しかも、マーケティング部門のトップが批判されて撤回するどころか、逆に重役クラスが出てきて擁護しているあたり、腹をくくっている感じがする。

Mozillaがそこまでするのは、デスクトップブラウザの市場が成熟し伸びが見込めない状況にあって、Firefoxがシェアを回復するにはChromeから奪い返すほかに手段がないからだろう。その意味で、Mozillaの認識はAndreas Gal氏の認識と部分的に重なる。違うのは、ブラウザの差別化が可能かどうかという点だ。もちろん、Mozillaは可能という立場だ。

はっきり言って、このキャンペーンは賭けである。成功すればFirefoxのシェアを回復できるかもしれないが、失敗すればMozillaのイメージダウンを招くだけで終わってしまうだろう。筆者の意見は、2年半前と変わらない。やはり、Mozillaコミュニティが価値を担い、Firefox自体は価値中立性を保つ形にとどめておくほうが賢明ではないだろうか。

(17/09/18追記)
以下のツイートは、Mozillaが米国で展開しているとみられるキャンペーンの1つを撮影したもの。Firefoxの利用を呼びかける看板に、大きく"BIG BROWSER IS WATCHING."の一文が記され、BROWSERの部分がChromeのアイコンの色で塗り分けられている。要するに、Chromeをジョージ・オーウェルの小説『1984年』に登場する独裁者ビッグ・ブラザー(Big Brother)になぞらえているわけだ。

Firefox 57でUI刷新を目指すPhotonプロジェクト

約3年半ぶりの刷新

Firefox 57はMozillaがFirefoxの大改造を予定しているバージョンであり、ユーザーインターフェイス(UI)もその例外ではない。現在のデスクトップ版UIは2014年4月、Firefox 29のリリース時に導入されたもので、Australisのコードネームで呼ばれる。2017年11月にリリース予定のFirefox 57では、Photon(光子)のコードネームが付いた新UIが披露され、約3年半ぶりにUIが刷新されることになる。

Photonプロジェクトの存在が明らかにされたのは、2016年12月下旬。本格的な始動は2017年3月下旬ころだ。判明しているだけでも15人のエンジニアと7人のUXデザイナが関与しており、現在ではさらに増えているとみられる。

この大プロジェクトの初期段階のデザインをスクープしたのが、オーストラリアオーストリアのsoeren-hentzschel.atである。早くも3月22日には"Firefox 57: Erste Vorschau auf das neue Firefox-Design (Photon)"という記事をドイツ語で発表し、その後も最新のモックアップを基にした記事を次々に物している。これを追いかけてgHacksが英語で記事を書いているのが現状だ。

もっとも、最初のほうこそ少しばかり秘密主義をとっていたPhotonプロジェクトも、最近はモックアップをオープンにするなど、状況が変わってきた。本記事ではPhotonプロジェクトの概要を簡単に紹介し、新UIについても見ていく。

f:id:Rockridge:20170515210238p:plain

6つのサブプロジェクト

Photonプロジェクト(Bug 1346488)は6つのサブプロジェクトに分かれており、対応するチームが存在する。各チームの開発状況はFirefox/Photon/Updates - MozillaWikiに掲載され、随時更新される。また、各チームの意見交換のためPhoton-devというメーリングリストが存在し、そのアーカイブは誰でも閲覧することができる。

6つのサブプロジェクトとは、標準テーマを刷新するVisual Redesign、起動から終了までの体感パフォーマンスを向上させるPerformance、メニュー・ツールバー・パネルの構造に手を加えるStructure、アニメーション処理を改良するAnimation、インストール直後の起動時におけるユーザー体験を改善するOnboarding、設定画面のカテゴリーと項目を再編成するPreferenceである。

この中で、Preferenceだけは本格的な成果が前倒しで投入される可能性がある。設定画面がリニューアルされる時期は、今のところFirefox 55だ。ただ、デザインを見直してFirefox 56以降に投入すべきとの意見も有力であり、上記の時期は確定ではない。

また、Australisのときとは異なり、Photonプロジェクトにおいて開発ブランチは設けられていない。これは、プロジェクトの成果が直ちにNightlyチャンネルに投入されることを意味する。初期設定では無効化されるとしても、Firefox Nightlyのユーザーはいち早くPhotonの内容に触れられるわけだ。

それどころか、最近の開発動向からすると、Photonの取り組みの一部はFirefox 55のリリース版にも投入されるようだ。たとえば、ツールバーアイコンが全面的にPNG形式からSVG形式に移行し、タブの移動・変更時のアニメーションが新しくなり戻る・進むボタン再読込・停止ボタンがロケーションバーから切り離される。

新UIのデザイン

ここからは新UIのデザインについて見ていく。現在公開されているものはWindows版を前提にしており、macOS版やLinux版では若干スタイルが異なりうる。また、言うまでもないが、モックアップなので最終的なデザインにおいては修正が加えられる可能性が高い。

新UIでは、画面上部中央にロケーションバーが置かれ、検索ボックスはなくなる。戻る・進むなどのボタン類はバーの左側にまとめられ、バー内にはブックマーク用のスターボタンとアクションメニューを呼びだす3点リーダのようなボタンがあるだけだ。バーの右側にツールバーボタンが並び、右端にハンバーガーメニューがあるのはこれまでどおりである。

f:id:Rockridge:20170515221040p:plain

標準のテーマではタブ列が暗くなっているが、別のテーマ(LightとDark)に切り替えることもできる。しかも、PhotonではUIの「密度」を調節できる。密度は通常・コンパクト・タッチの3つから選択し、タッチにするとタブバー・ツールバー領域が広がり、コンパクトにするとコンテンツ領域が広がる。テーマの種類やUIの密度はカスタマイズ画面から変更可能だ。

メニュー画面は文字が中心でアイコンが脇役になっており、情報量が格段に増えた。他方、サブメニューや履歴とブックマークの管理画面、ブックマーク追加時のパネルなどは従来のデザインをほぼ踏襲しており、一番目立つ部分を重点的に変えているようだ。

f:id:Rockridge:20170515223304p:plain
f:id:Rockridge:20170515223353p:plain

ライブラリボタンもメニューを呼びだす仕組みになっている。ブックマーク、履歴、ダウンロードなどのサブメニューに移行すると、より詳しいメニュー項目が出てくる。

f:id:Rockridge:20170515225323p:plain
f:id:Rockridge:20170515225609p:plain

サイドバーを呼び出すボタンもある。サイドバーでは表示する内容(ブックマーク、履歴など)を切り替えられるほか、表示する位置(右側か左側か)を変更することもできる。なお、初期設定でサイドバーは右端に表示される。

f:id:Rockridge:20170515230238p:plain
f:id:Rockridge:20170515230302p:plain

これらのアイコンに関し、ツールバーに常時表示される数には限りがあるようで、いわば「溢れた」アイコンを収納するメニューもある。

f:id:Rockridge:20170516072430p:plain

ロケーションバーから呼び出すアクションメニューには、ページのブックマーク追加と並んで「Pocketに保存」という項目があるのが目につく。「URLのコピー」があるのもライトユーザーにとって嬉しい配慮だ。また、SNSへのシェア機能も充実している。メニュー内にスクリーンショットという項目があるのは、Firefox 55でTest Pilot掲載のPage Shot⁩が統合されるのを踏まえたもので、「スクショ」をSNSでシェアしやすいようにしている。

f:id:Rockridge:20170516072916p:plain
f:id:Rockridge:20170516072937p:plain

以上のデザインに不満を覚えた場合、ユーザーはカスタマイズ画面から修正を行うことができる。画面には現行のデザインであればメニューパネルに配置されるアイコンが多数並んでおり、Photon UIではこれらをツールバーに置くことになる。初期設定では表示されない検索ボックスもここから復活させられる。そのうえ、ロケーションバーが中央の位置にあることさえ、空白のスペースで挟まれていることによるものだから、これらの空白を外せばバーの位置を動かせるのだ。

f:id:Rockridge:20170516074527p:plain

コンテンツ領域に目を向けると、スタートページが刷新されている。Test Pilot掲載のActivity Stream⁩が統合されるためだ。新規タブも同様とみられる。モックアップには「トップサイト」とPocketからのおすすめ記事が表示されているが、おそらく過去のブラウジング履歴に基づく「ハイライト」も加わるはずだ。

f:id:Rockridge:20170515223237p:plain

そのほか、セッション復元、ネットワークエラー、ライセンス表示など、特殊な画面も新しいものが用意される。

f:id:Rockridge:20170516081258p:plain

Project Tofinoの影響

ロケーションバーを中央に配置してシェア機能を組み込むこと、戻る・進むなどのボタン類をバーの左側に固めて配置すること、タブのデザインを四角くすること。こういったPhotonの特徴は、Project Tofinoが遺したもの - Mozilla Fluxで紹介した、Tofinoの成果であるコンセプトUIを受け継いでいる。一方、同じくコンセプトUIにあったOverview(概要)タブや「ナビゲーションバー」などは採用されていない。

f:id:Rockridge:20161218203649p:plain

Project Tofinoの影響は限定的だったとの評価もありうるが、Photonが明確にFirefox 57をターゲットにしていることを考慮すると、現行のデザインから無理なく変更できる部分をまず採り入れたとの見方もできそうだ。別の言い方をすれば、現在明らかにされているのはPhoton v1という通過点に過ぎず、2018年のPhoton v2でTofinoのコンセプトUIにより近づいていくのではないか。

Mozilla HacksのWebAssembly連載記事の和訳が開始 続編に期待(追記あり)

Firefox 52で有効化された新機能の1つにWebAssemblyがある。WebAssembly のコンセプト - WebAssembly | MDNの冒頭では、その内容を次のように説明している。

WebAssembly はモダンなウェブブラウザで動作して新たな機能と大幅なパフォーマンス向上を提供する新しい種類のコードです。基本的に直接記述ではなく、C、C++、Rust 等の低水準の言語にとって効果的なコンパイル対象となるように設計されています。

この機能はウェブプラットフォームにとって大きな意味を持ちます — ウェブ上で動作するクライアントアプリで従来は実現できなかった、ネイティブ水準の速度で複数の言語で記述されたコードをウェブ上で動作させる方法を提供します。

それ以上に、その利点を享受するために利用者は WebAssembly のコードをどのように作成するのか知る必要さえ有りません。 WebAssembly モジュールはウェブ (あるいは Node.js) アプリにインポートする事ができ、WebAssembly の機能は JavaScript を経由して他の領域から利用できる状態になります。JavaScript 製フレームワークでは大幅なパフォーマンス改善と開発中の新機能をウェブ開発者が容易に利用できるようにするために WebAssembly を用いることができます。

上記コンセプト記事内には、他にも「WebAssemblyの目標」、「WebAssemblyはどのようにウェブプラットフォームに適合するのか?」、「WebAssemblyをどのようにアプリで用いるか?」といった項目が立てられ、WebAssemblyの概要が的確にまとめられている。ただ、このテーマに関する情報を以前から追いかけてきたならともかく、ふつうのWeb開発者がこの記事を読むと、もう少し背景について掘り下げてほしいと感じるのではないか。

そうした要望に応えるように、2017年2月末、WebAssemblyの概略を紹介する連載記事がMozilla Hacksに掲載された。その内容は充実しており、わかりやすい。だが、6本ある記事はいずれも英語で書かれており、これまで国内でもWebを高速にするアセンブラ技術の今と将来 | マイナビニュースFirefox, Chrome, SafariがCSS Gridに一斉対応ほか──2017年2月と3月のブラウザ関連ニュース | HTML5Experts.jpで言及されたものの、反響は大きくなかった。

広く読まれるためには、やはり和訳が必要だ。とはいえ、内容が内容だけに、正確な和訳には英語力に加えて相当量の知識が求められる。記事が掲載されてから2か月近くが経過しても動きが見られず、このまま話題に上らなくなってしまうのかと思われた。

そこへ颯爽と登場したのが、WebAssembly の漫画での紹介 | Mozilla Developer Street (modest)である。GWに掲載されたこの記事は、連載の第1弾である"A cartoon intro to WebAssembly"を、T.Ukegawa氏が和訳したもの。連載の中ではいわば導入部分にあたり、WebAssemblyがブラウザで有効化されることによって、2008年にJITコンパイラが登場して以来、久々にJavaScriptのパフォーマンスが大きく向上するフェーズに入るとする。

たぶん今後も連載記事が和訳されていくはずだ。そう信じて、以下、残る5つの記事のさわりだけ紹介しておく。

連載の第2弾は、"A crash course in just-in-time (JIT) compilers"である。WebAssemblyの前史であるJavaScriptインタープリタとJITコンパイラのおさらいから始め、コンパイラによる最適化処理の内容をかいつまんで教えてくれる。その際、stubやbailing outといった概念に触れている点も評価できる。

連載の第3弾となる"A crash course in assembly"でも、まだWebAssembly自体は出てこない。機械語とアセンブラ、さらに中間表現(IR)について、図を交えながら説明している。

連載の第4弾、"Creating and working with WebAssembly modules"に至って、話は一挙に核心に迫る。LLVM(コンパイラ基盤)のIRからWebAssemblyへの変換や、コードの動作、モジュールの構造など扱う内容は多岐にわたり、読み応えがある。

連載の第5弾、"What makes WebAssembly fast?"は、WebAssemblyの速度に焦点を当てる。通常のJavaScriptよりも高速に処理される理由を、Fetching・Parsing・Compiling + optimizing・Reoptimizing・Executing・Garbage collectionの各場面に分けて解説している。第4弾および第5弾のディープな内容は、第3弾までの丁寧な説明があってこそだろう。

連載の最後を飾る第6弾が"Where is WebAssembly now and what’s next?"。WebAssemblyは2017年2月28日にブラウザプレビューの段階を脱し、大手ブラウザはそろって有効化に向けて動いた。今後、パフォーマンスの面ではJavaScriptとの間のファンクションコールを高速化し、WebAssembly自体の読み込み速度や実行速度も改善していく。また、仕様の面ではDOMを直接操作可能にし、並列処理を進め、例外処理のハンドリングを行えるようにする。

(17/05/13追記)
連載第2弾の和訳として、ジャスト・イン・タイム (JIT) コンパイラの短期集中コース | Mozilla Developer Street (modest)が公開されている。

(17/05/22追記)
連載第3弾の和訳として、WebAssembly の短期集中コース | Mozilla Developer Street (modest)が公開されている。

(17/10/02追記)
連載第4弾の和訳として、WebAssembly モジュールの作成と操作 | Mozilla Developer Street (modest)が、連載第5弾の和訳として、WebAssembly を速くするには? | Mozilla Developer Street (modest)が、それぞれ公開されている。

(17/10/19追記)
連載第6弾の和訳として、WebAssembly は今どこにあり、次に何があるのか | Mozilla Developer Street (modest)が公開され、シリーズが完結した。翻訳者に対し、惜しみない賛辞を送りたい。

マルチプロセス化の完全実施に先行してFirefox 54で多プロセス化を開始

Firefox 48でマルチプロセス機能(e10s)が導入され、Firefox 50から52にかけて、RTL言語ロケールやタッチスクリーン環境でも順次e10sが有効化されるようになった。また、拡張機能をインストールしている環境でも、WebExtensionsベースのもの(Firefox 49以降)やe10s互換性のあるもの(Firefox 50以降)については、有効化を妨げないようになった。若干予想外な出来事として、Firefox 51で追加された拡張機能のホワイトリストがその後撤回され、Windows版でアクセシビリティツールが動作している場合はFirefox 55まで有効化が延期されるといったことがあったものの、2017年4月3日(米国時間)時点で、リリース版ユーザーの52.82%がe10s有効化に至っている。

こうした状況を踏まえ、MozillaはFirefoxの多プロセス化を実行に移す。その中心はcontentプロセスの複数化(e10s-multi)だ。最近までFirefox 55がそのターゲットとされていたが、Firefox 54に前倒しされる可能性が高くなってきた。

2017年1月下旬にFirefox Nightly 54で2つのcontentプロセスが(Bug 1303113)、3月中旬にFirefox Nightly 55で4つのcontentプロセスが(Bug 1336398)、それぞれ有効化され、4月上旬にはFirefox Aurora 54でも4つのcontentプロセスが有効化された(Bug 1304546)。この流れはロードマップどおりであり、あとはBeta版でのテストを経るのみとなっている。

Mozillaがe10s-multiにおいてcontentプロセスを4つまで増やす背景には、省メモリ化の進歩がある。Are they slim yet, round 2 – Eric Rahmによれば、2016年2月から1年余りの間にデスクトップ版の各プラットフォームで、多プロセス化した場合の消費メモリが顕著に低下したという。1年前にcontentプロセス×1で消費したメモリ量は、現在のWindows版だとcontentプロセス×2に相当し、macOS版に至ってはcontentプロセス×4に相当する。Chromeとの比較でも優位に立っていて、特にWindows版/Linux版では差が大きい。

f:id:Rockridge:20170430221823p:plain

e10s-multi以外の多プロセス化については、mozilla.dev.platformのAll the processesスレッドにまとめられている。既にWindows版ではGPUプロセスの導入が始まっており、今後はWebExtensionsベースの拡張機能PDFium/Pepper API版Flashのほか、Service workerも独立したプロセスの対象となっていく。

以上のように多プロセス化が展開される一方、その基礎となるe10s有効化は完全実施の時期がFirefox 57まで延期された。当初はFirefox 53で実現する予定だったが、拡張機能のe10s対応がMozillaの想定していた以上に進まなかった。

Firefox 56まで、拡張機能をインストールしている環境では、すべてがWebExtensionsベースまたはe10s互換性ありになっていない限り、e10sは有効にならない。そのため、古い拡張機能を使い続けている場合、Firefox 57にアップデートした時点でその拡張機能が動作しなくなるばかりか、本体がいきなりe10s-multiの状態になる。一部では混乱もありそうだ。

(17/06/13追記)
Firefox 54正式版のリリースに伴いcontentプロセスの複数化(e10s-multi)が有効になるのは、「e10sが有効かつアドオンをインストールしていないユーザー」の80%にとどまる(Bug 1367244)。Mozillaは、次のFirefox 55では「e10sが有効かつ従来型アドオンをインストールしていないユーザー」全員を対象にe10s-multiを有効化しようとしている

Firefox Developer Editionは早期Beta版として存続 未署名のアドオンも引き続き利用可能

速報:Firefox 55でDeveloper Editionの廃止が決定 - Mozilla Fluxを公開してから3週間が過ぎた。この間、Mozillaのリリースマネージメントチームが"Dawn project or the end of Aurora"(以下「公式アナウンス」)でAuroraチャンネルの廃止を正式に発表した。ところが、実は公式アナウンスの後も計画が変更されている。本記事執筆時点の最新情報をお伝えしよう。

Auroraチャンネル廃止の影響範囲とスケジュール

Auroraチャンネルの廃止は、Firefoxデスクトップ版のみならずAndroid版も対象となっている。だが、Google Playはアプリの作成者がユーザーを別のアプリに引き継がせることを認めていない。そこで、MozillaはFirefox Aurora for DevelopersアプリをNightlyビルドのアプリに置き換える予定だ。

また、ThunderbirdSeaMonkeyでもFirefoxのAuroraチャンネル廃止と同様の措置が執られる。これによりEarlybirdも終了となる。

Firefoxの新しいスケジュール(米国時間。以下同じ)は以下の公式画像が見やすい。ただ、RapidRelease/Calendar - MozillaWikiによるとFirefox 56のリリース時期は2017年9月26日となっている。公式画像は古いスケジュールのまま作ってしまったようだ。

f:id:Rockridge:20170422203145p:plain

Firefox Developer EditionはBeta版の派生ビルドへ移行

Mozillaは、Auroraチャンネルの廃止後もFirefox Developer Editionの提供を続ける。これまでと違うのは、Firefox Beta版をベースにする点だ。従来通り独立したブランドとしてMozillaのWebサイトで公開されるほか、従来のユーザーにはBeta版をベースにした新Developer Editionが自動アップデートで提供される(Bug 1353825)。この際、Developer Edition用のプロファイルは維持され、設定やテーマだけでなくショートカットも変更されることはない。

新Developer Editionは、通常Beta版と同様に概ね週2回のアップデート間隔になる。もっとも、アップデートの設定上は「早期Beta」と呼ばれて区別され、NightlyからBetaへの移行時、まずは新Developer Editionのユーザーが対象になるという差がある。ここで問題が見つかった機能は無効化されて、通常Beta版ユーザーに提供される。おそらく、他にも新機能を実験的に有効化するなど、新Developer Editionだけに適用される措置があるだろう。

公式アナウンスが出たのは2017年4月17日だが、この時点で新Developer Editionは通常Beta版のrepackつまりカスタマイズ版になるはずだった。Mozillaは提携企業がFirefoxのカスタマイズ版を作成できるようにしているが、この機能を利用していわば公式カスタマイズ版となる新Developer Editionを作成し、作業に要する時間やコストを抑えようとしたのだ。

しかし、この方法ではmacOS版において問題が発生することがわかった。Developer Editionのアイコンやアプリケーション名が変更されてしまうのだ。検討の結果、Auroraチャンネルの廃止によって浮いたリソースを流用し、Betaチャンネルのコードを基にDeveloper Editionビルドが作成されることになった(4月21日決定)。この方法だと自動化テストも必要になるため、カスタマイズ版よりも作業時間やコストは大幅に増える。

ユーザーにとって大きいのは、Beta版のカスタマイズではなく独自ビルドとなったことで、従来のDeveloper Editionと同様に、Mozilla Add-ons(AMO)のデジタル署名が付いていないアドオンを引き続き利用できるという部分だろう。副作用としてリリース候補版相当のアップデートが受け取れなくなるが、早期Beta版の位置付けからすればほとんど問題にならない。

ローカライズはNightlyチャンネルでの作業がメインに

Auroraチャンネルが廃止されると、Firefoxのローカライズ作業は必然的にNightlyチャンネルがその中心となる。では、Nightlyからリリースまでの期間が6~8週間も短縮されることに、どう対処していくのか。

1つの回答が、cross-channelの導入である。すなわち、Nightly用・Beta版用・リリース版用に分かれているローカライズ向けリポジトリを一本化する。そうすることで作業の重複を省き、新規投入・修正される文字列の翻訳に集中することができるわけだ。Mozilla Corp.でローカライズ担当エンジニアを務めるFrancesco Lodolo氏によれば、Auroraチャンネルの廃止時期が予期せず前倒しになったため、cross-channelを直ちに導入することはできないものの、Nightly 56への切り替えには何とか間に合わせるという。

もう1つの回答が、2017年後半に予定されるL20nの導入である。L20nはローカライズ・国際化に関する新しいフレームワークであり、これがFirefoxに実装されると、FTL構文を用いることで翻訳担当者の作業が容易になるだけでなく、Firefox本体のリリースから独立したローカライズ部分のアップデート(「翻訳のライブアップデート」と呼ばれる)も可能になる。要するに、リリース直前に文字列の修正などがあって翻訳作業が間に合わない場合でも、後から翻訳されたものに差し替えられるようになるのだ。

トップダウンの決定?

Auroraチャンネルの廃止が判明してから3週間の動きを見ていると、Mozillaの準備不足が目につく。過去に類似の計画が実現できずに終わっているにもかかわらず、リリースマネージメントの担当者らは実施方法の細部を詰めていなかったし、実施時期についてローカライズ担当者らとの調整も行っていなかった。しかも、Auroraチャンネル廃止の狙いであったはずのビルド作業・テストの省力化は、Developer Editionビルドの作成を決めた時点で実現できなくなったわけだが、そのことで揉めた様子もない。これらのことから、筆者は今回の廃止がトップダウンによるものではないかと疑っている。

Nightlyからリリースまでの期間が短くなれば、ユーザーは最新の機能を従来よりも早く手元で使うことができる。同じことを開発者サイドから眺めてみると、QuantumプロジェクトのようにFirefox 57で一定の成果を示すといった形で締切りが決まっている場合、より締切りに近い時期まで開発作業を続けることが可能になる。ユーザーの得になるうえ6~8週間の開発期間が捻出できるとなれば、Firefox開発の責任者としては多少の無理を押してでも実行に移そうとするのではないか。外部からは知るよしもないが、Senior Vice President, FirefoxのMark Mayo氏か、Vice President, Product, FirefoxのNick Nguyen氏のコメントを聞いてみたいものだ。

(17/06/13追記)
米国時間の5月26日ころに Firefox 54 Beta 11ベースのDeveloper Editionのインストーラが公開され、6月1日には既存のDeveloper Editionユーザーに対しBeta 12ベースのアップデートの配信が開始された