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
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
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.
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.
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.
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.
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.
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.
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
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.
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:
- setting breakpoints
- stepping through code
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.
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
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