アドオンSDKのロードマップの更新

私たちがJetpackプロジェクトのさらなるバージョンとアドオンSDKを一つのプロダクトとしてシェアしてから、既に数ヶ月が経ってしまいました。才能豊かなチームメンバーが増えその推進力も維持されるなど、その時点から多くの出来事がありました。それには、アドオンSDK1.0のリリースを含みます。いつもの通り、私たちがどこに向かっているか、そしてどの部分が重要なのかを決めるために、少しばかり時間を取るのがよいようです。それでは、始めましょう。

皆さんがご存知のように、これは私の頭に描かれた常にドラフトを意味するロードマップです。私たちは、どんな事柄が重要で、いかにチームが進行中の作業に落とし込むべきかを振り返るために常に必要となるでしょう。そこで、私たちは取引きをして、このダイナミックでかつ息づいているロードマップを検討していきましょう。決して、これをただのドラフトと名づける心配をする必要はありません。

ここで目標のリストがたくさんあり、かつまた容易ではないので、私たちは内部でMozillaのJetpackチームを成長させてきた一方で、私たちはこのSDKを使う人たち、そして、欠けているピースを見つけ、あるいはこれらの目標のいくつか、あるいは全てを手伝ってくれることに興味のある方、つまり皆さんロケッターからの貢献を必要とし、また欲しているのです。

気に留めていただきたいのは、私たちが常にアドオンSDKのコアを小さく維持する計画を持っており、さらに機能を追加したときでも比較的保守的に進めたいのです。一方で、アドオン開発者にたくさんの機能を提供するために、貢献いただき共有するライブラリーは大きな集合となっています。このことは、さらに拡張可能なツールの集合をオープン化し、アドオンを作成しようと思う人ならば誰に対しても、より良いコミュニティを提供することになります。そしてまたこれは、親しみやすくまさにMozilla ウェイと感じるべきものです。

ここでリセットをかけましょう

Jetpackプロジェクトは、常に、開発しやすい拡張を作ることがその目標とされてきました。2009年において一つの実験として開始された一方で、私たちはすぐにそれを書き直して、プロダクト開発に移行したのです。その間、チームは2010年中にMozillaラボから卒業しました。アドオン SDK 1.0のリリースと共に、私たちは主要なアドオンのユースケースを開発しやすくする為のAPIの集合を定めました。そこではオープンなWebツールつまり htmlやcss、javascriptと協調するようになっています。さらには、それらのAPIはデフォルトで再起動が要らないものとして、アドオン SDKを使って開発されたアドオンは間違いなくインストールがしやすいものとなります。このことを確かにするため、アドオンSDKはもやはプロトタイプでもなく、実験でもありませんが、しかしながら私たちの前にある作業は、いくつかのケースで穴を塞がなければならず、一つ一つのステップにおいてこのプロジェクトの初期の創造としてチャレンジングなものとなるでしょう。私たちはアドオンSDKはあなた方アドオン開発者の全ての方への解答となるとはまだ言えないのです。しかし、私たちはそれを目指しています。そのために、みなさんの協力を求めているのです。

優先順位

それでは、それを得ることにしましょう。ブラウジングとコンピューティングの風景を変える結果になったと私たちが答えられるように、多くの方が後に、このMozillaプロジェクトがビットのシフトを起こしたというかもしれません。その結末には、私たちは近年盛り上がりを見せているモバイル端末に、そして人々がそれらの端末をどのように使いたがっているかに、フォーカスしなくてはなりません。私たち「ロケッターズ」は、私たちがこのシフトを可能に出来るようにしてやらなければなりません。このことは、私たちのモバイルに対するサポートが、私たちの目標リストのトップに来ることをを示しています。心に留めておいていただきたいのは、将来リストのトップにそれをするのではなく、トップの項目のいくつかの前になされるべきであるという意味でもありません。長期間にわたって人々を一つのことに集中させるのは難しいことですし、そのほかの項目のいくつかは、優先度がトップというよりも開発やテストが容易だということもあるのです。それでもなお、私はみなさんがこの高い優先度の項目に、その作業がさらに複雑さを増すことになっても、その中に大きなムーブメント理解してくださることを期待しているのです。

