Office for Mac and the interoperability divide
As an industry we are terrible at working on interoperability. The open-source world should be the one to fix this.
I was reading the latest issue of Mac|Life tonight (I liked it better as Mac Addict, by the way), and it struck me how dependent Apple is on Microsoft. For all the cool things that come with Mac hardware and OS X, a large swath of the Mac user population would be crippled or wiped out if Microsoft decided to stop supporting Office for Mac.
The Mac faithful (of which I am part) won't like to hear this, but it's true. OpenOffice is an excellent program (It actually is now--three years ago it was rubbish), but many of us simply couldn't use it "in production." Sure, I could run Office for Windows in Parallels' coherence mode (and almost certainly would), but that's an unnecessarily roundabout way of solving something best done directly.
This is a relatively small problem for Mac users, right? I suppose so. The same thing, however, is true in the enterprise. Many prefer to run Linux for an increasing array of server-based applications. But they don't want to be stranded, just as I would be on my Mac without Office. Net net: interoperability is a Very Good Thing. It's good for open source, but it's also good for Microsoft (and everyone else, because no one has a complete lock on any particular area of enterprise software).
All of which makes me wish we could, as an industry, talk about interoperability with more candor. More honesty. This isn't a dig at Microsoft, though it has been guilty of conflating patents (a desire to get paid) with interoperability (a desire to get along). The two don't necessarily go together.
No, the problem goes much farther than Microsoft, and hurts Microsoft as much as it hurts Red Hat, SAP, Oracle, MySQL, etc. As an industry we are childish in how we approach interoperability. We squabble over standards, each of us trying to make sure our standard is the chosen one. And then we squabble over whom should "go first" and risk standardization.
In my world, customers are asking that Sharepoint repositories interoperate with Alfresco repositories interoperate with Documentum repositories interoperate with...In the database world, enterprise customers want their Oracle, PostgreSQL, DB2, Ingres, MySQL, etc., databases to work together (indeed, EnterpriseDB is building a solid business by offering drop-in compatibility with Oracle). In e-mail, more applications (open source and proprietary) should interoperate with Exchange.
It just shouldn't be so hard. Especially since, historically, markets dramatically expand as interoperability/standards permeate them. We are better off when we work together, even when it appears that we'll lose in the short term. When customers win, vendors win.
I believe it is the open-source world that needs to be doing more to be driving interoperability. It should be the open-source world that "opens the kimono" on interoperability, in part because it's easier for us to do so. We don't need to worry about what the kimono is hiding because, by definition, open source has nothing to hide.
A good start would be joining forces to push leading incumbents like Microsoft, Oracle, etc., to develop programs to work with open-source companies. Microsoft has come closest to this (SugarCRM, Zend, MySQL, JBoss, etc.) but has yet (to my knowledge) to develop a programmatic (read: safe) way of working with the company, and its patent noise has muddied the water a bit.
We in the open-source world want to interoperate with the proprietary world. Would some of us prefer to have the proprietary world open up? Of course. I'm in that camp. But in the meantime, we want consistent ways to partner with incumbent vendors to bring value for our mutual customers. I, personally, would love to help proprietary vendors figure out how to engage open-source communities and companies without getting burned, so that there's mutual trust and respect. I'm thinking a small caucus is in order to hash out some ideas...
Meet me on the mountain biking trails of Deer Valley in September. Let's figure this out.