Mozilla Add-ons Community Blog
Categories: developers jetpack

Add-on SDK Roadmap Update!

7 responses

Its been quite a few months since we shared the greater vision for the Jetpack project and the Add-on SDK as a product. A lot has happened since then, including the release of Add-on SDK 1.0 and the growth of a team of talented people to keep the momentum going. Still, its always good to take some time, think about where we are going, and decide which parts are most important. So let’s do it!

You know, this is a roadmap… In my mind that means its *always* in draft form. We will always need to take a look at what things are important and how they should fit in to the ongoing work. So let’s make a deal and consider this thing dynamic and living – then we don’t have to worry about labeling it a draft.

The list of goals here are many and not easy and while we’ve grown the internal Mozilla Jetpack team, we still want and need contributions from you Rocketeers out there who are using the SDK on a regular basis and identify missing pieces or are just interested in helping out with some or all of these goals.

Keep in mind that we’ve always had the plan to keep the core of the Add-on SDK small and relatively conservative when it comes to features. What we would rather have is a large set of contributed, and shared, libraries to extend the functionality for add-on developers. This opens up a far more extensive set of tools and a better community for anyone who wishes to create an add-on, and frankly, just feels like the Mozilla way!

Let’s reset for a minute

The Jetpack project has always had the goal to make extensions easy to develop, and easy to install. While it started out as an experiment in 2009, we soon did a rewrite and moved on to product development while graduating the project from the Mozilla Labs in 2010. With the release of Add-on SDK 1.0 we have made a set of APIs that allow for the majority of add-on use-cases to be developed easily and with open web tools (html, css, & javascript). In addition, as they are restartless by default, add-ons developed with the Add-on SDK are definitely easy to install. To be sure, the Add-on SDK is no longer a prototype or experiment but the tasks ahead of us, while filling in holes in some cases, will be every bit as challenging as the initial creation of this project. We can’t say that the Add-on SDK is the answer for all of your add-on development needs yet, but we want to get there. For that, we want your help!

The Priorities

So lets get to it. Many people may have noticed lately that the Mozilla project has done a bit of shifting to make sure we are answering the changing landscape of browsing and computing. To that end, we have to focus more on emerging mobile devices and how people want to use these devices. We Rocketeers have to make sure we are also making that shift. This means that our support of mobile has to be at the top of our list. Keep in mind that just because a feature didn’t make it to the top of the list, doesn’t mean it won’t get done before some of the top items. Its hard for people to focus solely on one thing for a long time, and some of the other items (or pieces of the other items) are easier to develop and test than the top priorities. Nonetheless, I expect that you will see a great deal of movement on these higher priority items even though they are the more complicated tasks.

The Mozilla Products team has also been hard at work on new set of processes and tools to help explain new features and why we want them. The new “Feature Pages” are being used by the Jetpack team so for any of the priorities listed below you can click on the link to the Feature Page for it and see more detail and what the latest plans are with them.

By the way, any time you want to check on the latest changes to the Roadmap, you can always look here: https://wiki.mozilla.org/Jetpack/Roadmap

Top Priorities

Our top priorities for the second half of 2011 into 2012 are:

1) Support Firefox Mobile. As we now all understand, the web experience is moving towards smaller devices, we have to make sure that any developer creating an add-on via Jetpack will find that their add-on just works in mobile. Mozilla cares as much about user choice and personalization on mobile devices as it does on the desktop, Jetpack must reflect that with no work from end-user developers.

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

2) Enable jetpack to always create add-ons that take advantage of Electrolysis (e10s) to run in a separate process. Running an add-on in a separate process is important for users and the add-on developer as it makes it much easier to determine if an add-on is affecting the browser’s performance. In addition, there may be some security enhancement as its much harder to exploit a vulnerability if its being run in a separate process. For Jetpack, we want to ensure that our users never even have to think about e10s or how to use it for their add-ons to run in a separate process.

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

