Guess it's up to Canonical to make Ubuntu Touch a viable open source smartphone OS - are there even devices running it that are being sold in the U.S.?
Did not expect that Sailfish OS would outlive Firefox OS.
Ubuntu Touch cannot compete. It will have been 3 years since its announcement while still being a buggy disaster.
Not one of these camps alone can come close to Android. If they had worked together - Firefox, Sailfish, Ubuntu, and Plasma, even WebOS - we may not have the defeated corpses of a dozen half baked dreams but instead have a common phone platform that were truly open and community driven.
As it is, the only way to compete with Android is with a better software stack (the ADK and bionic / surfaceflinger stack is awful hacked togther crap, and Linux / Wayland / QT promise to be way better if they ever ship a marketable result) and an open governance model. And what about Tizen? It exists, it is even shipping on a few devices, and you can contribute upstream patches, albeit with the same kind of bullshit copyright assignment that Ubuntu and the FSF use. Why exactly aren't we supporting that platform? Because we aren't the rulers? If its open we can fork it, and its mostly GPL so nobody can close it off again.
I still think Plasma Mobile might be the salvation. Outside of the kiddish Gnome vs KDE trolls (nobody working on either project actually engages in that crap, since both projects share protocols to inter-operate most of the time via freedesktop standards) everyone should be able to get behind that as the base to put Unity 8 / Firefox / whatever Sailfish's shell is on top, plus if Shashlik ever works you get Android apps, which are pretty much required.
As much as I respect Mozilla, when the user experience is worse than a cheap Android 1.6, you should know you've got a problem. It's cool that they tried, but on one hand if you want an open-source OS it makes much more sense to fork Android, and yes I believe Ubuntu is doomed as well.
And for Mozilla this may mean more resources spent into Firefox for Android, a mobile browser that is turning out to be the browser of choice for power users due to its extensions, an awesome browser that could use some love from Mozilla as it's lagging behind Chrome in terms of standards relevant for mobiles (e.g. push notifications, app manifest). And Firefox on the desktop needs some love as well. The multiprocess support is almost there, except for a list of bugs that keep delaying it.
Mozilla has many things on its plate. Firefox OS is a cool experiment, but it didn't work, so time to move on.
> And for Mozilla this may mean more resources spent into Firefox for Android, a mobile browser that is turning out to be the browser of choice for power users due to its extensions, an awesome browser that could use some love from Mozilla as it's lagging behind Chrome
Exactly the thing Mozilla should do - focus on Firefox and maybe even continue to invest in making Thunderbird better. There are a lot of reasons why that approach is more likely to succeed.
To be fair, Jolla is having some financial turmoil just at the same time. There were some (possibly temporary) lay-offs, and deliveries of the new tablet are delayed.
Do you really think so? What are some of the best internet apps?
I think a native app will always give a better experience because they can always just contain a browser view (it's basically a superset). Plus native code will always be more efficient and in mobile, that matters.
A native app is already lost at the start because it requires the user to install it. Also at least on Android I don't buy the efficiency argument at all, Java and JavaScript are both JITed. You think Java JITs better than asm.js?
The integration argument is decent, but it's only really relevant for apps that get a lot of use, not the long tail of stuff that you use once or twice.
> A native app is already lost at the start because it requires the user to install it
The billions of installed apps indicates that the friction isn't significant.
> I don't buy the efficiency argument at all, Java and JavaScript are both JITed
That's how everything worked back in the Gingerbread days. Android's ART system compiles applications to native code when they are installed. You can also install actual native code with Android's NDK.
If you like the idea of asm.js, then you should check out Go on Android. It does the same thing - offers a restricted set of the language that runs very fast.
There's definitely a subset of apps that work very well in a browser. But you can do more, faster, with lower power consumption with native apps.
Because Google has almost completely stopped pushing things to AOSP and instead keeps all the goodies locked under their proprietary apps. There is no AOSP for their "Okay, Google" stuff for instance. Most Google AOSP functionality is stuck in Android 2.x days.
I don't think that argument makes any sense. The options seem to be write everything from scratch or take AOSP and write only the services. The latter option makes a lot more sense to me.
The biggest problem with forking Android is that all of the apps will be developed for Google's flavor of Android. Which generally means you need to try to remain compatible with it, with ends with "you have to follow Google's development direction". And Google's development direction, of course, is selected by Google's business interests.
> Which generally means you need to try to remain compatible with it, with ends with "you have to follow Google's development direction"
You certainly don't need to do any of that. Amazon didn't do that and they have a pretty successful line of tablets. Even their crappy phone was far better than the Firefox OS phone.
Firefox could fork AOSP, break compatibility (if they want), rename it, and never look back. If they did this, they would be far ahead of where they are right now with Firefox OS.
Amazon DOES have to do that. Each version of their OS is based on a version of Google's version of Android. And they have to follow Google in re-implementing every Google API as an Amazon API as quickly as possible so they don't lose compatibility with apps.
Still, any AOSP fork needs to track Google's version only if they want to run applications built for Google's version of Android.
The first iteration of Firefox's mobile OS didn't run any Android apps so it would be no loss if their fork of AOSP also didn't run Android apps. That's why I would suggest renaming so that people don't think they can install Android apps.
The question then is... why would you build on Android? It's not exactly the zippiest platform around these days. The primary pain point for alternative platforms like Windows Phone or any other "third OS" is the lack of apps. Which is the case for keeping compatibility. If you're going to drop it, why not at least focus on a more performant core to your platform?
Also, currently Android has been ruled as copyright infringement from Oracle over Java APIs. It may be advisable to avoid building your own new OS on those same APIs.
> It's not exactly the zippiest platform around these days.
It's zippy enough, especially when you look at all the different platforms it works on. It's pretty far behind iOS, but then iOS has only a few platforms to worry about. Android is probably good enough especially when you factor in power consumption.
In the end though, it's all about trade-offs. Going with an Android fork gives you a pretty solid base to build off of. It's a nice option for app developers because the tools for Android development are excellent and the OS is well understood.
Did not expect that Sailfish OS would outlive Firefox OS.