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.
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.
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.
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.
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 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.
Like Apple, Oracle, IBM and many other commercial vendors. Still don't get why only Microsoft gets bashed about it.
Google are currently showing how it's done perfectly.
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.
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.
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.
http://www.microsoft.com/en-us/legal/intellectualproperty/IP...
...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.
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.
Oh, the horror...
dot42 focuses on Android exclusively and targets dex/dalvik instead of the Mono runtime. [2]
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.