Microsoft is working on its next Windows release (isn’t it always) and most rumors point to it being a release code-named Threshold.  The rumors also suggest developers may see Threshold before the end of this year, but general availability is sometime in 2015.  I don’t know about the name or dates, but I do believe that whatever Microsoft does next is absolutely critical for its success or failure in the client OS business.  That particularly holds true for Windows Phone.  So I’m going to call the next release Threshold and discuss it, particularly in the context of Windows Phone but also a more generally.

The most recent bit of Threshold rumor is that Microsoft may make it available for free to Windows XP, Vista, 7, and 8.1 customers.  This is neither surprising nor particularly significant financially.  Recall that the vast majority of Windows revenue comes from two sources, new copies of Windows licensed through OEMs for new devices and volume licensing agreements with enterprises.  The Enterprise version of Threshold is unlikely to be free, unless of course you essentially already paid for it by having Software Assurance.  And the OEM version is only free for small form factor devices that currently are not a material part of the business.  So free upgrades is a nice way to encourage adoption, but its financial impact should be negligent in the short-term (and positive in the long-term if it does encourage adoption).

Throughout the rest of this post I’m going to merge rumors and my opinions of what Microsoft must do, and in many cases what I believe they are doing.  Don’t get confused into thinking I have any contacts feeding me facts.  It’s all speculation as far as I’m concerned.  But I wouldn’t bet against what I’m about to say.

Threshold is clearly a release designed to (a) clean up the Windows mistakes of the past few years, (b) reposition Windows as a single platform across a wide variety of devices with experiences tuned for device classes, and (c) establish Windows as the platform for running apps of all types.  A lot has been written about (a) and (b) already so I’ll spend most of my effort here on (c).

The main mistake to be fixed is Windows 8’s de-prioritization of the desktop user, but there are plenty of others.  Even within the Modern user experience there are things that just don’t make sense.  For example, even heavy Windows 8.x users struggle with having Print buried inside the Devices charm.  Tweaks in 8.1, 8.1 Update 1, and in the apps design guidance (e.g., most print-oriented apps now expose their own Print menu item) have worked towards addressing these smaller items.  In Threshold those shortcomings should become mostly a memory.

One of the mistakes for Windows 8 was the incomplete state of the Windows Runtime.  Because the initial version was targeted at specific categories of apps, many developers wrote it off as a dead-end and stuck with their focus on desktop Win32 applications.  Even Microsoft’s most critical application for succeeding in tablets, Office “Gemini”, is held up because the Windows Runtime doesn’t yet support everything it needs.  Threshold will fix this problem, rounding out the Windows Runtime so that it is capable of supporting the vast majority of applications that developers would care to write.  From the lightweight front-end kinds of apps generally found on phones and tablets to the heavyweight productivity and enterprise applications that currently call the Desktop home.

If you combine a fleshed out Windows Runtime with the recently introduced concept of Universal Apps you get a very powerful environment for addressing the app gap.  The app gap is a problem both on tablets and phones for Microsoft, and the initial divergence in development platforms has only made it worse.  Fitbit did an app for Windows early on, but only just released a Windows Phone (universal) app.  On the other hand Yelp has an app for Windows Phone but not Windows.  Add on directional changes in the app platform between Windows Phone 7 and 8 and Microsoft certainly wasn’t making it easy on developers.  That’s already changing, and with Threshold developers should have a clear, complete, and more stable platform to target.

Unfortunately Windows Universal Apps and a stable complete Windows Runtime based development platform isn’t enough to save Windows Phone.  As much as I’ve been a supporter and booster of Windows Phone since it came out, I recently left the fold.  And I have one foot in the “Microsoft should just abandon Windows Phone” camp, because on current course, speed, and publicly visible strategy it will never break out of single digit percentage market share on a world-wide basis.  And if that is the case then it isn’t clear what strategic value it has, nor is there any way it can yield a positive financial return.  So is there a viable strategy for Windows Phone and how does Threshold play into it?

First let me restate the problem.  On a world-wide basis Android has now achieved 85% market share, and its share is growing.  It has achieved roughly the same virtuous cycle as Windows achieved in the 1990s.  Most of the remaining market share accrues to Apple’s iOS, which increasingly looks like it has carved out the same high-end niche that it owns with the Mac in the PC business.  In affluent countries the iPhone has a much stronger position than the world-wide numbers indicate, but the world-wide trends mirror what happened in PCs.  There is, in essence, no room for a third player.

