{"id":2221,"date":"2011-01-20T16:49:38","date_gmt":"2011-01-21T00:49:38","guid":{"rendered":"http:\/\/blog.mozilla.org\/addons\/?p=2221"},"modified":"2011-01-20T16:49:38","modified_gmt":"2011-01-21T00:49:38","slug":"the-jetpack-2011-roadmap","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/addons\/2011\/01\/20\/the-jetpack-2011-roadmap\/","title":{"rendered":"The Jetpack 2011 Roadmap"},"content":{"rendered":"

“I solemnly swear that I am up to no good!”<\/strong><\/p>\n

It’s been almost a year since Mozilla decided to build a team to productize the Jetpack project’s vision and technologies, and the team recently shipped the first beta release of Add-on SDK 1.0, so it’s a good time to review and update our roadmap for the next year of development. The roadmap described in detail in this blog post (and summarized on the Jetpack roadmap page<\/a>) is the current draft, not the final version. Your feedback via comments on this post or in the discussion group thread<\/a> is welcome!<\/p>\n

Why We Need a Roadmap<\/strong><\/p>\n

Projects like Jetpack with lofty goals are easy to imagine as panaceas for a variety of problems faced by a number of constituencies. But a small team like Jetpack’s cannot possibly meet all such expectations. So it’s important to be deliberate and explicit about what we are doing (and aren’t doing) and why.<\/p>\n

A Brief History of Jetpack<\/strong><\/p>\n

The Jetpack project was conceived around four years ago, around the same time Mozilla started the Personas project, as a way to do for extensions what Personas was doing for themes: make them much easier to both develop and install, in order to attract many new participants to the processes of building and using them.<\/p>\n

And throughout both its experimental (spring 2009 to winter 2010) and product development (winter 2010 onwards) phases, our primary focus has largely remained on this mission of bringing new add-on developers into the fold.<\/p>\n

That’s why we’ve spent so much time designing and implementing high-level APIs that use common web technologies like HTML, JavaScript and CSS to make frequent add-on tasks easier; spent months incorporating forwards-compatibility with the anticipated future sea-change to a multi-process browser (i.e. Electrolysis<\/a>, a.k.a. e10s); and invested significant resources into Add-on Builder<\/a>, an easy-to-use all-in-one web application for building add-ons using only your web browser.<\/p>\n

What About Existing Add-on Developers?<\/strong><\/p>\n

With the Firefox 4 release coming up, several people have recently suggested to me that the SDK might help developers of traditional add-ons for Firefox 3.6 update their add-ons for Firefox 4, and those suggestions have been weighing heavily on my mind, because supporting Firefox 4 and our existing add-on developer base is really important!<\/p>\n

Unfortunately, the SDK is not yet a good tool for updating a traditional add-on to work on Firefox 4. Here’s why:<\/p>\n

First, but definitely not foremost, the SDK is still in beta, which means it is not yet at a level of quality and functionality that is appropriate for many developers.<\/p>\n

More importantly, the SDK delivers not just Firefox 4 compatibility but also, and primarily, a new way of building add-ons, and that means that using it to upgrade a traditional add-on means rewriting the add-on to a significant degree (at least the parts that touch the Firefox user interface). And that’s a lot more work than it would take to make the minimal changes necessary to make that add-on compatible with the changes to Firefox 4’s user interface.<\/p>\n

This isn’t by accident, nor did anyone on the team have any desire to make what Joel on Software calls<\/a> “the single worst strategic mistake any software company can make” (although Wesley<\/span> Spolsky is only mostly dead<\/span> right<\/a>, as rewriting from scratch is something you should only almost<\/em> never do; there is the occasional time when it’s actually right on).<\/p>\n

Rather, it is the result of the SDK achieving one of the principal goals that drove the foundation of the Jetpack project: to make Firefox add-ons restartless.<\/p>\n

To satisfy that key constraint, we had to change the way add-ons modify (and unmodify) Firefox’s innards (platform) and outards (chrome), because the mechanisms for doing so in the traditional extension model (like XUL overlays, XPCOM components, and JavaScript Modules) were designed without restartlessness in mind and don’t support it. And we could see no path to changing that, neither via artful engineering nor via inartful but pragmatic hacks.<\/p>\n

OK, But What About Existing Add-on Developers?<\/strong><\/p>\n

Does that mean the SDK will never be the best way for add-on developers to update their traditional add-ons to work with a new version of Firefox, and we should leave those developers in the lurch?<\/p>\n

Absolutely not! Although restartlessness is significant, there’s an even bigger change coming down the pike: the Electrolysis project plans to split Firefox execution into multiple processes (as it has already done for Fennec<\/a>, Mozilla’s project to bring Firefox to mobile devices).<\/p>\n

And that will require major changes to the way many add-ons are written, as the add-on code that modifies Firefox’s chrome (and much of its platform) will run in a separate “chrome” process from the “content” processes that load and interact with web pages.<\/p>\n

Note a key difference between restartlessness and e10s: in Firefox 4, restartlessness is optional; if you want it, and you’re willing to do the work, you can make your add-on restartless (with or without using the SDK); but if you don’t want it, you can do nothing to make your add-on restartless, and users will still be able to install and use it\u00ad\u00ad\u2013they’ll just have to restart their browsers to do so, as they currently do in Firefox 3.6.<\/p>\n

But in the version of Firefox that incorporates e10s, e10s compatibility will not be optional. If your add-on does anything with content (and perhaps even if it only touches chrome), it will have to take e10s into account.<\/p>\n

Over here in the Jetpack project, we’ve been planning for that day for the last sixish months, and we continue to spend a ton of time on it, so when the day finally comes, we can say:<\/p>\n

If you wrote your add-on using the SDK and its high-level APIs, there is nothing you need to do to make your add-on compatible with the new e10sified version of Firefox (except possibly some minor housekeeping tasks\u2013but we’ll try to eliminate even those).<\/p>\n

And if, on the other hand, you wrote your add-on using Mozilla’s traditional add-on platform, then converting your add-on to use the SDK is now the best (easiest, most straightforward, most supported, best documented, etc.) way to update it to be compatible with the new Firefox. Plus, in the process of doing so, if you haven’t already made your add-on restartless, you’ll get that as well, along with all the other benefits of using the SDK.<\/p>\n

The Priorities<\/strong><\/p>\n

As I mentioned before, we’re a small team, and we can’t do everything. We have to focus, or we’ll fail. So what are the most important things for us to be doing? In 2011, I think our top three priorities, in the order we should tackle them, are:<\/p>\n

    \n
  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.\n

    The Jetpack project should ship the initial versions of these products, and the add-on platform they provide, at our earliest possible opportunity.<\/li>\n

  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.\n

    The Jetpack project should do everything in our power to make that transition as painless as possible.<\/li>\n

  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.\n

    The Jetpack project should help make add-on development a great experience for Firefox on mobile devices.<\/li>\n<\/ol>\n

    The Non-priorities<\/strong><\/p>\n

    <\/strong><\/p>\n

    <\/strong>As Drew Willcoxon once astutely pointed out to me, it’s incredibly useful when making such a list of priorities to also produce its antithesis, i.e. the set of things we should intentionally not focus on, despite sometimes plentiful temptation to do so. Thus here are the top three things I think we should not tackle in 2011:<\/p>\n

      \n
    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.\n

      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 Mozilla Labs’ Chromeless Browser experiment<\/a> are better positioned to explore a potential future replacement.<\/p>\n

      The Jetpack project should leave deep extensibility to the traditional add-on platform and Mozilla Labs experiments.<\/li>\n

    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.\n

      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>\n

      The Jetpack project should not build tools for app development and distribution.<\/li>\n

    3. Firefox-SDK integrationThe 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 dependency hell<\/a>, and makes it easier to architect and nurture a rich ecosystem of third-party APIs.\n

      The Jetpack project should not land its API implementations in the Firefox tree and ship them with Firefox.<\/li>\n<\/ol>\n

      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.<\/p>\n

      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.<\/p>\n

      Note also that I haven’t talked about specific APIs and features of the SDK and Builder. Figuring out exactly which APIs to land and in what order to focus on them is an ongoing project, and we’ll be conducting miniature versions of this prioritization and roadmapping exercise on a monthly or quarterly basis to determine the specific planned featureset of a given release.<\/p>\n

      However, one thought about APIs in general is that it would perhaps be very effective for growing a great add-on platform over the long term to build API development into the Firefox feature development process itself, i.e. to make it a requirement that every major Firefox feature that gets checked into the tree be accompanied by a high-level extensibility API in addition to the unit tests, UX review, and other requirements we impose.<\/p>\n

      Finally, note that we’re still a very small team (although I hope we can expand to a slightly less small one in 2011!). We couldn’t have gotten this far without the support of many other Mozilla teams, including Labs, the Firefox and platform engineering teams, IT, QA, webdev, releng, marketing, legal, PR, and all the others I inevitably forgot.<\/p>\n

      And we won’t accomplish our 2011 goals without continued support from all those teams and others. Our goals have to align with the broader Mozilla mission, and we need everyone who believes in that mission to help us achieve them.<\/p>\n

      So if you’re doing something else around Mozilla, and we come knocking on your door, any help you can provide will be very much appreciated! And if there’s something you really want to see happen, even if it’s on our list of 2011 priorities (f.e. you are a Firefox for mobile developer, and support for mobile add-ons is on our list), your assistance in making it happen is likely to be crucial!<\/p>\n

      The Process<\/strong><\/p>\n

      So how do we actually get there? We need a plan and a process. I’ll talk about the process first (delving into a bit of software development process wonkery\u2013bear with me), and then I’ll propose the plan.<\/p>\n

      One common way of describing the software development process generally is that it involves making trade-offs between three worthy but conflicting goals: a set of features<\/strong> you want the software to have, a release date<\/strong> by which you want it to ship, and a level of quality<\/strong> you want those features to exceed on that date.<\/p>\n

      It’s impossible to achieve all three goals to the extent you want to achieve them (at least if you are being as ambitious as you should be when you are out to achieve Mozilla’s mission<\/a>), and software development efforts succeed because, among other reasons, they make the right set of trade-offs between these goals.<\/p>\n

      I’m a big fan of a model of software development called the train model. In this model (described in more depth in this Thinking in Code blog post by Dean Povey<\/a>), the sacrifice you make is on features. You establish a fixed timeline of releases, akin to the timetable for trains (and planes, and automobuses for that matter), and you release according to that schedule. You also establish metrics to gauge quality (automated tests, manual testing, user feedback, and the like), and you never ship a product that fails to meet your quality standards.<\/p>\n

      But in order to achieve those goals, you do compromise on features, refusing to ship any feature that doesn’t meet the necessary quality metrics in time to make a release. And you do this ruthlessly, no matter how much you want a given feature to ship.<\/p>\n

      Because shipping a crappy version of a feature doesn’t give your users what they really want, and they may not stick around for the better version you promise them later.<\/p>\n

      And delaying the release doesn’t give your users those other features (and bug fixes) they really want, and they may not stick around to wait for them.<\/p>\n

      And finally, because there is always another release train leaving the station. Missing a release is not the end of the world. It is but a tiny death in a giant sea of birth, rebirth, and evolution.<\/p>\n

      Nevertheless, this doesn’t mean that we won’t prioritize and schedule feature work. We still have to make decisions about what matters the most for us to do and when best to do it, and it can be helpful to think about releases as having focuses (“traditional add-on migration”, “mobile add-ons”, etc.). So we’ll continue to do that planning, even if it doesn’t actually constrain release dates.<\/p>\n

      (FWIW, although such a model may today seem alien to the Mozilla project, whose Firefox releases have been feature-driven, Mozilla actually employed something quite similar to this model to ship the Mozilla Application Suite back in the project’s nascency, especially for the major point releases between 1.0 and 1.7, but even before that during the M* and 0.* days, employing a roughly three-month schedule that can still be somewhat seen in this release history table<\/a>.)<\/p>\n

      So like I said, I’m a fan of the train model. Nevertheless, there’s an important exception to it: the first release. When you first release a software product, an additional goal becomes a principal part of your calculations: it must be useful enough to your initial target audience for them to install, configure, and learn how to use it, so you can acquire a user base that gives you both the mindshare and in some cases the revenue (whether through commercial sales or, as in our case, nonprofit fundraising activities and business deals) to sustain further train-based development. Which means it has to have a minimally useful initial set of features.<\/p>\n

      And that’s a very long way of explaining why we’ve established a set of feature requirements for the initial version of the SDK (including a set of high-level APIs that are forwards-compatible with an e10sified version of Firefox) and have been sacrificing ship date rather than features: Add-on SDK 1.0 doesn’t have to do everything everyone wants, but it does have to be useful enough to enough add-on developers to be worth putting into their hands.<\/p>\n

      (Nevertheless, over the last nineish months that we’ve been releasing development versions of the kit, including nine alpha releases and the first beta), we have employed something of a train model for the development releases, favoring regular releases over feature-driven ones, but with quality standards appropriate for the alpha and beta stages of development.)<\/p>\n

      As soon as we ship SDK 1.0, however, I think we should switch to an explicit train model of development, in which we establish a regular schedule of releases, establish high quality bars for all functionality, work on the features and enhancements we identify and prioritize as being most important for our existing and potential future target audiences, and ship each one of those in the first release vehicle for which it is ready.<\/p>\n

      The Plan<\/strong><\/p>\n

      Until SDK 1.0, we continue doing four week development cycles (except for 1.0b2, because of the Monsters That Ate December), with three weeks of open development followed by a week of stabilization and preparation for the release, with the following timeline:<\/p>\n\n\n\n\n\n\n
      <\/td>\n1.0b2<\/td>\n1.0b3<\/td>\n1.0b4 or perhaps 1.0rc1<\/td>\n<\/tr>\n
      thaw<\/td>\n12-01<\/td>\n01-24<\/td>\n02-21<\/td>\n<\/tr>\n
      freeze<\/td>\n01-19<\/td>\n02-16<\/td>\n03-16<\/td>\n<\/tr>\n
      release<\/td>\n01-26<\/td>\n02-23<\/td>\n03-23<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

      And we have the following set of remaining tasks to complete the feature set and meet our quality metrics:<\/p>\n