Inventory and Strategy

“There’s class warfare, all right, but it’s my class, the native class, that’s making war, and we’re winning.” -- Android and iOS, blatantly stolen from Warren Buffet

Firefox OS tried to bring Web apps to the mobile world and it failed. It has been brain dead - for phones - for three days and the tubes preserving its life will be turned off in May 2016. I don't believe at all myself in the IoT space being a savior for Mozilla. There are better and older competitors in that space, companies or projects that bring smaller, faster, cleaner software architectures to IoT where footprint and performance are an even more important issue than in the mobile space. Yes, this is a very fragmented market; no, I'm not sure FirefoxOS can address it and reach the critical mass. In short, I don't believe in it at all.

Maybe it's time to discuss a little bit a curse word here: strategy. What would be a strategy for the near- and long-term future for Mozilla? Of course, what's below remains entirely my own view and I'm sure some readers will find it pure delirium. I don't really mind.

To do that, let's look a little bit at what Mozilla has in hands, and let's confront that and the conclusion drawn from the previous lines: native apps have won, at least for the time being.

  • Brains! So many hyper-talented brains at Mozilla!
  • Both desktop and mobile knowledge
  • An excellent, but officially unmaintained, runtime
  • Extremely high expertise on Web Standards and implementation of Web Standards
  • Extremely high expertise on JS
  • asm.js
  • Gaia, that implements a partial GUI stack from html but limited to mobile

We also need to take a look at Mozilla's past. This is not an easy nor pleasant inventory to make but I think it must be done here and to do it, we need to go back as far in time as the Netscape era.

