Two Thoughts on Interoperability

by chromatic

If you define the problem as "A product 100% binary, bug for bug, compatible with Excel that releases new versions at the same time as Excel" you kinda stop even the hope of migrating someday in the future, because that ain't possible.

jmorris2 on LWN's "A think tank's view of free software"

Proprietary software companies such as Microsoft have their own source code and they have unencumbered access to read any free software source code they wish—without incurring any legal obligation to distribute their source code. If they truly wanted interoperability, they could pursue it anytime.


Simon Hibbs
2007-05-10 06:32:05
This is a good point. People who realy care about precise conformance with all the idiosyncracies of Excel simply aren't going to stop using Excel. To compete I do think you need some level of compatibility, but your actual target market is essentialy new spreadsheet users then that should drive your product development.

I suspect there would be a lot of mileage in developing versions of open source applications specificaly aimed at students, accademics and home users. They're demographics that would realy appreciate free quality tools and either have little invested in existing apps or are generaly willing to adopt new products and techniques. Frankly OpenOffice is never going to beat MS Office in the corporate market simply on merit, so why even try? Look at what user constituencies are being under-served by commercial vendors, and try to help them. The problem is that is run by a corporate sponsor who isn't going to see this.

2007-05-10 10:38:45
@Simon, exactly. Availability of source code probably isn't the primary driver for adoption for most people in the world (nor is it likely to be even if the campaign to educate people about software freedom succeeds).

I started to wonder today how this argument applies to hardware as well.

Roy Schestowitz
2007-05-11 17:11:47
"A product 100% binary, bug for bug, compatible with Excel"

It's not a bug, it's a standard.

Rick Jelliffe
2007-05-16 21:09:58
There are two kinds of interoperability issues: one is the surface syntax, the other is the underlying model. Differences in the surface syntax are at worst inconvenient for users, and transformations and alternative syntaxes are trivial. Differences in the underling model are far more problematic.

For example, when one spreadsheet supports shared string tables and the other doesn't, does "interoperability" require that the former gets rid of this feature, or that the latter should add support, or merely that one of the options for saving should be in a simplified subset that doesn't support the feature?

Or when one application is entirely based on referential indirection (multiple files, where references to the files are mediated through a lookup table in a separate file, and references are made using the lookup keys) and the other is based on direct use of URLs, does interoperability require that everyone dumb down or that everyone bloat up?