Shipping great software to lots of people is hard. At Mozilla we talk about shipping only “when it’s ready,” and the devotion our community has to Firefox users, and to shipping them a high quality product, is unlike anything I’ve seen elsewhere. We answer to no one but you.
“When it’s ready” doesn’t mean we can take our time, though. Firefox 4 is good for the web, good for our users, and puts the heat on other vendors to up their own game. We need to ship it ASAP – we want release candidates in weeks, not months. And that means a hard look at our blocker list.
Blocker bugs have a rank order. If you can’t have all of them, there are some you’d want more than others, even though every single one of them is a bug we want to fix. That’s healthy. Building software means making those calls. Each bug is evaluated against whether it’s worth holding back the thousands of fixes that have already made it into the Firefox 4 tree. At this point, very few bugs are worth holding back that much awesome.
Hard vs. Soft Blocking1
To that end, then, if you watch bugzilla, you’ve seen blocker bugs sprouting one of two new whiteboard labels:
- [hardblocker] – These bugs prevent us from shipping. We’ll hold the release for the very last one of them. A hard blocker is a failure of a core part of our release criteria, e.g. a crash, a memory leak, a performance hit, a security issue, a UI breakage that can’t be recovered from, an incompatibility we can’t stomach.
- [softblocker] – These bugs are things we want to fix as soon as possible, but can ship with if the hard blockers are done. They can be fixed in maintenance releases if needed, or in Firefox 5 which, remember, is not so very far away. Soft blockers might include visual polish, strange edge cases, optional aspects of new specs, or opportunistic performance wins.
Hard blockers trump everything. That doesn’t mean they are the only things that will get fixed – indeed we hope and expect many of our soft blockers to make it in as well. We didn’t clear their blocking flags, they are still legit work items and have landing pre-approval. Soft blockers are what beltzner calls the “opportunity space” – the work that lifts the quality and delight of the product. But we have to make the hard calls, and soft blockers are second priority to shipping. People paid to work on Firefox will be focusing exclusively on hard blockers, first.
The hard blocker list is currently at 143. When it hits 0, we can ship. Let’s kill it dead.
 Inevitably, when we do a pass like this, someone will want to digress into a thread about nomenclature. “Why are they blockers if they don’t block?” “Are there hard soft blockers, or soft hard blockers?” I love the creativity of our community, but I think it’s a distraction right now, and I’d suggest to you that we have more interesting problems to solve in the next little while!