Jetpack/Roadmap-2011: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(initial version of updated roadmap with visibility through end of 2011)
Line 1: Line 1:
= '''Jetpack High-Level Product Roadmap''' =
{{draft|}}


Jetpack development comprises numerous releases of multiple products that achieve four major milestones, which this chart summarizes.
This document summarizes the Jetpack project's roadmap for 2011.


<table border="1" bgcolor="#ffffff">
= Priorities =
  <tr style="vertical-align: baseline;">
    <th></th>
    <th style="text-align: left; background-color: #9f9f9f;">[[Labs/Jetpack/Roadmap#Milestone_One|Milestone One]]</th>
    <th style="text-align: left; background-color: #cfcfcf;">[[Labs/Jetpack/Roadmap#Milestone_Two|Milestone Two]]</th>
    <th style="text-align: left;">[[Labs/Jetpack/Roadmap#Milestone_Three|Milestone Three]]</th>
    <th style="text-align: left;">[[Labs/Jetpack/Roadmap#Milestone_Four|Milestone Four]]</th>
    <th style="text-align: left;">[[Labs/Jetpack/Roadmap#Milestone_Four|Milestone Five]]</th>
  </tr>


  <tr style="vertical-align: baseline;">
Our top three priorities, in the order we will tackle them:
    <th></th>
    <th style="text-align: left; background-color: #9f9f9f;">Jetpack Prototype</th>
    <th style="text-align: left; background-color: #cfcfcf;">Jetpack SDK 0.1</th>
    <th style="text-align: left;">Jetpack SDK 0.2 - 1.0b</th>
    <th style="text-align: left;">Jetpack SDK 1.0</th>
    <th style="text-align: left;">Jetpack SDK Future</th>
  </tr>


  <tr style="vertical-align: baseline;">
# <p>Via Add-on SDK and Add-on Builder, ship a great platform for creating add-ons for desktop Firefox 4 (and up).</p><p>Doing this is the culmination of all the great work we have done to date, and it is the essential first step to everything else we hope to accomplish not only in 2011 but beyond. Nothing is more important to our project until this is done.</p><p>The Jetpack project will ship the initial versions of these products, and the add-on platform they provide, at our earliest possible opportunity.</p>
    <th>ETA</th>
# <p>Build tools, write docs, conduct outreach, and concoct strategies to help developers migrate traditional add-ons to the new platform in time for the e10sified version of Firefox.</p><p>If the Jetpack project is successful in achieving its foundational goals to bring in new developers, Mozilla will have many new add-on developers by the end of 2011. But we'll still have many developers of existing add-ons that will need to change their add-ons to work with the e10sified version of Firefox. And those add-ons will have millions of users who will still want to use them when they upgrade to that version of Firefox.</p><p>The Jetpack project will do everything in our power to make that transition as painless as possible.</p>
    <th style="text-align: left; background-color: #9f9f9f;">DONE, 2009 Q4</th>
# <p>Update and expand the platform to support the development of add-ons for Firefox on mobile devices.</p><p>Mozilla leaders recognized a number of years ago that the expanding web-using world population was switching from traditional computing devices to mobile ones, and Mozilla has put a ton of effort into evolving Gecko and Firefox into a great mobile browsing platform and product. Mozilla cares as much about user choice and personalization on mobile devices as it does on desktop ones, and our add-on efforts must reflect that.</p><p>The Jetpack project will help make add-on development a great experience for Firefox on mobile devices.</p>
    <th style="text-align: left; background-color: #cfcfcf;">DONE, 2010 Q1</th>
    <th style="text-align: left;">2010 Q2 - Q3</th>
    <th style="text-align: left;">2010 Q4</th>
    <th style="text-align: left;">2011 Q1</th>
  </tr>


  <tr style="vertical-align: baseline;">
    <th style="text-align: right;">Firefox</th>
    <td style="background-color: #9f9f9f;"></td>
    <td style="background-color: #cfcfcf;"></td>
    <td>Extension Manager no-restart API, transparent content iframes, addon bar</td>
    <td></td>
    <td>Support for Jetpack-native packages, Jetpack library in core?</td>
  </tr>


  <tr style="vertical-align: baseline;">
= Non-priorities =
    <th style="text-align: right;">Platform</th>
    <td style="background-color: #9f9f9f;"></td>
    <td style="background-color: #cfcfcf;"></td>
    <td>Chrome object wrappers, OOP Jetpack</td>
    <td></td>
    <td>ECMAScript 5?</td>
  </tr>


  <tr style="vertical-align: baseline;">
Three tasks to which we will not set ourselves in 2011:
    <th style="text-align: right;">AMO</th>
    <td style="background-color: #9f9f9f;"></td>
    <td style="background-color: #cfcfcf;"></td>
    <td>Stats on Jetpack-built extensions</td>
    <td></td>
    <td>Support for Jetpack-native packages</td>
  </tr>


  <tr style="vertical-align: baseline;">
# <p>Deep extensibility.</p><p>The traditional add-on platform, with features like XUL overlays and XPCOM components, was designed for deep extensibility. Indeed, you can do almost anything to Firefox with the traditional platform.</p><p>But the vast majority of existing and potential add-ons don't need this capability; the remainder can still be implemented using the traditional add-on platform; and projects like <a href="http://mozillalabs.com/chromeless">Mozilla Labs' Chromeless Browser experiment</a> are better positioned to explore a potential future replacement.</p><p>The Jetpack project will leave deep extensibility to the traditional add-on platform and Mozilla Labs experiments.</p>
    <th style="text-align: right;">Security</th>
# <p>Apps.</p><p>Mozilla, other browser vendors, and other industry participants are hard at work defining standards, UX affordances, and distribution channels for the next generation of web apps. But apps differ from add-ons, even if they sometimes bundle themselves as such for lack of better distribution channels.</p><p><a href="https://apps.mozillalabs.com/">Mozilla Labs' Open Web Applications project</a> is kicking ass here and is much better positioned to identify and address the exposure and distribution needs of apps, while Mozilla's developer tools team headed by Kevin Dangoor is the right locus for activity around tools for web developers.</p><p>The Jetpack project will not build tools for app development and distribution.</p>
    <td style="background-color: #9f9f9f;"></td>
# <p>Firefox-SDK integration.</p><p>The SDK and Builder bundle API implementations with each individual add-on. This strategy, akin to static linking for compiled code, has its downsides, but it allows the products and add-on platform to evolve independently of the Firefox release cycle, avoids <a href="http://en.wikipedia.org/wiki/Dependency_hell">dependency hell</a>, and makes it easier to architect and nurture a rich ecosystem of third-party APIs.</p><p>The Jetpack project will not land its API implementations in the Firefox tree and ship them with Firefox.</p>
    <td style="background-color: #cfcfcf;"></td>
    <td>Reduced-privilege security model</td>
    <td></td>
    <td>ES5-based API hardening?</td>
  </tr>


  <tr style="vertical-align: baseline;">
Note that the absence of a goal from the priorities list, or its presence on the anti-list, does not mean we won't accept code that achieves it. To the contrary, provided such contributions don't work at cross-purposes to the core goals of the project, we couldn't be more thrilled to see our technologies get used by the Mozilla and broader open source communities.
    <th style="text-align: right;">L10N</th>
 
    <td style="background-color: #9f9f9f;"></td>
So if you're a Thunderbird developer, a web dev tools hacker, a XULRunner appmeister, or anyone else who wants to see Add-on SDK and Builder (or their component parts) better support your own particular use cases (or get repurposed into your own new products), know that we want to see that too! So please don't hesitate to dream about how the project can help you, talk about your ideas with us, and make them happen.
    <td style="background-color: #cfcfcf;"></td>
    <td>web service</td>
    <td></td>
    <td>Jetpack-native APIs/tools</td>
  </tr>


  <tr style="vertical-align: baseline;">
    <th style="text-align: right;">API</th>
    <td style="background-color: #9f9f9f;">Prototypes and proposals of various APIs</td>
    <td style="background-color: #cfcfcf;"></td>
    <td>Implementation of robust library satisfying common add-on use-cases</td>
    <td>Stable core library, community  library collections</td>
    <td></td>
  </tr>


  <tr style="vertical-align: baseline;">
= Plan =
    <th style="text-align: right;">Dev Tools</th>
    <td style="background-color: #9f9f9f;">Bespin-based editor in extension</td>
    <td style="background-color: #cfcfcf;">Command line</td>
    <td>FlightDeck web-based IDE</td>
    <td>Firefox HUD console integration</td>
    <td></td>
  </tr>


  <tr style="vertical-align: baseline;">
In December 2010, we released Add-on SDK 1.0b1, and in January 2011 we released Add-on Builder 1.0a7.
    <th style="text-align: right;">Distribution</th>
    <td style="background-color: #9f9f9f;">Individual JS files</td>
    <td style="background-color: #cfcfcf;">XPIs w/embedded Jetpack runtime</td>
    <td></td>
    <td></td>
    <td>Jetpack-native packages (JPIs?)</td>
  </tr>


  <tr style="vertical-align: baseline;">
Until we reach Add-on SDK 1.0 final, we will continue development of beta versions of the SDK in four week cycles comprising three weeks of open development followed by a week of stabilization and release preparation.  After we reach Add-on SDK 1.0 final, we will continue development of the SDK with a roughly month-long cycle culminating in an alpha release, another culminating in a beta release, and a 1-2 month cycle culminating in a final release.
    <th style="text-align: right;">Documentation</th>
    <td style="background-color: #9f9f9f;"></td>
    <td style="background-color: #cfcfcf;">bundled with SDK</td>
    <td>bundled with Flightdeck</td>
    <td>MDC</td>
    <td></td>
  </tr>


</table>
We plan the following releases:


<!--
{| class="fullwidth-table"
 
|- style="background:#efefef"
TODO: commented out for now. Not aligning with specific releases. -dietrich
| 2011
 
| early Q2
== Milestone One ==
| mid Q3
 
| late Q4
The first milestone was a Mozilla Labs experiment that prototyped Jetpack's vision with a Firefox extension for installing, using, and managing Jetpack-based extensions; a set of high-level APIs for common extension use cases; a simple Bespin-based development environment for coding and testing extensions without having to restart Firefox; and easy distribution of Jetpack-based extensions via a basic software distribution website (the Jetpack Gallery) and developers' own websites.
|-
 
| Releases
The milestone was aligned with Firefox 3.5 and achieved in 2009 Q4 with the seventh release of the Firefox extension.
| SDK 1.0, Builder 1.0b1
 
| SDK 1.1, Builder 1.0
<small>[[Labs/Jetpack/Roadmap#High-Level_Product_Roadmap|< back to overview chart]]</small>
| SDK 1.2, Builder 1.1
 
|-
== Milestone Two ==
| Themes
 
| initial set of restartless, e10s-compatible APIs and tools for building add-ons for Firefox 4.0 on the desktop
The second milestone begins the incubation of the Jetpack for eventual integration into Firefox as a production-quality feature of the browser.
| tools, docs, etc. for migrating traditional add-ons to SDK/Builder
 
| support for building add-ons for Firefox on mobile devices
It is building a Jetpack SDK with a robust architecture designed to achieve Jetpack's quality, security, and user/developer experience goals; a command-line-based development environment for power developers on which a web-based IDE for casual developers can be built; and distribution of extensions to Firefox users via traditional extension packages (XPIs) and AMO.
|}
 
This milestone is aligned with Firefox 3.6, will be achieved with the initial release of the SDK (0.1), and is scheduled for 2010 Q1.
 
<small>[[Labs/Jetpack/Roadmap#High-Level_Product_Roadmap|< back to overview chart]]</small>
 
== Milestone Three ==
 
The third milestone continues Jetpack's incubation with a version of the Jetpack SDK that incorporates a reduced-privilege security model to limit the potential surface area of attacks; an l20n-based localization infrastructure that makes it easy to localize extensions and doesn't require developer effort to package/distribute them; a robust library of APIs for common extension use cases; a simple web-based IDE (FlightDeck) for extension development; and support for installing/uninstalling Jetpack-based extensions without restarting Firefox.
 
This milestone is aligned with a future Firefox release (3.6.x? 3.7?), will be achieved with releases of the SDK (1.0?), the IDE, and Firefox, and is scheduled for 2010 Q3/4.
 
<small>[[Labs/Jetpack/Roadmap#High-Level_Product_Roadmap|< back to overview chart]]</small>
 
== Milestone Four ==
 
The fourth milestone is the culmination of the project's incubation, resulting in a production-quality, stable and robust Jetpack API library that is integrated with Firefox; a Jetpack-native packaging format supported by both Firefox and AMO; and ECMAScript 5-based API security hardening to further protect against potential extension-based attacks.
 
This milestone is aligned with a future Firefox release (4.0?), will be achieved with that Firefox release, and is scheduled for 2011 Q1/2.
 
<small>[[Labs/Jetpack/Roadmap#High-Level_Product_Roadmap|< back to overview chart]]</small>
 
-->
 
= '''SDK Release Roadmap''' =
 
Included from [[Labs/Jetpack/SDK|Labs/Jetpack/SDK]]:
{{:Labs/Jetpack/SDK}}
 
= '''SDK 1.0 Goals''' =
 
* A carefully selected set of APIs that satisfies the common use cases of addons;
* A sublime user experience vastly superior to the traditional addon development model;
* A robust security infrastructure that restricts access to unnecessary privileges;
* The execution of addons in separate processes for performance and responsiveness;
* A coherent plan and process for maintaining API compatibility across multiple Firefox releases.
 
And how do we know when we satisfy the common use cases and are
providing a sublime user experience? One good metric is SDK usage
relative to usage of the traditional model, as evidenced by the ratio of
SDK-based vs. traditional addons being submitted to AMO. When a majority
of new addons are SDK-based (and perhaps even sooner), we'll have
certainly arrived.
NOTE: Some of these are already achieved by the move to the SDK approach, and some made obsolete/irrelevant. These goals need updating.
 
Previous 1.0 set, needs integration into above:
* '''A seamless install process''': It defeats the purpose of Jetpack to first require users to install Jetpack, then install a particular Jetpack, before using its features. Instead, we need a solution which allows a seamless install process.
* '''Seamless debugging''': No pointless error messages, and all relevant warnings, line numbers, and tracebacks, are displayed.
* '''Enabling API''': An API deep enough to support a large range of add-ons. It is a non-goal in 1.0 to support everything, instead it is to support 80% of the long-tail of add-ons. The exact feature set of the API will be determined by a set of target add-ons (TBD) and feedback from Jetpack authors.
** '''Frozen API''': Although the API may be versioned, we the API will be backwards compatible from 1.0 on.
* '''Beautiful by default''': A set of OS-specific icons, as well as a beautiful look for Jetpacks.
* '''Security-sensitive Import mechanism''': The strength of any API is measured in how easily 3rd parties can extend it. The 1.0 release will have a strong import mechanism, replete with security provisions.
* '''Security''': A functioning security system that mixes code with social protections.
** An AMO-like service with social code-review
* '''Localization story'''
* '''Works on Fennec'''

Revision as of 00:15, 21 January 2011

Draft-template-image.png THIS PAGE IS A WORKING DRAFT Pencil-emoji U270F-gray.png
The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly.
If you have any questions or ideas, please add them as a new topic on the discussion page.

This document summarizes the Jetpack project's roadmap for 2011.

Priorities

Our top three priorities, in the order we will tackle them:

  1. Via Add-on SDK and Add-on Builder, ship a great platform for creating add-ons for desktop Firefox 4 (and up).

    Doing this is the culmination of all the great work we have done to date, and it is the essential first step to everything else we hope to accomplish not only in 2011 but beyond. Nothing is more important to our project until this is done.

    The Jetpack project will ship the initial versions of these products, and the add-on platform they provide, at our earliest possible opportunity.

  2. Build tools, write docs, conduct outreach, and concoct strategies to help developers migrate traditional add-ons to the new platform in time for the e10sified version of Firefox.

    If the Jetpack project is successful in achieving its foundational goals to bring in new developers, Mozilla will have many new add-on developers by the end of 2011. But we'll still have many developers of existing add-ons that will need to change their add-ons to work with the e10sified version of Firefox. And those add-ons will have millions of users who will still want to use them when they upgrade to that version of Firefox.

    The Jetpack project will do everything in our power to make that transition as painless as possible.

  3. Update and expand the platform to support the development of add-ons for Firefox on mobile devices.

    Mozilla leaders recognized a number of years ago that the expanding web-using world population was switching from traditional computing devices to mobile ones, and Mozilla has put a ton of effort into evolving Gecko and Firefox into a great mobile browsing platform and product. Mozilla cares as much about user choice and personalization on mobile devices as it does on desktop ones, and our add-on efforts must reflect that.

    The Jetpack project will help make add-on development a great experience for Firefox on mobile devices.


Non-priorities

Three tasks to which we will not set ourselves in 2011:

  1. Deep extensibility.

    The traditional add-on platform, with features like XUL overlays and XPCOM components, was designed for deep extensibility. Indeed, you can do almost anything to Firefox with the traditional platform.

    But the vast majority of existing and potential add-ons don't need this capability; the remainder can still be implemented using the traditional add-on platform; and projects like <a href="http://mozillalabs.com/chromeless">Mozilla Labs' Chromeless Browser experiment</a> are better positioned to explore a potential future replacement.

    The Jetpack project will leave deep extensibility to the traditional add-on platform and Mozilla Labs experiments.

  2. Apps.

    Mozilla, other browser vendors, and other industry participants are hard at work defining standards, UX affordances, and distribution channels for the next generation of web apps. But apps differ from add-ons, even if they sometimes bundle themselves as such for lack of better distribution channels.

    <a href="https://apps.mozillalabs.com/">Mozilla Labs' Open Web Applications project</a> is kicking ass here and is much better positioned to identify and address the exposure and distribution needs of apps, while Mozilla's developer tools team headed by Kevin Dangoor is the right locus for activity around tools for web developers.

    The Jetpack project will not build tools for app development and distribution.

  3. Firefox-SDK integration.

    The SDK and Builder bundle API implementations with each individual add-on. This strategy, akin to static linking for compiled code, has its downsides, but it allows the products and add-on platform to evolve independently of the Firefox release cycle, avoids <a href="http://en.wikipedia.org/wiki/Dependency_hell">dependency hell</a>, and makes it easier to architect and nurture a rich ecosystem of third-party APIs.

    The Jetpack project will not land its API implementations in the Firefox tree and ship them with Firefox.

Note that the absence of a goal from the priorities list, or its presence on the anti-list, does not mean we won't accept code that achieves it. To the contrary, provided such contributions don't work at cross-purposes to the core goals of the project, we couldn't be more thrilled to see our technologies get used by the Mozilla and broader open source communities.

So if you're a Thunderbird developer, a web dev tools hacker, a XULRunner appmeister, or anyone else who wants to see Add-on SDK and Builder (or their component parts) better support your own particular use cases (or get repurposed into your own new products), know that we want to see that too! So please don't hesitate to dream about how the project can help you, talk about your ideas with us, and make them happen.


Plan

In December 2010, we released Add-on SDK 1.0b1, and in January 2011 we released Add-on Builder 1.0a7.

Until we reach Add-on SDK 1.0 final, we will continue development of beta versions of the SDK in four week cycles comprising three weeks of open development followed by a week of stabilization and release preparation. After we reach Add-on SDK 1.0 final, we will continue development of the SDK with a roughly month-long cycle culminating in an alpha release, another culminating in a beta release, and a 1-2 month cycle culminating in a final release.

We plan the following releases:

2011 early Q2 mid Q3 late Q4
Releases SDK 1.0, Builder 1.0b1 SDK 1.1, Builder 1.0 SDK 1.2, Builder 1.1
Themes initial set of restartless, e10s-compatible APIs and tools for building add-ons for Firefox 4.0 on the desktop tools, docs, etc. for migrating traditional add-ons to SDK/Builder support for building add-ons for Firefox on mobile devices