Interoperability is one of the sacred goals of IT, and even consumer computing.  If operating systems, utilities, and applications do not work together, user productivity matches the low level I achieve on Friday around cocktail hour … which is "none at all."

Open Source is ripping profitability out of the IT software market in part do to growing interoperability.  Unlike traditional technology vendors, Open Source benefits from creating the greatest amount of interoperability possible.  More commercial vendors keep margins high by locking in customers to their suite of products.  This is partially achieved by minimizing interoperability with competing and non-partner solutions, and thus raising switching costs should a customer consider "dumping and jumping" to a different stack.

Linux/GNU and their compatriots have been a model for interoperability.  They collectively seek to create as much of the stuff as possible, assuring most of the components of the Linux stack work extremely well together.  Without traditional profit motives, the only barriers to interoperability were time and complexity (the time it takes to code interoperations, and the complexity of supporting multiple points of interoperation).

But this interoperability has been done on a handshake when developers from different projects found need and motivation.  This has led to odd partnerships, some necessary exclusivity, and a bit of weariness by IT in adopting Open Source solutions for fear that necessary interoperability that exists today might not exist in the future.  Open Source has now grown to a point where consumers desire a bit more structure.

The Open Solutions Alliance (OSA) has started adding structure.  This happened pretty quickly for an organization that didn’t exist three months ago.  But when you have founding members like CollabNet (who now owns SourceForge Enterprise), EnterpriseDB, Hyperic, JasperSoft, SourceForge.net, SpikeSource, and Unisys … well, you have a bit of muscle to get things done.

What OSA initiated is an interoperability roadmap — an attempt to specify some well-defined interoperability standards in the business software space.  That’s right, interop in applications.  The objective is to document standards and best practices for Open Source developers to use when building their software.  The OSA will help by prototyping working code to demonstrate the principles of the standards. The initial prototype will be the Common Customer View.  This standard joins information held in different applications (CRM, ERP, etc.),  business intelligence software, and for demo sake, a legacy point-of-sale application.

This presents new issues for software marketing professionals.  If you are a traditional application vendor, you will eventually encounter new competitive threats.  All other things being equal, interoperability between Open Source applications would be a deal-making differentiator. 
Your products will either have to interoperate with best-of-breed commercial applications, interoperate with Open Source applications using OSA standards, or both.

If you are a dual-source vendor, these standards will become part of your value proposition.  This is a boon to dual-source vendors, creating an advantage over best-of-breed commercial applications while adhering to the Open Source promise of lower cost and greater flexibility.  I can foresee a time when the old networking-centric Interop trade show could become the application-centric Interop event, where all the application software vendors demonstrate live how they work with all the other vendors in the building.  Interop launched standards-based networking, and OSA may launch standards-based applications.