Interview with John Fryer, President of OpenSAF
By Lance A. Leventhal, Technical Editor

1. What is the purpose of OpenSAF?

OpenSAF (Open Service Availability Framework) is an open source project. It is backed by the OpenSAF Foundation, which provides financial, legal, and marketing support. The aim is to develop high availability middleware applicable to many industry segments which anyone can download and use. A strong ecosystem around OpenSAF allows for multiple distributions and support mechanisms for the code base using both commercial and non-commercial business models. With broad adoption and easy access using the well understood LGPL v2.1 open source license, OpenSAF will serve as the main implementation base for system developers, ISVs, and software application developers.

High availability middleware was once considered a key differentiating feature in systems. Therefore, many companies developed their own implementations, which were ultimately specific to their applications. Today, time to market, rapid application development, and easy integration of applications onto a single platform, all in a cost sensitive environment, are critical business drivers in many industry segments. With OpenSAF, the LGPL v2.1 license enables multiple companies and individuals to contribute to the code base, sharing the cost and accelerating development, without anyone taking direct commercial advantage of their contributions and intellectual property. Additionally, ISVs and software application developers can use OpenSAF as their main high availability software platform with the knowledge that broad adoption will mean easy integration of their code. Businesses can then make a pragmatic choice between creating their own IP and integrating a third-party application. It is very much a win-win scenario for everyone.

2. Who are the top-level members of OpenSAF?

Currently, the OpenSAF Foundation’s members are mainly companies with active technical experts supporting the project side. OpenSAF has top level participation from major telecom equipment manufacturers (Ericsson, Huawei, and Nokia Siemens Networks), enterprise computing companies (HP and Sun Microsystems), embedded computing suppliers (Emerson Network Power Embedded Computing), and software companies (ENEA and Wind River Systems). This diverse group brings a wealth of expertise from many industry segments and application environments. This breadth of knowledge and involvement is the hallmark of successful open source projects, which is why OpenSAF was initially created with significant multi-company backing.

It is important to realize that, since this is an open source project, there may be many anonymous participants. You do not have to join the OpenSAF Foundation to become involved with the OpenSAF project. There have been many hundreds of downloads of the code and mails from a diverse group of people. We hope that eventually some of them will become deeply involved with the project and then join the Foundation, but driving Foundation membership, although important, is secondary to growing OpenSAF project participation.

3. Where did OpenSAF’s technology originate?

High availability middleware is complex, so it is unreasonable to expect that it would be created from a blank piece of paper in an open source environment. The original contribution to OpenSAF was made by Emerson Network Power Embedded Computing, but there have been significant enhancements to the code base. The initial contribution was made under the LGPL v2.1 license and is even copyrighted under OpenSAF since all the founding companies agreed that it was important to demonstrate that this is an industry initiative, not something driven by an individual company. The good news is that the original code base was already stable and had been deployed in carrier networks. However, it is important to point out that many defects have been corrected, and new functionality has been added as the code base that has been deployed on a variety of hardware platforms with different architectures and availability models from the original AdvancedTCA platform. This demonstrates the power of open source where collective testing and development accelerates the functionality and stability of an implementation much faster than is possible in the proprietary case.

4. How does OpenSAF differ from SA Forum? Why do we need two organizations that seem to largely involve the same technologies, companies, and people?

This is a common question, but the two organizations are actually quite different. The Service Availability (SA) Forum focuses on the development of open specifications – API’s and frameworks for service availability. It has taken several years to create specifications that can now be implemented and deployed, and you see the results in implementations such as OpenSAF. The SA Forum’s bylaws essentially prevent direct association with implementations. Also the members include several commercial suppliers, which would prevent the adoption or creation of something like OpenSAF. So, OpenSAF is an independent, although closely related, entity. It is an open source implementation based on the SA Forum specifications – the Application Interface Specification (AIS) primarily, but it also interfaces to the Hardware Platform Interface (HPI) specification. However, it is important to note that OpenSAF is not bound to blindly follow SA Forum specifications. OpenSAF will adopt specifications and contributions from any entity, provided they further the adoption of high availability middleware.

Both OpenSAF and the SA Forum recognize that the adoption of open specification based high availability solutions will be accelerated if the differences between implementations, at least from the application development perspective, are minimized. Essentially, everyone wins if it is easier to port between platforms and middleware implementations. A key objective of OpenSAF is to create a broadly adopted implementation that is recognized as a significant force within the middleware space.

5. What are OpenSAF’s major accomplishments so far?

OpenSAF has now been going for just over a year. In that time, we have released enhancements to the code base, including many bug fixes, expanded the base of participants, both on the project side and the Foundation side, and we have seen significant downloads, in the many hundreds, of the code base. In an open source environment, it can be difficult to track who is actually doing what with the code base. However, the mailing lists and feedback from commercial companies involved with the code and at the initial OpenSAF Developer Days conference in Munich in October reveal significant global interest across a broad range of industries. For example, Developer Days, a first-time event, attracted 54 participants from over 20 organizations.

6. What are OpenSAF’s main goals at this time?

In 2009, we have several objectives. First and foremost, we want to continue to grow the OpenSAF community and deliver new releases of the code base. The interest is there, and the challenge is in educating would be developers to feel confident in actively submitting contributions. That was a significant effort in 2008 and created a vibrant core group, and we want to continue it in 2009. The other main objective is to raise the awareness of the project through increased marketing. We plan to hold the next Developer Days event in Asia in May. This will be after release 3 of the code base and will align nicely with planning for release 4. The interest and increasing number of developers in Asia led us to make this choice. We will also hold educational seminars for product managers, engineering management, and interested developers. Some of these may be in association with the SA Forum, at related industry events, and alongside OpenSAF meetings. Success for the project will naturally lead to increased interest on the Foundation side as we start to leverage the “OpenSAF” brand in the marketplace.

7. How large is the OpenSAF development community? Which industries have significant representation?

OpenSAF started with a focus on telecommunications, as the current membership indicates. However, because of its open-source status, it has rapidly drawn interest from other industry segments. These include the defense industry, government agencies, and some higher end enterprise applications that increasingly require high availability. The core group of developers numbers around 40, but that is not the whole picture. In many cases, multiple developers and test engineers sit behind the main project participants and feed them contributions and bug fixes. Companies with commercial distributions and support models around the code base also have teams working with their OpenSAF customers, so the true picture can be quite complex. None of this accounts for organizations that have downloaded the code and that currently use it simply for their own purposes. Hopefully, we will see increased participation from them over time.

8. What is the relationship between OpenSAF and other open-source efforts such as OpenHPI and OpenAIS?

This is another common question. OpenSAF is completely independent of OpenHPI, OpenAIS, or other open source high availability projects. OpenAIS was originally created to do exactly what OpenSAF has done. The consensus seems to be that it was a good initial effort, but that OpenSAF is better suited to distributed environments requiring high availability, such as AdvancedTCA and bladed architectures. However, parts of OpenAIS are widely available in Linux distributions, and we expect OpenSAF will have a similar status in the future.

OpenHPI is also separate, although OpenSAF has an HPI interface that integrates with OpenHPI. It’s quite normal and logical for one open source project to interface with another, and in other areas OpenSAF uses additional open source code. The developer website details all of this.

9. What progress has occurred toward commercial adoption?

OpenSAF is already commercially deployed. Many companies are actively engaged in developments using the code base, and we hope that in 2009 we will be able to talk publicly about deployments. It is obviously easy to guess from the membership of OpenSAF as to who is developing solutions involving hardware and who will have commercial offerings around the code base.

10. When and why should developers select OpenSAF rather than a commercial middleware implementation?

Open source has proven itself to be a powerful model for software development in many areas. Ultimately, it’s hard to see why anyone would use anything other than an open source implementation that has broad backing and a robust ecosystem. It enables companies to leverage the work of others and contribute in specific areas where they have expertise or feel enhancement is necessary. This works particularly well in areas where functionality is essential, but is no longer a differentiating factor, such as with high availability.

Open source is freely available to try out and even take to deployment. It has an accessible development community around the code base, and commercial distributions and support models are available in the marketplace. The choice of whether to adopt the code is really a business decision based on available resources, the cost to maintain the code in a specific environment, and time to market pressures. Ultimately, it comes down to a cost benefit analysis of “do-it-yourself” or working with a commercial distribution and using the freed up resources on differentiating application development. Of course, it’s important that multiple commercial sources are available so that a competitive market exists.

Companies have already deployed and adopted OpenSAF. As with any vibrant project, there are always enhancements and new ideas from innovative developers. Whether to adopt now or wait for a future release is again a business/technology decision, but it is clear that the current code base is stable and has deployable functionality.

11. How is licensing handled when OpenSAF is used in commercial applications?

OpenSAF is licensed under LGPL v2.1. This makes the code base freely available to anyone through the OpenSAF website. Anyone changing that base is also bound by the terms of the LGPL license and must offer the modifications at no charge. However, they are not obliged to offer any modifications back to the OpenSAF project, although the hope is that most will do so. Any code that links to OpenSAF, or tools and capabilities that enhance its use, are not subject to the LGPL and so may be offered for sale. LGPL was selected as the license primarily to make it clear that applications using or linking to OpenSAF are not covered.

As with any complex code base such as OpenSAF, the opportunity exists to offer commercial distributions, which may contain additional features and capabilities and generally offer a robust support and test model. The various Linux distributions are a good example of the proliferation of open-source business models.

12. How does open-source development fit in an area that has a small user community, little general interest, a customer base consisting mainly of a few very large commercial equipment manufacturers, complex applications, and a tremendous need for support?

If we just take the statements in the question at face value and add the premise that high availability is necessary, but no longer differentiating in these markets, then I argue that an open source solution is ideal for all the reasons stated previously. In actual fact, high availability is an increasing requirement in many market segments and the telecom market is still large and growing, even during the current economic downturn. As I said above, the defense, aerospace, and government markets have always had requirements for high availability and with their increasing transition to COTS, a project such as OpenSAF is very interesting to them. Reports of the impact of server and application failures on real-time transactions and online business applications make it clear that there is a need for high availability in these areas as well. What is ultimately important is that, although OpenSAF may implement complex concepts, it must evolve to be easy to use and the mechanisms for application development must be simple to understand.

13. What are the issues in making open-source development a part of projects that are highly competitive and often involve closely guarded or specially restricted information?

This question really comes back to the choice of license. LGPL v2.1 is a very permissive and well understood license. Most companies already have a policy on how to use open source under it. As I said before, OpenSAF selected it primarily because it was unambiguous in how other commercial and proprietary code could be used with OpenSAF. Even if you change the OpenSAF code base, you are not obligated to return the changes to OpenSAF, but they must be offered under the same terms as LGPL v2.1 if they are distributed. So, it is quite possible to use the code base, make changes that are deemed essential and proprietary, and keep them largely private. The downside is that such changes must be maintained and brought forward in subsequent releases. Again, this is a business decision based on costs and the value of the technology. Many companies involved with OpenSAF and other entities that are using the code base operate in highly competitive and sensitive markets, so this has not turned out to be a barrier in practice.

Those of us involved with OpenSAF believe it is the right model to drive high availability forward. Distributors with commercial interests believe that the market will grow to encompass many more segments over time. With the first year of operation under our belts, I think we can say that OpenSAF has made an excellent start toward achieving its objectives.

For more information about the OpenSAF Foundation and the OpenSAF project, go to www.opensaf.org

John Fryer is President of the OpenSAF Foundation and Director of Technical Marketing at Emerson Network Power. You can reach him at john.fryer@emerson.com.