X
Tech

For Windows developers, Sinofsky's legacy is fragmentation and frustration

This last year, being a Windows developer on Microsoft's mobility platform has been frustrating at best.
Written by Matt Baxter-Reynolds, Contributor
thumbnail-sinofsky-quit.png

The statement "Windows will lose its dominance and the PC will become irrelevant" always gets people riled up, but logically has to be a time when that statement becomes a concrete fact.

The problem with that statement is it's missing a qualifier. Look 200 years in the future and it's obviously true. The sort of computing platforms we use today will look like quaint clockwork curiosities decades just decades from now. Windows and the PC will ultimately wither and die -- it's just a matter of when.

Some people in our little technology universe have the ability to affect when that happens. Sinofsky was one of those, and his departure gives us chance to reflect on his legacy. Some parts are good -- I'm a big fan of Windows 8. It does a good job of negotiating the inventor's dilemma, on paper.

But some parts are bad. Particularly the damage he managed to do to the developer story within Microsoft.

Being open is better

I've always felt that specialising in Microsoft development was like staying in, alone, every Saturday night whilst everyone else you know went our clubbing 'til 4am at the most happening joint in town.

I first started getting into web stuff in the mid-90s. This movement started outside of Microsoft's influence in the "open web" community based on technology like Linux, Apache, PHP, MySQL, and so on. It's stayed that way ever since. Think of any large, retail web properties -- Amazon, eBay, Facebook, Twitter, Yahoo!, the list just goes on and on, you'll find it rare that they engineer their solutions on Microsoft products. Private, proprietary enterprise development tends to take a different approach where Microsoft's stuff gets more play.

Ten years ago Microsoft released .NET. Ostensibly a strategy to head off Java, within the Microsoft community this has become the de facto standard way of building software on the Microsoft stack. Whilst .NET was created as closed, even in the early days Microsoft would make noises about being more open. Submitting C# as an ECMA standard along with a shared source CLI implementation (Rotor) in 2006 was an early one. This story has been getting much better recently. TypeScript -- although not a .NET technology -- isn't just having its source released open source project, it's being run in a way that's highly sympathetic with the open web community. And how about Entity Framework where the Microsoft developers will even accept pull requests from the wider developer community.

Open source isn't important because it's hip, groovy, and a cool thing to do. It's important because it marks a developmental shift in our industry. We're becoming more mature. We started as an industry where everything was private and hidden. As we develop we expose out our ideas to peers and share, collectively, the process of becoming better at engineering as a whole. Imagine the industry of building a bridge where structural engineers didn't share what they learned in the process of bridge building. The idea that a group of structural engineers who discover that building a bridge in a certain way causes it to collapse would keep that a secret and not share it is ridiculous. It's clearly a more logical approach to share that knowledge. Although "open source" is typically used to describe licenses, it's much more about the philosophy of driving advancements in technology through collaboration.

The individual software engineers and management staff within Microsoft gets this. This is why the "DevDiv" team -- those that build the tools like Visual Studio, platforms like .NET, and libraries like Entity Framework -- are much more accommodating to the ideas of open source. You can test this out yourself. Find any Microsoft developer on Twitter and ask them about their job and their work. I've yet to meet one that didn't love to share their passion for what they do -- but when they do that they're doing that in a very "open source" way. The products they're developing may be closed, but their personal philosophy will most likely be very open.

(This by the way is why I like to think of this stuff as "open web" rather than "open source". It's not about licenses and business models -- it's a philosophy.)

WinRT

Much has been written about how in the reimagined Windows 8 and Windows RT we have a new development model called "Windows Store apps" which are based on a new library called Windows Runtime, or WinRT. (Peter Bright did a fantastic job of explaining all this in great detail.)

When designing the new APIs for the new platform, Microsoft -- well, Sinofsky -- had two options. Base it on .NET or do something different. He should have based the new platform on .NET -- but for various reasons he chose to reboot the entire developer story on WinRT. The most likely reason is that .NET was blamed in part for the failure of Vista. When you're running the Windows team, the last thing you want is "another Vista". 

Sinofsky's decision to base the new developer story on an untried and closed technology is not only risky, but it obviously fragments the Microsoft developer platform story along two axis.

On the first axis, it's not .NET. Sure, you can use .NET to build Windows Store apps, but it's just a baseline technology within a much larger stack. Generally developers find working on Windows Store apps hard. (I've been working on .NET since before it was released. Trust me -- it's much more difficult to build apps with WinRT.) At its core, WinRT is not .NET -- it's more like the APIs used for building Windows and megalithic applications like Office and PhotoShop than the more easy going and forgiving experience that .NET provides. (DevDiv designed .NET to be easy, and so it's easy and a bit slow. WinDiv -- Sinofsky's team -- designed WinRT to be fast, and so it's fast, but hard to develop for. In fact, it's not even very fast when you actually try and use it.)

And on the second axis we have the problem that WinRT and Windows Store apps are fundamentally closed. In this instance, the WinDiv team are both out of kilter with their own developers (Microsoft's engineers want to be more open) and with the community at large.

Again, this isn't about "open source" and licenses. This is about philosophy. We now know that the Windows Phone 8 APIs are different to the Windows Store app APIs. Yet logically these two platforms must converge. Where's the clear messages that it will or won't? Nothing -- all developer get from Microsoft is stony silence.

There's a rule about being open: if you're first, be closed, but if you're following, be open. Apple can afford to be closed with iOS because it runs that whole market of that whole market. Android started out as open, and for simplicity lets just say that it is. Microsoft are way, way in the back. A closed strategy with Windows Store apps (and with the Windows Phone platform) is just crazy in that context.

Conclusion

Let's come back to my point about how Sinofsky has the power to extend or reduce the working life of Windows. Wait. I meant "had" the power.

Sinofsky's choices with regards to the developer story in the new world of the ridiculously named "Windows Store apps" have been nothing short of disastrous. Effectively deprecating .NET for native Windows 8 and Windows RT development, obfuscating the message throughout on Windows Phone, obsessing over running Office on tablet, and by stopping the "open web" philosophy bubbling up from the Microsoft developer rank and file has devastated Microsoft's chances in the post-PC market.

What's my rationale? Apple's stuff is incredibly difficult to work with from a technical perspective. Culturally, they are closed and secretive. Even to build software for it you need to drop thousands of dollars on hardware. Yet developers flock to them in droves. Why? Follow the money. There's actually a market for the iPad. The only way that the "Windows-on-a-tablet" story can survive Sinofsky's missteps is if it sells in vast numbers and developers start following the money to Windows.

That's a chicken and egg problem. Developers have to have the mood and inclination to build Windows Store apps despite the poor APIs, a culture that's tended to being overly-secretive and out of kilter with the general "care and share" mood of the industry, and assume that sales of Windows tablets are going to hit all sorts of crazy big numbers as opposed to just being "modest".

It looks like Julie Larson-Green has her work cut out for her.

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

Editorial standards