To be sure, SQLite is very well supported, runs on tons of platforms and is going to be around for a long time. But still, it is less archival quality, and more inherently complex (even though that complexity is very well encapsulated).
> Finally, let us reiterate that this essay is a thought experiment. The OpenDocument format is well-established and already well-designed. Nobody really believes that OpenDocument should be changed to use SQLite as its container instead of ZIP. Nor is this article a criticism of OpenDocument for not choosing SQLite as its container since OpenDocument predates SQLite. Rather, the point of this article is to use OpenDocument as a concrete example of how SQLite can be used to build better application file formats for future projects.
This is purely a marketing exercise. They're hanging the thought experiment tag on to try and avoid undue criticism.
It didn't work too well when I tried it a few years back, but it proves that it is possible to reimplemented support for the file format itself.
Doing it as well as the original SQLITE library, well, that's different.
Why is it not comparable, if not significantly better, to have a mostly uniform public domain code base that has been deployed to billions of devices?
When a popular format can't be unilaterally controlled by one actor, both the users and the market as a whole tend to be better off.
More complex yes, but why is it less suitable for archival? It's very well documented, and the code to read it is fully open source and will run on a practically all platforms in existence.
Yes, there's also a binary command line interface to interface with a db file, but that's not what SQLite mainly is.
It's also worth noting that you also have the option of purchasing a license for $6000. I'd imagine it's mostly companies that are likely to have concerns over licensing issues, and for most companies that price should be completely affordable. Especially when you consider the project's superb quality level and extensive test suite.