"As enterprise open source solutions become more prevalent (and more mission critical) in IT, they will need to interoperate with other open source applications and non-open source systems. This is the main challenge faced by most open source vendors today."

Bertrand Diard, CEO, Talend SA

The Open Solutions Alliance (OSA) is a consortium of leading commercial open source vendors, integrators and end users dedicated to the growth of open source based solutions in the enterprise. We believe Linux and other infrastructure software, such as Apache, has become mainstream, and packaged solutions represent the next great growth opportunity. However some unique challenges can temper that opportunity. These challenges include getting the word out about the maturity and enterprise-readiness of those solutions, ensuring interoperability both with each other and with other proprietary and legacy solutions, and ensuring healthy collaboration between vendors and their respective customer and developer communities.

We feel this last point, collaboration, is critical. All of these challenges are common problems that relatively small vendors find difficult to solve on their own, and collective action is called for. However, collective action is something that differentiates the open source community: we have proven this works in development. Now it's time to take this spirit of collaboration to the next level, into the business domain.

While this article focuses on interoperability, the overarching theme is that of effective collaboration between vendors and their customers and developers. Within this spirit of collaboration, interoperability can be much more effectively dealt with.

Why is Interoperability Important for Open Source?

The OSA is often asked: "why is interoperability an issue with open source?. The code is open, so can't people easily make the necessary changes to interoperate as they wish? And, don't developers have the good sense to use open standards and build modular code?"

Our experience is that this is true with only the most successful projects, but not universally true for all open source projects. Drupal is an example of a successful project that owes its success to getting interoperability right at the very beginning. Its modular design facilitated parallel development by individuals all over the world, and downstream customers could easily "plug and play", thus helping drive adoption. But many great product ideas are being left behind because interoperability was an afterthought. Thus, collectively, the open source industry faces a significant unmet opportunity.

This isn't only true with developer communities, as commercial open source vendors often make the same mistake. Most vendors are small and take pride in being "focused", and their natural tendency is to focus on core product features so they can better compete with each other and the proprietary alternatives. Product managers request interoperability, but it frequently ends up "below the line" for product releases because of limited time and resources. Vendors get caught up in the feature competition game, and they plan on "ilities" later, such as interoperability, manageability, scalability and so forth.

The OSA believes this is suboptimal. Interoperability should be treated as a core feature. Without interoperability, many prospects will simply not adopt, resulting in less revenue opportunity, and therefore fewer engineering resources to fix the problem in later releases. Furthermore, the feature competition game never ends. This may sound like a chicken-and-egg problem, but vendors need to get interoperability right in version one of their products. The OSA wants to help educate and promote this among independent software vendors (ISVs). A little bit of near-term pain can result in a lot of long-term gain.

Many commercial open source companies sell through channels. They should be aware that the 800-pound gorilla of software channels is Microsoft, which sports a broad array of infrastructure and applications, most of which interoperate in a sensible way. Many integrators get everything they need from Microsoft, and don't worry about interoperability. That is our competition. Most commercial open source vendors, on the other hand, are small and focus on a point solution, which may or may not interoperate as well as the Microsoft alternative. If an integrator finds they need to spend more time to "stitch together" disparate open source solutions, they'll be less inclined to adopt them.

The same holds true for enterprise customers inclined to integrate themselves. Buying from Microsoft, Oracle or SAP may be deemed the "safe" option, because there is one vendor to hold accountable for getting the whole set of solutions to work. There is no equivalent in commercial open source. Instead, smaller vendors need to rely on a collaborative spirit and work together to overcome this.

Why is Interoperability Important Now?

The OSA has interviewed many commercial open source ISVs and other industry figures in recent months. We get the sense that the commercial open source industry is at an inflection point. There was a big wave of new startups and Series A and Series B investment rounds in 2005 and 2006, with entrants in most major categories of business software. Name any type of product and there is probably a commercial open source vendor who delivers it.

Now, there's a sense of "show me the money", as these companies try to drive adoption and grow their businesses. There is tremendous growth opportunity, but challenges remain in order for that growth to be realized. Most are adopting the usual "Open Source Sales 101" model of many downloads of free community versions, conversion to support and services contracts or commercial licenses, and attracting channel partners who add value. However, it seems that a small number of companies are excelling, and their success is overshadowing a broad spectrum of underachievement. We sense a growing disillusionment by many ISVs with this model as being too expensive and too time-consuming to generate results. We fear there will be a period of consolidation as more opportunity and attention accrues to the leaders.

