Robert Pogson

Here is an excerpt from
http://edge-op.org/iowa/www.iowaconsumercase.org/010807/PLEX_5906.pdf an M$ memo, an exhibit in the Iowa Consumer case.

Switching Costs

In economics there is a well-understood concept called switching costs – how much it costs for a trading-partner to change partners. Our philosophy on switching costs is very clear: we want low switching costs for customers who want to start using our platform, and we want to provide so much unique value that there are in effect high costs of deciding to move to a different platform. There is a name for this: it is
called Embrace and Extend.

Embrace means we are compatible with what’s out there, so you can switch to our platform without a lot of obstacles and rework. You can switch from someone else’s Java compiler to ours; from someone else’s Web server to ours; etc. Customers love when we do this (as long as we don’t spend our energy embracing extra standards no one really cares about); our competitors are not so sure they like it because they prefer us to screw up.

Extend means we provide tremendous value that nobody else does, so (A) you really want to switch to our software, and (B) once you try our software you would never want to go back to some inferior junk from our competitors. Customers usually like when we do this, since by definition it’s only an extension if it adds value. Competitors hate when we do this, because by adding new value we make our products much harder to clone – this is the difference between innovation and just being a commodity like com where suppliers compete on price alone. Nobody builds or sustains a business as successful as Microsoft by producing trivial products that are easy to clone – that would be a strategy for failure.

If we fail to embrace, we can lose because there are big barriers to buying our products. But if we fail to extend, or do only humble work that is easy to clone or to surpass, we automatically lose because our competitors will spend literally billions of dollars to clone our work and replace us.

The Windows API

Windows was a very successful embrace-and-extend move. People already had DOS machines and DOS apps, and we were able to go in and say “add this to your machine and it will just get better.” Wow! What a deal! It seems to have worked out all right so far. NT is a very similar move; although it’s not trivial to upgrade from Win95 to NT, in general you can use the same compuler, same apps. and same APIs as before, plus more.

The really big win in Windows is the API. An app that calls the Windows API is effectively calling upon thousands of person-years of engineering work to help their app get its job done in a very specific way. You could argue that the API is too hard to use, that not every library is as fast as ii should be, or other serious imperfections, but the fact remains: if you took away Windows, that application would no longer work.

The Windows API is so broad, so deep, and so functional that most ISVs would be crazy not to use it. And it is so deeply embedded in the source code of many Windows apps that there is a huge switching cost to using a different operating system instead. You can’t just take a Windows app and stick it on some weird Java NC from Oracle, for example, and expect it to work – the guts just are not there. For many customers, the cast of reworking all their apps would be huge.

It is this switching cost that has given customers the patience to stick with Windows through all our mistakes, our buggy drivers, our high TCO, our lack of a sexy vision at times, and many other difficulties. People have tried to clone Windows, but it is just too hard to do well. Customers constantly evaluate other desktop platforms, but it would be so much work to move over that they hope we just improve Windows rather than force them to move.

In short, without this exclusive franchise called the Windows API, we would have been dead a long time ago.

This was written while developing strategy to embrace and extend java, but it is the same thing with Linux. It is difficult to migrate apps to Linux from that other OS if the full API (or that part of the API M$ has revealed to outsiders) has been used. Apps are a problem for about 20% of situations with PCs so this is one factor that prevents users from migrating to Linux. It is also obvious that using M$ stuff makes it difficult to interoperate. M$ goes out of its way to extend standards so that competitors cannot interoperate. IE-only websites are an example we see frequently.

Computer users need foresight to realize that bearing the cost of that other OS forever is a huge burden. It is worth the short-term pain to save that huge cost (and freedom from FUD, malware, BSODs etc.). It is much like a mortgage on your house: a shorter amortization period is more difficult, but you can pay off the mortgage in half the time and really boost your discretionary cash flow later. The easy cases of migration to Linux terminal servers and thin clients can break even in a few months. The difficult cases may take years to break even. It all depends on how long you plan to stick around. I think the future is brighter with Linux on the desktop.