Open Solutions Alliance
OSA = UK-based corporate alliance of companies/vendors using open source licenses.
URL = http://www.opensolutionsalliance.org/
Description
"The Open Solutions Alliance consists of leading companies dedicated to making enterprise-class open software solutions work together. We help customers put open solutions to work by enabling application integration, certifying quality solutions, and promoting cooperation among open solutions developers. Membership is open to organizations that provide high-quality, business-ready open solutions." (http://www.opensolutionsalliance.org/)
Discussion
OSA betrays free software
A critique by Glyn Moody [1]:
A citation from the Register:
= "Recently named Open Solutions Alliance president Anthony Gold told The Reg that his goal is to take the two-year-old organization to the "next level" by turning it into a destination for practical advice on interoperability between proprietary and closed-source software." [2]
Glyn Moody comments:
"This is a dramatic shift – from interoperability between open source apps, to interoperability between open source and proprietary software. Where the first is about making the free software ecosystem stronger by helping its components to fit together better – and thus offer an even better alternative to the closed source ecosystems - the second is about about making open source simply another part of the proprietary one.
To my mind, that's really a betrayal of the OSA's original purpose. Improving interoperability with proprietary codebases does nothing to promote free software – on the contrary. It means that free software plays by the rules of the closed source world – think of how Microsoft has embraced, extended and extinguished the definition of “open” in order to dilute and pervert the true meaning of open standards (OOXML, anyone?) and open source.
In addition, interoperability with proprietary systems often implies explicitly entering into licensing agreements or implicitly accepting software patents. Both weaken the very basis of free software.
Instead, open source companies should be standing fully behind truly open standards, and pushing for their wider adoption in the enterprise world. Actively supporting proprietary standards simply bolsters them, and makes displacing with fairer alternatives even harder.
The original purpose of the OSA was to strengthen the appeal of a different and better way of doing things in software, not simply to create a convenient umbrella organisation for easier kowtowing to the old way." (http://www.computerworlduk.com/community/blogs/index.cfm?entryid=1765&blogid=14&pn=2)
The OSA on Interoperability
This views may be superseded by the views of the new president, critiqued just above by Glyn Moody.
By Dominic Sartorio, president of the Open Solutions Alliance:
"Why is Interoperability Important for Open Source?
The OSA is often asked the question, "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. Modularity facilitated parallel development by individuals all over the world, and downstream customers could easily “plug and play”, thus helping drive adoption. But there are a lot of great product ideas 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. Commercial open source vendors often make the same mistake. Most 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 it, many prospects will simply not adopt, resulting in less revenue opportunity, and therefore fewer engineering resources to fix the problem in later releases, and 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.
Also, 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, and 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. 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. 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, 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. We sense a growing disillusionment with 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 aiming them 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 my 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.
What Has the OSA Done about 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 (http://www.opensolutionsalliance.org/team/ProjectManagementFiles.do?command=Details&pid=1&fid=5&folderId=-1). 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, 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.
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, such as single signon. Sometimes they will be 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, but 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. Depending on the idea, somebody will respond with how to move forward.
Second, all of our work is publicly available on our website (http://www.opensolutionsalliance.org). 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. " (for the Talent First Network at osbr.ca, January 2008)
More Information
"The Open Solutions Alliance has clarified its stance regarding the approaches to the licensing and open business models taken by its members. It offers a framework for thinking about a definition of "open solutions" and commits its members to a strict policy of transparency in disclosing their approaches to licensing."
The framework is at http://www.opensolutionsalliance.org/Portal.do?command=Default&siteId=2&tabId=9&pageId=45