It's interesting to think about what alternatives to this path could have existed. The author makes what he thinks is a watertight argument about security, but

It's interesting to think about what alternatives to this path could have existed. The author makes what he thinks is a watertight argument about security, but it's a lot leakier than is made clear. Mozilla didn't actually have an extensions malware problem at any point. That's why he won't cite any actual examples, saying in the comments he's afraid of lawsuits because the extensions came from "high profile apps". High profile apps the user is choosing to install are by definition not malware, yet Mozilla allowed a bizarre authoritarian impulse to develop amongst its engineers that let them rationalize to themselves that any desktop app that extended Firefox (i.e. outside the add-ons site they controlled) was "malware" regardless of what it did or whether users actually liked it. That's a totally incorrect definition, which is why they are so squirrelly about it, any why users reject it. Nor is the API stability argument well founded. Nothing would have stopped them introducing stable APIs they could commit to and helping extension authors migrate. They could have implemented WebExtensions as well as continuing to allow XUL extensions, which would have given the extensions that didn't need more functions stability without killing the others. Why could Google design such APIs but not Mozilla? The real reason they didn't want to does seem to be described - designing APIs and then sticking to them is tedious and boring work. The chrome guys didn't have to do that, at least for a while. What fun! In a parallel universe, Mozilla realized that whilst performance and security are important, they're also largely a pure function of how much you depend on engineers and thus they could never win against Chrome in that department. The only battlefield on which they could gain advantage was the field of ideas. Features were the one place their smaller engineering budget wouldn't automatically lose against Google, but clearly by this time Mozilla had run out of ideas for features users might want. XUL extensions were a valuable proving ground for features they could then later have merged into the main browser, potentially finding even just one idea that Chrome would struggle to match. Reducing the maintenance burden could have been done in all sorts of ways, for example by using a Linux Kernel style model in which popular extensions are invited to be developed in tree where they can be activated during testing cycles and refactored atomically as the browser changes. Typescript would have made this easier, but xpcom already offered some type safety.