Interoperability: How standardisation helps you be different

In the FOSS community, we are always thinking about Free/Open Source Software, and especially in FOSS United circles, the discussion is now broadening to include similar ideas in other fields like Open Hardware and Open Data.

What is often overlooked is the glue that holds these things together: Open Standards.

Some of you may be familiar my with talk on the flip phone revival, which I presented at IndiaFOSS 2025. Today, I want to highlight one observation from using a flip phone, which is: standards have helped me use a relatively unique, niche device while still maintaining compatibility with what other people are using.

Good standards allow us to build a strong, resilient ecosystem of products that are not dependent on one company’s success or failure. If something standards-compliant is not working out—be it a privacy-invasive app, a faulty component, or a burnt-out charger—we can easily swap it for something better with minimal disruption. Because hyped-up companies and products come and go, but widely adopted standards tend to stay!

(While I use flip phones as an example, the same message can be applied to any technology we work with. I will try to pause in between and let others chime in with how standards affect their own field of work!)

• Standards help existing technology be repurposed for new uses beyond what the original creators envisioned. Standardisation doesn't mean everything has to be the same; rather, it creates a common minimum contract that allows for endless customisation on both ends

• Anybody can write a spec and call it a standard, but wide adoption helps it become a standard in practice. (This is why you should use funding.json 😉)

• Stewardship by standards bodies helps to keep standards relevant over time while not breaking older implementations. This makes standards more resilient as they are not dependent on the success or failure of a single company or product. (If they are, it's a problem!)

• Learning generic terms and standards rather than software and brand names helps to get a clearer picture of how things work and avoid vendor lock-in. (Everyday examples include: "email/SMTP/IMAP" vs. "Gmail/Outlook", "HTTP REST API" vs "Postman")

• Federated standards (XMPP, ActivityPub, Matrix) allow small projects to leverage the network effect without having to build a wider audience first. (This also works for standards controlled by a single entity like Reddit or NPCI, though to a lesser extent)