Open community source: software licensing that makes sense - Embedded.com

Open community source: software licensing that makes sense

Transportation. Energy. Defense. Industrial. Medical. These are big distributed systems with big architecture challenges. They push scale and complexity as never before. And they all face the same problem: software structure and costs are out of control.

The technical response is becoming clear: standardize on common infrastructures. Unfortunately, current pricing and licensing models make this expensive. Infrastructure pricing must evolve to match infrastructure technology.

At our company, we think that open community source is the right approach. Using it we offer implementation of the OMG Data Distribution Service (DDS) standard free to software teams. It combines open community source licensing for DDS, royalty-free distribution, very low-cost commercial licenses, flexible support, and affordable advanced products. Here are some of the reasons why.

Common Infrastructure
The goal of common infrastructure is not a new one in the industry. Companies have long been interested in standardizing architectures on an infrastructure so that it can be deployed across projects and programs throughout an organization. Common infrastructure is also desirable because familiarity of technology can be leveraged across the people of an organization in order to re-use technology from project to project and program to program.

Companies believe that if they create a common infrastructure successfully, they can bring their systems to market faster, which translates into cost savings. Although common infrastructure has been a goal of the industry for a long time, it has been difficult to achieve for a number of reasons.

Interoperability
Interoperability is very closely related to the concept of a common infrastructure. Interoperability is a more recent industry trend and at its core, it is about doing more with what you have. It’s the idea that by allowing systems to share information and services with each other, the whole can be greater than the sum of its parts.

When an interoperable architecture is pushed into a company’s supply chain, it can improve competition among their suppliers, which in turn may contribute to further cost reductions. When interoperability is adopted as a strategy, it can result in a significant competitive advantage.

Interoperability is a commonly misunderstood concept and we have observed many unsuccessful attempts by companies trying to achieve interoperability. The fundamental reason for this is that some organizations have made the assumption that if they use a certain technology, or adopt certain standards, the outcome will be interoperability – but it’s far more complicated than that, as some of the following use case examples indicate.

Use Case #1: United States UAS UCS Architecture
The Unmanned Aircraft System (UAS) Control Segment (UCS) Architecture is a framework representing the software-intensive capabilities of current and emerging UAS programs across the US services, including the Army, Navy, and Air Force.

UCS is ambitious and quite large, being that there are over 100 organizations in the various working groups with 300 actively participating people across these organizations. These numbers help to provide a picture of the organizational complexity of interoperability. Interoperability is not just a technical challenge, but an organizational challenge as well.

Use Case #2: Future Interoperability Camp Protection System
Another successful use of interoperability is the Future Interoperability Camp Protection System (FICAPS), a research program sponsored by the European Defense Agency. This program was designed to demonstrate interoperability between the various subsystems in a camp protection system.

The project was completed, and resulted in a successful demonstration of two independently developed camp protection systems. Rheinmetall, a German company, developed one of the systems, while a French systems integrator developed the other.

Using the power of interoperability, the systems were able to monitor and control detectors and sensors from the other subsystems, even though each system was developed independently. This is an example of the power of interoperability; allowing organizations to exchange services between two independently developed systems.

Use Case #3: United Kingdom’s GVA MOD standard
Yet another example of interoperability at work is Generic Vehicle Architecture (GVA). GVA has been adopted as a UK Ministry of Defense (MOD) standard called DEF STAN 23-09, and it defines the electronic architecture for all future MOD ground vehicle procurements. This is one of the few examples in which an interoperable architecture has been formally incorporated into an MOD standard.

Use Case #4: DocBox
The examples addressed so far are all military-related, but we are seeing just as much effort being put toward interoperable systems in commercial industries. The difference is that, in the case of the government and the defense industry, interoperability objectives for key programs are being publicly promoted because it enhances the competitive nature of the supply chain, decreases costs and increases operational utility.

What’s being observed in the commercial world is an interest in gaining a competitive advantage, which is why there isn’t as much publicity surrounding the technology.

One commercial example of interoperability is DocBox. DocBox is developing an innovative clinical process management solution for hospitals that promises to help clinicians eliminate medical mistakes, improve clinical work flow and processes and free up much of the time spent on administrative duties so that they, and particularly nurses, can focus on providing care.

A commonality in these types of systems is the interest in using the OMG DDS as the basis for an interoperable architecture. DDS is a data-centric middleware, and therefore has emerged as the standard upon which these mission-critical systems are based.

Barriers to Interoperability and Common Infrastructure
If an individual or a company believes interoperability and common infrastructure are important than we must also address what’s keeping said companies from getting there.

The main business obstacle to interoperability is the way infrastructure software is licensed and priced, in that it prevents the collaboration. that would allow teams to work together within organizations, leverage each other’s work and benefit from the sharing of ideas. Commonality of infrastructure and interoperability are not possible without the ability to collaborate.

The root of the problem is License Scope. All software licenses have scope. Scope determines who can use the software and for what purpose. Across the industry of infrastructural software (middleware, operating systems, networking protocols) most licenses are limited in scope to a single project.

This type of scoping impedes the type of collaboration necessary for interoperability and common infrastructure. In most licenses, sharing is not allowed between projects.

Another common issue is that many vendors will structure their pricing models around a volume-based schedule in which the first few purchases cost a lot and the customers pay progressively less per purchase. Some may say this is why they use open source, but that’s not a perfect solution either.

The Ideal Software Model
The first step in creating an ideal software model is to broaden the scope to encompass multiple projects. An ideal model would get rid of artificial distinctions between projects so that the scope doesn’t create limitation.

In the approach we have taken, we don’t limit the software model scope to a single company. If collaboration makes sense between two companies, or even multiple companies, why limit the scope to hinder this? If the goal is common infrastructure and interoperability, and that requires collaboration, we have opted for enabling it and not putting up any barriers.

Simplifying licensing pricing . Many software-licensing fees are very complicated and difficult to grasp. The ultimate goal should be to make it simple to understand a vendor’s price list, because the customer shouldn’t need a PhD to understand pricing. Secondly, pricing should be predictable so that companies have the ability to budget.

Making software pricing fair. One problem with many models on the market today is that if a developer has a large project, the licensing fees are amortized over the entire budget. In these situations, small projects get penalized and software may become unaffordable. Small teams create many innovative projects, and fair pricing keeps smaller teams of developers from being excluded.

Scale with Perceived Value. This is the last component of an ideal software model. It is important to define the parameter that makes a customer go from one licensing fee to another. It becomes a problem when there’s a misalignment between the perception of the value received and the license fees. Most people perceive value to be associated with the size of the development team, in contrast to the number of units that are deployed. The bigger the team, the more people are willing to pay for license fees.

Conclusion
Is the industry at an inflection point for mission-critical real-time systems? We believe it is. There is a combination of forces acting on the industry right now.

First, there is a tremendous amount of economic pressure and no sign of things changing any time soon. There is also no decrease for demand in operational utility. No matter what happens in terms of the economy, end-users are always going to desire more capability. The future is interoperability.

Curt Schacker is Executive Vice President of Sales and Services and Chief Commercial Officer at Real-Time Innovationss. He has more than 20 years of proven software engineering, worldwide sales, marketing and business development experience. Most recently, he managed all aspects of business operations for Toroki Communications. Prior to running his own company, Curt served as a field applications engineer at real-time operating system pioneers Ready Systems and Wind River Systems. At Wind River, he rose to the position of VP of Worldwide Marketing and Corporate Development. Schacker began his career at Lockheed Martin developing flight software for the NASA Hubble Space Telescope before moving into the embedded industry. Curt graduated with honors from Wright State University in Dayton, Ohio with a BS in Computer Science.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.