Whether or not this succeeds, I think it's a great effort. SQLite not taking any outside contributions is of course their prerogative. But it would also be cool to see what could happen with a more open development model. And their (libsql) plans around io_uring and Rust for future code both sound like a good start.
The way they're going about this fork (described in the repo [0] readme) seems healthy enough for both projects as well.
Maybe the biggest challenge though is recreating SQLite's private/proprietary test suite [1].
SQLite's proprietary test suite is its secret sauce that has kept it closed to contributions and kept forks from happening. It is the thing that made the SQLite Consortium a going business proposition. It is the thing that makes it possible to fund an open source infrastructure project with a small, cohesive team.
The public believes that that test suite exists and has 100% branch coverage, and that it is much larger and more complete than the public test suite. Of course, there's no at the private test suite exists, but we the public believe it does and we have plenty of reason to believe that it does.
Any fork will instantly lose the benefits of that private test suite. This is what keeps the SQLite team able to reject external contributions, and what keeps forks from taking hold.
Any hard fork will have a struggle with this.
I believe a Rust re-write would have much less trouble w.r.t. the private test suite, owing to Rust's memory safety. But any fork that remains C-coded will have trouble getting public acceptance, and will have to have amazing features -or a new public test suite- to get acceptance.
Meanwhile the SQLite team could respond by making SQLite3 a bit more modular and able to be used in distributed database constructions w/o alteration to any of the SQLite3 code. That would take the wind out of the sails of any fork. This possibility means that any forks need to be properly funded to be able to compete, but the SQLite Consortium is almost certainly well-funded, so it will take a serious commitment -maybe even by some of the consortium's members- to see a fork succeed.
The private suite is about (among others) MCDC ie extremely stringent test coverage constraints at the binary level - what does this have to do with rust vs c?
Yeah, the test suite seems pretty key. It also probably contains information about the proprietary extensions and contract work from clients and can likely never be released.
Proprietary test suite is a pretty interesting strategy actually. Very difficult for others to just steal your code and support effort and run if they have to start from zero to build a massive test suite.
I wonder how difficult it would be for some sort of tool to assume a particular original sqlite.c has full coverage and then suggest where additional tests are needed for patches?
> But it would also be cool to see what could happen with a more open development model.
It seems a little disingenuous to act like we don't know what would happen, at least in broad strokes. Just compare and contrast the nature of SQLite with "more open" projects and you can get the gist.
More features, more bugs, abandonment of excellent testing standards, poor handling of what are dismissed by the developers (but not the current, extremely wide base of users) as niche concerns.
It would be quite an uphill battle for this project to succeed in the longterm. But I don't understand what's disingenuous about hoping for innovation by a change in process.
The way they're going about this fork (described in the repo [0] readme) seems healthy enough for both projects as well.
Maybe the biggest challenge though is recreating SQLite's private/proprietary test suite [1].
[0] https://github.com/libsql/libsql
[1] https://www.sqlite.org/th3.html