“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.
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?
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 and was marked obsolete a few years later. 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.
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:
Apple must accept third-party rendering engines even it's necessary to
sue Apple.
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:
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.
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.
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.
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.
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.