Firefox Operating System: Finally Launched at Mobile Congress 2013(technogist.com)
technogist.com
Firefox Operating System: Finally Launched at Mobile Congress 2013
http://www.technogist.com/2013/03/firefox-operating-system-launched.html
6 comments
I could see Ubuntu become the main alternative to Android for manufacturers, because Canonical will make it easy to piggyback on Android drivers, so it should be very easy for manufacturers to port Ubuntu to their devices. It also gives them at least as good customization power as Android, and the hacking/ROM community are going to love it, which I think is a good way to get people excited about a device/OS online these days.
WP8 doesn't give them any of that, it's been stagnating at 2% for more than 2 years and a half, and besides perhaps helping Nokia a bit (while being a much smaller company than they used to be, so easier to be "satisfied" with it), there's nobody really benefitting from supporting it in terms of sales. So Ubuntu would be a great WP8 replacement there, and as a strong customizable alternative to Android.
As for Firefox OS, I guess it depends on how well this ChromeOS/FF OS thing will work. And if it does, it probably only works on the low-end, at least for the next 5-10 years, when data will be so cheap, that using web apps won't be a problem anymore (although you can still use "native" web apps in FF OS, just like in Ubuntu Touch, so I guess there's that, too).
But since FF OS is going to be used mostly on low-end devices, that means it could be on a lot of devices as well, so it could do well in terms of market share (or at least well enough to give a company like Mozilla good revenues). For the same reason, I don't really see FF OS and Ubuntu competing with each other, since Ubuntu will be more on devices with at least a quad core A9/A53 or dual core A15/A57.
The only way they are competing with each other is manufacturer's attention. Some of them may not be ready to take on more than 2 operating systems at once, and if they have already committed to FF OS, then it might take stronger persuasion to start supporting Ubuntu as well, to have an alternative for high-end Android devices.
Android will continue to compete with both, at the low-end and at the high-end, although I think Google needs to make Android 5.0 a little leaner to put it back into the Gingerbread-range of resources needed, if they want Android to go hard into the sub-$50 phone market.
WP8 doesn't give them any of that, it's been stagnating at 2% for more than 2 years and a half, and besides perhaps helping Nokia a bit (while being a much smaller company than they used to be, so easier to be "satisfied" with it), there's nobody really benefitting from supporting it in terms of sales. So Ubuntu would be a great WP8 replacement there, and as a strong customizable alternative to Android.
As for Firefox OS, I guess it depends on how well this ChromeOS/FF OS thing will work. And if it does, it probably only works on the low-end, at least for the next 5-10 years, when data will be so cheap, that using web apps won't be a problem anymore (although you can still use "native" web apps in FF OS, just like in Ubuntu Touch, so I guess there's that, too).
But since FF OS is going to be used mostly on low-end devices, that means it could be on a lot of devices as well, so it could do well in terms of market share (or at least well enough to give a company like Mozilla good revenues). For the same reason, I don't really see FF OS and Ubuntu competing with each other, since Ubuntu will be more on devices with at least a quad core A9/A53 or dual core A15/A57.
The only way they are competing with each other is manufacturer's attention. Some of them may not be ready to take on more than 2 operating systems at once, and if they have already committed to FF OS, then it might take stronger persuasion to start supporting Ubuntu as well, to have an alternative for high-end Android devices.
Android will continue to compete with both, at the low-end and at the high-end, although I think Google needs to make Android 5.0 a little leaner to put it back into the Gingerbread-range of resources needed, if they want Android to go hard into the sub-$50 phone market.
Firefox OS uses the Android kernel, so it benefits from Android drivers, too.
I'm looking forward to a more open development model, than the "dump here is the latest code" model Google seems to be using.
Patches accepted! :) https://github.com/mozilla-b2g/
The Gaia repo contains the JS application frameworks and system apps. The Gon repo is the Android-based kernel and userspace. I believe the name Gonk refers to the small rectangular robots from Star Wars.
The Gaia repo contains the JS application frameworks and system apps. The Gon repo is the Android-based kernel and userspace. I believe the name Gonk refers to the small rectangular robots from Star Wars.
Firefox OS devices will be first opened to the markets of the following countries: Brazil, Colombia, Hungary, Mexico, Montenegro, Poland, Serbia, Spain and Venezuela.
Wow this is the first global company I've seen opening up first to countries outside Western Europe + US/Canada. I wonder what the motivation for that is.
Wow this is the first global company I've seen opening up first to countries outside Western Europe + US/Canada. I wonder what the motivation for that is.
Probably the target consumers. From what I saw they're targeting the lower end of smartphones with cheaper devices and people in developing countries such as most of those above are more likely to buy something like that compared to US/Canada or Western Europe, where more people afford higher end devices.
As much as I want them to succeed, I don't think they have a chance in the western world if they don't polish their OS a bit first. I think this is exactly what they are trying to achieve by releasing the OS this way.
I think success requires much more than just some polish.
Based on the information available so far, it sounds like a very unappealing platform for developers. As a developer, you're essentially stuck using HTML, CSS, and JavaScript. I think this will drive away the best developers, who much prefer to use robust, mature languages like Java or Objective-C, rather than JavaScript. Likewise, the native frameworks of Android and iOS, for example, are much more pleasant and powerful to use than HTML and CSS.
It's not a recipe for success when good developers are driven away by a lousy technology stack. These are the developers that create the apps that really make a difference. Sure, a mediocre web developer may be able to create yet another to-do app for Firefox OS using HTML, CSS and JavaScript, but the value in what they produce is extremely minimal.
Without good apps, users will want nothing to do with it. Even then, it looks doubtful that this will offer any real benefit over the numerous existing mobile platforms. With it so unclear why developers would want to adopt it, and with it so unclear why users would want to adopt it, it just looks so much like a dead end.
Based on the information available so far, it sounds like a very unappealing platform for developers. As a developer, you're essentially stuck using HTML, CSS, and JavaScript. I think this will drive away the best developers, who much prefer to use robust, mature languages like Java or Objective-C, rather than JavaScript. Likewise, the native frameworks of Android and iOS, for example, are much more pleasant and powerful to use than HTML and CSS.
It's not a recipe for success when good developers are driven away by a lousy technology stack. These are the developers that create the apps that really make a difference. Sure, a mediocre web developer may be able to create yet another to-do app for Firefox OS using HTML, CSS and JavaScript, but the value in what they produce is extremely minimal.
Without good apps, users will want nothing to do with it. Even then, it looks doubtful that this will offer any real benefit over the numerous existing mobile platforms. With it so unclear why developers would want to adopt it, and with it so unclear why users would want to adopt it, it just looks so much like a dead end.
"when good developers are driven away by a lousy technology stack".
This fear of JavaScript and a web stack says a lot more about you than the technologies. There are a huge number of good developers creating great software with these languages. Coming from a Java and C# background, learning JavaScript has been a real joy and made me a much better developer.
In my experience, the best developers become productive in new languages very quickly.
This fear of JavaScript and a web stack says a lot more about you than the technologies. There are a huge number of good developers creating great software with these languages. Coming from a Java and C# background, learning JavaScript has been a real joy and made me a much better developer.
In my experience, the best developers become productive in new languages very quickly.
Oh, I don't "fear" JavaScript. It's quite the opposite situation. I have many years of experience with it, from using it with Netscape Enterprise Server in the 1990s, to browser-based development, to more recent server-side development.
Luckily, I also have many years of experience with many other programming languages and platforms. I can see quite easily how poorly JavaScript stacks up against them.
As an industry, we can do better. We have done better. It's not encouraging to see Firefox OS limit itself to the worst options available, when so much better could be done.
Luckily, I also have many years of experience with many other programming languages and platforms. I can see quite easily how poorly JavaScript stacks up against them.
As an industry, we can do better. We have done better. It's not encouraging to see Firefox OS limit itself to the worst options available, when so much better could be done.
Given Mozilla's goals for Firefox OS can you explain how these web technologies are anything but the best option? If you think that Java, C# or Objective C would have been better choices you've misunderstood what they're trying to achieve [hint: it's about creating a mobile OS by extending the world's most widely used technology stack].
By inclination I like languages that have seriously clever type systems, but I hardly ever write code in anything that is not javascript these days, and the reason for that is that javascript can be run easily almost anywhere.
I know that if I write some useful code in javascript, I will not have to rewrite it. You can't really say the same thing about any other language.
I know that if I write some useful code in javascript, I will not have to rewrite it. You can't really say the same thing about any other language.
With or without FirefoxOS, people are developing web apps. If somebody has a nice web app already, maybe they will look into whatever little bit of adaptation is needed for FirefoxOS.
> Based on the information available so far, it sounds like a very unappealing platform for developers. As a developer, you're essentially stuck using HTML, CSS, and JavaScript.
Saying you are stuck with JS is like saying iOS developers are stuck with ARM. Yes, underlying it all is ARM or JS on the respective platforms, but you can compile many other languages into those two: C#, C++, etc.
Saying you are stuck with JS is like saying iOS developers are stuck with ARM. Yes, underlying it all is ARM or JS on the respective platforms, but you can compile many other languages into those two: C#, C++, etc.
Elevating JavaScript to the pantheon of machine code ignores two simple and incontrovertible facts:
- JavaScript is significantly slower than ARM (even if you cheat and reference asm.js)
- JavaScript is not machine code.
- JavaScript is significantly slower than ARM (even if you cheat and reference asm.js)
- JavaScript is not machine code.
> - JavaScript is significantly slower than ARM
How much slower, in your opinion?
How much slower, in your opinion?
I don't see how opinion factors into this.
Mozilla estimates a best case of 2x slower than native with asm.js, and that's with a strict JavaScript subset that defines a machine translatable byte-code, coupled with a proprietary runtime to do the translation. They estimate 10x slower without that proprietary translation.
That's a ridiculous waste of resources, especially on battery-powered devices.
Mozilla estimates a best case of 2x slower than native with asm.js, and that's with a strict JavaScript subset that defines a machine translatable byte-code, coupled with a proprietary runtime to do the translation. They estimate 10x slower without that proprietary translation.
That's a ridiculous waste of resources, especially on battery-powered devices.
> Mozilla estimates a best case of 2x slower than native with asm.js
No, it's ~2x slower with the early prototype. It will get significantly faster than that.
> a proprietary runtime
The asm.js optimizations being worked on in Firefox do not match any definition of "proprietary" I ever heard. All the work is done openly and is open source, and that includes the spec, the Firefox optimizations and the emscripten support for asm.js.
> That's a ridiculous waste of resources, especially on battery-powered devices.
~2x slower than native is not optimal, sure. But it is in the same range of things like Java and C#, popular languages for mobile development (Android, Xamarin/Mono, etc.). And again, 2x is the starting point.
No, it's ~2x slower with the early prototype. It will get significantly faster than that.
> a proprietary runtime
The asm.js optimizations being worked on in Firefox do not match any definition of "proprietary" I ever heard. All the work is done openly and is open source, and that includes the spec, the Firefox optimizations and the emscripten support for asm.js.
> That's a ridiculous waste of resources, especially on battery-powered devices.
~2x slower than native is not optimal, sure. But it is in the same range of things like Java and C#, popular languages for mobile development (Android, Xamarin/Mono, etc.). And again, 2x is the starting point.
> No, it's ~2x slower with the early prototype. It will get significantly faster than that.
And we just need hardware XML accelerators and then XML will be great. This is not a new refrain from people who promote a subpar technology stack. Quality is just around the corner! We swear!
I'll believe it when I see it, and I'll be happy, because it'll mean that we're finally that much closer to the next step of dropping JavaScript as a first-order target entirely.
> The asm.js optimizations being worked on in Firefox do not match any definition of "proprietary" I ever heard. All the work is done openly and is open source, and that includes the spec, the Firefox optimizations and the emscripten support for asm.js.
It's not JavaScript. It's a custom VM built around a (bizarre) bytecode. The bytecode is an inefficient ASCII representation which happens to be interpretable as JS, but can't be interpreted as JS to actually be implemented efficiently -- which is to say, it's not really useful JS at all.
You may as well write a shell-script based ARM interpreter and call your ARM assembly "shell script". True, in a fashion, but also a totally pointless distinction. Everybody else will just call it "slow".
> ~2x slower than native is not optimal, sure. But it is in the same range of things like Java and C#, popular languages for mobile development (Android, Xamarin/Mono, etc.). And again, 2x is the starting point.
Android has the NDK for a reason, and even they are starting from a better position than trying to eek out runtime+rendering performance from an in-browser bytecode. Maybe on the web we'll get NaCL to serve the same purpose.
It'll be great if it all works out and we wind up with a cross-platform efficient and useful development target, with robust view management and event systems and common widget toolkits. Of course, at that point the web will look pretty much like the application development environments that we've been targeting for decades: operating systems.
And we just need hardware XML accelerators and then XML will be great. This is not a new refrain from people who promote a subpar technology stack. Quality is just around the corner! We swear!
I'll believe it when I see it, and I'll be happy, because it'll mean that we're finally that much closer to the next step of dropping JavaScript as a first-order target entirely.
> The asm.js optimizations being worked on in Firefox do not match any definition of "proprietary" I ever heard. All the work is done openly and is open source, and that includes the spec, the Firefox optimizations and the emscripten support for asm.js.
It's not JavaScript. It's a custom VM built around a (bizarre) bytecode. The bytecode is an inefficient ASCII representation which happens to be interpretable as JS, but can't be interpreted as JS to actually be implemented efficiently -- which is to say, it's not really useful JS at all.
You may as well write a shell-script based ARM interpreter and call your ARM assembly "shell script". True, in a fashion, but also a totally pointless distinction. Everybody else will just call it "slow".
> ~2x slower than native is not optimal, sure. But it is in the same range of things like Java and C#, popular languages for mobile development (Android, Xamarin/Mono, etc.). And again, 2x is the starting point.
Android has the NDK for a reason, and even they are starting from a better position than trying to eek out runtime+rendering performance from an in-browser bytecode. Maybe on the web we'll get NaCL to serve the same purpose.
It'll be great if it all works out and we wind up with a cross-platform efficient and useful development target, with robust view management and event systems and common widget toolkits. Of course, at that point the web will look pretty much like the application development environments that we've been targeting for decades: operating systems.
> It's not JavaScript. It's a custom VM built around a (bizarre) bytecode.
It is most definitely JavaScript. It runs perfectly in other browsers - in fact it often runs faster than non-asm.js compiled code, so it is worthwhile even without new optimizations for it.
It is also, in addition, optimizable like a low-level VM.
> Maybe on the web we'll get NaCL to serve the same purpose.
asm.js, by design, can have pretty much the same level of performance as NaCl. Both can use the same sandboxing mechanisms, for example. Unless there is something specific in the asm.js spec you feel is preventing some additional level of optimization that is possible in NaCl - if so, what?
It is most definitely JavaScript. It runs perfectly in other browsers - in fact it often runs faster than non-asm.js compiled code, so it is worthwhile even without new optimizations for it.
It is also, in addition, optimizable like a low-level VM.
> Maybe on the web we'll get NaCL to serve the same purpose.
asm.js, by design, can have pretty much the same level of performance as NaCl. Both can use the same sandboxing mechanisms, for example. Unless there is something specific in the asm.js spec you feel is preventing some additional level of optimization that is possible in NaCl - if so, what?
> It is most definitely JavaScript. It runs perfectly in other browsers - in fact it often runs faster than non-asm.js compiled code, so it is worthwhile even without new optimizations for it.
It can only run at speed if you interpret it as something that is not JavaScript.
In other words, the fact that it's valid JavaScript is essentially pointless, because it's totally useless (relative to actual native applications) unless you interpret it as something that's not JavaScript.
> asm.js, by design, can have pretty much the same level of performance as NaCl. Both can use the same sandboxing mechanisms, for example. Unless there is something specific in the asm.js spec you feel is preventing some additional level of optimization that is possible in NaCl - if so, what?
Stupid bytecode format aside (which incurs a cost for every single VM implementor, tool implementor, and developer that has to use the language, forever) ...
Here's a simple example: You can use NEON directly from NaCL/ARM. This matters on mobile. A lot.
Is asm.js going to define NEON and SSE intrinsics, too? If so, why the hell isn't asm.js just another output target for (P)NaCL so that people with Internet Explorer can run really really really really slow applications?
Or, how about the fact that NaCL can output ARM and x86 binaries directly, such that one doesn't need to AOT compile on every user's system, or introduce the cost, complexity, and overhead of JIT, when targeting standard/popular architectures.
How about this one -- I was going to write something up asking about thread-local storage and %gs-relative loads, or architecture-specific atomic operations on shared state, but then I realized -- asm.js doesn't define a threading model. At all. Unless I'm mistaken, it can't, because JavaScript itself doesn't define a shared state threading model.
It can only run at speed if you interpret it as something that is not JavaScript.
In other words, the fact that it's valid JavaScript is essentially pointless, because it's totally useless (relative to actual native applications) unless you interpret it as something that's not JavaScript.
> asm.js, by design, can have pretty much the same level of performance as NaCl. Both can use the same sandboxing mechanisms, for example. Unless there is something specific in the asm.js spec you feel is preventing some additional level of optimization that is possible in NaCl - if so, what?
Stupid bytecode format aside (which incurs a cost for every single VM implementor, tool implementor, and developer that has to use the language, forever) ...
Here's a simple example: You can use NEON directly from NaCL/ARM. This matters on mobile. A lot.
Is asm.js going to define NEON and SSE intrinsics, too? If so, why the hell isn't asm.js just another output target for (P)NaCL so that people with Internet Explorer can run really really really really slow applications?
Or, how about the fact that NaCL can output ARM and x86 binaries directly, such that one doesn't need to AOT compile on every user's system, or introduce the cost, complexity, and overhead of JIT, when targeting standard/popular architectures.
How about this one -- I was going to write something up asking about thread-local storage and %gs-relative loads, or architecture-specific atomic operations on shared state, but then I realized -- asm.js doesn't define a threading model. At all. Unless I'm mistaken, it can't, because JavaScript itself doesn't define a shared state threading model.
Slow is not always "totally useless". It just degrades gracefully. Furthermore, the fact that it's based on JS makes the integration with the DOM much easier.
The bytecode format is not as big of a deal as you claim. 1,000 lines of code for the verifier.
There's nothing intrinsic to JS that forbids having SIMD support. In fact, it's under active discussion...
Having two back ends for PNaCl seems suboptimal. Why force all Web developers to generate two bytecode formats because we don't like the way asm.js looks?
AOT compilation isn't a panacea. You still have to verify it. So it's not like the NDK could just be adopted to the Web as is. Besides, caching can mitigate the startup costs a lot.
Finally, JS has threading, and it could grow shared state threading in the future. This doesn't strike me as that big of an obstacle.
The bytecode format is not as big of a deal as you claim. 1,000 lines of code for the verifier.
There's nothing intrinsic to JS that forbids having SIMD support. In fact, it's under active discussion...
Having two back ends for PNaCl seems suboptimal. Why force all Web developers to generate two bytecode formats because we don't like the way asm.js looks?
AOT compilation isn't a panacea. You still have to verify it. So it's not like the NDK could just be adopted to the Web as is. Besides, caching can mitigate the startup costs a lot.
Finally, JS has threading, and it could grow shared state threading in the future. This doesn't strike me as that big of an obstacle.
> It can only run at speed if you interpret it as something that is not JavaScript.
By that argument any JS JIT is "no longer JS".
All JS JITS find cases where JS can be optimized as something simpler. For example CrankShaft and TraceMonkey find areas where variables are simply-typed and heavily optimize those.
This isn't surprising - to make JS be fast, you do need to find where you can make it go faster, by avoiding the "normal" JS dynamism where anything is possible. So the JIT optimizes it as something that is "not JS". Again, nothing new with asm.js there, JS JITs have been doing this since 2008 (and JITs in other languages far earlier).
> You can use NEON directly from NaCL/ARM [..] NaCL can output ARM and x86 binaries directly
Those are not portable, which JS must be. A better comparison might be PNaCl, which is like NaCl but has an intermediary portable format. PNaCl will of course have the same issues asm.js does with not having direct binaries that can just be loaded and run, not allowing use of CPU-specific code, etc.
If you don't care for portability, then the web/JS/asm.js/WebGL/etc etc. are likely not the best thing for you. Instead, a native app could make more sense.
By that argument any JS JIT is "no longer JS".
All JS JITS find cases where JS can be optimized as something simpler. For example CrankShaft and TraceMonkey find areas where variables are simply-typed and heavily optimize those.
This isn't surprising - to make JS be fast, you do need to find where you can make it go faster, by avoiding the "normal" JS dynamism where anything is possible. So the JIT optimizes it as something that is "not JS". Again, nothing new with asm.js there, JS JITs have been doing this since 2008 (and JITs in other languages far earlier).
> You can use NEON directly from NaCL/ARM [..] NaCL can output ARM and x86 binaries directly
Those are not portable, which JS must be. A better comparison might be PNaCl, which is like NaCl but has an intermediary portable format. PNaCl will of course have the same issues asm.js does with not having direct binaries that can just be loaded and run, not allowing use of CPU-specific code, etc.
If you don't care for portability, then the web/JS/asm.js/WebGL/etc etc. are likely not the best thing for you. Instead, a native app could make more sense.
Spain is in Western Europe
Spiritually it may as well not be. They usually stand on their own and stay out of the news when it comes to politics of Western Europe as a whole, since they were kept out of the UN post WWII. The biggest tie to the rest of Western Europe recently is that of organized crime; the Garduña of old evolved into the Comorra of today, well known across Europe, especially in Italy, obviously.
> In this article, we will talk about the new operating system made by Firefox.
Seriously? You really shouldn't put such blunders in bold. Not on a site named "technologist".
Seriously? You really shouldn't put such blunders in bold. Not on a site named "technologist".
I guess it's good that Firefox is doing this, but kind of like the Ubuntu mobile project, I just don't think it's going to make much of a dent.
Consumers don't care about technology ideology. Native vs web, NOBODY CARES!
Consumers want their apps. They want to play games. They want instagram. They want beautiful hardware and lots of accessories.
The only place in major markets where a Firefox OS stands a chance is low cost prepaid like Virgin Mobile USA, Straight Talk, etc. but there are enough good android options and even iPhone now, that it might be too late.
Maybe it could take off in some other countries, but I don't see Firefox OS taking off like the original Firefox did.
Consumers don't care about technology ideology. Native vs web, NOBODY CARES!
Consumers want their apps. They want to play games. They want instagram. They want beautiful hardware and lots of accessories.
The only place in major markets where a Firefox OS stands a chance is low cost prepaid like Virgin Mobile USA, Straight Talk, etc. but there are enough good android options and even iPhone now, that it might be too late.
Maybe it could take off in some other countries, but I don't see Firefox OS taking off like the original Firefox did.
> Consumers don't care about technology ideology. Native vs web, NOBODY CARES!
You are absolutely correct. And when they sell these for $50 a pop in Africa, South East Asia and Brazil people will be happy they didn't have to buy the $600 iPhone or Android.
These devices aren't even schedules to arrive in the US till mid to late 2014. And by the time they do they may have a strong enough foothold with developers and existing websites to have leverage with the US carriers.
You are absolutely correct. And when they sell these for $50 a pop in Africa, South East Asia and Brazil people will be happy they didn't have to buy the $600 iPhone or Android.
These devices aren't even schedules to arrive in the US till mid to late 2014. And by the time they do they may have a strong enough foothold with developers and existing websites to have leverage with the US carriers.
Why would you think a firefoxOS device is going to end up cheaper than Android, when both OSes are open source and linux based?
As I understand it, Gecko has significantly lighter resource demands compared to Dalvik. Andy Rubin himself, speaking on FirefoxOS, has said that there are simply places where Android cannot go.
Cite: "There are places where Android can’t go," [Rubin] said, referring to memory and other hardware requirements. Firefox can help reach those. "For certain markets, it makes sense." [http://allthingsd.com/20130226/googles-andy-rubin-on-firefox...]
Cite: "There are places where Android can’t go," [Rubin] said, referring to memory and other hardware requirements. Firefox can help reach those. "For certain markets, it makes sense." [http://allthingsd.com/20130226/googles-andy-rubin-on-firefox...]
Because that's what Mozilla keeps telling me.
Actually, Huawei Ideos goes for $50 in Africa right now (with Android), but I get your point.
The trick will be if they can position FirefoxOS as a capable product parallel to iOS and Android without letting the cheaper price tag tarnish it's image.
> Consumers want their apps.
Which is all the more reason to build above the walls that currently surround mobile platforms.
Which is all the more reason to build above the walls that currently surround mobile platforms.
Really? I was starting to think this would be the "Duke Nukem Forever" of operating systems.
I don't know how you could seriously say[0] that.
[0] https://en.wikipedia.org/wiki/Firefox_OS#History
[0] https://en.wikipedia.org/wiki/Firefox_OS#History
Why did you think that? Did Mozilla not deliver at some point in the past?
First are the apps. As for Ubuntu, developers love Linux. That would help to get apps ported. Plus Ubuntu have the recently introduced webapps integration, that provides unity integration for selected webapps. I expect that they will improve this feature, and include more apps. Then there is the choice of QT as the UI toolkit. This is a good choice, because QT is proven and has a big community of developers.
Meanwhile FirefoxOS relies on the traditional web platform, a popular and accessible environment for developers, that is currently improving relatively fast. The web, enhanced with the mobile APIs that Mozilla is working on, is probably enough for almost all productivity apps. And with webGL, it is becoming good for decent gaming. Web development has the advantage of being portable across platforms. That lower costs. And it is relatively easier and cheaper to find developers for it. These are facts that should not be ignored.
So both Ubuntu and FirefoxOS, are offering an attractive development proposition. From a pure development standpoint, I much rather prefer both Ubuntu and FirefoxOS alternatives, than Android Java or Apple objetiveC.
There is a strategical factor: Android device manufacturers fear Google. It is the most powerful web company in the world, controls Android, and also owns Motorola. So it competes with device manufacturers. That is too much power. And who knows if it decides to become like Apple at some point. So device manufactures, should be open to examine alternatives, as a countermeasure against Google excessive power. Both Ubuntu and Mozilla are solid software companies, that seems unthinkable to become device manufactures.
As for windows, I can imagine device manufactures waking up from nightmares, screaming at midnight. Dreaming about a mobile world dominated by Microsoft, where they would have to pay a big fee for each windows license, out of their thin margins. It is also relevant the interest of big third-parties. Big players like Facebook and Amazon, would feel more comfortable, if their apps were running on OSs not property of their rivals, Google, Apple and Microsoft. Where these could implement strategies, to undermine the former.
Linux as a gaming platform is on the rise. Steam, the Ouya, Nvidia project shield, etc. There are more incentives to consider games for Linux. Making porting to Ubuntu mobile easier and more enticing. And webGL appears poised for a brilliant future. So both FirefoxOS and Ubuntu could be good gaming platforms.
I hope that with the help of these factors, they at least can establish a sustainable presence on the market, and are able to build from there. I would be happier with a world where open OSs are present on the mobile market.