Mozillaのプロダクトチームは、新しい機能を導入する新しいプロセスとツールの集合に取り組んでいます。それはなぜなのでしょうか。下記にリストされる全ての優先順位に対して、この新しいJetpackチームによって使われている新機能のページが使われています。新機能のページについて知るには、リンクをクリックして、さらに詳しく見ることができます。そして、それに対する最新の計画を見ることが出来ます。

ところで、このロードマップへの最新の変更についてチェックしたいときにはいつでも、あなたは次のページを見ることができます。https://wiki.mozilla.org/Jetpack/Roadmap

優先順位の首位

私たちの2011年下半期から2012年への優先順位トップは、

1) Firefoxモバイルのサポート。私たちが今のところ理解している限りにおいては、Webの利用はより小さいデバイスに移動しています。そこで、私たちはJetpackを通じてアドオンを開発しようとする全ての開発者に、彼らのアドオンがモバイルでもそのまま動くことを保証しなければなりません。 Mozillaは、ユーザーの選択とパーソナル化についてデバイスがデスクトップにあったときと同じように、モバイル端末においてもケアしていくつもりです。そのため、Jetpackはエンドユーザーの開発者から特別に作業の必要がないように反映しなければなりません。

https://wiki.mozilla.org/Features/Jetpack/SDK_Support_for_Firefox_for_Mobile_Addons

2) 別々のプロセス上で実行するための「Electrolysis(e10s)」の有利さをアドオンを作成する際には常に享受できるようにJetpackをしておかなければなりません。別々のプロセス上でアドオンを実行することは、ユーザーにとって重要ですし、アドオン開発者はアドオンがブラウザーの性能に影響するかどうかを見極めることを容易にすることになります。付け加えて言うならば、別々のプロセスでアドオンを動かせば、脆弱性を攻撃することが難しくなりセキュリティ面も機能向上が見込めます。Jetpackに対し、私たちはユーザーがe10sについて考えないようにすること、また、別のプロセス上でアドオンを実行することに対しどのように使えばいいかを考えないようにすることを重要視しています。

https://wiki.mozilla.org/Features/Jetpack/Out-of-Process_Addons

さらに、私たちはアドオンSDKが特定のプロセスがアドオンのプロセスとならないように実行できるようにする要素を必要としています。アドオン開発者がいかなる心配をしなくてよいように、そのようにされるのです。私たちが開発を計額している二つの直行したアプローチの関連した部分が二つに分かれていることを認識していました。それでもなお、私たちがサポートを必要としている別のプロセスをサポートするため、新機能ページは開発されました。

https://wiki.mozilla.org/Features/Jetpack/Browser-e10s-Support

3) アドオンローカライゼーションAPIとサービス。Mozillaが獲得するのが難しかった全世界に到達する背後では、もはやJetpackがぐずぐずしてはならないのは重要です。私たちは開発者たちにローカライズされたアドオンを作れるようにするために、彼らの努力を最小限のするためのローカライゼーションのソリューションを持たなければなりません。SDKにおけるアドオンのローカライズは、ローカライズするための文字列を記述するためのシンプルでハイレベルのAPIや、addons.mozilla.org(AMO)が自動的にローカライズのために申請されたアドオンを配信するためのローカライズサービス、ローカライズ担当者がアドオンをローカライズすることができ、そして新しい更新されたローカライズ版をAMOを使って配信されるアドオンの自動的な再パッケージのためのWebアプリケーションから構成されます。

https://wiki.mozilla.org/Features/Jetpack/Add-on_SDK_Localization_API_and_Service

優先順位二位

