Microsoft's new revenue model

Windows 8 brings a number of changes to software. A new UI, a new Windows API, and a spiffy new logo. But there is one other change that has gotten little discussion.

Windows 8 brings a new revenue model for Microsoft.

Microsoft's former revenue model was to charge end users, server operators, and developers. That is, Microsoft charged fees for software that they provided (think Office), for programs running on servers (think SQL Server and Exchange), and for development tools (think Visual Studio). It is a system that has worked since the beginning of the PC era -- but it has a hole.

The hole in this revenue model has been third-party software. Were I to build software and sell it, I would pay Microsoft for the development tools (third-party development tools have long been pushed aside) but after that I was free to sell my software to anyone, with no royalties to Microsoft. The revenue collection point (the "tollbooth") was on the development tools.

Windows 8 moves the tollbooth for third-party software. Microsoft has moved the tollbooth from the receiving dock on third-party manufacturing facilities to the front door of the retail center (the Microsoft App Store, conveniently operated only by Microsoft).

This is the model used by Apple. Apple charges nominal fees for development tools and mandates that all apps are distributed through iTunes, where it can collect a part of the action.

One can assume that Microsoft will reduce the cost for development tools, perhaps even open-sourcing parts of their development tools. Doing so is in their best interest. The more people they have developing software for Windows 8 and selling (through the Microsoft App Store), the better for Microsoft. It is better for Microsoft to collect 30% on the sale of $5 retail units (sold in millions) than 100% on the sale of $500 development kits (sold in thousands).

Likewise, look to see Microsoft reduce the complexity of development for Windows 8. Instead of a large API with intricate calls, look to see a simplified API with easy-to-understand calls. A complicated API is good when you are selling the development tools; a simple API is better when you are selling (or collecting on) the retail units. You want to encourage the development of new apps.

I expect that the Windows 8 API will undergo a number of changes in the first few versions. Unlike the classic Windows API, the changes will simplify the API, not make it more complex. Microsoft has strong incentives to make it easy for the development of Windows 8 apps. (Besides the revenue model, Microsoft must compete with Apple and Android.)

The new model holds for the Windows 8 retail apps, the ones sold through the Microsoft App Store. For applications that run on servers, the old revenue model applies. Expect a bifurcation of Microsoft products and pricing, with cheap and easy-to-use tools for the development of retail apps and expensive and hard-to-use tools for server-based applications. (Until Microsoft releases their Microsoft Server App Store, which lets it collect revenue on the sale and use of server-based apps.)