4 ms·

Of course they are scratching their own itch, so to speak. Thats what companies do. I think the fact that they are doing so much in the open is the indication

Of course they are scratching their own itch, so to speak. Thats what companies do. I think the fact that they are doing so much in the open is the indication of good stewardship itself. I'm not sure what else they would do or release that they didn't need internally. For that matter, I'm not really aware of many significant contributions to FLOSS at all that aren't initially intended for company use, that's kinda how it works. Where I'm surprised here is how much secret sauce Turso is sharing at all.

ncruces 2y ago
I have no problem with them scratching their itch. That's par for the course. I'm salty about them describing the SQLite licensing, development model, and code of ethics as almost toxic, setting up a separate entity with a website and a manifesto promising to do better, and then folding “libSQL into the Turso family” within the year. They forked, played politics, added a few features (with some ill-considered incompatibilities), and properly documented zero of them. And I'm salty because I'm actually interested in some of those features, and they're impossible to use without proper documentation. I've had much better luck interacting with SQLite developers in the SQLite forum.
- avinassh 2y ago
  disclosure: I work at Turso > code of ethics as almost toxic This is simply not true. Can you tell me where it is being said so? > then folding “libSQL into the Turso family” within the year. libSQL was always part of Turso. So, I don't get your point. > They forked, played politics, added a few features (with some ill-considered incompatibilities), and properly documented zero of them. Again this is incorrect. There are some docs here: https://github.com/tursodatabase/libsql/tree/main/docs https://github.com/tursodatabase/libsql/tree/main/docs I am really not sure why are you so angry about libSQL.
  - ncruces 2y ago
    > This is simply not true. Can you tell me where it is being said so? It's right there in “your” manifesto. https://turso.tech/libsql-manifesto https://turso.tech/libsql-manifesto > We take our code of conduct seriously, and unlike SQLite, we do not substitute it with an unclear alternative. We strive to foster a community that values diversity, equity, and inclusion. We encourage others to speak up if they feel uncomfortable. The word toxic clearly stung, but putting “unlike SQLite … we encourage others to speak up if they feel uncomfortable” in a manifesto is fine. Well, I could argue I'm just speaking up. > libSQL was always part of Turso. So, I don't get your point. My point is explained quite clearly in your post detailing the decision. https://turso.tech/blog/were-bringing-libsql-into-the-turso-family-8cc1a653448e https://turso.tech/blog/were-bringing-libsql-into-the-turso-... > We have our own self interest in making those changes (…) But we also wanted to create a welcoming community, that is open to everybody, abides by a modern code of conduct and a clear OSS license, and reimagined what SQLite could be in broader ways than just our narrow needs. A little latter down that line you sum it up: doing the above (living up to your grandiose claims of a more welcoming SQLite) “meant twice the investment” (aka a lot of money) and didn't pan out as a marketing play (showed engagement). So instead of a community that “reimagined what SQLite could be in broader ways than just our narrow needs" we just get the features you had your "own self interest in making." Which is fine, but doesn't really match the manifesto. > Again this is incorrect. There are some docs… Emphasis on some. Do you have any documentation on how to build on the Virtual WAL (internal SQLite API that you simply opened up)? Or is that's still a Rust example of an implementation that simply wraps another and logs without detailing anything beyond function names? Do you have any documentation about the new WAL API that isn't "libsql_wal_insert_begin begins WAL insertion"? I'm sorry, but goal here isn't to make things useful to others. Which is fine really: you're doing more than you're required. But compared to SQLite developers, and their forum, it's not much. PS: you also behaved… untowardly when you integrated SQLite3MultipleCiphers, and did this with not previous a word to the author. https://turso.tech/blog/fully-open-source-encryption-for-sqlite-b3858225 https://turso.tech/blog/fully-open-source-encryption-for-sql... > One project in particular was very suitable for us, SQLite Multiple Ciphers. Since it is licensed under MIT, we have just moved the code into libSQL.
    - _zagj 2y ago

ncruces 2y ago

I have no problem with them scratching their itch. That's par for the course. I'm salty about them describing the SQLite licensing, development model, and code of ethics as almost toxic, setting up a separate entity with a website and a manifesto promising to do better, and then folding “libSQL into the Turso family” within the year. They forked, played politics, added a few features (with some ill-considered incompatibilities), and properly documented zero of them. And I'm salty because I'm actually interested in some of those features, and they're impossible to use without proper documentation. I've had much better luck interacting with SQLite developers in the SQLite forum.

avinassh 2y ago
disclosure: I work at Turso > code of ethics as almost toxic This is simply not true. Can you tell me where it is being said so? > then folding “libSQL into the Turso family” within the year. libSQL was always part of Turso. So, I don't get your point. > They forked, played politics, added a few features (with some ill-considered incompatibilities), and properly documented zero of them. Again this is incorrect. There are some docs here: https://github.com/tursodatabase/libsql/tree/main/docs https://github.com/tursodatabase/libsql/tree/main/docs I am really not sure why are you so angry about libSQL.
- ncruces 2y ago
  > This is simply not true. Can you tell me where it is being said so? It's right there in “your” manifesto. https://turso.tech/libsql-manifesto https://turso.tech/libsql-manifesto > We take our code of conduct seriously, and unlike SQLite, we do not substitute it with an unclear alternative. We strive to foster a community that values diversity, equity, and inclusion. We encourage others to speak up if they feel uncomfortable. The word toxic clearly stung, but putting “unlike SQLite … we encourage others to speak up if they feel uncomfortable” in a manifesto is fine. Well, I could argue I'm just speaking up. > libSQL was always part of Turso. So, I don't get your point. My point is explained quite clearly in your post detailing the decision. https://turso.tech/blog/were-bringing-libsql-into-the-turso-family-8cc1a653448e https://turso.tech/blog/were-bringing-libsql-into-the-turso-... > We have our own self interest in making those changes (…) But we also wanted to create a welcoming community, that is open to everybody, abides by a modern code of conduct and a clear OSS license, and reimagined what SQLite could be in broader ways than just our narrow needs. A little latter down that line you sum it up: doing the above (living up to your grandiose claims of a more welcoming SQLite) “meant twice the investment” (aka a lot of money) and didn't pan out as a marketing play (showed engagement). So instead of a community that “reimagined what SQLite could be in broader ways than just our narrow needs" we just get the features you had your "own self interest in making." Which is fine, but doesn't really match the manifesto. > Again this is incorrect. There are some docs… Emphasis on some. Do you have any documentation on how to build on the Virtual WAL (internal SQLite API that you simply opened up)? Or is that's still a Rust example of an implementation that simply wraps another and logs without detailing anything beyond function names? Do you have any documentation about the new WAL API that isn't "libsql_wal_insert_begin begins WAL insertion"? I'm sorry, but goal here isn't to make things useful to others. Which is fine really: you're doing more than you're required. But compared to SQLite developers, and their forum, it's not much. PS: you also behaved… untowardly when you integrated SQLite3MultipleCiphers, and did this with not previous a word to the author. https://turso.tech/blog/fully-open-source-encryption-for-sqlite-b3858225 https://turso.tech/blog/fully-open-source-encryption-for-sql... > One project in particular was very suitable for us, SQLite Multiple Ciphers. Since it is licensed under MIT, we have just moved the code into libSQL.
  - _zagj 2y ago