Being that third player means it is hard to gain and keep the attention of the channel (carriers, retailers) or garner the top-tier of OEM support.  And most importantly, it means that Developers see your platform as having the worst return on investment of any they do, or might consider, supporting.  That means they either never bring their apps to your platform, or treat them as second class citizens that are updated less frequently and receive mediocre support, or abandon the platform when they see it makes no financial sense to continue supporting an app on it.  Windows Phone is having all three problems, and unless it gains share rapidly I think abandonments will accelerate.

So how can Microsoft work around developers’ barriers to supporting Windows Phone, and thus close the app gap?  One that we’ve already discussed is making the overall market bigger by having the same apps target all Windows variants.  But in the short run that strategy does more to attract enterprise, as well as more productivity-oriented, apps than the broader consumer app category that makes up the app gap.  So Microsoft has been embarked on a mission of supporting multiple efforts around cross-platform app development.

Microsoft has gotten very close to Xamarin, who offers a way to do cross-platform development using Microsoft technologies.  So close in fact that speculation surfaces periodically that Microsoft will acquire Xamarin.  Microsoft has also thrown its support behind Apache Cordoba,  A platform focused on using JavaScript and HTML to create cross-platform native mobile apps.  In many ways this is a natural move.  With Windows 8 Microsoft sought to capture the attention of the largest development community there is, web developers, by making JavaScript/HTML5 a native Windows app development platform.  It has since made WinJS, the library behind Windows’ support for JavaScript/HTML5 apps, open source and added support for WinJS-based apps to Windows Phone 8.1.  But these moves, while helpful in the long-term, still will not address the app gap in the short or medium terms.

Microsoft has only one play to really close the app gap in the next 12-18 months, and that is something they have to do that if they want Windows Phone to have a future.  That play is make it easy for developers to port Android apps to Windows Phone, a capability I think is likely to be part of Threshold.  It’s possible that Microsoft would simply choose to allow Android apps to run on Threshold, perhaps just on phones but tablets are also a possibility.  There are a number of existing sources for technology to do this, but I suspect Microsoft is working with OpenMobile World Wide.  Want a clue on this?  Open the data sheet for the upcoming OpenMobile ACL for Windows and look at the picture on the upper right.

While being able to run existing Android apps on Windows Phone would close the app gap extremely quickly, it would leave a problem with the quality of the app experience.  I suspect Microsoft is looking to take this another step, and use the opportunity to easily run Android apps on Threshold to convince developers to adapt them to the Microsoft environment.  For example, first use it to encourage developers to support Microsoft services (when running on both Windows and Android).  Then use it to convince developers to turn their Android apps into multi-platform apps, with customizations (to the user experience) when running on Windows.  How far they will go is a big question mark, but I believe they will go beyond just wanting to run existing apps unchanged.

There are lots of risks around supporting Android apps on Threshold.  The first one everyone brings up is that it would seem to discourage developers from creating “native” apps for Windows.  In some cases this will be true, but as (and if) the Windows Phone platform grows in market share than user demand for a higher quality application experience will solve this problem.  But I think a bigger issue is that the strategy doesn’t have a great history of success, at least on a cross-vendor basis.  The analogy most people use is that the ability to run Android apps on the Blackberry hasn’t helped it, but I don’t think that the app gap has been their biggest problem.

I like the OS/2 example better than the Blackberry example.  IBM kept OS/2 going after Microsoft abandoned the effort because (IMHO) they wanted a platform they could control even if its prospects for success on the desktop were virtually nil.  To solve the app gap problem they included the ability to run Windows applications on OS/2, and even had a deal with Microsoft to run Office on it.  It may have helped sell some copies of OS/2, but didn’t help OS/2 achieve anything other than a marginal market share followed by a trip to oblivion.

So the strategy of running Android apps on Windows Phone is risky, but when you have 3% market share how much risk is it really?  And to be clear, closing the app gap is not all that it will take to grow Windows Phone’s market share.  But failure to close the app gap certainly dooms the platform.

While press and pundits will focus on running Android apps on Windows Phone, assuming it is true that Threshold will support this, I think it misses the bigger point.  With Threshold Microsoft may be completing the move away from the our way or the highway application platform to broad acceptance of multiple development technologies and runtimes.  If you follow Azure you’ve already seen Microsoft do this in a big way.  They’ll continue to offer their own application platform, and open source much of it to encourage broader adoption.  But we are clearly in the waning days of Microsoft focusing intensely on a proprietary Windows application platform.

And speaking of thresholds, this is going to be my last blog post on Microsoft or any kind of IT industry analysis/commentary.  There is a time to blog and there is a time to build, and I’ve decided it’s time once again for me to build.  I’ll reveal my plans at an appropriate point in the future.