The API War and Microsoft
Thought I may as well weigh in on Joel Spolsky's post on How Microsoft Lost the API War. It's a great read but I think that Joel is way off on his thoughts on .NET. I wasn't aware of the lengths Microsoft has gone to in the past to retain backward compatibility. Some of the backward compatibility workarounds seem absolutely crazy (at least to someone who has never dealt in thousands of deployment desktops let alone tens of millions+). This post doesn't get into arguing whether .NET is a worthwhile development direction as I'm sure there'll be plenty of posts on the subject (Scoble references a bunch in his blog). For me using .NET is a no-brainer once you spend some time researching the environment and languages available. It's simply a top notch development environment.
Regardless of this, I have been disappointed a few times working with the .NET environment. Most of these times relate to strategic planning as to what APIs to use and when to use them. Hence the relevance to the Joel Spolsky post. My .NET API disappointments include:
- ADO.NET in .NET 1.0. When first looking into the System.Data namespace back in 2003, the lack of emphasis on the ADO.NET interfaces struck me. All the code examples referred to the concrete classes such as OleDb* or Sql*. But the bigger disappointment was that there was no OODB concepts in the framework. Over the next couple of years I avidly read any scraps I could find on ObjectSpaces. Then this year, just as it was getting close to a release, bam! it slipped away another 2 years+ from my fingertips. Like all the major .NET API changes so far, I read and understood the Microsoft spiel and it mostly makes perfect sense. I remember viewing the code part of the MSDN show on Longhorn and WinFS and thinking hmmm.. do the WinFS and ObjectSpaces teams talk?
- Windows Forms vs Avalon. It's frustrating to commit to a particular API and build up an investment in it only to have rumours of it's imminent replacement send shivers of doubt down your spine. The investment is in terms of time spent learning the API, purchase of third party components that rely on the API and developed source code that needs to be maintained. The first rumour that Microsoft was looking at a Windows Forms replacement was in the discussion groups of the Mono project. The discussion was questioning whether it was worth attempting a Mono implementation of Windows.Forms since a replacement was already on the cards (less than a year after the .NET 1.0 release from memory). At the time I thought, how does Miguel de Icaza know there's are a Windows Forms replacement? He must have a mole in Microsoft or something (visions of the seedy underworld of software development espionage followed).
- .NET Remoting. I almost feel sorry for .NET Remoting (as an API entity). It only just started it's API life time (what a couple of years or less?) before it's been shoved onto the API scrap heap. .NET Remoting is very much a second class citizen these days (see the Channel 9 Video with Richard Turner). Whatever happened to Ingo Rammer and his devotion to that API? He used to be the ".NET Remoting" guy until Don Box got to his brain (tried it on de Icaza as well). Listening to the Indigo spiel, it all makes sense except for the fact that Indigo isn't available to use now. This makes decision making more uneasy if you need high performance remoting style functionality now and don't need to go outside a particular organization's boundary.
- SOA Emphasis. There seems to be way too much emphasis on SOA at the moment. Don't get me wrong, SOA sounds like the way to go for a broad set of applications. I thoroughly enjoyed Pat Helland's talk on Metropolis, but feel that there is still a large set of applications that fit within a deployment boundary and would actually benefit from sharing of code between parties - sort of like the smart client deployment concepts except applied to remoting.
- Generics Support. The available of generics support in VS.NET 2005 will be great. One downer about it is that so much of the standard framework that exists now wasn't designed with generics in mind. This isn't that much of a problem, but the "neatness" nut in me would like to see generics used consistently all over the framework (where it applies of course, the Standard C++ approach of templatizing every freakin thing is not what I'm taking about here).
Okay... enough of the API whinges you say! I'm actually coming around to the point of this post. Unlike Joel Spolsky, I thoroughly applaud Microsoft's .NET efforts but... A developer can only take some many major API turnarounds until cynicism sets in. Microsoft's reasoning for all of the API disappointments listed above do make sense to me. I've accept the reasoning and moved on with strategic planning based on my understanding of the various API directions. Now if another major .NET API turnaround/replacement hits us then.. well then I'll finally lose it (patience that is).
Back to the war analogy for APIs and some crazy-ass crystal ball gazing 
:
It seems to me that Microsoft will be winning most of the various API skirmishes coming in the next 2-3 years. This is because of the excellent work being done on the .NET framework (or it's next incarnation WinFX). The real "battleground" in my mind (continuing Joel's analogy) is once .NET/WinFX is established as the primary API and installed on most of the world's desktops and a fair chunk of the servers. The WinFX API will "settle down" and alternative implementations of the API will start catching up. The important parts of the WinFX API have to eventually settle down. If they don't developers will probably just throw up their hands and ignore any new APIs or direction changes.
My reasoning for there being non-Microsoft versions of WinFX is that if a bunch of talented people can reproduce the Win32 API in Wine then it is likely that something similar will happen with WinFX - especially considering the advantages of managed code (versus x86 specific binaries). The beauty of managed code is that it is just that "manageable". This is why we have such programs like Reflector, .NET Test and JTest. They live in the world of IL/bytecode and leverage off of it.
Once alternative implementations of WinFX start appearing in 2-3+ years, Microsoft will have some headstart because of all the technical trail-blazing and it will probably be somewhat of a "golden age" for the company. But eventually Microsoft will have some choices to make for handling the new situation. Some options include:
- Starting to become more attack oriented with their defensive patent portfolio (and other such litigation measures).
- Just keep pumping out the new APIs.
- Start obfuscating more IL code to retain some form of propietrary advantage - even the standard libraries (where practical).
- Rely on having a better implementation of the APIs.
- Rely on the installed based to carry them through.
Some of these options are particular unsavoury (at least to me). Well... It's going to be fun looking at these sort of posts a decade down the track and seeing how wrong I was!
PS: I know it's unrealistic to theorize about these sort of futures, because of the probability of getting it right is ridiculously low. But the thought process is useful to help make decisions in the here and now.