Skip to content

The Great Add-on Bug Triage

The AMO team is meeting this week to discuss road maps and strategies and among the topics is our backlog of open bugs. Since mid-2011 there has averaged around 1200 bugs open at any one time.

Currently any interaction with AMO’s bugs is too time consuming: finding good first bugs, triaging existing bugs, organizing a chunk of bugs to fix in a milestone — they all require interacting with a list of 1200 bugs, many of which are years old and full of discussions by people who no longer contribute to the bugs. The small chunks of time I (and others) get to work on AMO are consumed by digging through these old bugs and trying to apply them to the current site.

In an effort to get this list to a manageable size the AMO team is aggressively triaging and closing bugs this week, hopefully ending the week with a realistic list of items we can hope to accomplish. With that list in hand we can prioritize the bugs, divide them into milestones, and begin to lobby for developer time.

Many of the bugs which are being closed are good ideas and we’d like to fix them, but we simply need to be realistic about what we can actually do with the resources we have. If you contribute patches to any of the bugs, please feel free to reopen them.

Thanks for being a part of AMO.

Tagged , ,

Retiring AMO’s Landfill

A few years ago we deployed a landfill for AMO – a place where people could play around with the site without affecting our production install and developers could easily get some data to import into their local development environment.

I think the idea was sound (it was modeled after Bugzilla’s landfill) and it was moderately successful but it never grew like I had hoped and even after being available for so long, it had very little usable data in it. It could help you get a site running, but if you wanted to, say, test pagination you’d still need to create enough objects to actually have more than one page.

A broader and more scalable alternative is a script which can make as many or as few objects in the database as you’d like. Want 500 apps? No problem. Want 10000 apps in one category so you can test how categories scale? Sure. Want those 10000 apps owned by a single user? That should be as easy as running a command line script.

That’s the theory anyway. The idea is being explored on the wiki for the Marketplace (and AMO developers are also in the discussion). If you’re interested in being involved or seeing our progress watch that wiki page or join #marketplace on

Tagged , , ,

Marketplace Update for Q2

Every quarter the apps team gets together to meet people and talk about all the pieces of the projects. This quarter we’re doing a little different format which I think will turn out to be a lot more social and hopefully keep things interesting. As part of the project I put together this short video talking about Q2 for the Marketplace. Thanks to all the developers working on the Marketplace, Andy McKay for the payments videos, and Katt Taylor for helping piece it together.

You can download this video.

…and yeah, when I say “mammoth feat” I’m totally thinking of “mammoth feet.”

Tagged , ,

Improving our process; part 2: Public Priorities

Part 1: Identifying Priorities

As promised, there is now a public view of upcoming work on the Firefox Marketplace. This dashboard shows a rough representation of our thought process when we evaluated each project using the criteria from Part 1. If you hover over the titles there are also some helpful descriptions and questions we asked ourselves. Clicking a project title will expand to show some information about the project as well as any notes about the scoring. Some of the projects have been grandfathered in to this process so they are a bit light on details, but if you look at a project like Support Low Memory Firefox OS Devices (128MB) you’ll see the potential.

We’re still working on the right people to get in the room to do the scoring. Mailing lists are hard because of the lack of easy discussion but in person is hard due to scheduling and not wasting time bikeshedding. We’ll get better as we get experience, our main focus at this point is staying consistent with the scoring – being sure to consider the entire ecosystem when assigning a value.

There are still a lot of projects to evaluate but I’m really excited about being able to link to a backlog of projects and easily point out which are a high priority and why. As always, feedback welcome.

Tagged , , ,

Ten years of

Ten years ago, Ben Smedberg and Wolf landed the first version of the code that would make up AMO. At the end of 2004 it was still called, written in PHP, and was just over 200k, compressed.

Behold the home page of

This moved through, I think, 1 major revision “update-beta” which added a database tabled called main that held all the add-on info. This came with some additional fancy styles:

