In my last post, I talked a bit about how Microsoft's fixation on Metro/Modern and the appstore had resulted in it basically ignoring large swathes of its developer community. So that post got a lot more attention than I was expecting, with some agreeing and others disagreeing. Some discussions however took a turn where people began debating how much trouble, if any, developers were in with Microsoft's move. This was something that I had decided not to explore further because the previous post had already reached a fairly ridiculous length. The following will talk a bit about the ramifications for developers, but will also reiterate the point I was trying to make. Ultimately the people who got shafted by Microsoft in one form or another need to choose what to do next. This however depends a bit on what piece they relied on that Microsoft has deprecated and the nature of that deprecation.
In the case of the Silverlight developers, they are actually not nearly as screwed in some respects. Microsoft has offered an assurance that Silverlight in its present form will continue to function for the next ten years on Microsoft OSes, so there is not any immediate danger of the various line of business applications suddenly not working anymore. Something similar happened in the past with both pre-.NET Visual Basic and Microsoft Foundation Classes applications. Even today, there are still VB6 and MFC applications developed and used internally by various corporations, for whom rewriting in something newer has been deemed cost prohibitive, nevermind the fact that VB6 has some fairly serious architectural flaws and a lot of VB6 applications are far more complex than the framework was ever intended to support. These applications are often even being extended, which is more excusable for MFC than VB6, considering Microsoft has actually released updates to MFC to help developers take advantage of certain newer features. But so long as companies continue viewing IT as a cost sink, they are unlikely to ever properly invest the resources to migrate off their more antiquated systems, even if they're only increasing that cost in the long term by ignoring the problems and probably setting themselves up for some catastrophic customer visible failure down the road. So for Silverlight developers, Microsoft's position is a short term inconvenience but likely a long term maintainability issue due to the lack of updates to tooling support, especially considering the Mono project stopped development of Moonlight over a year ago and so has no alternative available.
The XNA people are both luckier and unluckier at the same time. Silverlight had a lot of corporate users invested in it so Microsoft couldn't really afford to just dump it without thoroughly pissing them off and killing any hope of future Windows adoption. XNA did not have such major backing and so Microsoft has dropped support for it outright in Windows 8. By doing this however, Microsoft has basically given the Mono developers the perfect opportunity to capture those developers. Mono has announced their own game development framework, MonoGame, which is intended to be API compatible with XNA. This means that after swapping out a few package inclusion lines, the rest of the program should work as is. That kind of source level compatibility is huge for programmers as they do not need to learn a new framework and can continue writing games with their existing knowledge. At the same time, Mono has been promising cross-platform support for MonoGame, meaning games that were previously restricted to Windows or the Xbox due to using XNA can suddenly run on Android, iOS, Linux, and Mac OS X in addition to Windows. The popularity of C# as a language for developing games has also not escaped others. The Unity engine also uses Mono as a foundation, as does Sony's Playstation Mobile SDK. Microsoft created this ecosystem of game developers using a managed language by making XNA a really convenient and surprisingly powerful framework. So what basically happened was by cutting off the XNA developers, Microsoft has effectively seeded every other OS platform with game developers, a traditional weakness of Linux and OS X. I believe in soccer this is called scoring on one's own goal.
One of the points some people made while discussing my last post was that their usage of .NET technologies made their programs cross platform, often in response to others using my post as backing when proclaiming relying on Microsoft technology was foolhardy. The cross platform argument is for the most part true, but suggests those same people might have missed the point I was trying to make, specifically which group suffers the most damage from Microsoft's actions. Too many thought I was pitying the developers, whereas I was actually pointing out the harm Microsoft is doing to itself. Managed developers were not somehow fundamentally crippled with the loss of Silverlight and XNA and regular .NET developers do have alternatives to Microsoft's ecosystem if Microsoft does something disagreeable. But this is a bad thing for Microsoft, not a good thing, when they are trying to funnel developers to their appstore. To channel developers to the appstore, Microsoft basically created gaps in its ecosystem that did not exist before, taking away things that people relied upon in the past to create an artificial loss of supply so to speak. Microsoft's hoped for reaction was probably that developers would shift their focus to the new tools it provided to create applications for its appstore. Instead, others started coming in to fill those gaps, allowing those developers to shift out of Microsoft's ecosystem outright and basically eliminating their need to shift focus to Metro/Modern, which basically neutralized Microsoft's actions. This was possible principly because the Mono project was mature enough to provide the foundation needed to fill in the gaps, which serves as a very useful precedent for certain other efforts. So the people or group that will likely suffer the greatest long term harm is not the developers that had their tools deprecated, but Microsoft itself. Whether Microsoft will draw the correct lessons from this remains to be seen, as its management has not been very flexible as of late in their mad dash to try and focus everyone's attention on the appstore.