applying amazon’s lessons to mozilla (part 1)

Several days ago, somebody pointed me at Why Amazon is eating the world and the key idea has been rolling around in my head ever since:

[The reason that Amazon’s position is defensible is] that each piece of Amazon is being built with a service-oriented architecture, and Amazon is using that architecture to successively turn every single piece of the company into a separate platform — and thus opening each piece to outside competition.

The most obvious example of Amazon’s [service-oriented architecture] structure is Amazon Web Services (Steve Yegge wrote a great rant about the beginnings of this back in 2011). Because of the timing of Amazon’s unparalleled scaling — hypergrowth in the early 2000s, before enterprise-class SaaS was widely available — Amazon had to build their own technology infrastructure. The financial genius of turning this infrastructure into an external product (AWS) has been well-covered — the windfalls have been enormous, to the tune of a $14 billion annual run rate. But the revenue bonanza is a footnote compared to the overlooked organizational insight that Amazon discovered: By carving out an operational piece of the company as a platform, they could future-proof the company against inefficiency and technological stagnation.

…Amazon has replaced useless, time-intensive bureaucracy like internal surveys and audits with a feedback loop that generates cash when it works — and quickly identifies problems when it doesn’t. They say that money earned is a reasonable approximation of the value you’re creating for the world, and Amazon has figured out a way to measure its own value in dozens of previously invisible areas.

Open source is the analogue of this strategy into the world of software.  You have some small collection of code that you think would be useful to the wider world, so you host your own repository or post it on Github/Bitbucket/etc.  You make an announcement in a couple of different venues where you expect to find interested people.  People start using it, express appreciation for what you’ve done, and begin to generate ideas on how it could be made better, filing bug reports and sending you patches.  Ideally, all of this turns into a virtuous cycle of making your internal code better as well as providing a useful service to external contributors.  The point of the above article is that Amazon has applied an open-source-like strategy to its business relentlessly, and it’s paid off handsomely.

Google is probably the best (unintentional?) practitioner of this strategy, exporting countless packages of software, such as GTest, Go, and TensorFlow, not to mention tools like their collection of sanitizers. They also do software-related exports like their C++ style guide. Facebook opens up in-house-developed components with React, HHVM, and Buck, among others. Microsoft has been charging into this arena in the past couple of years, with examples like Visual Studio Code, TypeScript, and ChakraCore.  Apple doesn’t really play the open source game; their opensource site and available software is practically the definition of “throwing code over the wall”, even if having access to the source is useful in a lot of cases.  To the best of my knowledge, Amazon doesn’t really play in this space either.  I could also list examples of exported code from other smaller but still influential technology companies: Github, Dropbox, Twitter, and so forth, as well as companies that aren’t traditional technology companies, but have still invested in open-sourcing some of their software.

Whither Mozilla in the above list?  That is an excellent question.  I think in many cases, we haven’t tried, and in the Firefox-related cases where we tried, we decided (incorrectly, judging through the above lens) that the risks of the open source approach weren’t worth it.  Two recent cases where we have tried exporting software and succeeded wildly have been asm.js/WebAssembly and Rust, and it’d be worth considering how to translate those successes into Firefox-related ones.  I’d like to make a follow-up post exploring some of those ideas soon.




  1. Well, there are also plenty of cases where Mozilla tried and failed – either because the product just wasn’t good enough, but typically because there is a difference between a good internal tool and a general-purpose one, and Mozilla didn’t see the gain in going from former to the latter. There are many examples, with XULRunner being a prominent one. It was the right tool coming out at the right time – back when it was published there were no other frameworks that allowed building native-like cross-platform applications easily. Quite a few companies made a bet on XULRunner, and all of them had to give up, one after another. In the end, Mozilla never seriously tried to treat XULRunner as a platform, it was always an internal tool with messy interfaces with kept changing with each release. Too hard? Probably. But a few years later GitHub brought out Electron and is very successful with it – and Mozilla failed once again when trying to copy their approach with Positron.

    • Nathan Froyd

      Yes, the XULRunner effort spans the spectrum between “not trying”, “trying, but with not enough effort”, and “deciding the risks weren’t worth it”. It definitely gets referenced in the draft post that I have for part 2. I don’t know much about the Positron effort, but my impression is that it falls somewhere around the last two points in the spectrum above.

      • I’d rather put Positron somewhere between the first two points. When I was at MozLondon last summer, plenty of people seemed excited about Positron and I thought that Mozilla finally found an embedding story that they want to stick with. After all, it would be crazy from Mozilla to leave the embedding space to WebKit and Blink. So I was very surprised when it was shut down because “the Tofino project was shut down, so nobody needs this now.” But at least this one died quickly, I guess that not too many outside Mozilla decided to use it (with Mozilla’s track record, convincing people to bet on Mozilla technology would be a hard sell these days).

  2. This seems relevant with respect to our lackluster efforts to improve SpiderMonkey’s embeddability as a general-purpose Javascript engine. :-\