1) 開発者に従来のツールからJetpackへ移行してもらうための道筋を作ること。もし新しい開発者たちにFirefoxのアドオン制作を提供することに成功したとして、私たちは従来のツール類を使ってきた開発者を忘れることは出来ないでしょう。e10sやモバイルのような機能を含んだ上で、それらの新しいテクノロジーやプラットフォームと共にうまく動くアドオンの制作をもっとも容易な手法を提案することが求められるのです。私たちはJetpackが、単純に移植することができるという意味で私たちの現在のアドオン開発者たちにがこれらの新しい機能のアドバンテージを生かすための有効な方法だと考えています。彼らの既存のアドオンに対し彼らを自動的に助けるという意味においてこの作業はツールの作成を含むかもしれません。同様に、彼らが入り口としてこれまでの方法との違いの理解を容易にするために、よい文書とサンプルが含まれます。

https://wiki.mozilla.org/Features/Jetpack/Traditional_Addon_Conversion_to_SDK_Platform

2) アドオンSDKのシンプル化。JetpackはMozillaが提供してきた従来のアドオンツールに比較して、シンプルな開発ツールである一方、私たちはさらなる開発者の参加のためにドアを開け放っておくことを認識しておかなければなりません。さらに開発者の参加が増えれば、より民主的なアイディアや実装に繋がるのです。それらのすべてがオープンなWebに利益をもたらすことができるのです。さらなるJetpackのシンプル化は、Mozillaの使命に共通しているものである以上、非常に優先度が高いのです。

https://wiki.mozilla.org/Features/Jetpack/Simplify_the_Add-on_SDK

3) アドオンSDKの欠けている部分。現在まだサポートしていないFirefoxの機能がいくつか残っています。これらはサポートを提供すべき単純なAPIとなるでしょう。

Prefs API
Places API
Sidebar API
Add-on Tab API
Tab Groups API

minimal XPIs
packed XPIs
add-on testing without browser restart

https://wiki.mozilla.org/Features/Jetpack/Add-on_SDK:_the_Missing_Pieces

4) アドオンとしてのアドオンSDK。私たちは、現在、アドオンSDKをzipファイル、もしくはgithubを通したソースコードの形態で出荷しています。このことは、私たちがこのSDKを配布する方法として最良ではないかもしれません。第1に、私たちはaddons.mozilla.orgを使って安定的かつベータ版としての配布チャネルに対するサポートを提供し、ビルトインされた自動的な更新機構を持っているのです。第2に、私たちはSDK開発者たちに「ドッグフードを食べる」ように SDKをパッケージするすることが出来れば、パッケージの確認や性能のテストを毎日行うことができます。最後に、Alexandre Poirot氏がSDKをアドオン化した移植作業と同様、オリジナルのプロトタイプを作ることになれば、私たちはアドオンSDKユーザーが、難しい依存関係を避ける一方でユーザーに対し、ビルダーの時間レジューム機能のいくらかを減らすことができるようになります。

https://wiki.mozilla.org/Features/Jetpack/Add-on_SDK_as_an_Addon

5) アドオンSDKのデバッグ。デバッグ作業は、printfのための古いスタイルのエラーダンプに沿って行われています。しかしながら、アドオンユーザーは、私たちがprintfにダンプしていることに気づいているかもしれません。SDKに作りこむことができる多くのデバッグ機能があります。特に、私たちのすばらしいWeb開発ツールチームから、ひとつきっかけをうる事が出来れば。それらの項目には、下記のようなものがあります。

内部観察機能
プロファイリング
ブレークポイント設定
コードの順次実行

https://wiki.mozilla.org/Features/Jetpack/Add-on_SDK_Debugging

6) アドオンSDKをWebにもっと近づけること。JetpackはオープンなWebテクノロジーを使って、堅牢な開発ツールを作成するために多くの作業がなされてきました。しかしながら、アドオンを開発することは、いまだWebページを開発するのとはだいぶ違っています。私たちは、プラットフォームを可能な限り包括的なものとすべく、Web開発と共通して、かつまた役に立つ要素をサポートしていく必要があります。

https://wiki.mozilla.org/Features/Jetpack/Make_Add-on_SDK_Hug_the_Web_Harder

目標ではないもの