Technology Year(s) Result
Anya 2003 AOL (Netscape's parent company) did not want of Anya, a remote browser moving most of the CPU constraints to the server, and it died despite of being open-sourced by its author. At the same time, Opera successfully launched Opera Mini and eventually acquired its SkyFire competitor. Opera Mini has been a very successful product on legacy phones and even smartphones in areas with poor mobile connectivity.
XUL 2003- Netscape - and later Mozilla - did not see any interest in bringing XUL to Standards committees. When competitors eventually moved to XML-based languages for UI, they adopted solutions (XAML, Flex, ...) that were not interoperable with it.
Operating System 2003- A linux+Gecko Operating System is not a new idea. It was already discussed back in 2003 - yes, 2003 - at Netscape and was too often met with laughter. It was mentioned again multiple times between 2003 and 2011, without any apparent success.
Embedding 2004- Embedding has always been a poor parent in Gecko's family. Officially dropped loooong ago, it drove embedders to WebKit and then Blink. At the time embedding should have been improved, the focus was solely on Firefox for desktop. If I completely understand the rationale behind a focus on Firefox for desktop at that time, the consequences of abandoning Embedding have been seriously underestimated.
Editing 2005- Back in 2004/2005, it was clear Gecko had the best in-browser core editor on the market. Former Netscape editor peers working on Dreamweaver compared mozilla/editor and what Macromedia/Adobe had in hands. The comparison was vastly in favor of Mozilla. It was also easy to predict the aging Dreamweaver would soon need a replacement for its editor core. But editing was considered as non-essential at that time, more a burden than an asset, and no workforce was permanently assigned to it.
Developer tools 2005 In 2005, Mozilla was so completely mistaken on Developer Tools, a powerful attractor for early adopters and Web Agencies, that it wanted to get rid of the error console. At the same moment, the community was calling for more developer tools.
Runtime 2003- XULRunner has been quite successful for such a complex technology. Some rather big companies believed enough in it to implement apps that, even if you don't know their name, are still everywhere. As an example, here's at least one very large automotive group in Europe, a world-wide known brand, that uses XULRunner in all its test environments for car engines. That means all garages dealing with that brand use a XULRunner-fueled box...
But unfortunately, XULrunner was never considered as essential, up to the point its name is still a codename. For some time, the focus was instead given to GRE, a shared runtime that was doomed to fail from the very first minute.
Update: XULRunner just died...
Asian market 2005 While the Asian market was exploding, Gecko was missing a major feature: vertical writing. It prevented Asian embedders from considering Gecko as the potential rendering engine to embed in Ebook reading systems. It also closed access to the Asian market for many other usages. But vertical writing did not become an issue to fix for Mozilla until 2015.
Thunderbird 2007 Despite of growing adoption of Thunderbird in governmental organizations and some large companies, Mozilla decided to spin off Thunderbird into a Mail Corporation because it was unable to get a revenue stream from it. MailCo was eventually merged back with Mozilla and Thunderbird is again in 2015/2016 in limbos at Mozilla.
Client Customization Kit 2003- Let's be clear, the CCK has never been seen as a useful or interesting project. Maintained only by the incredible will and talent of a single external contributor, many corporations rely on it to release Firefox to their users. Mozilla had no interest in corporate users. Don't we spend only 60% of our daily time at work?
E4X 2005-2012 Everyone had high expectations about E4X and and many were ready to switch to E4X to replace painful DOM manipulations. Unfortunately, it never allowed to manipulate DOM elements (BMO bug 270553), making it totally useless. E4X support was deprecated in 2012 and removed after Firefox 17.
Prism (WebRunner) 2007-2009 Prism was a webrunner, i.e. a desktop platform to run standalone self-contained web-based apps. Call them widgets if you wish. Prism was abandoned in 2009 and replaced by Mozilla Chromeless that is itself inactive too.
Marketplace 2009 Several people called for an improved marketplace where authors could sell add-ons and standalone apps. That required a licensing mechanism and the possibility to blackbox scripting. It was never implemented that way.
Browser Ballot 2010 The BrowserChoice.eu thing was a useless battle. If it brought some users to Firefox on the Desktop, the real issue was clearly the lack of browser choice on iOS, world-wide. That issue still stands as of today.
Panorama (aka Tab Groups) 2010 When Panorama reached light, some in the mozillian community (including yours truly) said it was bloated, not extensible, not localizable, based on painful code, hard to maintain on the long run and heterogeneous with the rest of Firefox, and it was trying to change the center of gravity of the browser. Mozilla's answer came rather sharply and Panorama was retained. In late 2015, it was announced that Panorama will be retired because it's painful to maintain, is heterogeneous with the rest of Firefox and nobody uses it...
Jetpack 2010 Jetpack was a good step on the path towards HTML-based UI but a jQuery-like framework was not seen by the community as what authors needed and it missed a lot of critical things. It never really gained traction despite of being the "official" add-on way. In 2015, Mozilla announced it will implement the WebExtensions global object promoted by Google Chrome and WebExtensions is just a more modern and better integrated JetPack on steroids. It also means being Google's assistant to reach the two implementations' standardization constraint again...
Firefox OS 2011 The idea of a linux+Gecko Operating System finally touched ground. 4 years later, the project is dead for mobile.
Versioning System 2011 When Mozilla moved to faster releases for Firefox, large corporations having slower deployment processes reacted quite vocally. Mozilla replied it did not care about dinosaurs of the past. More complaints led to ESR releases.
Add-ons 2015 XUL-based add-ons have been one of the largest attractors to Firefox. AdBlock+ alone deserves kudos, but more globally, the power of XUL-based add-ons that could interact with the whole Gecko platform and all of Firefox's UI has been a huge market opener. In 2015/2016, Mozilla plans to ditch XUL-based add-ons without having a real replacement for them, feature-per-feature.
Evangelism 2015 While Google and Microsoft have built first-class tech-evangelism teams, Mozilla made all its team flee in less than 18 months. I don't know (I really don't) the reason behind that intense bleeding but I read it as a very strong warning signal.
Servo 2016 Servo is the new cool kid on the block. With parallel layout and a brand new architecture, it should allow new frontiers in the mobile world, finally unleashing the power of multicores. But instead of officially increasing the focus on Servo and decreasing the focus on Gecko, Gecko is going to benefit from Servo's rust-based components to extend its life. This is the old sustaining/disruptive paradigm from Clayton Christensen.

