Flickr

Disclaimer

What I write here does not represent the views or beliefs of my employer. I may even disagree with myself.

The Add-ons Landscape

Standard

We’ve been a bit quiet lately because we’ve been cooking up something new. Shortly after April’s re-release of the addons.mozilla.org (AMO) front-end, Mike Shaver came on board. He’s given the project some direction and has been mixing things up a bit with new ideas. He’s helped us focus and move forward on:

Drafting policies

Gathering more complete requirements for future product releases

Making better performance decisions

Choosing correct data structures

Taking advantage of web frameworks and new technology

We’ve been able to work on all this and still manage to keep things running thanks to community volunteer efforts from people like Mel Reyes, Olive, Nitallica, Alan Starr, Wolf, Pontus Freyhult, Chris Blore, Lupine, Robert Marshall, Giorgio Maone, Mike Kroger, Ed Hume, Daniel Steinbrook, Sethnakht, and Cameron. They have working hard to review add-ons, work with developers, help users, report bugs and submit patches. We all owe them a pat on the back.

Another factor has been the addition of badly needed resources:

The attention and focus of Shaver, who genuinely cares about our project

Additional staff to help organize and speed up development — myself, Wil Clouser (clouserw), Andrei (sancus)

New developers and volunteers stepping up, like Cameron and fligtar (Justin Scott)

The ongoing support and direction of Mike Schroepfer (schrep)

With the next major release of Firefox and Thunderbird around the corner, one thing was certain for addons.mozilla.org — change. Lots and lots of yummy change.

Shaver coined “remora“, the shiny-sexy codename of AMO v3. We’ve set up a public wiki where we’ve gathered and cleaned up most of your requirements, and posted a project schedule. We even had one of our volunteers create an image for us (it’s giving birth to add-ons!):

Our goals are clear:

Make finding and installing add-ons easier

Support localization of site pages and data

Reduce and simplify design and layout with a fresh new look

Take full advantage of our new hardware resources

Provide better support through forums and threaded discussions

Develop with a test-oriented mindset for a more robust and mature application

Revitalize and streamline our review process to ensure the quality of add-ons

All this should add up to a common goal: extend Mozilla products to make the web better. Period.

So things are looking up! Please read the wiki and join us in IRC if you have ideas or want to participate in the project:

I hope this name ‘Remora’ is not permanent; if it is, I suspect it reveals an underlying resentment against the extension community by the developer community (for making apps less stable?).

The name ‘Remora’ implies that
a. extensions are life-sucking parasites detrimental to the host, slowing down the host application (sometimes true, but probably not in eyes of user who uses it), and
b. just as host organisms are better off without remora dragging them down, Mozilla apps would be better off to get rid of extensions if they could (not true, and a negative metaphor bad for building community).

In contrast, for example, a Cleaner-fish has a mutually beneficial relationship with the fish it cleans (and extensions can be thought of as cleaning-up/simplifying the UI for particular use-cases).

Surely there are other beneficial parasites out there that could make better metaphorical names.

No, it means that with a db redesign to support a framework, the backend will be pushed along with the new front-end. It may not have as much marketing / fresh look emphasis but it will be a huge improvement and easier to extend.

Re: “Remora” — it’s just something to use besides AMO v3. And yes, I’d opt to use the positive spin on it. 🙂 Think “symbiosis”. If you look at the fish itself, it’s less a parasite and more of an add-on. 😀

I don’t believe we will have multiple apps — we have support for different apps built-in to the database, which is pretty much a carry-over from the old site. The key there will be (as it was before) being able to present compatibility information in a usable way.

I think we’ve done a crappy job of that in the past, and will improve on that with the help of some of the design experience of Radiant Core.

As for the “new” apps, I’m not sure — we have to evaluate how much we want to support them, especially if they are in beta phases. Our primary responsibility is towards our flagship apps like Fx, Tb, SeaMonkey, and even now I believe people can add support for those apps if they want to as long as they are compatible with at least one flagship (Mozilla supported) application.

As other applications progress, they will get the attention they need, I am sure of that. The interface and database is designed to grow past just one or two, so it’d be great if many more apps grew exponentially — I’m all for it!

“As other applications progress, they will get the attention they need, I am sure of that. The interface and database is designed to grow past just one or two, so itâ€™d be great if many more apps grew exponentially â€” Iâ€™m all for it!”

Is there any specifics on when an app gets added? Flock compatibility used to be listed and was removed this year prompting us to have to build our own extension catalog just so users could see the compatibility of extensions while they are browsing.

It has also complicated things for extension authors as well since they have to submit extensions to multiple sites. Songbird is having to do the same thing. Do we really want to fracture the extension author community?