There's no doubt that sector-by-sector, open source solutions offer powerful and cost-effective alternatives to proprietary enterprise software. But in one respect, open stacks still lag behind their closed-source equivalents. Partly as result of the heritage of individual projects beavering away on their own, the overall open source offering lacks the kind of co-ordinated and integrated development that Microsoft, say, can impose, top-down, on its products.
The importance of this issue has just been confirmed by a survey conducted the Open Solutions Alliance (OSA), which found that interoperability – or lack of it – between open source applications is the principal concern of the users it questioned.
By an amazing coincidence, the Open Solutions Alliance was set up to address precisely that problem. Here, its president, Dominic Sartorio, explains the origins of the group, its aims, how it functions and what future developments he sees for both the Open Solutions Alliance, and open source in enterprises.
GM: What's the background to the OSA: How did it come to be formed, who were the original members and what problem is it trying to solve?
DS: In early November, 2006, a group of leading open solutions and open source application developers got together to form an alliance dedicated to growing the market for enterprise class open business solutions. Open source development had proven itself at the operating system and middleware layers but was still in the “early adopter” stage at the application level. ISVs participating in the OSA kickoff meeting identified three important areas where collective action could be successful in accelerating adoption:
Defining and promoting guidelines and best practices for interoperability between applications.
Fostering a multi-vendor "meta community" of users, developers, and systems integrators.
Driving advocacy and drive awareness about the benefits of open solutions for business customers.
All of us agreed that none of these challenges could be readily addressed by any one vendor in isolation. Issues of awareness, interoperability and community are inherently collective in nature, such that collective action is required to address them. This led to the decision to create a trade association through which collective activity could be coordinated.
The Open Solutions Alliance was initially founded in December 2006 and the initial founding members officially joined during January 2007. Three working groups were established corresponding to the three major issues identified at the kickoff meeting: (1) Interoperability, (2) Community and (3) Advocacy.
Most of the attendees at this kickoff meeting have chosen to become founding members of the OSA, including Centric CRM, Hyperic, Jaspersoft, Openbravo and SpikeSource. During subsequent weeks, other founding members joined who were also instrumental in getting the OSA started prior to its launch, including AdaptivePlanning, Collabnet, EnterpriseDB, Sourceforge and Talend.
The OSA officially “unveiled” itself publicly at the LinuxWorld OpenSolutions Summit in New York on February 14, 2007. Since then, we have grown to 23 members and have made significant progress on all three fronts. The common theme of “working together on common challenges” continues to resonate, and we continue to attract more organizations and grow the portfolio of projects facilitated by the OSA.
GM: What are the main projects that the OSA is working on at the moment? How do these operate on a day-to-day basis, and how can companies get involved?
DS: Our current priority continues to be interoperability. We’re driving this on several fronts.
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, like single signon. Sometimes they will be paired with code that developers can download and use as a starting point.
Second, we have several “hands on” projects ongoing, involving OSA members’ product teams working together to get their solutions to interoperate. These efforts have several goals, including learning through experience, and also 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 licence.
Companies can get involved in several ways. The most direct way is by joining as a member of the OSA. This allows 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 (member dues and time commitment), but for those companies not inclined to make the commitment, there are other ways to stay involved:
First, we have an active mailing list, interoperability at opensolutionsalliance.org, which is open to the public. Anybody may subscribe (by sending email to interoperability-subscribe at opensolutionsalliance.org) and suggest ideas. Depending on the idea, somebody will respond with how to move forward.
Second, all of our work is public, on our website. One can go to www.opensolutionsalliance.org, click on the “Community” tab, and find landing pages of current projects. One can also register, and then respond to discussion threads, offer feedback on existing projects, and so forth.
GM: You talk about "open solutions": what do you mean by that, and why do you prefer this emphasis? Which licences do you use for the code you produce?
DS: When we launched, there was some criticism of the OSA not being true to the spirit of open source because we had some members with non-OSI-compliant-licensed products. We accepted that in good faith, as we made the mistake of not being clear about what we meant by an “open solution”. So, we responded with the “open solution definition”, which is a broader definition that is inclusive of companies that may publish their source code but have commercial licences for it. Many companies who say their products are “based on open source” would probably fit this definition.
We continue to get some occasional questions about this, but the truth is, we have yet to meet a customer who cares nearly as much about “the true meaning of open source” as they do about “does it work”, “how do I get support” and “is it interoperable”. Licensing issues and open source philosophical issues show up fifth or lower in all customer surveys we’ve seen, and the input from our own customer outreach corroborates this. Actually, some customers have told us that the “what is open source” debate in the industry has turned them off, out of concern that the vendor community is getting distracted and not focusing enough on customer needs. Of course, this is not to say that the open source definition doesn’t matter to vendors deciding upon a business model, or integrators deciding what open source projects to build upon and redistribute. It is important, but there are other, more fundamental issues that are getting in the way of customers adopting the resulting solutions.
What does matter to customers, however, is whether they can engage with a vendor in a spirit of open collaboration. We have heard this over and over again. We have heard many horror stories of customers being locked in to unresponsive, paternalistic proprietary vendors, and it’s a breath of fresh air to work with vendors who engage in open dialogue, accept customer feedback in good faith and respond promptly, and treat customers like peers. Our experience is this spirit of open-ness isn’t limited to vendors with certain licences. I don’t think it’s possible to write an exact definition of this. It’s more of a “you know it when you see it”, but I believe our open solution definition comes pretty close.
Nonetheless, all code we author is released under OSI-compliant licences. We have made several projects, including a single signon component and a search aggregator, available on Sourceforge under the Open Software Licence. This is a permissive licence, which we intentionally chose to allow free and easy embedding by a wide spectrum of vendors. We did this for practical reasons, to proliferate our interoperability best practices as widely as possible. In a way, this practice makes us like the Eclipse Foundation: Not all of our members are OSI-compliant, but everything we produce is OSI-compliant.
GM: How has the OSA grown and changed since it launched a year ago? What lessons have you learned? How do you see the OSA developing?
DS: Our priorities haven’t changed significantly since our launch, however we have learned a lot and our methods have evolved.
Initially, we had a strong focus on marketing ourselves, getting the word out about our mission and objectives and inviting more organizations to join. We felt that, while we didn’t need every vendor in the open solutions universe to join as a member, we needed critical mass in order for our deliverables to be credible as representative of the industry. We launched in February with 10 members, and this quickly grew to 18 by May, and 22 by August. Since then we have focused more on getting things done with our current membership, and have been happy with the results. (Just to be clear: More members are certainly welcome to join; we have merely slowed down on the member recruiting side of things.)
In parallel, 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, one can easily 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 get our hands dirty and actually build integrations between our disparate applications, before getting too far ahead of ourselves with best practices and white papers. This way, we learn from the experience and can 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, 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 centrepiece 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 Inter-Open 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, both success stories and lessons learned. Universally, we hear that 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 signon and data integration) before others.
Going forward, we expect to deliver more interoperability best practices, code, and integrated offerings like the CCV. Moreover, we are hoping for a continuation of what has very recently become an interesting, and very positive, development: Large integrators and distributors approaching the OSA for suggestions and guidance regarding interoperable solutions, and which vendors they should work with. Unisys was certainly the first, but we are starting to talk to more. This is proof-positive that interoperability matters, if distributors feel they get more value working through a 501c6 non-profit than the vendors directly. Moreover, it provides a nice payback to the membership for their hard work, if these distributors end up recommending and reselling OSA member products because of their superior interoperability. So, expect more news along these lines in 2008.
GM: What about the current and future state of open source in the enterprise: what are the main trends that you observe?
DS: I’ve talked to a lot of commercial open source ISVs and other industry figures in recent months, and I 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. You name a type of product, and I could probably name 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. Most are adopting the usual “Open Source Sales 101” model of many downloads of free community versions, converting them 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. I sense a growing disillusionment with many ISVs with this model as being too expensive and too time-consuming to generate results. I fear there will be a period of consolidation coming up as more and more opportunity and attention accrues to the leaders.
This would be unfortunate – I see a lot of strong products out there, but they are paired with business models and strategies that are aiming them in the wrong direction. Fortunately, I see only a few things separating winners from losers, and these are all actionable by vendors’ executive teams.
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. Lots of companies are making this mistake, inevitably those whose management has limited open source experience. The winners understand this at their core, and is 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 I had a nickel for every time I heard this: "I know I should make my product more interoperable, but I have to focus on my core features instead." Sounds good, but this 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. They 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 go out of their way to plan for interoperability, starting in version 1, with modular and standards-based architectures. Moreover, they go out of their way to form an ecosystem of complementary ISV partners, and then collaboratively build out and test the integrations. Of course, joining the OSA is a good way of doing this.
The definitive collection of interviews with the key players in the open source and free software sector.
This work is licensed under a Creative Commons Attribution-Non Commercial-No Derivative Works 2.0 UK: England & Wales Licence. Please link back to the original post.