Hmm. Am I the only one who immediately jumps to the thought that any VC backed "open source" tool is just using open source as a cost of customer acquisition, and will soon find a way to pay-wall necessary features? The majority of the effort will be in the paid SaaS product, not the open source stuff.
Maybe I'm getting old and jaded, but that's not really the spirit of open source.
FYI it seems ChatGPT could have answered this for you.
> The book you're describing sounds like "Rainbows End" by Vernor Vinge. In this near-future sci-fi novel, set in 2025, one of the subplots involves a project called the "Library Project," where the UCSD (University of California, San Diego) library decides to digitize its entire collection. The process is somewhat as you described: books are destructively scanned by being shredded into tiny pieces, which are then scanned and digitized, with the text being reconstructed from the scans. This process is a part of the broader themes of the book, which include the effects of technology on society and the concept of "wearable computing" and augmented reality. Vernor Vinge, a retired San Diego State University professor of mathematics, computer scientist, and Hugo Award-winning author, is well-known for his works in the science fiction genre, especially for exploring the concept of the technological singularity.
But yeah you're right for the most part. Turns out pretty much any database can be written in terms of transactions of KV pairs, which is what foundationdb gives you, so it means you can write your database query layer as a stateless, scalable service.
There have been attempts to write a SQL RDMS layer for it but it isn't maintained.
The Enabler team type is outward looking, evaluating and bringing new tech and concepts into the business and training other teams. They will collaborate with other teams often in order to help train and transfer knowledge.
This is different to platform teams which are meant to mostly build internal services which other teams use with self service, meaning they don't directly interact with members of the platform team (allowing both teams to operate independently). That said, platform teams may occasionally collaborate with steam aligned teams when building out new features or to better understand the problems the stream aligned teams are having.
Formally verified, bug free software exists. It just costs a LOT to produce, and typically isn't worth it, except for things like cryptographic libraries and life or death systems.
As the discipline has evolved, the high integrity tools are slowly being incorporated into typical languages and IDEs to generally improve quality cheaper. Compare C++ to rust for example, whole classes of bugs are impossible (or much harder to make) in rust.
You know that there's nothing stopping an open source project funded as a not for profit from doing the same thing right?
If something is hard, that's an argument for making a standard not for profit version of it, so it becomes a common good instead of platform rent seekers keeping out competition by saying it's "too hard".
My understanding for the reasoning behind this is that they don't want apps to have to ship the runtime stuff to avoid downloads and app sizes getting large.
That could be fixed by just shipping an updated shared library to all phones similar to how Google play services works on Android, but I guess they figure if you're updating anyway you might as well just update the whole OS.
These points are solved by the workers electing an executive or directors who makes those decisions, until the workers are sick of them and replace them in an AGM or an emergency meeting.
Something else I was caught out on recently is cross availability zone traffic, especially for multi AZ kubernetes where the nodes are very chatty. It's possible to get the services to consider network topology to limit cross az traffic, but it's not the default.
Maybe I'm getting old and jaded, but that's not really the spirit of open source.