Our world has big problems to solve, and something desperately needed in that pursuit is the open-source and open-standards communities working together.
Let me give you a stark example, taken from the harsh realities of 2020. Last year, the United States experienced nearly 60,000 wildland fires that burned more than 10 million acres, resulting in more than 9,500 homes destroyed and at least 43 lives lost.
I served as a volunteer firefighter in California for 10 years and witnessed firsthand the critical importance of technology in helping firefighters communicate efficiently and deliver safety-critical information quickly. Typically, multiple agencies show up to fight these fires, bringing with them radios made by different manufacturers that each use proprietary software to set radio frequencies. As a result, reprogramming these radios so that teams could communicate with one another is an unnecessarily slow — and potentially life-threatening — process.
If the radio manufacturers had instead all contributed to an open-source implementation conforming to a standard, the radios could have been quickly aligned to the same frequencies. Radio manufacturers could have provided a valuable, life-saving tool rather than a time-wasting obstacle, and they could have shared the cost of developing such software. In this situation, like so many others, there is no competitive advantage to be gained from proprietary radio-programming software and many priceless benefits to gain by standardizing.
Open source and open standards are obviously different, but the objectives of these communities are the same: interoperability, innovation and choice.
The benefit of coherent standards and corresponding open-source implementations is not unique to safety-critical situations like wildfires. There are many areas of our lives that could significantly benefit from a better integration of standards and open source.
Open source and open standards: What’s the difference?
“Open source” describes software that is publicly accessible and free for anyone to use, modify and share. It also describes a collaborative, community-oriented software development philosophy, with an open exchange of ideas, open participation, rapid prototyping, and open governance and transparency.
By contrast, the term “standard” refers to agreed-upon definitions of functionality. These requirements, specifications and guidelines ensure that products, services and systems perform in an interoperable way with quality, safety and efficiency.
Dozens of organizations exist for the purpose of establishing and maintaining standards. Examples include the International Organization for Standardization (ISO), the European Telecommunications Standards Institute (ETSI), and the World Wide Web Consortium (W3C). OASIS Open belongs in this category as well. A standard is “open” when it is developed via a consensus-building process, guided by organizations that are open, fair and transparent. Most people would agree that the standard-building process is careful and deliberate, ensuring consensus through compromise and resulting in long-lasting specifications and technical boundaries.
Where’s the common ground?
Open source and open standards are obviously different, but the objectives of these communities are the same: interoperability, innovation and choice. The main difference is how they accomplish those goals, and by that I’m referring primarily to culture and pace.
Chris Ferris, an IBM fellow and CTO of Open Technology, recently told me that with standards organizations, it often seems the whole point is to slow things down. Sometimes it’s with good reason, but I’ve seen competition get the best of people, too. Open source seems to be much more collaborative and less contentious or competitive. That doesn’t mean that there aren’t competitive projects out there that are tackling the same domain.
Another culture characteristic that affects pace is that open source is about writing code and standards organizations are about writing prose. Words outlive code with respect to long-term interoperability, so the standards culture is much more deliberate and thoughtful as it develops the prose that defines standards. Although standards are not technically static, the intent with a standard is to arrive at something that will serve without significant change for the long term. Conversely, the open-source community writes code with an iterative mindset, and the code is essentially in a state of continuous evolution. These two cultures sometimes clash when the communities try to move in concert.
If that’s the case, why try to find harmony?
Collaboration between open source and open standards will fuel innovation
The internet is a perfect example of what harmony between the open-source and open-standards communities can achieve. When the internet began as ARPANET, it relied on common shared communications standards that predated TCP/IP. With time, standards and open-source implementations brought us TCP/IP, HTTP, NTP, XML, SAML, JSON and many others, and also enabled the creation of additional key global systems implemented in open standards and code, like disaster warnings (OASIS CAP) and standardized global trade invoicing (OASIS UBL).
The internet has literally transformed our world. That level of technological innovation and transformative power is possible for the future, too, if we re-energize the spirit of collaboration between the open-standards and open-source communities.
Finding harmony and a natural path of integration
With all of the critical open-source projects residing in repositories today, there are many opportunities for collaboration on associated standards to ensure the long-term operability of that software. Part of our mission at OASIS Open is identifying those open-source projects and giving them a collaborative environment and all the scaffolding they need to build a standard without it becoming a difficult process.
Another point Ferris shared with me is the necessity for this path of integration to grow. For instance, this need is particularly prevalent if you want your technology to be used in Asia: If you don’t have an international standard, Asian enterprises don’t even want to hear from you. We’re seeing the European community asserting a strong preference for standards as well. That is certainly a driver for open-source projects that want to play with some of the heavy hitters in the ecosystem.
Another area where you can see a growing need for integration is when an open-source project becomes bigger than itself, meaning it begins to impact a whole lot of other systems, and alignment is needed between them. An example would be a standard for telemetry data, which is now being used for so many different purposes, from observability to security. Another example is the software bill of materials, or SBOM. I know some things are being done in the open-source world to address the challenge of tracking the provenance of software. This is another case where, if we’re going to be successful at all, we need a standard to emerge.
It’s going to take a team effort
Fortunately, the ultimate goals of the open-source and open-standards communities are the same: interoperability, innovation and choice. We also have excellent proof points of how and why we need to work together, from the internet to Topology and Orchestration Specification for Cloud Applications (TOSCA) and more. In addition, major stakeholders are carrying the banner, acknowledging that for certain open-source projects we need to take a strategic, longer-term view that includes standards.
That’s a great start to a team effort. Now it’s time for foundations to step up to the plate and collaborate with each other and with those stakeholders.