もしあなたが、以前のロードマップのコピーをまだ手元にいれば、この「目標ではないもの」はほとんど同じであることに気づくでしょう。ただ心に留めておいていただきたいのは、このロードマップにおいて、これら「目標ではないもの」にリストアップされた項目が、しばらく先の将来において目標にはならないということを意味しているのではありません。私たちの現在の開発がそれらに向けての制約を記憶にとどめることが重要なのです。その終わりには、私たちが達成しなくても良い事柄が残ることになります。

1. 拡張性を深めること。従来のアドオンプラットフォーム、つまりXULオーバーレイやXPCOMコンポーネントといった機能は、深い拡張性のために設計されました。実際、あなたは従来のプラットフォームを使えば、Firefoxにほぼ何でも行うことが出来るのです。しかし、既存の、そして潜在的なアドオンの大半はこのような機能を必要としません。このリマインダーは、従来のアドオンプラットフォームを使うことによって、いまだに実装することができるのです。そしてプロジェクトは、潜在的に未来における置き換えを探求すべく、より良い位置に置かれます。Jetpackプロジェクトは、従来のアドオンプラットフォームやMozillaラボの実験に向かって、さらに拡張性を深めていくでしょう。そうはいっても、このSDKによって、拡張性を深めることが可能であることを思い出すことが重要なのです。あなた方は私たちがサポートしているAPIの領域の下へ、深く潜ることが要求されます。

2. アプリケーション。Mozillaやそのほかのブラウザーベンダー、あるいは業界の参加者は、標準の策定や、UX品質、次世代のWebアプリケーションの配布チャンネルといった作業に精力的に取り組んでいます。しかし、アドオンに比べてアプリケーションは、それらがよりベターな配布チャンネルを持っていないために、ときにはバンドルされることもあります。Kevin Dangoorに率いられたMozillaの開発ツールチームがWeb開発者のためのツール周辺の作業に正しい位置を見出しているのに対して、 MozillaのオープンWebアプリケーションチームは、奮起してアプリケーションを公開するための場所を確保し、よりよい位置を決めなくてならないのです。Jetpackプロジェクトは、アプリケーション開発と配布のためのツールを構築することはしません。

3. FirefoxとSDKの統合。SDKとビルダーは、個々のアドオンと共にAPIの実装をバンドルしています。この戦略は、私たちが1.0のリリースを通した限りにおいてはうまく機能し、私たちのニーズに対してはよい計画でありました。そうは言っても、Firefoxとの統合については、議論が進んでいるところで良い話し合いを持っています。この点では、この議論から導きだされるいかなる結論に関しても、このロードマップになんらかのステップを含めるのは早すぎるので、この統合に関しては「目標ではないもの」に挙げることにしました。

最近になって、アドオンSDKの開発と配布に関する議論の一部として、アドオンSDKがMozillaの中央部に置かれないのかという点について、Jetpackチームの技術リードであるMyk Melez氏が彼の考えを述べています。 http://mykzilla.blogspot.com/2011/08/why-add-on-sdk-doesnt-land-in-mozilla.html

開発計画

1.0のリリースを通じて、Jetpackチームは、Firefox開発サイクルに密接に続くサイクルに、Jetpackの開発を移行することに決めました。これは主に、メンテナンスについての理由によって行われました。というのも、私たちはFirefoxの新しいバージョンに追随していくためです。これによって、アドオン開発者たちは彼らのアドオンをアドオン・ビルダーの上で、自動的にリビルドすることができるようなり、Firefoxの新しいバージョンと共にaddons.mozilla.orgを機能させることができます。付け加えるならば、私たちは優先順位3位までを各項目に対し、3ヶ月から6ヶ月の見通しを持って作業することができるでしょう。私たちのバージョン番号は、私たちがメジャーな変更か変更を断ち切るまでは、ドットによって増えていくのみとなるでしょう。このことは、人々がそのリリースに認識すべき重要なことがあるのだと理解させるために必要なのです。開発計画について詳しい情報は、以下のURLをご覧ください。https://wiki.mozilla.org/Jetpack/Development_Process

出典: http://blog.mozilla.com/addons/2011/08/12/add-on-sdk-roadmap-update/

ChangeLog:

2011-8-18, skoufugata translated EN to JA as the 1st draft.