The Open Solutions Alliance

Businesses are increasingly attracted by the freedom and flexibility that open source provides, but many remain put off from making the leap by concerns over interoperability in the absence of any centralized coordination. The free software community recognized this as a growing problem some years back, and set up projects like the Linux Standard Base to ease compatibility issues. But the LSB deals only with interoperability between GNU/Linux and the applications its runs. As more open source enterprise programs have appeared further up the stack, a secondary — and even thornier — problem has emerged that involves interoperability between the many different combinations of applications.

To begin to address this problem, the Open Solutions Alliance (OSA) was launched [PDF] in February by ten companies operating in the field of open source applications: Adaptive Planning, Centric CRM, CollabNet, EnterpriseDB, Hyperic, JasperSoft, OpenBravo, SourceForge.net, SpikeSource and Talend. The Alliance grew out of a meeting in November 2006. "It was a collection of Bay Area open source vendors that wanted to talk about collaborating to build better enterprise class solutions," explains Hyperic's Stacey Schneider. "The conversation quickly turned to being a community issue that was larger than anything we could do as point solutions."

As SpikeSource's Dominic Sartorio, who is also president of the OSA, explains, the basic inspiration was open source itself: "a large number of commercial entities have grown where open source is a development methodology and means of doing business, and they could collaborate through collective effort in similar ways that developers around the world collaborate on building better software." The OSA also hopes to extend the scope of collaboration: "we were also thinking in terms of taking the notion of community to business users, getting together on common requirements," Sartorio says.

Finally, the OSA intends to tackle another problem its members constantly face when bidding for contracts. "Open source just hasn't been one of the alternatives that [a] particular customer may have considered," Sartorio explains. "They may have a short-list of proprietary vendors, but they haven't even thought of the open source one. And we found the reason for that may just be that even if they are are aware that alternatives exist they may not believe it's mature, or they may not have seen enough success stories to believe it's mainstream enough to be ready for them to adopt." The OSA aims to counter that impression by pooling efforts to raise awareness about the maturity and increasing adoption of open source solutions.

One of the main arms of the OSA is its interoperability group, which is headed by Barry Klawans, CTO of JasperSoft. He explained how the group works. "We've actually changed our thinking a little bit since February, when we launched the OSA. Our plan then was we would launch projects on the forums, we have a lot of discussions about them, we drive to some recommendation, codify it, then do a reference implementation. We've since decided that it probably makes sense to launch the initiatives, talk about them a little bit, then dive in and get our hands dirty - really learn by doing. Then, when we've really got some more insight and more detail, put together a formal recommendation, go through that, codify it, and at that point, retrofit any previous work to match the actual codified standard that comes out at the end."

Klawans explains why there was a shift: "It's not like we're a standards organization where people who have been working on this for 20 years get sent to the committees; we're a consortium of vendors who are all trying to work together." According to Klawans, this is an important distinction: "I don't want us to become a traditional standards body, because in my mind that is the opposite end of the spectrum from innovation: when you stop innovating, you then codify."

Sartorio echoes this thought: "Whenever we're driving any kind of interoperability initiative, very, very rarely do we expect that we'll have to invent something new. In most cases we find that there are existing standards, or existing reference implementations, or existing best practices out there, but they may not be widely used, or there may be several different options to choose from and the fact that there's so many options makes it an interoperability problem. So it helps to have an organization like the OSA come in and in a completely open and public way have a debate over what are the right approaches in making an implementation." Klawans emphasizes the importance of outside input, and asks anyone interested to "register at the site, get onto the forums, participate in the discussions, help us out."

As part of its open approach, the OSA has published what it calls its Interoperability Roadmap [PDF], detailing who will do what, and when. For example, the Infrastructure Task Force aims to "reduce install, configuration and deployment burden, minimize the footprint of deployed components, and ensure that disparate applications are easier to integrate out of the box." The Management Task Force, meanwhile, will be addressing ways of improving the user experience of installation, configuration, logging and monitoring by agreeing common approaches.

The first project, to create a common customer view profile, is already underway. As Klawans explains, this has grown into a surprisingly ambitious undertaking. "That just came out of us in the interoperability group talking about well, we want to do this, we want to do that, we want to define the common data model, we're working on security and single sign on," he says. "And at some point, someone said, you know, why don't we build something that shows all of these?" Although audacious, taking such a bold approach for the first project does have its advantages. "It would help us figure out the process," Klawans notes, "it'll really make us sweat the details, and at the end of the day, it will make a great OSA demo."

All this work will be fully open source. "Whenever we're working on any kind of prototype," Sartorio says, "where we want to take several applications and prototype some kind of integration, we're always going to use an OSI license version of any of those products. Similarly, whenever we have to develop new code - for example, if we're taking on an interoperability challenge and there's no existing standard or existing reference implementation - we'll always release that under an OSI license."

This rigor contrasts with a more relaxed attitude when it comes to membership of the OSA, which depends on a company espousing "open solutions" rather than strict open source. As Sartorio explains: "we didn't want to limit ourselves to a very strict definition and then leave out a lot of the hybrid entities out there that really do share a lot of these common problems with us, and really are adopting open source at least as a development methodology, and at least sort of the spirit of doing things in an open and collaborative way."

Given this looser definition, one intriguing possibility is that Microsoft might in theory be eligible to join the OSA. Sartorio comments: "I'm sure if they did, they would be some real interesting conversations. I for one would be concerned about the public image if they joined. I don't think that would happen." Moreover, Sartorio believes that it's "definitely possible" that the definition of "open solution" might be tightened up in the future as more companies adopt OSI-compliant licenses.

It is still very early days for the OSA. New members are joining [PDF] all the time — the initial ten has grown to 18 — and new projects are being defined. But Sartorio already has some clear ideas of what he hopes to achieve. "First, driving the adoption of commercial open source alternatives to proprietary, to the degree that we're going to make every short-list. The second measure of success, on the interoperability front, would be if we've got good solid and ratified interoperability proposals and best practices that cover most if not all of the interoperability issues that one would typically encounter during the course of a deployment or trying to bring different solutions together." To which Klawans adds a third: "another measure of success for the interoperability group will be when closed source vendors start implementing our interoperability rules as well."

Glyn Moody writes about open source at opendotdotdot.