You have to offer export consistent with your import tools or you demonstrate lock in by design.

This gets around version drift with binary export formats.

Static export, as PDF or other non-native markup format is not what is required. This is hard copy, not backup.

Different person but my prios for export:

1. Versioned export/backup which will be guaranteed to work with current Colanode version

2. ..., well-documented

3. ..., with migrations so it's always future-compatible

4. ..., human-readable

I think integrations with any specific other tools should be ezpz if the fundaments are solid!

For import/insert, I guess some cli API with similar properties would be a nice fit.

(Coincidentally I think the above is also what would facilitate LLMs to do a decent job for anyone trying that)

The first export type implemented should be as minimal and human readable as possible (text files for most content, maybe w/ minimal markup). If that's not possible for all data, then standard formats like html or pdf.

After that, go after your biggest competitor. If people know they have a path back to a familiar shore they're less scared to swim in new waters.