I started around 16 months after this foundation was laid. AMO was essentially flat HTML files sprinkled with PHP code and database queries, just like everyone says not to do now. I think the code was running on a single server named Chameleon at the time and as we released versions of Firefox it would get overwhelmed and become unresponsive. Most of the work at this time was adding in layers of caching like Smarty and keeping everything in memcached.

We had a major rewrite in planning (one with more dynamic possibilities) and I chose CakePHP as the foundation. That release happened and brought another redesign with it:

Check out how those gorgeous pale yellow and faded blue bars complement each other. Also note that we’re still claiming to be in beta at this point.

The Adblock detail page in 2006. Rated 5 out of 5 by someone named Nick!

Finally, at the end of 2006 the infamous chopper design appeared and took over the top third of our site:

Customizability was the message we were trying to communicate with this design. There were some concerns voiced at the time…

This version followed the first quickly. The header was reduced slightly, the content got some more margin, and we started using whitespace to keep things looking simple. On the other hand, you’ll notice our buttons getting more complicated – this was the beginning of our button horrors as we started to customize them for each visitor’s device.

Both chopper designs were relatively short lived and, I want to say around early 2008 we moved to another infamous design – the green candy bar.

Here we are emphasizing search. And how. There was a rumor we actually stole this design from another site at the time – I assure you that wasn’t the case.

I don’t remember the actual date on this one, but let’s say 2009 since we seem to redesign this every year. This was a complete departure from our previous work and the design was done from scratch.

Not a bad looking design and one that served us well.

Finally, our current design:

I still think this is a good looking site.

This design was also the first year we had a separate mobile site.

I’ve had the draft for this post written for years and I think it’s time just to hit publish on it – feel free to comment about all the things I forgot. There should probably also be some disclaimer about me writing this on a Friday afternoon and I take no responsibility for misinformation or wrong dates. :)

Thanks to fligtar for having screenshots of all the old versions!

Tagged , , ,

Improving our process; Part 1: Identifying Priorities

One of our stress points is juggling too many projects. It’s easy to hear ideas pitched from excited people and agree that we should do them, but it’s hard to balance that with all the other commitments we’ve already made. At some point we have too many “top priority” projects and people are scrambling to keep up with just the bare minimum – forgoing any hope of actually getting the enhancements done.

With a large number of projects, developers begin working independently to finish them which increases feelings of isolation, contributes to poor communication (“I don’t want to interrupt you”), and delays code review until someone can context switch over to look at it. Basically we’ve hit a point where – on large enough projects – working separately is slowing down our delivery and lowering our team morale.

In addition to being spread too thinly, there is also the question of why are we working on the projects we’re working on. In theory, it’s because they support our company goals, but that can often get muddled in the heat of the moment and interpretations and definitions (and even memory) can affect what we actually work on.

The work week helped highlight these two concerns and after several discussions (thanks to everyone who participated) we came up with some solutions. I’ll address them in reverse order – firstly, to determine priorities (the why), we wanted a more objective and public way of ranking the importance of projects. A public list of projects not only lines up with our open philosophy, but helps developers and the community know who is working on what, and also helps anyone requesting features get a feeling for a delivery timeline. Our solution was to build a grid with 16 relevant fields which we rank from 0-5 and then sum to get a final score. The fields are categorized and are broken down as follows:

  • Who finds value from the request? Separate points for consumers, developers, operators, OEMs, and Mozilla employees.
  • How does the request align with the company goals? Separate points for each goal.
  • How does the request align with the 2014 Marketplace goals? Separate points for the three goals.
  • Lastly, is there internal necessity? Separate points for Technological Advancement, Legal Compliance, and Urgency.

Once we have a request, a champion for the request meets with representatives from the product, UX, and developer teams, as well as any other relevant folks. We discuss the request and the value in the specific areas and then add up the score to get a number representative of priority. Clearly this isn’t a hard and fast science, but it’s a lot more objective than a gut feeling. It lets us justify decisions with reasoning, helps us think of all affected groups, and makes sure we’re working on what is important. If something has a high score we’ll start talking about timelines and moving things around, keeping in mind commitments we’ve made, planning and research that needs done, and any synchronizing we need to do with other dependent teams.

