The other mobile ecosystems are now so far in front they have no viable option other than the embracing and extending. Android happens to be flexible enough at the software layer (not just licensing) to make such a thing remarkably easy to do, given the resources.
> The other mobile ecosystems are now so far in front they have no viable option other than the embracing and extending.
That's your opinion. I doubt that it would get any traction inside MS.
It just doesn't make sense - are MS more likely to take the android kernel and reskin it to look like WinPhone, or continue to believe that writing OS kernels is a core company competence ... which it is, really. If one day MS could not write OS kernels any more they would be in serious trouble. It's a core business function, so they do it themselves.
How would re-skinning android help MS get "in front" anyway? They have technically solid product in Windows Phone, they need other things to make it win, and they know it. Hence, the whole Nokia deal.
"they need other things" - like the extremely strong app eco-system of Android (in comparison to Windows Phone, specifically). WP is a strong OS with some great design choices etc (IMO, obviously); it's main downfall from my point of view is the lack of apps. Forking Android (not necessarily just "skinning" but a step beyond that) is an obvious solution to that issue.
The entire article is all about how it's not really an obvious solution at all. Amazon is forking Android, and they have rewritten many of the GMS APIs, and yet, many of the apps do not run on Kindle Fire like they do on Android.
There's almost no value add in a custom kernel from a customer perspective. MS don't so much sell Windows as Office, Exchange etc. These are whole platforms in and of themselves. Android is flexible enough to enable MS service clients to sit on top of it and act as if they're built in to the system, while getting easy portability for all the existing Android developers. (This is the point I think most objectors underestimate, since Android is a giant mess, but has an inspired way for plugging apps together at runtime).
Windows as a standalone product is essentially dead, but selling it as part of a system for running Outlook, Exchange and Excel is not and won't be for a long while.
> There's almost no value add in a custom kernel from a customer perspective. MS don't so much sell Windows as Office, Exchange etc.
True, the OS kernel is an enabler not a feature.
> Windows as a standalone product is essentially dead
And on the server world it's a platform for IIS servers, SQL servers, and azure clouds.
Yes, a company that does this could decide to use someone else's OS kernel to enable all that. The original article that I linked to in grandparent comment explains why that would be a dangerous decision and is not going to happen.
I'm afraid your link merely shows the misguided point-of-view leading to the MS malaise.
Look at your examples for server stuff: it would make no difference to the end user if those were running on Windows or not. IIS gets value from ease of .net application deployment, SQL server from playing well with .net, and Azure can deploy Linux because that department can't afford not to be in the embrace/extending mode.
From an MS point of view making the OS might make these things easier to deploy, but just because you're good at doing something doesn't mean other people are going to keep paying you to do it, and so it will be with Windows. MS are going to end up disadvantaging themselves given they have to duplicate a lot of work going on in the open source community.
If you use Chrome in Metro mode on a Win8 machine you'll see the extent to which Google are outplaying MS, as it apes the Chrome OS experience completely. Google are leveraging the Windows user base to reduce friction to them eventually moving to Chrome OS.
Look at your examples for server stuff: it would make no difference to the end user if those were running on Windows or not. IIS gets value from ease of .net application deployment, SQL server from playing well with .net
IIS also gets value from Windows account permissions integration, from Computer Manager integration and MS Best practises Analyser, from PowerShell and VBScript and Visual studio integration, from Windows certificate services integration, blah blah.
The "Windows" benefit is integration, Microsoft products aren't standalone.
What benefit rewriting everything for Linux? Except alienating a huge chunk of Linux-ambivalent administrators.
> I'm afraid your link merely shows the misguided point-of-view
I agree that it is MS's point of view on this topic. We're going to have to disagree that it's "misguided". IMHO Jeff Atwood was right on the mark in that essay, and it applies to this case.
Will it be enough for MS and for Windows Phone in particular? I don't claim to know. Would swapping over to android help? Unlikely, once you factor in the loss of face involved. Are others like Google doing it better? Probably.
Faire enough, I just complained, because it is quite common in places like HN to bash Microsoft, while forgetin about similar practices done by other companies, just because they enjoy a few more geek points.
Its really only common because Microsoft did so well with it compared to the rest. Its not like we "forget" other companies do it, just that they haven't done nearly as well as microsoft in their heyday.
"Embrace, extend" was more effective (and terrifying to competition) when Microsoft was the juggernaut. But now Microsoft is actually behind Google, so there's little chance they can extend it any meaningful way that would give them leverage against Google. Google has equal engineering resource and huge head-start in install base and ecosystem.
So the real question is what could Microsoft leverage from AOSP? My instinct is they could probably build anything from AOSP into WinPhone far faster than they could utilize AOSP directly.
Your instincts are wrong, but I've run into this misconception a lot. Nokia made this error, and RIM/Blackberry are doing it all over again.
All they have to do to use AOSP is 1. start using it, 2. develop apps which are clients for their services, and 3. release a device with those clients preinstalled. There is no magic hidden step.
Everything from the accounts system, inter app communication, billing, push, is pluggable and they already have the servers for most of it setup, which is far and away the hardest part.
Why do you think apps wouldn't be compatible? It would be just like Amazon - yes, you'd need to run a new store (fairly trivial for an MS or Nokia type org to get going) and need a new billing API, but that's all you'd need to get going.
To put this in perspective moving Play Store builds to the Amazon store is generally a matter of replacing the billing and push APIs, if you've used them, which takes a few hours. (If you've used game services it might take longer, but again it's not actually hard). This is far easier than redeveloping your app completely for a different platform.
I've been involved with apps for which the move to Amazon was simply a 10 minute boot up on a Kindle Fire to establish it worked.
Nokia are bad at it, but you might recall the N-Gage that had a services layer that wasn't completely terrible. In Europe the operators usually ran this stuff, at least pre-Apple/Google, and there were a good few companies that existed by selling portals which were white labelled and branded as the operator stores.
These things certainly can be killed in bureaucracy, but the tech issues aren't too bad, especially if you're already sitting on a giant pile of servers and a billing solution for each country. At one point I knew one team running stores for about 20 operators (each country is essentially separate) with less than that in developers, and only a handful of sysadmins, if you can have such a thing.
I'm not sure what misconception your think I have, but it has nothing to do with how easy or hard AOSP is to use. It's the fact that Microsoft already has a good mobile phone OS tied into their ecosystem. What does AOSP bring to the table that is going to move the needle for them?
Even better, Microsoft already license the Exchange protocols to Google and Apple, and then they get to pay Microsoft and do the work of integrating their mail and calendaring software with Exchange.
Embrace extend works for markets and technologies not so much for operating systems. Nobody has done well embracing and extending Android, those who tried such as Samsung are throwing in the towel because of...
...wait for it...
...you know it's coming...
...vendor lock-in.
I think the article gives Android too much credit for mindshare. Sure it's a platform for developers (this is why the monkey boy criticism of Ballmer makes no sense) but it's not really a brand among consumers. In consumer minds, Android is simply not an iPhone and increasingly not a Windows Phone. All that manufacturer and carrier customization erodes the idea of Android. In so far as Android is a brand, it's Google, not Andorid. But the primary brand of an Android phone is the Phone's manufacturer. Doing Apple on the cheap doesn't work.
Isn't Kindle Fire OS a perfect example of embrace and extend? Sure, it's also vendor lock in, but a good example that you can fork Android without relying on Google's services.
I'm in the MS hating camp, BUT, I suppose they could actually devote enough resources to make a quite usable mode in Visual Studio that supports a .NET subset that maps to the Android/base API and then translates .NET bytecode to dex/dalvik format.
The other mobile ecosystems are now so far in front they have no viable option other than the embracing and extending. Android happens to be flexible enough at the software layer (not just licensing) to make such a thing remarkably easy to do, given the resources.