Open Standards + Community Support = Healthy Wireless Networks

You may be thinking “who needs another open source High Availability (HA) project?” Or, in fact, “why do we need any open source HA project?” For those who do not know, OpenSAF is the latest in a line of open source HA projects that is specifically designed to address high availability and clustering. First we’ll look at what OpenSAF is and then some of the previous open source HA projects to make comparisons. We will look at some of the unique characteristics of the OpenSAF project that make it different from earlier HA projects — and more like successful open source examples such as Eclipse or Apache.

OpenSAF is an open source community project developing a high availability base platform HA middleware under the LGPL. The general philosophy of the project is that the work is consistent with Service Availability Forum (SA Forum) specifications. SA Forum is a consortium of leading communications and enterprise computing companies as well as platform suppliers who have jointly implemented APIs for high availability platforms based on open specifications. While the APIs and technology are by no means specific, or restricted to the telecom industry, telecom is the primary consumer today. Other industries such as industrial, military, government and aerospace are also beginning to adopt SA Forum based HA products.

What’s the Need?

Why do we need an open source HA project at this point in time? Consider the growth of open source in the telecommunications industry during the last 8 years. Since 2000, the telecommunications industry has been the largest ‘vertical’ consumer of Linux.

Long before the media hype around Linux in cell phones or other consumer products, the leading telecom vendors were integrating Linux into their next generations of GSM and CDMA network elements. And, in order to keep all those base stations and controllers operational 24×7 so consumers like us don’t drop calls, high availability was a critical component of the software solution.

While still a critical component, HA is no longer considered a “core-value” of most companies’ solutions. Instead they must focus on time-to-market and differentiating value in the application software — such as gateways, soft-switches and base-stations. For the same reasons that they chose Linux as the operating system for their devices — the high rate of technology evolution, freedom of vendor selection and reduced costs — these same vendors are now looking at open source alternatives for high availability as the next step up in the software chain.

There is a clear trend in the industry to move open source software up the stack beyond the operating system. HA middleware is a key building block that is now being addressed by the open source community, just as the operating system with Linux was 10 years ago. The timing is perfect for the OpenSAF project to fill this void.

To address the first question of why another open source HA project, we must first look at the predecessors and why they have not been adopted.

Standards, Support and License

The first key reason is standards. In any major market, solutions are increasingly based on industry standards in order to ensure compatibility, interoperability and vendor selection. Only in the last few years have the SA Forum APIs become mature and widely used enough for vendors to base their solutions on those APIs.

Previous open source HA projects such as Linux HA or Mission Critical Linux were not based on any accepted industry standard. Also, they may have addressed only partial solutions — such as heartbeat in the case of the Linux HA project. While Linux HA is a very solid open source project that does get a lot of usage, it is not based on standards and usually not considered to be a whole or complete HA solution.

There are many components of an HA solution (such as tracing, logging, etc.) that Linux HA does not really address well. Mission Critical Linux, an early project with great technology, had no traction in the community and never really took off.

The second key criteria a vendor looks for is widespread support and adoption. There is another open source HA project based on the SA Forum APIs called “openais.” However, this project was never widely supported by multiple vendors (i.e., there were not a lot of contributions by multiple vendors) and was heavily supported by only two or three contributors. When I last looked at the openais project page, its last version seemed to be released in June of 2007, so it appears to be withering due to lack of support. No telecom vendor will integrate an open source component unless they know that it has strong support in the community.

The third key to a successful open source HA project is the license itself. There is at least one example of a very good HA solution that was put into open source under a dual-licensing model. The Open Clovis project was based on early SA Forum specifications. Although technologically sound and rather complete, the licensing terms were inconsistent with the needs of the community of commercial vendors dooming the project to failure.

The Benefits of Openness

How is OpenSAF different? Let’s look at the key criteria.

First and foremost, OpenSAF is totally based on open specifications. Not only is OpenSAF based on mature SA Forum specifications that are widely adopted in the HA industry, it also strives to stay current with those standards. As SA Forum updates its APIs and addresses new capabilities, the OpenSAF project contributors are immediately providing patches to address these new capabilities. So the OpenSAF project is not only standards driven, but also timely in its support of new APIs.

The second criterion is widespread support by multiple vendors. While the common perception is that the open source “community” is a group of visionary and altruistic individuals, the reality is that nearly all contributors are employed by companies with commercial interests in creating and using open source software. These individuals are frequently assigned by their respective companies to contribute to and/or manage the open source project.

Companies that participate in open source projects understand the great benefits of leveraging open source in their products as we discussed earlier. With equipment suppliers such as Ericsson, Nokia Siemens Networks and Huawei, platform providers like Sun, Emerson and HP as well as a software vendors such as Wind River and ENEA all actively contributing to the OpenSAF project, it is relatively easy to reach the critical mass of contributions. There is also significant support and adoption that companies require to ensure the longevity and success of an open source software project that they will use in their next generation devices.

The third criterion is the license itself. So many projects have made the wrong choice in licensing — either BSD based, or a company specific open source license (e.g. Open Clovis) making it unacceptable to the community. It was critical to the founders of the OpenSAF that the code base is freely available and that anyone can become an active participant, while the boundaries between the OpenSAF code base and other code is clearly established to enable a commercial ecosystem to thrive around it. By choosing the LGPLv2.1 license, they ensured that no direct commercial benefit can be made from contributions, but the license does enable the use of the code in commercial products while enabling vendors to clearly and easily separate their intellectual property from open source.