The other issue – people trying to do too much – is easily solved in a conversation but will likely be a challenge in practice. The plan is to cap our active tasks to 3 or 4 at any one time. Anything else will queue up behind them or displace them as appropriate. The exact number may change based on size of the team and size of the project, but my goal is to get 2 to 4 people working on a project together and with our current numbers that’s about what we can do.

I’m working on a real-time public view of our tasks but I’m traveling this week and haven’t had a chance to finish it. I’ll post again with a link once it is finished.

Update Feb 13: Added links to goals.

Tagged , , ,

Splitting AMO and the Marketplace

Years ago someone asked me what the fastest way to stand up an App Marketplace was. After considering that we already had several Add-on Types in AMO I replied that it would be to create another Add-on Type for apps, use the AMO infrastructure as a foundation for logins/reviews/etc. and do whatever minor visual tweaks were needed. This was a pretty quick solution but the plan evolved and “minor visual tweaks” turned into “major visual changes” and soon a completely different interface. Fast forward a few years and we have two separate sites ( and running out of the same code repository but with different code. Much of the code is crudely separated (apps/ vs mkt/), but there are also many shared files, libraries, and utilities, both front and backend. The two sites run on the same servers but employ separate settings files.

There has been talk about combining the two sites so that the Firefox Marketplace was the one stop shop for all our apps/add-ons/themes/etc. but there was reluctance to move down that path due to the different user expectations and interfaces – for example, getting an app for your phone is a lot different flow than putting a theme on Firefox. While the debate has simmered with no great options the consequences of inaction continue to grow. Today’s world:

  • Automated unit tests which take far longer than necessary to run because they run for both sites.
  • Frustration for developers who change code in one area and affect a completely different site.
  • Confusion for any new employees or contributors as they struggle to set up the site (despite our decent documentation).
  • A one-size-fits-all infrastructure approach with no ability to optimize for the very different sites (API/service based vs standard MVC)

The best way to relieve the stress points above is complete separation of and Read the full (evolving) proposal. Feedback welcomed.

Tagged , , , , ,

Some new Marketplace dashboards

Cross posting from a mailing list:

I'm pleased to present a couple of dashboards I made over the break for the
Marketplace.  Behold:

1) How many bugs were closed this week?

   I actually had the code for that one already laying around, so that was just
   to see if Andy was taking pull requests on metaplace. :) 

2) What waffles are what?

   A long standing complaint is that it's hard to tell what waffles we have on
   which site.  Not anymore - now you can instantly get two scoops of knowledge
   as a healthy part of this complete dashboard. (prod's API isn't live so
   nothing in that column yet)

3) That API seems slow, but maybe it's just me...

   A close runner up in concerns, some of our API speeds have been questionable
   but it's hard to point to a problem when we're trying to find a graphite
   graph (behind auth) or it's only happening to you and you can screenshot it
   but it may just be slow that day or something.  Now we have our own personal so we can point to real(-time) data on our API speeds
   (measured from around the world via pingdom).  See the other thread on this
   list ("[RFC] API performance standards") for more thoughts on this

Happy 2014!
Tagged , ,

Marketplace in Q4, 2013

Another set of slides summarizing Marketplace accomplishments in Q4 of 2013 (html). Behold the animated gifs!

Also, hat-tip to Will Kahn-Greene’s summary of Input in 2013.

2013 Q3 Accomplishments

The end of September was the same as every quarter lately – a whirlwind of summaries and demonstrations. I gave several presentations on what the Marketplace, SUMO, and Input teams did but I didn’t post anything on this [neglected] blog. It’s my party and I like to emphasize demos and screenshots over text so I’m going to inline the slides here (and hope they are interesting). A downloadable version is available (7.3M, pdf). The list of accomplishments for the quarter is both incomplete and collected from many people – my contribution here is simply doing some management work and putting together the presentation.

A big thanks to the great folks working at Mozilla.

Tagged , , ,