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?
Related posts:
- 6 Tips for Small Software Vendors to Understand Enterprise Customers
- How to Distribute Commercial Python Applications
If you liked this, click here to receive new posts in a reader.
You should also follow me on Twitter here.
Comments on this entry are closed.
{ 3 comments }
In my blog: Platforms Come With a Culture http://bit.ly/axBo1
This comment was originally posted on Twitter
So you’re saying that SQL is not portable, but there are a lot of applications which support multiple SQL databases. Do you have any examples on where there are actual problems?
It’s of course quite possible to craft your application so that it works with, say, all of MySQL, SQL Server, and DB2. It depends on the situation if it’s going to be worth it or not.
My personal experiences are mostly with MySQL, Oracle, and Sybase. Getting the same code to work with Oracle and Sybase was a bit painful. Oracle cannot distinguish between empty strings and NULLs, for example. Oracle behavior with respect to locking (and hence deadlocks) is different from most other databases. No problems on Sybase, lots of deadlocks on Oracle. Also, things like integer type precisions are different in different databases so you need to watch out for that. The list could continue quite a bit.
Like writing portable C code, it’s possible to write your code so that it works with multiple databases. But it’s still a far cry from “our app will works with any standard SQL database” and “we’ll use ODBC, so we can switch the database for free” which seem to be a popular myths propagated by people who haven’t actually done portable SQL.