I think this slightly understates the "business development" problems with developing a new OS, and a mobile OS in particular. It turns out that there are certain apps that, if they are not available on your platform, are immediate deal breakers for huge numbers of consumers (to the extent that they will ask for them by name in stores and return devices that won't run them). Often these apps lack web frontends (for non-technical reasons).
Obviously there are technical workarounds that you can attempt but consumers are wary of "knock off" products. So there is a vicious cycle in which people won't produce the content that you need to get users until you already have users. Possibly one can break this by supporting Android apps, but you would have to make the experience as good as an actual android device, which seems both demanding and limiting (because of cross-app interactions via e.g. intents).
WhatsApp was the big missing app for Firefox OS. In Mozilla's target markets, WhatsApp was huge but the company didn't want to invest any engineering resources to support Firefox OS, understandably. Firefox OS was an unproven OS with no market share and no J2ME support.
In response, Mozilla Research started a "j2me.js" project to try running the WhatsApp J2ME app in JavaScript, sharing some code with the Shumway project to run Flash content. If that worked well enough, maybe WhatsApp would become interested. It did actually kinda work, but the project did not proceed for a number of reasons. Also, j2me.js was renamed "PluotSorbet", due to trademark concerns:
I read somewhere that supporting "ancient" mobiles via j2me was the reason WhatsApp got the advantage over other chat apps. Yes, they (did) put a lot of effort in supporting j2me phones.
bubble-vision. Whatsapp was pretty much messaging standard in South America, non-UK Europe, Russia and non-China SE Asia and I bet those were not majority iOS markets then nor now.
Actually, WhatsApp runs on Symbian and Series 40. Many, possibly most, people who use WhatsApp run it on devices that arguably aren't even smartphones.
Yeah. I live in South Korea, which is dominated by a local instant messenging platform, KakaoTalk. Anyone who cares to be social is on KakaoTalk. Text, photo, video, files, appointments, notifications, polls, payments, booking a hairdresser ... the list of things that are done through Kakao is long. A phone without a KakaoTalk client is useless.
I guess his response would be that the web-based approach changes the pitch from "make a version of KakaoTalk for our mobile OS" to "make a web version of KakaoTalk, which also runs on our mobile OS" along with "and you don't even need to talk to us for deployment".
> [biggest Achievements] Product — Successfully launched 20 devices in over 30 countries, mobilised the Mozilla community to help run launch parties and created slick branding and marketing campaigns
Therein lies the rub. The products were all mediocre-specced handsets from little known manufacturers. So, right from the outset Firefox OS felt like a down-market 'landfill Android' type product.
I'd have bought a Firefox OS phone in a heartbeat, if it felt like an upgrade [or even a sidegrade] from my existing phone. But the specs for the most top of the range model available were actually worse than those of my existing 3+ year old Android model.
Sadly, this 'pursuit of mediocrity' sees a lot of OSS projects shoot themselves in the foot.
You do have to understand that they also had no realistic chance of pursuing a top-tier device in a top-tier country. HTML-based UI:s (rendered on gecko) just aren't there in terms of performance.
Which leads to the question... why the heck did they pursue this in the first place? I would point at Mozilla management incompetency (Mitchell Baker etc).
My thoughts: They didn't do any technical/performance feasibility study before embarking on this adventure; rather relied on vaguer terms these people are atuned to (equality, openness, freedom, etc) rather than hard technical facts.
> HTML-based UI:s (rendered on gecko) just aren't there in terms of performance
I'm actually going to quibble with this. Having ran Firefox OS 2.1 on the original (crappy hardware) Flame, all of the main UI and built-in apps were buttery smooth. I wasn't expecting this, and it kind of blew me away.
I never got my grubby hands on a Firefox OS device. All of the reviews I read were unanimous in their dislike (because of framerate issue, primarily) though. What happened here?
New software. The version of FXOS that came with the Flame (1.0) was... not good at all. 1.1 and 1.2 added some niceties that started to make it usable as a daily driver phone; 1.3 added async pan and made things feel slick; and 2.0+ were just lovely.
So.. the best of the best kind of browser people at Mozilla optimized the HTML/JS/CSS and reached their target after a while.
This makes sense with my experience from Opera Software (who also tried to build a browser OS, but way back in 2003-2004 and quickly retreated after it failed):
The main issue here is that writing a performant HTML-based UI is a very complex thing. It works great when people who really understand the entire web platform writes the software, but breaks down when regular web devs are supposed to write "HTML apps" for it.
Meanwhile, the usual mindless singsong around HTML UIs is amongst the lines of "now 10 (or is it 20 now?) web developers can write mobile UI:s; they don't need to learn native Android or iOS development."
My main point here is that the HTML way is a lie. It's easy to make something that looks good; and it's insanely hard to make it perform well.
I mean, not to be flippant, but... that's just like your opinion.
Of course not anybody can make a well-performing web app, just like not just anybody can make a well performing Android app. In some ways, yes, it is a little more difficult.
But speaking as a C programmer who was pleasantly surprised by the change, it's not that difficult to make a performant web app. I've never had a problem with it.
Of course not *anybody* can make a well-performing web app, just like not
just anybody can make a well peforming Android app.
Now that's a false equivalence if I've ever heard one. Making a well-performing mobile website that does more than display text is really difficult. The tools one uses to build and test websites are all geared towards desktop development. Only recently have we begun to see browser vendors adding support to their dev consoles for mobile devices, and those tools still aren't nearly as extensive as the tools one uses for native app development.
Moreover, both iOS and Android have pretty decent documentation around how to use their APIs and what one needs to do to make an app that responds to user input nearly instantly. For the web... well, to call Javascript performance tuning folklore does a disservice to folklore. It's more like rumor and witchcraft.
Speaking as a C programmer who was pleasantly surprised by the change
Well, that sort of explains it, I guess. You moved from one platform with crappy tooling to a platform with ever so slightly less crappy tooling. Of course things look like an improvement to you. Meanwhile, to programmers coming in from Java, .Net, or other, more "corporate" languages, the lack of tool support for Javascript makes it really difficult to write good apps in a reasonable amount of time.
Now you might just say, "Well those guys are just shitty programmers." Fine. I agree with you. But somehow, Android and iOS allow even shitty programmers to write functional workaday mobile applications. HTML and Javascript do not (at least, not on mobile). So by that standard, HTML/JS is an objectively worse platform.
Wait what? It is insanely complex to make a performant web app compared to a performant C app (let's say we're using a traditional UI toolkit as a comparison).
You need to understand the DOM (and how various CSS declations contribute to rendering complexities), the rendering model, reflows, work around them, pre-fetch tricks, etc etc. Not saying anything like this impossible, but I'm pretty sure the claim that "oh all web devs can do this" is invalid. Basically; the performance issue with declarative UIs is that it's really easy to declare something very complex by mistake.
That was their strategy though- if they tried to introduce it as an alternative to iOS and Android, it was guaranteed DOA. They felt they could get it off the ground by introducing it as an alternative in poorer countries first. It might not have been a strategy that worked out in the end, but those were intentional choices, not choices made from ignorance or stupidity. Even though it didn't work out, it was probably much more likely to succeed than if they had gone the 'take on iOS and Android on the high end' strategy first. That would have been akin to the Chromebook Pixel- possibly an impressive product, possibly a product beloved by a very small group of people, but ultimately not something that a meaningfully-sized market existed for.
It would have a much higher chance of success if they didn't strip out Android layer completely but instead combined web apps with Android app on (opensource) Android core. It is very difficult to get initial traction - even Amazon mostly failed, and they build on Android.
One of lessons that Dell learned: do not create low-end laptops with Linux. The Linux users won't be interested in weak hardware and those who want to save the money, will be disappointed, because they do not realize that there's no Windows before the purchase.
That's why the project Sputnik used a machine from the higher end of the spectrum - and it was a success.
It seems like to get your mobile OS into the door, you need to have your foot into two doors- competitively priced, cheap phones to snap up underserved demographics (in this case, developing world markets), but also a flagship device to enthrall the upper tier of the market and get name recognition.
Seems like Ubuntu Touch is also facing such struggles ticking both boxes (they still don't have a flagship product, especially after the failure of the Ubuntu Edge campaign), and Windows Phone had some impressive Lumia phones with fancy cameras but I don't recall that they ever tried to fight Android on the lower end of the market.
Windows Phone had some impressive Lumia phones with fancy cameras, but I
don't recally that they ever tried to fight Android on the lower end of the
market.
If anything, my impression is of the exact opposite. Windows phone tried to fight Android on low and mid-range handsets and abandoned the high-end to Apple. The later Lumias (the 650s and the 950s) were all in the 3-400 "midrange" that's dominated by Android. Microsoft hasn't put out something that attempts to compete with Apple in quite a long time.
I still see no reason why they couldn't reboot the project and agree with his thinking here: "Create a mid-range tablet ... Carve out a niche in developed markets first ... Firefox OS was actually five years too early!"
I always thought they were trying to put a ChromeOS competitor on a phone when it actually belonged on laptops, tablets and 2-in-1s (to start). I would have been very interested in a device running an extension-rich privacy-respecting browser, using open tech, focused on education and as a device to develop for.
It's essentially Mozilla's mission statement made into physical form. Dealing with corporate interests, as the article suggests, forced Mozilla to diverge from their base (end-users). It was a learning experience, that was all.
I don't actually expect the project to be revived and that's a real shame given the hostility of the alternatives (not including Linux, etal) available to (the rest of) us.
I'd argue the same thinking could have been applied--perhaps moreso--to Palm/HP's webOS, which was thrusting in the same direction as mid-range tablet OS with the Touchpad, and into a desktop-capable OS (demonstrated in early state) before its EOL.
Plenty of parallels between the two OSes, down to some of the personnel who bailed to Firefox OS from HP.
At the end of the day the web is interpreted, and developed on desktop computers.
This result in two problems when doing web first on mobile.
1: bloated frameworks. Both in term of CPU usage, memory consumption, and the number of round trips needed to show something like a simple list of links.
2: "mobile" sites that may look right at first glance but that invariably show themselves to have elements that hint at having been designed on a large screen computer with a mouse attached.
But what sank FFOS was its availability. Its concept fitted perfectly into the SV mindset and the ongoing "maker" thinking.
But they were launched and sold to the "third" world as spruced up featurephones.
> bloated frameworks. Both in term of CPU usage, memory consumption, and the number of round trips needed to show something like a simple list of links.
You combine this with the fact they were targeting the low-end, entry level marketspace. and you have a recipe for failure. At a time when even low-end Android phones had finally overcome their sluggishness, the first Firefox OS device that I tried felt slow and unresponsive.
Unfortunately for Mozilla, the reality is that Google, with its combination of large marketshare, aggressive timelines, and wide platform penetration (on both their own first-party and others' third-party platforms) had accomplished more in enhancing the capabilities of code loaded by the Web: they develop all sorts of APIs to expose native platform functionality inside Javascript running inside the browser, ship them in Chrome, then submit most of them to W3C and evangelize their merits. The most trashy ones they deprecate in two or three years, replace it with a different, incompatible take, and remove support for it in a few versions.
The author's 'Lessons Learned' section reads as a wishful vision of web browsers themselves, which, is both surprising in its lack of differentiation, and yet simultaneously ambitious in its hopes of being able to culture a... what's the word? 'platform'? 'ecosystem'? 'environment'? where well-executed server-side technologies interact with thin but slick clients; how is this different from the existing web and its browsers again? Does the point then become to offer a FOSS low-level system OS on top of which a browser can run? Isn't this one of the few successes of B2G, yet also operates in a space entirely dependent on the whims of hardware vendors, and competes with the likes of Tizen, Sailfish OS, AOSP, and the Linux kernel itself?
The retrospective is interesting: a dissenting opinion from an inside source, and it definitely sheds light on some important details that were glossed over or ommitted from the more 'political', corporate communiqués. But the conclusions are unsatisfactory: the preferred outcome reads less like "Boot to Gecko" than "Boot Only to Gecko", which sounds a lot like Chromebooks. The difference being, of course, that Google has a diverse (if frequently culled) selection of web-accessible services that together can be used as a computing and browsing platform, feeding search and browsing metadata and usage habits to Google thanks to the power of defaults. What could Mozilla have offered in this space to realistically take on the exact same frenemy with a larger warchest?
I don't understand why they decided that Firefox OS would be a good fit for low-end hardware, when they had empirical evidence of how poorly webOS performed.
Firefox OS and webOS are essentially the same concept. Palm built theirs for 2009 top-end hardware, and it turned out that the hardware just wasn't quite enough to run a browser engine for the entire UI... And then Mozilla goes ahead and tries to do the same thing on low-end hardware that was worse than the Palm Pre.
What was the rationale here? I can only imagine this choice was imposed by the hardware partners they could round up. If so, it's a classic example of how engineering and business development manage to undermine each other to destroy a product.
This is addressed in the linked article in great depth.
I don't think the poor performance of WebOS means that approach is fundamentally doomed, especially since FirefoxOS was a few years later... a few years during a period of massive year-over-year increases in mobile computing power.
Long story short: relative to Android, they were bypassing the whole Java layer. Gecko (which is pretty mature + optimized) was essentially running on bare metal. Lose some performance here, gain some performance there. They felt this would offer strong performance.
Now, to be honest, I literally have no idea how this played out in reality. Never even touched a FirefoxOS device.
But, theoretically, there's no reason why this approach can't be pretty fast. At some point your apps need to talk to a widget-drawing layer. If implemented well there's no reason why an HTML-based approach can't be pretty darn fast, or at least fast enough not to be the limiting factor in your phone's performance.
Lol what? Relative to Java which is maybe 50% slower than native... they used Gecko, which is at least 100% slower than native in practice. There are huge obvious well-explored reasons why this can't be fast.
> Palm built theirs for 2009 top-end hardware, and it turned out that the hardware just wasn't quite enough to run a browser engine for the entire UI
I owned a first-gen Palm Pre, and this was not my experience. It had plenty of problems, but the UI was always responsive and pleasant to use. (More pleasant than I find Android today, on much beefier hardware nearly a decade later.)
Chrome (and v8) launched in 2008. When webOS came out, we were still early in the performance wars. Since then, browsers have become far faster using the same hardware. Layout engines have also gotten far faster (and added a lot of features). To make things worse than necessary, webOS used outdated versions of Qt webkit and v8. Unfortunately, it seems that nobody on the webOS team ever got permission to focus on non-feature work like speeding up performance (seriously, 2 minute startup time when you only have three devices?)
The UI/UX for webOS was fantastic. I really wish FF (or really anyone) would have used that UI/UX as nothing since has come close.
> I can only imagine this choice was imposed by the hardware partners they could round up.
What do you mean? Seems like this was fundamentally Mozilla imposing their philosophy/faith in their web technology/platform on hardware partners rather than the other way around? (And I believe the article supports that interpretation).
I meant the choice of low-end hardware. I feel like they could have been more successful in the ~$200 market where Nokia Lumia models did well for a while, but presumably the hardware partners didn't want to build those. And meanwhile engineering was set on a path that wouldn't work for $40 phones.
> What I Would Do Differently Today ... Product — Not try to create the cheapest smartphone.
But, then who will? Firefox OS allowed you to run a full HTML5 browser on a phone with half the specs of Android[1]. They sold a phone for $33 that was (and still is) the cheapest thing to run Youtube and Wikipedia! The only huge technological advantage Firefox OS had was the fact that Boot-to-Gecko didn't have the overhead of a middle layer virtual machine (like android). That's a HUGE deal if you are resource constrained, which means you can offer a ton more features for the same price on cheap smartphones.
And who uses cheap phones? The developing world, who more than anyone need access to modern information. Firefox OS shouldn't have seen itself as competing with Android. It should have seen itself as competing with flip phones. The amount of societal good Mozilla could have done by focusing on being a cheap "next-step" flip phone alternative is astounding. Here's a comment I wrote several years back when the $33 phone came out:
---------
I've been a huge fan of Firefox OS for a long time[1], but here's something I think many people here aren't realizing: Firefox OS considerably lowers the barriers to entry for app developers.
Firefox OS apps are just html pages in a zip file, so all you need to create one is a text editor and a browser. In fact, Firefox will soon include an IDE[2], so you don't even need a text editor anymore. I think that will have a massive impact on how many developers will make apps for Firefox OS, especially local developing world apps.
If you only have non-administrator access to a computer in an internet cafe or some other shared computer, you can probably still develop Firefox OS apps since it may already have Firefox installed. Additionally, there's millions of tutorials online about web development, many of which are very beginner friendly and in multiple languages.
This extremely low barrier to entry will allow local communities to easily make apps that cater to just their local needs. Want to know where the best location to get water is? Want to know which farms in the area are hiring? Want to see the local mayor's latest scandalous photo? These all can be coded in a weekend at the local internet cafe.
> Want to know where the best location to get water is? Want to know which farms in the area are hiring? Want to see the local mayor's latest scandalous photo? These all can be coded in a weekend at the local internet cafe.
These could also just be implemented as web ... sites.
Few have cheap internet access (just texts, calls, and small amounts of data), so you shouldn't assume your audience has easy access to it in local villages.
> And nearly every platform where web apps would work.
What platforms? Android is too expensive. Feature/flip phones don't run web apps.
So, yes, my point was that FirefoxOS was the only platform that had the potential to offer widespread web app access to this audience. Also, since FirefoxOS web apps could be zip files, they didn't necessarily have to have internet access to run and could be passed around via sneakernet.
These are also all possible with Service Worker enabled web sites. IMO that's the best possible model - no app store friction, you start using the site immediately, then add to your home screen.
But what phone under $35 is able to run Service Workers? FirefoxOS is still the only one that can pull that off. Android 4.0+ can't run on hardware that cheap.
So much of the story and motivation around FirefoxOS seemed to be: "we want to take web browser technology and build a smartphone around it."
Or interpreted another way: "Our agenda is to take technology X and apply it to a problem domain that would not seem like a natural fit for it."
Meanwhile their competitors were trying to out-do each other in trying to produce devices that would satisfy consumers the most (sell more). It was, and remains, a ferocious competition.
If you want success in the marketplace you need to focus on delivering customer value first, and put the technology agenda second (if not way behind other priorities).
>My main hope in documenting all of this is that Firefox OS is remembered as more than just a footnote in tech history which says “a failed mobile OS from Mozilla”.
I got one of the Mozilla Flame phones back when they came out and loved that device. I'm pissed that now the only option for a viable open source mobile OS I have is Google. But unless there is some unlikely comeback, that is exactly what it will be remembered as.
I disagree with some of the details of what they should have done better. But I do agree that it was too early to end the project and that it definitely had great potential in becomming a niche at least, from which it could grow.
>I'm pissed that now the only option for a viable open source mobile OS I have is Google
No one is forcing you to use Android and there are many alternatives. Additionally, there is no need to use Google services when setting up an Android phone. To be "pissed" that the only option you have is Google just reinforces my belief that Google should have closed sourced it from the beginning. The amount of entitlement some people think they have for an OS that is given away and costs millions to create is bizarre to me.
They should have forked AOSP instead and included F-Droid and Firefox by default. Maybe tweaked some things, like replacing WebView with a Gecko solution, adding first-class Web app support, etc.
Web apps would also have to get permissions like native apps.
But you're right that some permissions like complete file access might be a bit too much. They could implement it so that only signed Web apps installed through the app store would get such permissions.
The problem is not only permissions. The problem is that code execution model within anything a mile close to web and browsers is a security threat by itself.
Take Elop out of the picture and they did just fine. He did everything he could to destroy Meego.
They launched the n9 without marketing and only made it available in secondary markets, but people still beat down a path to get them. Elop also refused to provide sales numbers (instead writing the infamous "burning platform" email), but third party guesstimates are in the 4-8M (for comparison, the subsidized, heavily marketed, easily available S3 sold around 40M units in the same year).
Elop even refused to launch the n950 (aluminum n9 with a great physical keyboard) despite it being ready to go (they shipped around 5K as developer units).
Nokia had the answer. Elop was paid 25 Million to killed it.
I would agree that the timing of FirefoxOS is too early rather than too late.
Another infuriating thing is that they decided to focus the FirefoxOS on the cheapest smartphone. You have to remember the one who buy these cheap phones, of course they will be concern about their ISP price too. In the end it would be better for them just to buy a feature phones. Eventhough Firefox OS can work offline, most of the advantage of FirefoxOS is on the web interaction. They really should target urban customer
As mobile hardware becomes more commoditised it would be trivial today to find white label hardware on which to run our software. There’s also a real desire from OEMs to loosen their dependence on Google and differentiate themselves.
Is there a Moore's Law for every type of physical constraint? As with cheaper and more abundant microprocessors, broadband, storage, etc., it seems like previously unfeasible produces and services become unlocked, the business ideas now feasible. FFOS did not arrive at the right time to reap in the benefits of the rise of Chinese smartphone OEMs, and the growing push-pull between Google and OEMs over Android.
> Qualcomm, the first chipset manufacturer we were working with, would not license their firmware and device drivers to us directly, it had to be through a carrier or OEM. This meant that we legally couldn’t ship complete builds
What? Why are chipset manufacturers not permitted to sell to anybody?
I bought a Panasonic TV because it was said to have the best UI. It used Firefox OS. The UI was OK - I have nothing to compare it to since I didn't have a TV for 10 years. Anyway, they stopped Firefox OS development soon after. I wonder if I can install another OS?
I always wondered why they target the low end of the market. There are so many compromises and constraints that the only redeeming feature ends up being the price.
In some fields, incremental enhancement isn't enough, and that, I believe, is what killed Firefox phones. They've shown that their excellent engineering allows to run better code on cheaper spec - but people still buy phones for numbers in specs, not performance.
thanks for sharing this. It was nice to see this week with the lumia launch, how many people want a low-stress mobile phone, that doesn't beep, and doesn't track your every move.
b2g could have been amazing to a mobile industry that feels shallower each quarter.
Obviously there are technical workarounds that you can attempt but consumers are wary of "knock off" products. So there is a vicious cycle in which people won't produce the content that you need to get users until you already have users. Possibly one can break this by supporting Android apps, but you would have to make the experience as good as an actual android device, which seems both demanding and limiting (because of cross-app interactions via e.g. intents).