(I hope I did not make too many mistakes in the table above. At least, that's my personal recollection of the events. If you think I made a mistake, please let me know and I'll update the article.)

Let's be clear then: Mozilla really succeeded only three times. First, with Firefox on the desktop. Second, enabling the Add-ons ecosystem for Firefox. Third, with its deals with large search engine providers. Most of the other projects and products were eventually ditched for lack of interest, misunderstanding, time-to-market and many other reasons. Mozilla is desperately looking for a fourth major opportunity, and that opportunity can only extend the success of the first one or be entirely different.

The market constraints I see are the following:

  • Native apps have won
  • Mozilla's reputation as an embedded solution's provider among manufacturers will probably suffer a bit from Firefox OS for phones' death. BTW, it probably suffers a bit among some employees too...

Given the assets and the skills, I see then only two strategic axes for Moz:

  1. Apple must accept third-party rendering engines even if it's necessary to sue Apple.
  2. If native apps have won, Web technologies remain the most widely adopted technologies by developers of all kinds and guess what, that's exactly Mozilla's core knowledge! Let's make native apps from Web technos then.

I won't discuss item 1. I'm not a US lawyer and I'm not even a lawyer. But for item 2, here's my idea:

  1. If asm.js "provides a model closer to C/C++" (quote from asmjs.org's FAQ), it's still not possible to compile asm.js-based JavaScript into native. I suggest to define a subset of ES2015/2016 that can be compiled to native, for instance through c++, C#, obj-C and Java. I suggest to build the corresponding multi-target compiler. Before telling me it's impossible, please look at Haxe.
  2. I suggest to extend the html "dialect" Gaia implements to cross-platform native UI and submit it immediately to Standard bodies. Think Qt's ubiquity. The idea is not to show native-like (or even native) UI inside a browser window... The idea is to directly generate browser-less native UI from a html-based UI language, CSS and JS that can deal with all platform's UI elements. System menus, dock, icons, windows, popups, notifications, drawers, trees, buttons, whatever. Even if compiled, the UI should be DOM-modifyable just like XUL is today.
  3. WebComponents are ugly, and Google-centric. So many people think that and so few dare saying it... Implementing them in Gecko acknowledges the power of Gmail and other Google tools but WebComponents remain ugly and make Mozilla a follower. I understand why Firefox needs it. But for my purpose, a simpler and certainly cleaner way to componentize and compile (see item 1) the behaviours of these components to native would be better.
  4. Build a cross-platform cross-device html+CSS+JS-based compiler to native apps from the above. Should be dead simple to install and use. A newbie should be able to get a native "Hello World!" native app in minutes from a trivial html document. When a browser's included in the UI, make Gecko (or Servo) the default choice.
  5. Have a build farm where such html+CSS+JS are built for all platforms. Sell that service. Mozilla already knows pretty well how to do build farms.

That plan addresses:

  • Runtime requests
  • Embedding would become almost trivial, and far easier than Chromium Embedded Framework anyway... That will be a huge market opener.
  • XUL-less future for Firefox on Desktop and possibly even Thunderbird
  • XUL-less future for add-ons
  • unique source for web-based app and native app, whatever the platform and the device
  • far greater performance on mobile
  • A more powerful basis for Gaia's future
  • JavaScript is currently always readable through a few tools, from the Console to the JS debugger and app authors don't want that.
  • a very powerful basis for Gaming, from html and script
  • More market share for Gecko and/or Servo
  • New revenue stream.

There are no real competitors here. All other players in that field use a runtime that does not completely compile script to native, or are not based on Web Standards, or they're not really ubiquitous.

I wish the next-generation native source editor, the next-gen native Skype app, the next-gen native text processor, the next-gen native online and offline twitter client, the next native Faecbook app, the next native video or 3D scene editor, etc. could be written in html+CSS+ECMAScript and compiled to native and if they embed a browser, let be it a Mozilla browser if that's allowed by the platform.

As I wrote at the top of this post, you may find the above unfeasible, dead stupid, crazy, arrogant, expensive, whatever. Fine by me. Yes, as a strategy document, that's rather light w/o figures, market studies, cost studies, and so on. Absolutely, totally agreed. Only allow me to think out loud, and please do the same. I do because I care.


  • E4X added
  • update on Jetpack, based on feedback from Laurent Jouanneau
  • update on Versioning and ESR, based on feedback from Fabrice Desré (see comments below)
  • XULrunner has died...

Clarification: I'm not proposing to do semi-"compilation" of html à la Apache Cordova. I suggest to turn a well chosen subset of ES2015 into really native app and that's entirely different.


1. On Monday 8 February 2016, 15:41 by Fabrice

The Versioning System and large corporation issue has been addressed by ESR releases which are similar to other Long Term Support options eg. for OSes.

2. On Monday 8 February 2016, 18:24 by Anders

I wouldn't say that asm.js is something Mozilla (as opposed to "others") "have in hand", as it is an open standard implemented by multiple browser teams.

> Mozilla had no interest in corporate users
You could also mention the lack of an MSI installer here. (searching for "chrome msi" gives you a beautiful page with a download button and "firefox msi" gives you some unofficial pages and a support page talking about Firefox 4)

> The idea is to directly generate browser-less native UI from a html-based UI language
Are you thinking of something like https://facebook.github.io/react-na... , but for desktop?

As an aside: I think React Native have demonstrated, that the lack of "JavaScript into native [machine code]" compiler (and use of a JIT) isn't a problem for building native apps). Indeed plenty are using the .Net-runtime (that is JIT'ed and GC'ed) to build native applications on windows. But embracing something like TypeScript might make it easier for compilers and developers alike to create big applications.

> Build a cross-platform cross-device html+CSS+JS-based compiler to native apps
Something like http://electron.atom.io/ ?

3. On Monday 8 February 2016, 19:38 by Thaddée Tyl

The plan you envision is not novel. That is not necessarily a bad thing. However, in this instance, it means competing against well-anchored actors.

Appcelerator Titanium has eight years of experience in the domain. It gives access to native-only APIs and targets iOS, Android and Windows Phone, all compiled from a single JS + XML codebase. Even after all those years, it experiences some difficulty in providing a UI that feels native in each platform. Furthermore, it has required a very large effort in producing adequate developer tools, which prompted them to acquire Aptana Studio. Arguably, Mozilla has improved its mobile devtools capabilities, but it is still far from an optimal experience.

Apache Cordova is another very large contender in this space. Unlike Titanium, it is actually using HTML and CSS (instead of some XML format). It also provides native-only APIs. It has garnered a lot of attention by playing very well with others. It supports a wild range of mobile platforms, and being open-source, many actors were able to contribute to it. Given its age and impact, a large number of tools have been developed for it, including Adobe PhoneGap — Adobe has a reputation of producing great tools.

More recently, React Native has endeared developers with a development cycle that is very close to that for the Web — Chrome DevTools and ⌘ + R, with optional live reload. Yet again, it has its own XML format with quite a few platform-specific elements.

This does not mean that I feel it is impossible for Mozilla to go this path. It is not obvious to me that it has a higher chance of success than Firefox OS for mobile had, however. Not because of AOT compilation of JS; but because of competition, tooling, and supporting many widgets on many platforms interoperably.

Building a business out of a build farm is unusual, although what matters most to current entries in the space is the development / debugging experience, not the ability to get an iOS app compiled on Mozilla's servers without having to check that it works. It is always necessary for developers to check that it works on each platform, and to debug for that platform when necessary. And if you're debugging it, you probably have compiled it. The business so far has mostly been found in tooling.

4. On Monday 8 February 2016, 19:48 by Daniel Glazman

@Thaddée: no, Apache Cordova and Titanium are only semi-native and that's not what I am proposing. I suggest to go far beyond that and be more in line with what Haxe does with its hxcpp lib.

5. On Monday 8 February 2016, 19:57 by Ben S.

Thank you for these positive thoughts.
Please keep thinking out loud. Keep protecting our loved and so precious open web.

Thank you for pointing out Mozilla's weaknesses that way. Firefox OS death has been some "hope breaking" news for me, as I dream of open devices using web technologies as a raw material. Today, we can see that nearly anything can be produced thanks to Web tech : 3D video games, musics, office-like software...
I can't imagine we cannot achieve one day to get a kind of OS we could install on any phone as we cn choose our OS on a PC.

6. On Monday 8 February 2016, 22:50 by Robert O'Callahan

Lots of things to argue about here, but just one point:

I'm not sure what you had in mind with "this is the old sustaining/disruptive paradigm from Clayton Christensen" re: Servo.

Nobody cares about Gecko qua Gecko. At Mozilla I think we'd be very happy if Servo cannibalized Gecko somehow. One problem is that Servo isn't ready to be a production browser engine yet, and even if we put all our resources into it it won't be for a while. Another problem is that a brand-new engine has the problem that without market share Web developers won't test with your engine, so sites don't work and you can't get market share; shipping Servo components in Gecko is a way to mitigate that problem.

7. On Monday 8 February 2016, 23:43 by mildred

Your post is refreshing. For the last few days, I have been deeply saddened by the current Mozilla strategy. It's been a long time that I'm thinking there is a need to take over and make good decisions for once. Seeing reactions like yours is just a sign that it is possible. Please make it happen else we are doomed.

8. On Tuesday 9 February 2016, 07:34 by LegNeato

@Thaddée FYI, React's JSX is merely syntactic sugar and compiles to pure JS functions. In fact, it is optional and you can call the JS functions directly.

@glazou: Interesting post, some points I agree with some I don't! For example, versioning/rapid release doesn't feel like it fits there. Also, it seems to be a success, regardless of what enterprises wanted / didn't get. Where would Mozilla be if they only released Firefox once a year? I'd argue completely irrelevant. Even IE has gone to the evergreen model of continuously releasing...

Of course, I am biased as I helped implement it and am advocating for Mozilla to get rid of ESR entirely!

9. On Tuesday 9 February 2016, 08:29 by Daniel Glazman

@roc: this isn't a new issue and Mozilla is not the first browser vendor facing a change of rendering engine. Servo is not even a product officially yet (https://support.mozilla.org/en-US/products) and it's not even visible from the home page. I hear what you said about "I think we'd be very happy if Servo cannibalized Gecko somehow" but this is not how it is perceived externally. And sorry, I still don't think it's a good strategy.

10. On Tuesday 9 February 2016, 11:18 by Olivier

Nice article!
Don't forget Mozilla also focused on integrating useless stuff in Firefox like "Hello" and "Pocket", instead of focusing on web standards (eg: input date fields are still missing in FF44).

11. On Tuesday 9 February 2016, 15:53 by Fabrice

I understand why you are coming up with this "compile html/css/js to native" proposal, and I agree this is very different from hybrid toolkits.

In some way, this is similar to FirefoxOS packaged apps: all web tech, but not really webby. For sure by targeting existing successful ecosystems you get more reach, but that doesn't address the more fundamental issues. This is not taking advantage of the unique strengths of the web, like linkability. So... it's a bit like acknowledging that the web as a platform has lost, and trying to save some pieces here and there. I'm not convinced that this is really Mozilla's mission, but for sure could be an interesting project!