This would be unfortunate. There are many strong products available, but they are paired with business models and strategies that are aimed in the wrong direction. Fortunately, we see only a few things separating winners from losers, and these are all actionable by vendors' executive teams. We suggest three differentiating factors.

First, the spirit of collaboration doesn't begin and end with open-sourcing one's code and attracting a few developers. The whole company, including sales, marketing and support, needs to engage in a spirit of collaborative give-and-take with its customers. Many companies are missing this, inevitably those whose management has limited open source experience. The winners understand collaboration at their core, as a defining aspect of their corporate cultures.

Second, don't assume there is a silver-bullet technical solution to the problem of how to reach customers. There is a lot of press these days about software-as-a-service and virtual appliances. These are useful, and vendors would be remiss to ignore them. But they are not a replacement for ongoing care and feeding of one's community, especially channel and end-users downloading one's product.

Third, don't ignore interoperability! If only we had a dollar for every time we heard: "I know I should make my product more interoperable, but I have to focus on core features instead." This stance misses the point that, increasingly, interoperability is a core feature. Most commercial open source ISVs, especially application vendors, are small companies focusing on a point solution, but most customers don't want a point solution. Customers need something that fits well into an end-to-end solution and the rest of their environment. ISVs ignore this at their peril. Successful ISVs plan for interoperability, with modular and standards-based architectures. Moreover, they form an ecosystem of complementary ISV partners, and then collaboratively build out and test the integrations.

The OSA and Interoperability

Shortly after our launch in February 2007, we found that we needed to be more specific about our interoperability goals and methods. Interoperability is a big hairball of issues, and if one isn't careful, it's easy to get bogged down and distracted from the issues most important to businesses looking to adopt open solutions. But what are those important issues? To answer this, the founding members spoke with our mutual customers, and their feedback resulted in our initial Interoperability Roadmap, published in April.

Simultaneously, we decided that we needed to actually build integrations between our disparate applications, before getting too far ahead of ourselves with best practices and white papers. This allows us to learn from our own experience and confidently recommend approaches that we know work in practice, instead of extrapolating from individual members' prior experiences. This exercise culminated in August at the LinuxWorld Expo, where we demonstrated the Common Customer View (CCV), an integrated suite of applications that streamlines visibility of business data relevant to customer relations. This was a huge success, both in terms of lessons learned and garnering further interest in our mission. Unisys decided to make the CCV the centerpiece of their open source business unit's services marketing efforts, and it continues to be our main interoperability testbed to this day.

And finally, we collectively realized that customer input isn't a point in time, but an ongoing process. Technologies and business requirements are always evolving. So, we decided to start the Customer Forum Series, a city-by-city series of half-day events designed to elicit input from end users of open solutions. We have done five of these now, and each has resulted in a wealth of anecdotes, success stories and lessons learned. Universally, we hear that the lack of interoperability is what stands in the way of broader adoption. Consequently, the interoperability priority hasn't changed, although we may focus on some specific problems, such as single sign-on and data integration, before others.

What is the OSA Doing Going Forward?

Interoperability will be a key focus through 2008. First, we continue to publish best practices for interoperability. These usually take the form of a white paper or how-to document focusing on a specific challenge. These are sometimes paired with code that developers can download and use as a starting point.

Second, we have several ongoing hands-on projects involving OSA members' product teams working together to get their solutions to interoperate. These efforts have several goals, including learning through experience, and offering lessons learned to integrators and enterprise developers.

Finally, while we usually try to leverage existing code and standards in our interoperability initiatives, sometimes we can't find anything that meets our requirements, and so we'll deliver something new. Such projects are available on Sourceforge under an OSI-compliant license.

Call to Action

Companies can get involved in several ways, with the most direct as joining the OSA as a member. Membership provides direct governance privileges and day-to-day influence and interaction with the rest of the membership, consisting of mostly executive-level development and marketing representatives of the member companies. Membership does come with responsibilities such as member dues and time commitment. For those companies not inclined to make the commitment, there are other ways to stay involved. First, we have an active mailing list which is open to the public. Anybody may subscribe and suggest ideas. Second, all of our work is publicly available on our website. The "Community" tab contains landing pages of current projects. One can also register and respond to discussion threads and offer feedback on existing projects. In short, it's all about a spirit of collaboration. "Go it alone" open source is the path to failure for all except those few companies with a killer app that were fortunate to get their product right at the very beginning. Everybody else should think holistically about what their customers really need, which often goes far beyond their own point products, and figure out how to best collaborate with other players to meet those needs.