12 May 2013

35743

2

A perspective: managed developers beyond Microsoft

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.

Comments (2)

  • anon

    [quote] - 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, [/quote]

    Do remember that many systems cannot be migrated due to safety or re-certification issues. The nuclear power industry, aerospace, military systems run applications that need to be maintained for safety or legal reasons. These system must NOT be changed as the implications in safety or in cost are tremendous, whole fleets of aircraft might be grounded if certified, supporting applications are not in place.

    From a personal point of view, having to recode an application that worked perfectly just because someone at Microsoft changed the o/s, is frankly boring to me. I am not a died-in-the-wool developer but I have developed thousands of lines of code in VB6. I am one of those VB6 coders that MS hates who do not relish having to re-learn a new IDE every few years let alone another language. Frankly I do not care what the technological underpinnings are, COM or .NET I just want the IDE to stay the same and my apps written in VB6 code to work under whichever framework/route MS forces me onto. I don't have the time nor money to recode virtually from scratch. I need backward compatibility or an environment which will allow the old WIN32 apps to run without worrying that MS will destroy the platform. I am so glad I abandoned .NET before I started down that route. I could foresee what MS would do in the next few years and decided to abandon MS altogether, javascript is an object based language and is flexible and my VB6 coding style applies. I just need to find the IDE...

    May 14, 2013
  • anon

    Good post, agree with most of it except the cost sink part (I suppose you mean cost center as opposed to profit center). In theory, cost centers should look at all costs, immediate and in future (whether you call it TCO or something else doesn't matter).
    Profit centers obviously should look at both costs and profits.

    In practice, you're right: often systems are not replaced even though cumulative maintenance cost exceeds (estimated) new build costs.
    Often, IT doesn't have enough resources to rebuild at the right time. Sometimes, the business side pressures to keep things as they are (probably - often correctly - afraid of escalating costs and timelines for new builds).

    Nitpicking point, really, as the main points of your post seem sound to me. Seems like Mono/Xamarin can scoop up quite a few customers.

    Jun 01, 2013
This blog post represents the personal opinion of the author and is not representative of the position of the ReactOS Project.