---

Whenever we talk about open standards, we often speak as though the word “open” settles everything. It doesn’t.

A standard isn’t made meaningful just because the specification is public, well-documented, and licensed in a way that anyone can implement it. Sure, by definition, that makes it “open”, but formal openness and practical openness are not always equivalent. Open standards are meant to be truly meaningful because they give people real freedoms, but those freedoms are only valid if developers also implement support for these standards without certain shortcuts and compromises.

I’ve been thinking about the substance of this for a while now, and it really hit home for me while comparing LibreOffice and ONLYOFFICE for one of my recent articles. Both are built around open standards. Both support many of the same formats in principle, such as ODF (Open Document Format), OOXML (Office Open XML), and PDF (Portable Document Format). Sounds like total wins all around, right?

Eh.... not what I experienced in practice, unfortunately.

The moment you step beyond “Can it open this file?” and start asking “What survives after I save it again?”, the conversation changes, and that’s a bit more than a bit of a problem. If open standards are to be truly meaningful, then interoperability must survive real use.

---

Tech Callout: We gotta round out the round trip

I’m doing something a little different this time: making a call from inside the house to the wider open-source community. It’s not enough to claim support for open standards if that support does not equate to good stewardship. If an app can open and save a file format, it should simultaneously seek to preserve it properly, at least wherever this is possible. Obviously, this can’t always be achieved, or every creative app would work like this (we’d hope).

However, I think it’s certainly fair to say that this can be done better overall if we simply follow some rules of thumb. For instance, if an app doesn’t support a particular feature of an open standard, fair enough. No serious person expects every piece of software to implement every corner of every spec. But I think it’s reasonable to expect that if that app can open a file, especially “natively”, allow changes, and then strip data it doesn’t understand or support, that’s not good interoperability. It’s introducing damage.

Again, I’ll use the example of LibreOffice and ONLYOFFICE, since I’ve had to work extensively with both simultaneously. Both tools support ODF and OOXML — both text-based formats. If you save these formats in either suite with features they don’t fully support, unsupported elements can be altered or stripped from the resulting file.

Long story short, you quietly lose bits of your work every single time.

Unfortunately, this is also why open standards often end up being avoided by users who come to them expecting better. The issue isn’t always as simple as “XYZ format bad”. Often, the issue is a lack of accurate, consistent implementations across the ecosystem. Different vendors, communities, or individual developers may all implement the same spec, but do so with such disparity that it ultimately doesn’t matter that the format is open.

Take SVG, for example. It’s unquestionably an open standard, but anyone who’s moved SVG files between different apps knows how quickly things can start to get shaky. From broken text to missing gradients or filters, effects, stripped metadata, and other factors, it can seem pointless to even attempt interoperability. The result is a user experience that can still end up feeling fragile when applications don’t preserve what they can’t interpret.

It really shouldn’t be that hard

And it doesn’t have to be. This isn’t me saying that the millions of developers around the world who work on the software that consumes open standards don’t know what they’re doing. This is just me asking for a simple set of ground rules that work quite well when they’re put in place:

• Don’t flatten what you don’t understand.
• If you’re going to allow saving to a format, don’t strip what your app can’t edit.
• Don’t claim compatibility you don’t deliver.

In other words, keep in mind that it’s not just a compatibility issue but a trust issue. That being said, we do have a good example of how this can work already. It may not be perfect, but that’s kind of the point: it doesn’t have to be.

The web already shows us what a better version of this looks like

HTML, CSS, and JavaScript aren’t a single standard; they’re a family of related standards and living specifications that form a shared public platform. Sure, browsers still have quirks and limitations, but the expectation is simple: websites and web apps should work broadly across browsers because interoperability is treated as part of the standard.

We don’t hand-wave massive variances as normal or harmless. We treat them as something to reduce as much as possible. Why? Because at least on the web, we believe that open standards exist so that the work we pour into it can preserve its meaning. In other words, the culture we build around our standards matters as much as the standards themselves. Interoperability, shared behaviour, and shared results should be expected. Openness is only meaningful when the ecosystem embraces its purpose with the same passion as the fact that open specification formats exist.

That is the bar open standards should be held to.

Not perfection, nor identical software: just honest implementations that carefully preserve and respect the user’s work, so moving between tools doesn’t feel like risking their investment. Otherwise, open standards have no meaning.

---

Practical Tip: “Write that down, will ya?”

This edition’s tip is a little different, a bit of a “note to self” that you might also find helpful. Do you ever find that you had an idea that you just can’t remember now, but it was really good... when it was in your head? And then you remember it, but you know it’s really not the same?

It happens to the best of us. Just like saving a file in a format that your brain doesn’t fully support anymore, little bits and pieces can get lost when you try to recall them later.

That’s why I’ve started to practice keeping small notes of my ideas whenever they crop up, so long as I have the opportunity. Whether on my phone or computer (I’m highly digitized these days), or, like in the past, in a notebook somewhere. Sometimes this is how you get to keep your best ideas.

---

Here’s what I’ve published recently:

It’s FOSS

• LibreOffice vs ONLYOFFICE - Which One Is Right For You?
  A hands-on comparison of two major open-source office suites, and a reminder that standards support is not always as clean as it sounds on paper.

---

Working with us

At RolandiXor Media Inc., we blend design and open-source thinking for our clients.

→ rolandixor.pro/services

---

Elsewhere

• Mastodon: mastodon.social/@rolandixor
• Threads: @rolandixor
• X: @rolandixor

---

Support this work

If this writing has been useful and you’d like to help sustain it:

→ https://ko-fi.com/rolandixor

---