It has been happening for a while with a bunch of startups like Supabase claiming to be "open source" and marketing themselves as such but making it really hard to self host for a long time.
It wasn't just them either.
I would see with disgust a bunch of startups use "open source" as their marketing tactic, no matter how hard it was to setup or run without their hosted service.
It is also a peverse incentive: the harder the open source system is to run and maintain, the more you will gravitate toward their cloud. Supposedly open source companies raising a ton of money from VC is also strangely contrary to the open source ethos.
I am not going to make any sweeping generalizations across all products. But at least in the case of Deno KV, there doesn't seem to be lock-in. So if you were running something self-hosted for KV persistence, it will continue to work unmodified.
> I would see with disgust a bunch of startups use "open source" as their marketing tactic.
Again, not sure which bunch of startups. But I am not seeing that with this product. Seems more like a survival strategy to add some cashflow behind the developers.
I am curious what you think Open Source should be (or should not be). I think it's fair that running a service in the cloud should cost something. And self-hosting it, I think it's fair that it requires a bit more effort than using the hosted service.
Isn't that the reverse? It's against the sentiment that being a part of system means that you implicitly agree with it, and any complaints you make about it are void.
Seems like you can similarly respond to any complaint with that meme too, which is also invalid. In reality, there is a lot more nuance than can be described by pithiness.
It looks to me like they've documented the KV Connect protocol they invented to support this feature, in enough detail that anyone else could build an alternative backend for it.
This has helped me feel completely OK with how they're handling this. They get an advantage in that they've already built an extremely robust proprietary backend, but I find that acceptable given the documented protocol.
I think this is great, except I feel odd that it's just hanging around on the Deno global instead of being e.g. imported like any other database client.
import KV from "https://deno.land/kv" // for example
If their protocol is indeed open and usable with your own backend, then that library should be able to work for anyone. And if they need some fancy native performance then maybe they could intercept that import when running code on Deno Deploy?
Treating their hosted service as "part of the runtime" which is what the Deno global tends to be for is the only remaining ick factor for me.
Yeah, this is the only thing I don't like. Having it readily available as a module import would not change anything (except one line of code) and it feels more decoupled. But in practice I don't see a huge difference, it's not like it's polluting the global namespace with dozens of functions.
I'm really confused by this statement. What exactly is being degraded in their service? Or in their API? Or in the underlying tech they are compatible with?
All I see here is an open source system that you can manage and deploy yourself, with a 100% compatible API for a cloud service that handles that for you, should you decide to pay money to have that problem solved for you.
Good Open Source is something like PostgreSQL: It's completely free, you can host it yourself, or you can pay someone to host it, there are multiple competing service providers, most of them contribute to the project, and everyone has access to almost all of the source code. Anyone can start offering a compatible service with minimal investment. If you run into a problem, the source code for everything is public, and you can often fix it yourself.
And then there is something like DenoKV: There's an Open Source version that is designed mostly for prototyping or small scale deployments, and a closed source hosted version designed for production. If you want to use it you have to pay one company and there are no competitors. You are locked in. Theoretically, a competitor could create a compatible product, but the required effort is huge, creating a big barrier to entry. And even if competitors do show up, any new features introduced by the proprietary service will take a long time to trickle down to competing services. If you run into a problem, you have to hope the vendor fixes it.
I am definitely ready to call out shams, sellouts, and "enshittification." But I don't see how this one option is any of that.
I'm building a back end with Deno and MariaDB, and pretty psyched about it so far. I haven't built a back end since I did one with PHP 5 in 2011 or so. Thus far I've found it easier to get something working than I did with the tools years ago. So much so that I'd consider throwing these guys a bone by paying for a service.
But... I don't know that a key/value store suffices for what I want to do, which will involve relational queries.
It has been happening for a while with a bunch of startups like Supabase claiming to be "open source" and marketing themselves as such but making it really hard to self host for a long time.
It wasn't just them either.
I would see with disgust a bunch of startups use "open source" as their marketing tactic, no matter how hard it was to setup or run without their hosted service.
It is also a peverse incentive: the harder the open source system is to run and maintain, the more you will gravitate toward their cloud. Supposedly open source companies raising a ton of money from VC is also strangely contrary to the open source ethos.
Deno KV is basically the next jump in that chain.
Richard Stallman was right once again, as usual.