.NET on Linux, part 2 - "It's the API, stupid"
Speculation on a strategy for Microsoft to co-opt Linux
Pardon the title. I'm not actually calling anyone stupid. Just couldn't resist co-opting President Clinton's '92 campaign theme.
While writing my previous blog entry on .NET on Linux, I started thinking about what makes up an operating system. Certainly there is the kernel, there are system services, and there is the developer API. If one company is going to control the flow of money related to an OS, it may not need to control the whole OS. And if it set out to control just one part of the OS, the developer APIs would be that part. Controlling the developer API means controlling how software is built on that platform. It means being in the best position to provide tools for that API. It means being the one to arbitrate interoperability.
I believe that Microsoft has a shot, if they so choose, at making .NET a cross-platform developer API that would give them almost as much money-making ability and control over open-source OSes, such as Linux and FreeBSD, as they have over Windows itself.
A good description of the value of controlling the developer API is found in Jerry Kaplans book, Startup:
Creating an API is like trying to start a city on a tract of land that you own. First you try to persuade applications programmers to come and build their businesses on it. This attracts users, who want to live there because of all the wonderful services and shops the programmers have built. This in turn causes more programmers to want to rent space for their businesses, to be near the customers. When this process gathers momentum, it's impossible to stop.
Once your city is established, owning the API is like being the king of the city. The king gets to make the rules: collecting tolls for entering the city, setting the taxes that the programmers and users have to pay, and taking first dibs on any prime locations (by keeping some APIs confidential for personal use).
This is the great secret of the computer industry. While the newspapers chronicle the daily skirmishes of computer companies and their products, the real wars are over control of APIs, a subject too arcane to attract the attention of the press. But once an API is established, the owner has a natural monopoly of unprecedented proportions. API wars are brutal, winner-take-all conflicts in which the losers become mere shadows, eking out a marginal existence in specialty markets.
Sun and Microsoft realized this long ago. At a strategic level, Java was an attempt to by Sun to wrestle the developer API away from Microsoft by providing a cross-platform abstraction for developers to code to rather than coding to the native APIs. And it might have succeeded. Sun was able to drum up enough industry support -- and enough players were wary enough of Microsofts growing hegemony -- that many vendors jumped on the Java bandwagon. Several capable companies tried to create pure Java suites to compete with Microsoft Office, for instance. Sun also ingeniously targeted the green-field "platform" of the browser as a way to differentiate Java from the cross-platform GUI toolkits of the past. Microsoft was forced by the industry to support Java, at least for a while. If Suns plan had worked, all the software we use today might be written in Java and Microsoft might be scrambling to catch up.
But it didn't work. Every pure Java office project, for instance, failed. Developers on those projects have told me that it was Javas lack of focus on usability and performance that killed them. Those types of apps have to be pixel-perfect and Java was not pixel perfect. So Microsoft retained app supremacy and also retained control of the developer APIs on Windows, which has become essentially the only business desktop platform that matters at this point. Microsoft also performed an "embrace, extend, extinguish" on Java, almost immediately adding proprietary features to their version of the JVM, the result of which has been lawsuits, C#, and banishment of the JVM from Windows XP.
However, Java did go on to find big success on the server, where cross-platform does still matter (because there are still several vendors selling servers; if Microsoft sews up the server market too, then cross-platform wont seem important on the back-end either). Plus, on the server, Javas usability issues are far less of a problem.
To reconnect with my original point, I fear that Microsoft is maneuvering into a position to turn the tables on Java and provide what Java set out to provide in the first place: an abstraction layer that will allow developers to write to build high usability apps for many platforms at once. And it has a much stronger starting foundation: firm control of the most prevalent desktop platform, a reputation for getting things "pixel-perfect", and the worlds most popular desktop software, Office.
If Microsoft chooses to go down this route, it can jump-start the process and start making money from Linux and other OSS platforms by making its vast catalog of applications available for purchase on those platforms. Those apps will pull the .NET framework onto desktops that dont already have it.
A world in which every computer is running Windows is probably impossible, because users get to choose, and there are users who dont want Windows, for one reason or another. But only developers choose the API and write software to it. Users dont necessarily even know about the API. If Microsoft successfully attracts large numbers of non-Windows developers to .NET as a way to develop Windows-style apps across all platforms, then they dont have to wait for users to adopt Windows. The essential parts will be baked into everything they could possibly buy.
Of course Microsoft has to want to do this, which is not a given right now (although they are already testing the waters with the Mac and FreeBSD), and the success of this strategy will depend on how strongly Microsoft can establish .NET as the client side technology standard.