See, that's the insanity: why would we need an independent implementation? sqlite has authoritative libraries, that everyone uses, and sqlite3 has been stable for literally over a decade. For all that time, the world could have benefited from "just bloody expose it" as opposed to "but there's no API-equivalent alternative implementations!".

Could it be related to the fact that SQLite, while open source, does NOT accept contributions (closed development)?

https://www.sqlite.org/copyright.html

"SQLite is open-source, meaning that you can make as many copies of it as you want and do whatever you want with those copies, without limitation. But SQLite is not open-contribution."

That's an exceptional bit of edition-based lying you're doing here. Here's the end of the paragraph whose start you quoted:

> the project does not accept patches from people who have not submitted an affidavit dedicating their contribution into the public domain.

So your statement that SQLite "does NOT accept contributions" is plainly wrong. SQLite is not "open contribution" because it requires an affidavit in order to ensure the project remains public domain.

>> > the project does not accept patches from people who have not submitted an affidavit dedicating their contribution into the public domain.

> So your statement that SQLite "does NOT accept contributions" is plainly wrong. SQLite is not "open contribution" because it requires an affidavit in order to ensure the project remains public domain.

You're both right. It does require an affidavit, but the project does not simply accept affidavits from drive-by folks. It's effectively "by invitation." (Citation/disclaimer: i'm a member of the sqlite project team.)

Given that your browser history, localStorage, etc. are all stored in sqlite databases: no, why would that even remotely be a problem? Clearly sqlite works for everyone's needs, just expose it via an API. Nothing about that would even remotely require changing sqlite itself.

I assume due to Hyrum's Law. Any quirks/oddities in sqlite would become the de facto standard.

Sure but the idea is that the standard is "just embed SQLite". Nobody has to pretend it's a generic database interface or anything.

“The standard is a third party project we have no view or control over” is not a standard.

We all know that 99.99% sites that need a client-side database will use $subj or its derivative regardless of these kicks and screams. Because there is no decent 300kb RDBMS which could be ported into a browser. All that was achieved by that decision was to put the whole industry on hold for more than ten years.

And that would be a problem... why? We've been working with those for over a decade, they already are.

But the standard is one of best tested apps on the planet.

The irony is that nobody wanted to make a new production-quality implementation because, well, why bother if SQLite already exists and is that good? It's an issue that's always going to arise when some problem has one solution that is already adopted as a de facto standard by the industry - which is exactly the kind of stuff that ought to be stable and battle-tested enough to build formal standards on.

Seems like entirely self inflicted problem; SQLite is not closed source, it doesn't need independent implementations