Rocketeers!
I've been working on the roadmap for 2011, and I have a draft
version (attached below) that I'd like to share with y'all. It's
long and detailed, but it has a ton of useful info on the history of
the project and where I think we should be going in 2011.
Take a look, and let me know your thoughts!
Cheers,
-myk
***DRAFT***
"I solemnly swear that I am up to no good!"
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.
Why We Need a Roadmap
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.
A Brief History of Jetpack
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.
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.
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.k.a. e10s); and invested significant resources into
Add-on Builder, an
easy-to-use all-in-one web application for building add-ons using
only your web browser.
What About Existing Add-on Developers?
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!
Unfortunately, the SDK is not yet a good tool for updating a
traditional add-on to work on Firefox 4. Here's why:
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.
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.
This isn't by accident, nor did anyone on the team have any desire
to make what
Joel
on Software calls "the single worst strategic mistake any
software company can make" (although
Wesley
Spolsky is only mostly dead right, as
rewriting from scratch is something you should only
almost
never do; there is the occasional time when it's actually right on).
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.
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.
OK, But What About Existing Add-on Developers?
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?
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,
Mozilla's project to bring Firefox to mobile devices).
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.
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–they'll just have to restart their browsers to
do so, as they currently do in Firefox 3.6.
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.
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:
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–but we'll try to eliminate even those).
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.
The Priorities
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:
- 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 should ship the initial versions of these
products, and the add-on platform they provide, at our earliest
possible opportunity.
- 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 should do everything in our power to make
that transition as painless as possible.
- 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 should help make add-on development a great
experience for Firefox on mobile devices.
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:
- 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 Mozilla Labs'
Chromeless Browser experiment are better positioned to
explore a potential future replacement.
The Jetpack project should leave deep extensibility to the
traditional add-on platform and Mozilla Labs experiments.
- 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.
Mozilla Labs' Open Web
Applications project 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 should not build tools for app development
and distribution.
- 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 dependency
hell, and makes it easier to architect and nurture a rich
ecosystem of third-party APIs.
The Jetpack project should 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.
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.
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.
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.
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.
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!
The Process
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–bear with me), and then I'll propose the
plan.
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 you want the
software to have, a
release date by which you want it to
ship, and a level of
quality you want those features to
exceed on that date.
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),
and software development efforts succeed because, among other
reasons, they make the right set of trade-offs between these goals.
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), 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.
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.
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.
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.
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.
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.
(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.)
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.
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.
(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.)
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.
The Plan
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:
|
1.0b2
|
1.0b3
|
1.0b4 or perhaps 1.0rc1
|
thaw
|
12-01
|
01-24
|
02-21
|
freeze
|
01-19 |
02-16
|
03-16
|
release
|
01-26
|
02-23
|
03-23
|
And we have the following set of remaining tasks to complete the
feature set and meet our quality metrics:
- e10s integration
- certain additional APIs (has been discussed, but needs a bit
more nailing down)
- API enhancements and bug fixes (needs bug triage and other
identification work)
- CommonJS compatibility fixes
- build-time module resolution
- code signing?
If we can finish the work we have left on SDK 1.0 by early Q2, which
is aggressive but possible (with the biggest unknown being the time
it'll take to finish the e10s integration work), then something like
the following schedule of stable releases seems reasonable:
|
early Q2
|
mid Q3
|
late Q4
|
Releases
|
SDK 1.0
|
SDK 1.1
Builder 1.0 beta
|
SDK 1.2
Builder 1.0 final
|
Theme
|
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 |
So each release after 1.0 will take three to four months and will
include about a month of open development culminating in an alpha
release, a month of stabilization and feature evaluation culminating
in a beta release, and a month or two to get to a release candidate
and then a final release.
Obviously there's more to fill in. What tools/docs/etc. will help
developers migrate traditional add-ons? How do we support building
add-ons for Firefox on mobile devices? We'll need to figure that
stuff out.
But the big picture plan is that we ship what we've built and then
keep shipping better versions of it on a regular schedule,
prioritizing Firefox for desktop with e10s, migrating traditional
add-on developers, and Firefox for mobile.