In case you don't read newsgroups, here's some of Mike Beltzner's latest comment:
The JetPack project is very interesting to Firefox, and we are participating (as should all of you, as interested consumers and stakeholders!) in its development both in terms of building the platform and setting requirements on that platform. It is a stated goal of the Firefox team to do what we can to make it easy to install, uninstall and manage JetPacks alongside other customizations such as Add-Ons, Plugins, Search Providers, Themes, and Personas.We also plan on continuing to dedicate time to working with the JetPack drivers to help them shake out requirements based on existing Add-Ons and what we know the most common compatibility "gotchas" are. It's my sincere hope that mconnor's "call to arms" will be heeded and that everyone contributes to that effort. JetPack is being built specifically for the purpose of making it easier to write customizations for Firefox, so please, tell us what you find difficult and help us understand what your requirements are.
Many people have interpreted mconnor's post to mean that the Firefox product team has already made a strategic decision to remove support for the existing extensibility platform and technology in the near future: this is not the case. What mconnor wrote was that from a strategic perspective, we will be focusing on building an effective and viable alternative platform in conjunction with our extension development community in order to address specific limitations of the current system. I do not see this as a zero sum game, although as a separate but related issue, some specific aspects of the current model may need to be modified for security and performance reasons (I'm referring to binary components, which will likely need to migrate to js-ctypes.)
I hope this clarifies things, somewhat.
And BZ chimes in as well:
I think this hasn't been made clear enough, actually, so here's my attempt to make it clearer.Right now we seem to have on the order of 10000 (a bit over 11k if I add my numbers right, but it's the order of magnitude that counts) Firefox add-ons on AMO.
Some of these are actively maintained; some are not.
The really popular add-ons, in my experience, have a tendency to be actively maintained. Even on trunk, adblock+ usually works just fine, and more importantly says so in its version metadata. Same for Firebug (it's been worse in the past, but is getting better). That sort of thing.
However there is a very long tail of add-ons that are not as actively maintained. This is fine; people are doing many of these in their spare time, and even the time they take to bump the maxVersion every time we do a new release is much appreciated. But the net effect is that:
1) Possible beta testers tend to avoid trunk builds because their
favorite add-on or three doesn't work with them yet, so we lose
useful feedback. The version check override approach helps some,
but only if the version check is really the only thing preventing
the add-on from working.
2) Doing a release involves getting several thousand people to update
things on AMO (at least the maxVersion, but in many cases more than
that).
3) Since even the updates from step 2 are not enough for the whole
long tail, we end up with users who are running outdated (hence
insecure!) versions of the browser because their favorite add-on
hasn't been updated.If we can get to a point where we serve, say, 98% of these add-ons with a stable API that doesn't involve any more changes, and if the most popular of the remaining 2% are updated expeditiously anyway, we suddenly find ourselves with a _much_ shorter tail, and the three issues above become much smaller problems. Note that this doesn't involve all extensions using the stable API, nor does it involve preventing truly innovative extensions from being written, nor anything along those lines. It just involves a preponderance of extensions using the stable API. Note that the stable API can have things added to it as needed; this would probably happen based on feedback from extension developers, especially those who are in fact exploring the space of what can be done with things outside the existing stable API.
I think the above list of problems we're trying to solve, and why Jetpack or some other stable API with growing surface area would help us solve them, is so much in the hindbrain of the people who've been banging their heads on this problem that it's easy to forget that none of the above is obvious "from the outside"....
To be clear, the stable API doesn't have to be Jetpack. Jetpack is the current attempt at creating such a thing, as I understand it.
