Jetpack/Roadmap/2013
 |
Jetpack 2013 Roadmap | |
| Owner: Jeff Griffiths | Updated: 2013-07-29 | |
| The Roadmap for Jetpack in 2013. | ||
|
THIS PAGE IS A WORKING DRAFT | 
|
| 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. |
2013 Jetpack Roadmap
The State of Jetpack
By any measure, 2012 was a great year for Jetpack. We saw increasing adoption of Jetpack with 1000+ add-ons on AMO and climbing, and several SDK-based add-ons gathering thousands and in one case millions of users. We also saw major partners such as Yahoo, Springpad and 1Password ship SDK-based add-ons successfully. We grew the team and the contributor base somewhat, and we also delivered on all of our releases on time.
If you look at the 2012 roadmap, there are a number of hits and misses, and some of the misses are copied forward into the 2013 Roadmap because we believe they are still valid ideas for the product. It is also worth looking at the hits, as some of the 2012 achievments directly inform our direction in 2013.
Needed Enhancements
- localization support.
- mobile support is nearly complete.
- simple-prefs.
- major enhancements to page-mod.
Re-architecture
- re-organization of the SDK tree to better fit with the Firefox codebase.
- the CommonJS loader and Promise module shipped with Firefox 16.
- numerous improvements and additions to the low-level implementation of the SDK in particular to improve the extensibility of the SDK's apis.
- re-implementation of the cfx tool's packaging functionality in JS.
Stabilization
- we worked closely with the Memshrink project to significantly improve memory usage and performance issues.
- we responded quickly to bugs in release versions with point releases.
The Roadmap
In 2012 we worked hard towards two notable goals: cfx in JS & landing the SDK apis in Firefox. These goals are long-term and we expect to reap the benefits in 2013 by removing the complexity and friction involved in developing with the SDK on the desktop, and also reducing the complexity of the Add-on Builder web application.
Top Priorities
These are the top priorities for the team in 2013.
Note: As this is a living document, when these priorities change we will update here.
-
Land the SDK's apis in Firefox -
support per-window private browsing in Firefox 20 ( see bug 748604 ) -
Ensure Builder works for add-on developers in the medium term. - Awesome Developer tools for add-on developers (for example: debugging)
- Rapid development of Firefox features as add-ons
- UX Work: [Features/Jetpack/Addons_In_Toolbar|Widgets on top] Tracking bug.
SDK API Development
When we provide a new high-level api in the SDK, that api must provide a clear benefit to the add-on develop in terms of ease of use while still not impacting Firefox performance.
-
Places API. [DONE] Tracking Bug Bookmarks and history are probably the most interesting stores of data in Firefox and in particular the most interesting to users. Providing performant and usable apis to access this data easily could enable all manner of browser / user innovations. - Awesomebar API. The awesomebar is *the* primary piece of browser UI, used more than anything else. As experiments like Bryan Clarke's searchspot add-on have shown us, it can be very powerful to inject custom results into the awesomebar.
Persistent Goals
There are goals we shall strive to achieve in the Jetpack project that may or may not be explicitly written in this Roadmap or in our Quarterly goals. However, these things will always be goals for the project and any products which we create:
Performance
We must always measure our preformance and be thoughtful of how the Add-on SDK affects the performance of Firefox.
Footprint
We should try to make sure that everything we create is as small as it can be while still providing the functionality we think is necessary.
Security
We must ensure the security of all our users and make sure that we are consistently reviewing, with the help of security experts, our code to be as secure as we can make it.
Simplicity
We should strive to provide the simplest structure to our APIs and tools to make sure the Jetpack experience is easy to use. In addition we should keep the codebase clean and simple to ease and encourage contributions.
Memory Consumption
We should strive to keep memory consumption of an add-on built with our high-level APIs as small as possible.
Stability
We will strive to make the Add-on SDK as stable as possible and respond to issues as quickly as possible to make sure that users can trust the SDK for their development.