In addition, we also need to ensure that for the elements the Add-on SDK exposes that need to run in particular processes that are *not* the add-on process, they are doing so (again, without any worry from the add-on developer). We recognized that these two bits are related pieces of work despite the orthogonal approach we plan to take in developing them. Nonetheless, a new feature page is being developed for supporting the other processes we need to support.

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

3) Add-on Localization API and Service. Its important that Jetpack no longer lingers behind in the the world-wide reach Mozilla has worked hard to obtain. We must have a localization solution that allows our developers to get localized add-ons with minimal effort on their part. Add-on localization in the SDK comprises a simple, high-level API for specifying the strings to localize, a localization service to which add-ons distributed by addons.mozilla.org (AMO) are automatically submitted for localization, a web application through which localizers can localize add-ons, and automatic repackaging of AMO-distributed add-ons with new and updated localizations.

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

Secondary Priorities

1) Create a path for developers using the traditional tools to move to jetpack. If we are successful in bringing in new developers to creating add-ons for Firefox, we must not forget the developers who have been using the traditional toolset. With the inclusion of features such as e10s and mobile, it becomes imperative that we offer the easiest methods possible to create add-ons that work with these new technologies and platforms. We see Jetpack as being a great path for our current add-on developers to start taking advantage of these new features – as long as we can make the porting equally simple. This work may include creating tools which will automatically help developers port their existing add-ons, as well as a good set of documentation and examples to help them understand the differences in approach.

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

2) Simplify the Add-on SDK. While Jetpack is a simple development tool to use as compared to the traditional add-ons tools Mozilla has offered, we have to recognize that simplicity opens the door for more participation. With more participation comes a greater democracy of ideas and implementations – all of which can benefit the open web. Simplifying Jetpack even more is a high priority because it is one and the same with Mozilla’s mission.

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

3) Add-on SDK: The missing pieces. There are several notable Firefox features we do not yet support. These would be simple APIs to offer support for:

  • 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) Add-on SDK as an Add-on. We currently ship the Add-on SDK as a zip file or source code through github. This may not be the best way for us to distribute the SDK. First, we have a built-in automated update mechanism with addons.mozilla.org which also provides support for stable and beta distribution channels. Second, if we can get the SDK to package itself we have a chance for SDK developers to “eat their own dogfood” – testing the packaging and performance everyday. Finally, possibly building upon the original prototype as well as Alexandre Poirot’s work of porting the SDK to an add-on we can start to offload some of the Builder’s time-consuming functions to the client while also avoiding difficult dependencies for Add-on SDK users.

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

5) Add-on SDK Debugging. Debugging has come a long way since the old style of dumping errors to printf. However, Add-on SDK users might notice… we dump to printf! There are many debugging additions we can make to the SDK, especially if we take a cue from our awesome web dev tools team. Some of these items could include:

  • introspection
  • profiling
  • setting breakpoints
  • stepping through code

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

6) Make Add-on SDK Hug the Web Harder. Jetpack has done a great job in embracing open web technologies to create a robust development toolset. However, developing an add-on is still more different from developing a web page than it has to be. We need to make sure we are supporting the most common and useful elements of web development to ensure the platform is as inclusive as it can be.

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

Non-Goals

If you still have a copy of the last roadmap around you might notice that the non-goals are pretty much the same. Keep in mind though, that just because we have these items listed as non-goals for this roadmap doesn’t mean they can’t become goals at some future date. Its just important to remind ourselves of the constraints of which our current development needs to fit in to. To that end, here are the things we are not trying to accomplish:

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 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. Having said that, its important to remember that deep extensibility is possible with the SDK; it just requires you to dive under the covers of our supported APIs.

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. The Mozilla Open Web Apps team 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 has worked for us so far through the 1.0 release and is still a good plan for our needs. Having said that, there is a good deal of ongoing discussion about integrating with firefox we are taking part in with the community. At this point, it is still too early to include any steps on this roadmap related to any of the conclusions coming from these discussions so it will still be listed as a Non-goal.

