X
Business

The Economics of Cross Platform

If you've read my bio, you know that I have an Economics degree from Penn. That pretty much entitles me to take your order at Starbucks. Essentially, it means that I wasn't quite good enough to get into Wharton and didn't want to work as hard as the Engineering kids. Despite my lackluster showing as a student, sitting through a bunch of economic classes did teach me to look at things a little differently, which has been an asset when evaluating technology. It is also one of the reasons I struggle so much with the issue of cross platform.
Written by Ryan Stewart, Contributor
If you've read my bio, you know that I have an Economics degree from Penn. That pretty much entitles me to take your order at Starbucks. Essentially, it means that I wasn't quite good enough to get into Wharton and didn't want to work as hard as the Engineering kids. Despite my lackluster showing as a student, sitting through a bunch of economic classes did teach me to look at things a little differently, which has been an asset when evaluating technology. It is also one of the reasons I struggle so much with the issue of cross platform.
On the surface, if you are a company like Microsoft, it makes almost zero economic sense for you to provide any cross platform support at all. You have 82% share for web browsers [1] and more than 90% [2] of the market for operating systems. With those numbers, what economic incentive do you have to support the remaining 10%? None. In fact because your developers are so used to building applications for your environment, the cost of brining in people who can do Mac and Linux development is massive. Microsoft's opportunity cost for supporting other platforms is simply too large to make it worthwhile. Their unsuccessful forays into Mac development only prove that in the end, capitalism wins out.

So what about a company like Adobe? Adobe has always had a long history with Apple, and because a lot of designers choose to work on Macs, Adobe supports them pretty well. It's also much easier to build on a foundation than to dig one from scratch, so Adobe can make heavy use of its Apple knowledge to build iterations of its software suite and help with new initiatives (like the most recent version of the Flash Player). Adobe's barrier to entry for the Mac world is very low, and as a result, there are a lot of Adobe apps for the Mac (although the Intel chip was almost like starting over). The fact that we'll soon see a Flex Builder version for Mac shows that if nothing else, Adobe has placed a heavy emphasis on the platform. With Flash, the goal is ubiquity, and if you can cover Microsoft's 90%, plus Apples 5%, you're running at close to 95% with very little extra development work. That number is more than good enough for upper management.

And now the Linux issue. Despite my belief that Linux is important, there isn't any economic reason for big companies to develop Linux applications. The cost of resources it takes to do Linux correctly far outweigh any profit or benefit. The fact that Adobe is running with a skeleton crew of Linux Flash Player engineers and that the player won't ship until 6-9 months AFTER the Windows version ships shows you the pressure that a big company faces. It's hard to justify throwing money at a project that isn't going to provide a return on the investment. Spending, lets say, 2 times the Mac development costs to deliver a Linux Flash Player doesn't make any sense with the market share is lower.

If there isn't any economic incentive, why is anyone doing Linux, especially a company like Adobe? It's because the move is strategic. I'll talk more about this later today, but there are signs that Adobe is going through a bit of an internal struggle. How far do they want to take the Flash platform, how much are they willing to invest, and how well equipped are they to take on Microsoft. It's pretty easy to see that not all of the decision makers within the company are on board, and what they do has a lot of impact on the future Rich Internet Applications.

Editorial standards