Right, but it makes the fork strictly worse from a reliability perspective than SQLite given it will be less tested.

If there wasn't a competitive advantage given it has no sales, wouldn't they have open sourced it by now?

> wouldn't they have open sourced it by now?

If there's minimal value in it, why put in the work to open source an extremely complex test environment?

Just for completeness sake, they do offer a SQLite Consortium Membership for $120k, which I guess includes all their test suites as a selling point: https://www.sqlite.org/prosupport.html

(Embedded) database has stricter requirements than a text editor or a compiler.

Obviously not, if nobody was willing to buy the test suite for their internal forks.

It follows fine, but you want to debate instead of think.

If the 100% MC/DC coverage was critical to forks, the companies that fork (there's lots of them!) would have bought it.

Nobody bought it, so it's not that important to maintaining a fork compared to the regular test suite even for such environments. A test suite which, to go back to my first comment, is still leagues ahead of the dozen other pieces of lynchpin software most companies have no problem depending on.

Meanwhile, for the 99.9% of us out here not building aircraft and merely shipping a billion browsers or phones...

> If the 100% MC/DC coverage was critical to forks, the companies that fork (there's lots of them!) would have bought it.

Again, that's a non-sequitur (or perhaps strawman, you can choose), because I wasn't addressing the proprietary test set, merely the comparison between a text editor and a database, which is completely absurd since the tolerance for failures is drastically different.

> I wasn't addressing the proprietary test set

Then perhaps you're in the wrong thread to be saying anything at all.