Here are some of the claimed advantages of portability. Do they hold up?
Claim: By supporting multiple platforms, we can address a new market segment. This is compelling since addressing more market segments with essentially the same product is a good thing. Be careful, though. Effective marketing practices teach us that the key to long- term success is successful market segmentation. If you're basing your market segmentation on the kind of operating system or hardware platform your customers are using, you may be choosing the wrong approach. Effective segmentation is based on the problems faced by common customers. Focusing on business problems, such as asset management or improving call center efficiency, usually dominates choices of technology platforms.
Claim: By supporting multiple platforms, we demonstrate that we can meet our customers idiosyncratic needs. This marketecture claim has a tarchitecture corollary. By supporting multiple platforms (or standards) we can demonstrate technical skill. Sadly, technical skill rarely wins customers. Solving their needs does. Portability can detract from this, especially when customers who choose a platform for specific features find that your product does not support them because they are not cross-platform portable. I refer to this as the portability paradox. Customers choose a platform for its unique features and perceived benefits, but most portable applications are explicitly designed to avoid platform-specific features!
My experience indicates that the real motivations for portability aren't that impressive. Here are some that I've stumbled across.
Real motivation: Developers think writing portable software is cool. It can be a lot of fun to write something that is portable. Portability can stretch your limits as an engineer, and creating an architecture that achieves key objectives (such as performance or stability) across multiple operating environments is an impressive accomplishment. On the other hand, it can be a real pain and no fun at all to create a portable application. Subtle differences in operating systems, even operating systems from the same vendor, often means that things that work in one version break in another. Sometimes there is simply no way to offer the same capabilities in different operating environments, which means that you have to compromise either your product objectives or your technical approach or both. Many developers find it tiresome learning about multiple operating environments.
Real motivation: One or two early, key, customers demanded different solutions. Unless a product is managed with considerable discipline, it is easy to do "anything" to secure early, key, customers, sometimes including porting the application to a different platform. This is usually a mistake. When a marketect finds customers who demand different solutions in the early stages of the product he should continue to search for a better customer (where better is defined as "within the target market") and not direct the development team to port the code too quickly. Experience has shown that this is arguably the biggest motivation.