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
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
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.
to post comments)