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 SQLit

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.