イギリスのコンピュータ雑誌PC Proが、オンライン版でMike Connor氏に対する独占インタビューを掲載している。"Mozilla reveals plans for Firefox 3.2"という記事で、2月10日付けだ。
記事の主眼は、Firefox 3.2にMozilla Labsの研究成果が取り込まれる予定だというもので、『Firefox 3.2を補強する三つの柱』で紹介した内容と重複する。しかし、それを除いても三点の重要なポイントが見られた。
重要な三点とは、1)Ubiquityの統合方法、2)メモリ管理モデルの変更、3)Firefox 3.2のリリース時期である。順番に検討していこう。
Ubiquityの統合方法
記事によれば、Connor氏は、MozillaがUbiquityをロケーションバーに統合することを目指していると述べたようだ。Ubiquityのコア機能をFirefoxに組み込むと明らかになったときから予想されたこととはいえ、Connor氏のブログ記事では明言されていなかったところであり、確定させた点に意味がある。
Ubiquityをロケーションバーに統合するプラン自体は、『UbiquityはFirefoxの一部となれるか』で既に紹介した。複数のデザイン案が提示されているが、どれも一長一短ある。Ubiquityの長所を生かしつつ、自然な形でFirefoxのUIに溶け込ませるのは容易ではない。Ubiquity開発者のAza Raskin氏が発表するであろう続報を待ちたい。
なお、Connor氏は、Ubiquityを統合することにした理由として、Firefoxの次期バージョンでは、速度の向上といった漸進的な改良ではなく、もっと純粋なイノベーションを求めていたこと、Ubiquity自体に対する反響が大きかったことを挙げている。
メモリ管理モデルの変更
Firefox 3.1は、IE8やGoogle Chromeと違い、「タブごとに独立したプロセスを割り当てる手法」を採用しない。が、主要開発者の一部に採用を検討すべきとの声のあることは以前紹介した（『Development Meeting 2009-01-27』）。
記事によれば、Connor氏は、Firefox 3.2でもこの手法を採用しないと明言した。理由は、タブごとに生じるメモリのオーバーヘッドが、累積すると無視できない量になるからである。「メモリを共有するほうが効率的だ」とConnor氏はいう。
しかし、同時に、ドメインごとにプロセスを割り当てる可能性を示唆した。たとえば、Gmailのタブはすべて一つのプロセスで走らせるといった形だ。Connor氏の影響力を考慮すれば、この示唆は重要である。
Firefox 3.2のリリース時期
さすがに、リリース時期についてはConnor氏も明言を避けている。だが、「次のリリースはFirefox 4ではないと思う」としている。現在、次のリリースを年内に出すか、それとも翌年の春に回すかを決めようとしているところだという。
ここでおさらいしておこう。『Firefox 3.1のリリース時期』で説明したとおり、Firefox 3.1はもともと5〜9か月のスパンで開発される「マイナーリリース」の予定だった。TraceMonkeyやプライベート・ブラウジング・モードなどの新機能が後から追加され、実際には開発期間が延びてしまったが、計画では、通常一年以上開発にかかるメジャーリリースよりも短い期間でリリースするものだったのである。
もし、Firefox 3.2のリリース時期が翌年の春になるとすると、開発期間は丸一年となり、メジャーリリースに近い扱いとなる。しかし、一年の間にその扱いに見合うだけの機能を追加できるかというと、それも難しい。なぜなら、Firefox 3.1に多くの新機能を投入したことで、ハードルが上がってしまったからだ。実装予定の機能を増やせば、不確定要素も増える。一年の予定がさらに伸びることも大いにありうる。
とすれば、Firefox 3.2は、追加する機能を少なくする一方、開発期間も短くするのが現実的ではないだろうか。3.1が4月中にリリースされるとして、3.2を年末にもってくるのはスケジュールとして妥当なところだ。
この見解に立った場合、メジャーリリースであるFirefox 4の開発をどうするのかという問題が残る。あまり大きな変更を加えずにバージョンアップしていくスタイルは、リリース時期の管理には便利だが、イノベーションを妨げるデメリットもある。
対策の一つとして、どこかの時点でTrunkを複線化することが考えられよう。マイナーリリースを開発するためのTrunkと、メジャーリリースを開発するためのTrunkを分け、後者にはかなり実験的なパッチの投入も認めることにすれば、Firefoxの進化を止めることもないはずだ。もちろん、管理コストは相当かかるが、Mozillaはそれに耐えるだけのリソースを備えつつある。潤沢な資金を人材と設備に回せば充分に実現可能と考えるが、どうだろうか。
