Discontinuing several features of AMO

AMO has grown a lot as a product over the last few years, and we’re starting to look more closely at its features to make sure they’re pulling their weight and are enjoyed by our users. As we continue our rewrite of the site, we’re going to be removing or not re-implementing a number of features that aren’t performing as well as we’d like.

This post lists the first batch of these features that will be removed in the coming months.

Ending Self-hosted Pilot Program

In November of last year we announced a pilot program allowing developers to create listings on addons.mozilla.org for their add-ons without requiring the add-ons to be hosted or reviewed by us. We hoped this would create a more comprehensive directory of add-ons where users could find any Firefox add-on they were looking for, even if it wasn’t hosted by us.

It’s been almost a year, and after reviewing the results of the program, we have decided to end it. We haven’t seen the kind of adoption we were looking for and still find that many of the best add-ons that aren’t hosted on AMO did not participate. Instead, add-ons that were already listed on AMO switched to self-hosted to avoid complying with certain review policies.

Self-hosted add-ons are difficult to maintain in our code base, as they require exceptions to almost everything we implement. We’re starting work on our new Developer Tools area of the site and could not justify re-implementing them in our new framework given their usage and maintenance cost. Finally, as announced earlier this year, we’ll soon be moving to a review model where every add-on available in our gallery must be reviewed for security. As self-hosted add-ons are not reviewed or hosted by us, they don’t quite fit in with our new standards.


Support for self-hosted add-ons will end with the launch of our revamped Developer Tools, likely in November. Developers of affected add-ons will receive an email prior to this time. We recommend converting your self-hosted add-on into a fully hosted add-on at least 2 weeks before that time period to allow for editor review and post-review modification. Once support is removed, all remaining self-hosted add-ons will be disabled.

Email Sharing

We implemented the ability to share add-ons and collections via email last year, but haven’t seen it used much at all. Requiring users to log in is likely a huge barrier to this feature’s usage, but for now we’ll be removing the feature until that and other issues can be resolved at a later time.

User Tagging

Currently, any registered user can tag an add-on to help classify and group similar add-ons. We’re going to simplify this by only allowing developers to tag their add-ons. Add-ons will have a maximum of 20 tags, and the migration to the new format will prioritize the developer’s tags and fill remaining slots with user tags. Once this process is finished, developers can delete any migrated tags they don’t wish to keep.

13 responses

  1. Daniel Glazman wrote on :

    D’oh πŸ™

  2. joe wrote on :

    Why isn’t this published at https://forums.addons.mozilla.org/viewforum.php?f=19 ?

  3. Christian Lehmann wrote on :

    I hope they speed up the review process for complex addons (like mine). Otherwise this will not work any more πŸ™
    I have an addon for a specific website and as soon as this site changes its code, I have to adjust the extension and publish it so that everybody can use it again. This review process with about 2 weeks is just too long to normal user as they have to wait 2 weeks before their functions are working again.
    And not everybody know that they can install unreviewed files as well. (will this still be possible? This would also not apply to your rules above.)

  4. wsm wrote on :

    With the demise of user tagging, I hope that devs will be forced, literally, to add a minimum number of useful tags to their add-ons. Add-ons that lack useful tags, of which there are many, makes the process of finding interesting and related add-ons less flexible and more difficult and time consuming via title and category. That is, unless you’ve substantially improve the search engine and/or added AI to search.

    I wish I could cite my exact experience, but it’s been too long ago since I tagged the ones that needed tags when I had trouble finding them. But I offer this unscientific examination of Thunderbird’s misc category, subsetted to recently added list https://addons.mozilla.org/en-US/thunderbird/extensions/miscellaneous/

    Looking only at the top 10, it’s nice to see that many have 3 or more decent tags. But almost half lack a “minimum” number of useful tags and some have none:

    The rest of the top 10, the good ones, are

  5. Nigelle wrote on :

    “Support for self-hosted add-ons will end with the launch of our revamped Developer Tools, likely in November.” What does this exactly means ?
    I hope that they will only disappear from the AMO site but still be usable…

    1. Justin Scott (fligtar) wrote on :

      This only affects add-ons listed on AMO. You’ll still be able to install add-ons in Firefox from anywhere.

      1. Julien H. wrote on :

        If developers don’t do this kind of change, the Self-hosted addons will only disappear from the AMO site but still be usable for the actual users who have installed them ?

  6. Grey wrote on :

    Do you really have to get rid of the self hosted add ons? That causes a real headache for seeing as I wanted to switch to self hosted because I could not upload it through your crappy uploader. Oh but, your seemingly easy solution is to what? upload part of the addon and then have the reviewer download the files and have them add it in the right directory when it already takes weeks to review an add on.

    If your new release doesn’t have the ability to upload large files (at least 20mb) then I’m out. I can handle waiting a few days for the release even though it is very long but, the fact that I can’t even upload it is aggravating.

    In my opinion you all should keep self hosted add-ons and have them get verified by a reviewer every (or every other) week or release to keep them listed on the add-on site.

  7. methuzla wrote on :

    Tags (1)
    I would also like to see the another layer of description categorising add-ons according to their level of fun through to fundamental function, for example

    /functional appearance-modifiers (stylish etc.)
    /functional ease-of-use add-ons (tab kit, )
    /functional activities (flagfox, downloaders, etc)
    /radical functional addons (tree-style tabs, Full size browsing with url-bar)
    /product maintenance (FEBE, etc.)
    /debug, test and development modules

    the idea being to facilitate searching for an add-on that has a particular appeal, by explicitly selecting the categories one does/does-not want to see in the search results.

  8. methuzla wrote on :

    Tags (2)

    In an effort to avoid spurious tagging,
    I think it might be useful to have another layer of tag confirmation, so that registered users can agree with/disagree with nominated tags, to get misleading ones removed.

  9. methuzla wrote on :

    I find it extra-ordinary that I cannot get straight back from an add-on listed in my AMO page
    (or about:support )

    directly to the manifest page for the add-on

    and also that sometimes there is no working reference to maintainer,

    and also that add-ons get into the collection that are difficult to uninstall.

    I hope these things will be fixed in the next iteration.

  10. Joe wrote on :

    I just found out you had Self-hosted Program. I had a Thunderbird add-on hosted on AMO which I decided to remove after a while because the standard add-on installer is too weak, and I have to use Windows msi installer. Self-hosted Program would have suited my needs. Allowing to host on AMO msi and exe installers might be good alternative.

  11. Noname wrote on :

    It’s interesting the manner in which this organization decides what users want. I’m beginning to think the stats are purposely flawed to give you guys an excuse to do what is best for you alone.