The Backwards Bridge
TL;DR: VOTE! ^
This series exists to build support around the idea of a ubiquitous .NET client application development model. This is not intended to be a final solution, but a starting point for discussion, awareness, and a sign of demand. Show your support by voting for this idea here:
Crossing Backwards ^
In our last article, we looked at the current guidance that serves as Microsoft’s official answer to a ubiquitous web client application model, and have demonstrated how it is a failed a broken bridge to its destination. In this article, we move on to another attempted bridge to web technologies, and hope to show it is as broken as it is backwards. This is especially so when we consider its business model implications.
To be sure: as of July 2015, Windows Store-compatible desktop and devices accounted for only 16% of the desktop market. So, what incentive does a web developer have to spend even one second towards building a solution that only reaches 16% of the desktop market when that same one second could be better used towards building a ubiquitously available application (which, incidentally, completely dwarfs the WinRT desktop market)?
Thankfully, in this case, logic seems to have won the day, as it seems a lot of web developers have asked this very question. As a result, WinJS has failed to gain significant adoption.
Backwards Thinking ^
Backwards Business Strategy ^
When viewed by the perspective of the typical web developer, the above value proposition is a headscratcher. But when viewed through the lens of Microsoft’s current business model, it makes perfect sense. Here’s why: in addition to claiming adoption for WinJS, Microsoft can also claim revenues from not only the developer, but also in the application that they create to host in the Windows Store. In fact, in order to even register into the store, an individual developer must pay $19.00 while a company must pay $99.00. Additionally, Microsoft also takes a portion (30%) of any revenues generated from within the developer’s submitted application. When accounting for this dynamic, it becomes clear that any attractive feature that the API/platform can provide to pull developers into this ecosystem (and by virtue its model) becomes tantamount, even if that means catering to developers whose skill set is better spent on a ubiquitous audience.
But even in this light, a web developer does not need to pay $19 for a ubiquitous application hosted on the web. So, the incentive is further marginalized to cross the “backwards” WinJS bridge.
Finally, there’s another curious wrinkle to this strategy: Microsoft’s smart acceptance and promotion of web standards provides value in the form of goodwill to the industry and in mindshare, but it does not provide any direct revenues for the company’s bottom line. As we have mentioned throughout this article, there is not a web client application model technology that is currently offered by Microsoft. Instead, Microsoft expects its own client developers to use externally provided application models and solutions, such as leveraging a curious relationship with Google to support Angular for web client development.
Microsoft does not garner any revenues from this, and what’s more, Microsoft does not produce or retain any intellectual property or proffer any assets towards its intellectual property cache. This leads to another confusing and seemingly self-inflicting question: why is Microsoft encouraging its own developers to use external, non-Microsoft technologies to build web-hosted client applications while simultaneously running a .NET client developer registration program whose purpose is to procure registrations (and revenues) for its Windows Store? For every Microsoft web developer out there deciding to deploy a ubiquitous web-hosted client application instead of deploying a client application to the Windows Store, Microsoft is losing $19 per developer.
Thinking Forward ^
Hopefully it is clear by now that Microsoft is offering guidance that not only hurts its developers and its brand, but is also offering a solution that simply flies backwards in the face of good business sense. In our next section, we aim to round out this series by demonstrating how Microsoft can fix these issues and mend their ecosystem by successfully creating and providing a ubiquitous .NET client application model offering.
Show Your Support ^
If you like the idea of a ubiquitous .NET client application development model, please take the time and let Microsoft know by voting for this idea on UserVoice: