What's So Open About OpenWare? Part Two

19 May 2017
RES3000 Rugged Ethernet Switch

In the second part of this 2-part blog, John looks at how OpenWare was developed using open source software as its base—and how Abaco has added the functionality specifically needed for complex, secure networks.

The beauty of how OpenWare has come together is how we have structured a switch management suite blending open source code where sensible with proprietary code where necessary. For example, some open source code is too focused on end systems to be easily used for switch/router hardware environments. That is one reason which might cause us to develop our own code instead of using an off-the-shelf, open source solution.

Another reason that we might choose to develop something in-house is where we believe that our market needs are different to the general market needs. Perhaps the story of STP (Spanning Tree Protocol) is a good one here. STP is a way to avoid the problems of “network loops” (which can lead to broadcast storms—a very bad thing). It is of particular interest in systems requiring physical redundancy—very important in military networks.  

Unexpected advantages

When we first developed STP, there wasn’t a suitable open source package available—so we developed it in-house. However, having our own code has given us some unexpected advantages. We progressed our STP implementation into the newer standards for RSTP and MSTP (for the “Rapid” and “Multiple” standards). We have also used the experience of designing and developing our STP package in several cases to produce some unique solutions to the problem of failover in networks—especially military networks. Some of these are designed with particular customer requirements in mind, and indeed, some are governed by specific export control rules. This is something we couldn’t have easily achieved had we not developed our original STP implementation for ourselves.

For some customers, the fact that we use open source, manage it well, and are happy to talk to them about any aspect of the development, is a very positive point. It means they can trust us to have the knowledge and ability to get to the bottom of any problem in the switch (hardware or software) without bringing in dozens of other organizations. It also allows us to offer source code access to customer engineers, involving a lot less complexity with NDAs, etc. For a lot of our users, the fact the switch uses a Linux environment is a major plus point—it allows them to understand it very easily.

Focus on security

In our internal development tools we also make use of much open source—combined with proprietary tools where appropriate. One good example here is in the focus we have had for the last few years on security, software quality and awareness of software vulnerability. The open source community does a great job of being actively engaged in minimizing vulnerabilities and the Common Vulnerabilities and Exposures (CVE) mechanism allows us to keep our latest releases up to date with appropriate CVE-related fixes. Open source also provides us with tools to manage things like licence compliance, and we are adopting the FOSSology tool.  However, we are not open source “purists” in that we also make use of proprietary tools for these security and quality topics, where we consider they add particular value—including having used a range of extensive proprietary test tools at both source and object level. Some of the proprietary tools we have used are the Wurldtech Achilles platform and both Checkmarx and Klocwork static analysis tools.

Our developers are keen supporters of the open source movement, and we also know how to “play nice” with the community. We respect licence terms, and use the code as responsibly as possible. In a small way, we have also contributed code and fixes back to the community and are active promoters of the concept of open source at all opportunities. We tend to encourage our customers to adopt open source tools for testing and deployment wherever appropriate.

In conclusion, use of open source has been a strong factor in the success of OpenWare (acknowledged in the name) and it has been an illustrative story of allowing good engineers to research, understand and apply software engineering in the most appropriate manner to produce an effective solution for our customers.

John Thomson

John Thomson has been working on software for over thirty years, having done a degree in Computing Science in the early 80s at Glasgow University. His focus has always been networking, in particular Local Area Networks, including years working on international standards for protocols - back in the early days of the Open Systems Interconnection (OSI). Having worked for a number of multinational companies (both large and small) he has been with Abaco (or its predecessors) since 2000, and leads the team of software people working on OpenWare – our Ethernet switch management suite. The OpenWare team is based in Edinburgh and California.

 

He and his wife took a career break for five years in the early 1990s, and were heavily involved in relief and development work (with Unicef and others) in Ulaanbaatar, Mongolia. He still claims to remember enough of the Mongolian language to ask for some very interesting foodstuffs!