Risks to format longevity

Data errors
Obsolescence
Vendor lock-in
Interoperability/complexity issues

Countermeasures?

Data errors: Files are corrupt. These errors may include filenames or filesystem tech-MD.
- Obsolescence: Not supported anymore by accessible tools. This is neither God-given, nor irreversible, unless it’s a black-box format. Format obsolescense/support is a human-made decision. Documentation/schematics are an important game changer.
- Vendor lock-in: For long-term preservation, vendor- and technology-neutrality is a must: They will come and go, and with lock-in situations Eternal Migration is hindered or even impossible. Format normalization helps here.
- Interoperability issues: If a format is read and written differently by different applications, it might “morph”. This morphed version might work fine with the tools used in a certain environment, but might be completely broken if read/written by another tool that misunderstands the “dialect”.
  A format offering more features, can be considered more “complex”. Whereas a format offering less features is considered “simpler”. Simpler (and more popular) formats are usually less susceptible to interoperability issues, than complex (and/or less popular ones)

Data errors: Error resilience?

Bitstream checksums:
Ability to know if the content is intact.
Error concealment: Optional choice of decoder to “mask” decoding issues. (decoder specific)
Make backup copies! 😇

Obsolescence / Vendor Lock-in

Open vs Closed

Theory vs Practice

“Implementation overrules paper specs. Always.”

If the implementation is open: you can use, study, share and improve if necessary.

If it’s closed/proprietary then there’s nothing you can do about it: Black box. Vendor lock-in. With digital, this means that it’s quite likely that this as-is binary may not be able to keep running/functioning when its environment changes.

You’ve probably seen how fast even good and stable programs “age” until they stop working, once their native Windows version is “too long ago…”?

Even with official standards, their implementation is what creates the actual encoding/decoding. Regardless of what’s written in any paper manual (=theory): The code implementation (=practice) is what counts.

Therefore, it makes sense to demand an openly accessible reference implementation, with its source code under a license that allows to make use of it as you see fit.