Before we dive in, I’ll share a story. This spring, I had the opportunity to spend time with my local police department through a Citizens Police Academy program. One topic we covered extensively was police dogs. My city uses an unusually large number of dogs for a wide range of tasks: drug detection, suspect apprehension, locating missing persons, and more. These dogs serve as incredibly effective tools in policing. However, I learned that they don’t succeed unless the department invests in training and fosters a strong bond between each handler and their dog. When a committed handler works with support from a dedicated organization, dogs become powerful force multipliers.

Open Standards work the same way. The handler represents the government’s commitment to training, integration, and long-term support. Both the standard and the user must contribute effort for Open Standards to create real value. To use them effectively, end users must engage with standards and vendors to solve problems collaboratively.

Open Standards, open standards, and Open APIs

Let’s define a few terms.

Open Standards (capitalized) have a legal definition in the US, especially in government procurement. While I won’t quote the exact wording, Open Standards follow a public process; anyone can join, contribute, and help shape them. Standards bodies like OGC, IEEE, and SISO develop these types of standards through transparent, inclusive procedures.

open standards (lowercase) function more informally. Industry often adopts these widely used formats or protocols, even if they didn’t originate through fully open processes. In the Modeling and Simulation (M&S) community, this includes formats like OpenFlight or FBX, proprietary or semi-open tools that became standards due to broad industry use.

Open APIs serve a different but critical role. If Open Standards are oranges and open standards are tangerines, then Open APIs are broccoli: nutritious and essential, but only loosely related. Open APIs allow customers to adapt COTS products to their own needs. They form part of broader Open Architectures. While I won’t focus on them here, they remain essential for building flexible systems.

Capital or Lowercase—There’s a Place for Both

Open Standards deliver the most long-term value because they invite transparency and community input. They often take years to develop; that timeline can frustrate people, but the resulting durability makes these standards ideal for systems that need to last decades.

Informal open standards (lowercase) like FBX evolve more quickly. Commercial forces often drive this process rather than public ones. But these standards once released fully to the public still offer great value; for example, nearly every 3D content tool supports FBX, even ones Autodesk didn’t make.

Sometimes formal and informal standards align. For example:

SISO maintains the RPR FOM as an Open Standard based on IEEE-1278 (DIS).

NATO’s MSG-223 team manages the NETN FOM, which extends RPR FOM. Although NETN doesn’t qualify as an Open Standard due to restricted membership, the team develops it quickly and shares the output so others can extend it through formal channels.

Governments should build a standards pipeline that starts fast and flexible, then matures through formal processes. They should open practical solutions early and refine them over time through open bodies.

The Standards Pipeline

Treat Open Standards as the foundation of a healthy standards pipeline. When you build systems:

• Choose Open Standards wherever possible.
• Select open standards (lowercase) only when no formal Open Standard (uppercase) exists.
• If no standard exists, design your solution so you can standardize it later.
• Open up your solution for the community so that an ecosystem can develop around it and the industry can learn

If Government teams want to embrace open standard they must learn to separate project-specific architecture from reusable architecture. As the architecture evolves, they should evaluate it for standardization and push it down the pipeline.

The government or its contractors can carry out this work, but they must plan and fund it appropriately. More importantly, every program should understand this pipeline from the start and build around it deliberately. Like using a police dog, this takes work on both sides, customers and vendors need to work on a shared vision of driving this pipeline. The Government must push industry and contract design towards this pipeline; the government must reward contract choices that use open standards and that embrace the pipeline. Industry representatives need to also embrace the pipeline when they can for the betterment of the ecosystem. Choices are made every day, and it takes conscious thought in design to make the right choices.

Standards Are Not Architecture (But They’re Part of It)

I’ve heard the same complaint many times: "We used an Open Standard, but our system still can’t connect to X."

This happens because one standard often isn’t enough for interoperability. Take HLA, for example. It defines an API, but systems also need compatible object models. Even with matching models, differences in assumptions, behavior, or architecture can block connections.

You gain real benefits even if you don’t aim for full interoperability:

• You simplify future integration.
• You allow staff to build overlapping expertise across projects.
• You lower the total cost of ownership.

Always consider standards as part of the larger system architecture. TCP/IP gives you sockets, which help, but not enough on their own. Add HLA; better. Add RPR FOM; even better. Add NETN FOM, and now you can model weather. Adopt OGC’s CDB standard, and you can share terrain. You haven’t reached perfect interoperability, but you’ve made significant progress.

Question Limitations and Motives Before You Reject a Standard

Engineers love to invent new things—protocols, formats, and even languages. But reinvention doesn’t always make sense.

Every new computer language has a reason it was created, because the author tried X and found it didn’t do what he or she wanted. Often times the motivation is purely pride, its fun to design new things. In computer science this is called greenfield design, and greenfield engineering is exactly what it sounds: fun. But one engineers fun or inability to learn about already produced solutions doesn’t make it fun in the long run.

Contractors and engineering teams often push back on using open standards by saying, “There isn’t one that fits our needs.” Occasionally they’re right. But more often, I’ve found they don’t understand what’s available or they want to control the new solution. Both motives create problems: fragmented designs, higher long-term costs, and reduced interoperability.

It Takes Teamwork

Standards—capitalized or not—cut costs most effectively when you implement them as part of a coordinated effort. But you need a true partnership between an informed buyer and an experienced vendor.

You can’t hand a German Shepherd to an untrained officer and expect good results. Likewise, you can’t drop an Open Standard into an unprepared program and expect success. Doing so leads to higher costs and weaker outcomes. But when a well-trained team uses well-supported standards, they can achieve remarkable results.

That’s the key lesson: standards are powerful, but only when applied with care. Like a well-trained police dog, they need the right partner and long-term care to reach their full potential. It’s also important to recognize that open standards don’t solve all interoperability problems just as having many police dogs doesn’t guarantee an effective police force. Interoperability requires architecture and foresight. It demands that governments and service providers work together toward a shared goal; it requires long-term thinking that embraces open standards and open APIs.

See Jim speak about this and more at the upcoming MAK ONE 2025 Release webinar on September 16, 2025. Register for the session that best fits your schedule: 10:30AM or 9:00PM EDT. All registrants will receive a link to watch the recording after the webinar.