Microsoft's developer problem isn't about trust, it's about relevance

My ZDNet colleague has written a superb piece on the issue of Microsoft and developer trust.

Microsoft has been struggling with a developer trust problem for some time. At some point during the whole "hey, let's reimagine Windows into Windows 8 thing", as an organisation they stopped communicating well, and started to make some really strange decisions.

Things like, developers not getting early access to Windows 8.1 RTM (although this decision was reversed), or limiting access to the Windows Phone 8 SDK.

However, for me -- and I suspect for a lot of developers out there -- the bigger problem is the relevance of the Microsoft stack as we get more submerged into the post-PC era.

Dotcom

In her piece, Mary Jo cites a blog post by ex-Microsoftie John Ludwig, and there's something profoundly relevant in what he says here:

I am relearning how to be a software developer after many years away and it is notable that, not only am I not using any Microsoft technologies or tools, nothing from Microsoft even entered the consideration set as I selected targets, libs, tools, etc.

And that's the relevancy problem right there. How we build software today -- well, how users are asking us to build software today -- isn't well aligned with what Microsoft is putting out there as a toolset.

To be honest, Microsoft has always had a relevancy problem. It's never been sexy or cool to base -- particularly -- consumer-focused services on Microsoft technology. If you go back to the dotcom boom of the late 1990s it was all but impossible to find top-tier web services that were running on the Microsoft stack. For a while, eBay was the only major non-Microsoft-owned site that used IIS, serving some functionality up through ISAPI extensions.

If you look at the most popular websites in the US, it's rare to find any in there that are based on Microsoft technologies. Obvious notable exceptions are Microsoft's own services, and Netflix which leverages Silverlight to provide DRM-enabled streaming to desktop clients. That situation has persisted for nearly two decades.

Obviously, people have been writing software for the Microsoft stack. Visual Studio remains one of Microsoft's billion dollar businesses, but it's mainly been enterprise and corporate clients that have been sponsoring this work.

Now in the post-PC era Microsoft that relevancy problem becomes more acute, and pressure is applied from two sides.

From one side, as post-PC grows there will be more demand for software that runs on non-Windows-based devices. Microsoft has no direct control over the currently dominant mobile platforms in that space. If you want to write software for iOS, or Android, you don't use Visual Studio, and apart from those people using Xamarin, you don't get anywhere near Microsoft technologies at all.

To put it another way, if your boss asks you to build an iPad app, Microsoft doesn't get a look in.

From the other side, pressure comes from a change in user experience expectation. A hallmark of post-PC-class software in contrast to enterprise-class software is that the user experience (UX) tends to be much better. Whereas in enterprise-land we could get away with a user dialog that had four hundred controls, half of which didn't work as expected, and all of which took thirty seconds to load, in post-PC-land that's not the expectation.

The problem now is that those signing off the projects has a post-PC expectation, not an enterprise expectation. Thus even if you are building a classic enterprise app to be rolled out in classic enterprise environments, you're going to end up being judged on the user's experiences of the post-PC world that they enjoy outside of using your clunky enterprise app.

Again, that's a relevance problem because Microsoft's tooling is rooted in providing enterprise-class experience, not post-PC experience. As such developers go outside of whatever Microsoft puts out there and goes with the tooling that the top-tier web services use to drive fantastic web UX.

The question then gets asked, even by shops that have been developing on Microsoft for years, -- is it easier to deliver the software that we want outside of the Microsoft stack entirely?

Conclusion

The challenge here for Microsoft is avoiding a perfect storm where they're both not trusted and not relevant, and it's both of these problems that have to be fixed.

Relevancy can be fixed, but it's going to need an acceleration of work Microsoft has already done in changing how it works with the developer community. More open sourcing their own stuff, more support for popular open source projects, and so on.

To mirror what Ludwig says in his post, yes, Microsoft needs to make a number of acquisitions to help them engage more readily with the community. The "chocolate mess" of assets he alludes to is an absolute requirement, and a strong way forward, although I'm not sure it's the right combination.

Ludwig talks about acquiring Xamarin. That's obvious -- I can't see how that would do anything other than help everyone both inside and outside the Microsoft universe, and I'd love to wake up one day and find that had happened. GitHub? Sure -- it's just a service. Acquiring StackOverflow? I'm not sure that move would build trust within the community. Similar problems would seem to exhibit themselves with the other technologies that Ludwig calls out (NoSQL, Hadoop, etc). Anti-Microsoft sentiment sometimes exists for a reason. I'm not saying this is easy.

But all of this would be a move in the right direction. No one outside of Microsoft cares at all about Windows Store app/WinRT (nee Metro-style app) development. (And before I get shouted down about that, I mean "relatively no one".). But everyone cares about jQuery, Angular, Vagrant, and a thousand one other open source tooling technologies.

It's possible to work through a breakdown of trust with a partner, but if the result of you working through that breakdown is to come face-to-face with a failure of the "so what?" test, you've got real problems.

What do you think? Post a comment, or talk to me on Twitter: @mbrit.