Early on in the OSA's history, before we launched, we identified interoperability as a key barrier to enterprise adoption. End users we spoke to raised this as their number one issue. Open source's greatest asset - the ability to tap into the innovative talents of organizations and individuals worldwide - can also be an end customer's greatest frustration - "How do I get all of this to work together"? This included a broad array of issues, both technical and non-technical (support, project management, and so forth).
Commercial open source vendors can address this within the scope of their respective point solutions, but can't individually address the many issues encountered in the typical enterprise nearly as well as our larger, consolidated proprietary competitors. Moreover, we should view this as a competitive threat,
as Dana Blankenhorn recently expressed.
However, this apparent weakness can also be a strength: Interoperability is, more than anything, a collective problem, and collective action is the best way to address it. And what better model for collective action than open source, applied to the universe of business solutions? This was the founding premise of the OSA. Through collective action, we can accomplish more than we could accomplish independently.
We also published an interoperability
manifesto followed by a
roadmap, outlining our approach to interoperability. After quickly publishing a handful of best practices, we learned that the thorniest issues also require some hands-on experience, and so we got our hands dirty. This led to our
Common Customer View prototype, which integrated CRM, ERP, business planning and business intelligence according to a set of real-world use cases.
We then demonstrated this at last month's LinuxWorld Expo in San Francisco, and got some valuable feedback from other vendors, integrators and end users.
Along the way, we acquired great experience in putting our respective products together, and also understanding of how to improve end customers' experiences with our and similar products. We also identified areas where clean, lightweight ways of solving a specific integration challenge were lacking, and built our own. These are all being
open sourced (under an OSI compliant license) and hosted on Sourceforge. Moreover, for the first of these (a single signon component) we hosted
a "hack-a-thon" at this year's OSCON, in an effort to educate and solicit input from interested developers.
In short, we have accomplished a lot on the interoperability side: Researching the main issues, outlining our approach, gaining experience in a hands-on way, and engaging with the developer community both to raise awareness and contribute code to the cause.
Of course, all of this begins and ends with the needs of our end users. In our next segment, we'll cover what we are doing in terms of customer outreach.
