Post date: Feb 3, 2012 6:11:02 PM
Each platform you support costs your engineering team extra effort. Each platform you code to not only has different APIs, but also different quirks that the same API calls have across different versions of the platform. You'll have to write your code portably for those parts amenable to such a treatment and have separate code bases for those parts of your code that aren't. This goes for OSes, UI frameworks, databases - any significant platform upon which your code is based. It's obvious that adding support for multiple platforms will increase costs.
But more insidious are the non-obvious costs associated with each additional platform you support. Because you must separate portable and platform-specific portions of your code, your architecture becomes more complex. Unless you're very lucky, adding new features will take longer because their platform-specific parts will require multiple implementations (and we will not touch here on the idiocy of a disastrous decision like allowing product functionality to diverge on different platforms). The build system will become more complex and more error prone. Unit tests will become more difficult to implement. All testing will require more test cases and more time. You'll need additional hardware and software to support each platform. And this is just in engineering - when you hand off the product to a support organization, the same fun is duplicated and your support costs will balloon. Sales will need to target different customer bases (whose markets they don't actually understand) and advertise in different places to reach these new customers. Costs of sales will skyrocket.
In addition, from a usability point of view, most products that target multiple platforms suck. Either they work well on their main development platform and suck on others or they suck on all of the platforms they run on. Why? Because platforms differ so much these days and have so many features that the features required on one platform will not translate to another. You'll either be stuck with separate products for each platform, which customers will hate when they can't easily switch back and forth between platforms, or a compromised solution, which customers will hate because the feature set isn't proper for the platform. It's an awful dilemma.
But things are a bit better with web-based interfaces, aren't they? Well, yes and no. Assuming you have an application that is amenable to web-based implementation (which is not always a given), you still have the plethora of browsers to support - the browser is a platform. You'll have to find a UI widget set that runs well on all of these platforms (and good luck with that, by the way) or code your own. Your days will be a tedious slog through minutia of browser bugs. Every Opera and IE6 user will complain that your code doesn't work right, and you'll never know when Firefox is updating. Your life will still be awful - just not in quite the same way.
The moral of this story - support as few platforms as is feasible.
The good news is that mature markets in software seem to ultimately devolve to a simple oligarchical structure - one major player, one minor player, and a plethora of also-rans. You'll only have to support two platforms to cover the majority of the market! The bad news? Your two main platforms (Windows and OS X, Android or iOS, IE or Safari) are going to be radically different in structure and in capabilities. You might be able to reuse some internal logic from your core code but, in reality, you'll be coding two separate apps. And the also-rans? At least one major customer with deep pockets will tempt your business with dreams of filthy lucre beyond your imagination if only you would support Sneezy, Grumpy, or Dopey (because they made a poor decision to standardize on this platform).
So what do you do? First, you stick with a single platform as long as you can. Perhaps, if you make enough money with that, people won't bug you about running on other platforms. Ha, ha! That was funny - businesses can never have enough money! So, second, each potential new platform must go through a rigorous cost-benefit analysis, making sure that all of the non-obvious costs - from engineering, support, and sales - are accounted for and that the all-to-real possibility that the product may not sell well on the new platform is taken into account. Finally, when there's no pushing back, when your hopes are dashed, and all your options have run out? "Prayer, Mister Saavik - the Klingons don't take prisoners."