Porting software to another platform is tricky business. Take the first version of Safari for Windows as an example. It was not a great success, because Safari 3 on Windows did not quite fit in:
Other grumbles were more because Safari seems like a Mac-application, making it seem out of place on a Windows desktop.
Mac-users, firmly convinced of the superiority of the Mac platform may assume that a Mac-app running on Windows should “obviously” appear superior to Windows users. That’s not the case.
Even if you were to accept that the font rendering in Safari 3 is superior to Windows standard font rendering, the difference sticks out like a sore thumb. In Safari 4 for Windows Apple fixed most of the issues:
Safari now looks more like a standard Windows app. Previous versions stuck with the iTunes/OS X brushed metal interface, which stood out for several reasons: the buttons and scroll bars were standard OS X Aqua elements, rather than standard Windows items.
So, when porting to a new operating system simply getting it to run is nowhere near enough. Operating systems come with a culture, complete with their own installers, GUI style, jargon, and soft drink preferences. Your port has to match the culture.
Sometimes you need to port between platforms which aren’t operating systems. You might feel the need to support two or more different RDBMS’s, for example. SQL is a standard, right? What could go wrong? Jim Melton, the editor of the SQL standard for 20 years, said in SE Radio Episode 137: SQL with Jim Melton:
“It’s unclear exactly what the driving factors were for most of the organizations [for standardizing SQL]. I know for some of the vendors who eventually became dominant, ones like Oracle, IBM, and Sybase, the driving motivation was the ability to have the illusion of portability. Yes, I’m being honest here – so that you could sell your system to a customer and allow him to believe that there was some chance he would be able to port his programs, and that there wouldn’t be vendor lock-in.
Not all standards were born alike, huh?
So, all this is evidence that you shouldn’t take porting lightly. It’s easy to underestimate the cost or downplay the importance of porting the culture. And the technical side ain’t always a walk in the park, either.
After the initial port, you’ll need to develop, test, support, and maintain the software on two platforms instead of just the one. Introducing a second platform can effectively double the surface area for bugs to attach to. Also, once you’ve opened that door, why not add a third platform? A fourth? Are you sure it’s going to be worth it?
- 6 Tips for Small Software Vendors to Understand Enterprise Customers
- How to Distribute Commercial Python Applications