Recently, as a part of the conversations around integration and the development and distribution of the Add-on SDK, the Jetpack team Tech Lead, Myk Melez, wrote up his thoughts on why the Add-on SDK doesn’t land in Mozilla-central: http://mykzilla.blogspot.com/2011/08/why-add-on-sdk-doesnt-land-in-mozilla.html

Development Plan

The Jetpack team decided during the 1.0 release that we would move our development to a train cycle that closely follows the Firefox development cycle. This was done mostly for maintenance reasons, which allow us to keep up with the new versions of Firefox. This will ensure that developers can have their add-ons rebuilt automatically on the Add-on Builder or addons.mozilla.org to work with the new versions of the browser. In addition, we will be working on our top three priorities with an outlook of 3 to 6 months for each item. Our version numbers will only increase by dots until we land major changes or breaking changes. This will be done to make sure that people recognize that there is something important to recognize with the release. More information about our development plan can be found here: https://wiki.mozilla.org/Jetpack/Development_Process

7 comments on “Add-on SDK Roadmap Update!”

  1. Bradley Rosenfeld wrote on

    A better, more user friendly way of handling settings is at the top of my list. But it is great to see what the team is envisioning and I see a lot of stuff on there that I would love to see.

    1. Dave Mason wrote on

      Hi Bradley, I’m glad you like the direction we’re on!

      For what you need, the “Prefs API” is in the “Missing Pieces” portion, and despite it being “P2”, it is already being worked on and, I think, pretty close to being done.

  2. Matěj Cepl wrote on

    * Add-on SDK for Thunderbird?

    * Stability, stability, stability. However:
    – is there some hope for revival of CommonJS effort? Is Add-on SDK 100% compliant with at least current standards?
    – is there some work on harmonization of Add-on SDK with Chrome/Safari similar APIs? If Mozilla is for the Open Web than it shouldn’t lock in developers to its own platform, right? (Of course, what others less non-profit motivated think about this is probably a different question)

  3. Anon wrote on

    What about reducing the jetpack SDK related leaks (bug 646575), memory bloat due to excessive use of compartments (bug 672443) and general poor level of code quality?

    I hate to be the party pooper in all this, but even as an outsider, I’m already aware of several core devs opinions that the SDK development process and general code quality is sub-par.

    We don’t need a repeat of the current non-jetpack addon situation where mem usage and performance goes downhill and yet users still blame Firefox itself.

    I sincerely hope the suggestions of the MemShrink team are taken on board sooner rather than later.

    Kind regards,

    A concerned volunteer contributor.

  4. jonas wrote on

    I like how jetpack simplified the addon process, a couple of years ago I felt intimidated with the complexity of the process. Although jetpack is a great tool for developers there are other lacks and scarcity, over all when you look at opera and chrome, with their development mode addon loading, and restartless testing.

  5. Tony Mechelynck wrote on

    After Firefox (done) and Fennec (planned), what about Thunderbird and SeaMonkey? Or will they forever enjoy only classical addons, and the few restartless ones which are not Jetpacks?

  6. Dave Mason wrote on

    I’ll try to answer a few comments with one response here, let me know if I don’t! First of all, this Roadmap is all about the direction we want to take right now and the feature priority which will start us down that path. As I said in the beginning, it is a dynamic document which will always change over time (as things get done and new priorities emerge). One thing that isn’t on here that is *always* a priority is stabilization. We take bug fixing very seriously and are working hard to make the Add-on SDK stable, lightweight, and the best it can be (And yes, following the standards we can follow like CommonJS). In fact, the 1.1 release presents us with the “problem” of trying to figure out what to tell people is new about it – its almost all stabilization work.

    As to Thunderbird, most of us are users of it and would also love to see the Add-on SDK work with it as well. However, development starts with prioritization and its just not the most needed area to cover right now. That does not mean that it never will be! The exercise of defining non-goals is all about defining scope, not about saying “never” – it also does not mean that we won’t accept code that achieves it!

    Speaking of which, I love seeing users and contributors following with interest – We want and need more! If you feel like we are failing in some way, don’t be shy to tell us, and to contribute code or useful information to us. We’ll even take the anonymous contributions, if that’s your thing.