Thanks for sharing, such an interesting approach! At my startup we're currently discussing licenses, this is very inspiring. I have a follow-up question!
The reasons for OSS you list include "Bus-Factor", "Longevity", and "Continuity". I'd summarize all of those as "even if they can't do business with [company] anymore, users can continue on" - our customers also say that's very important to them.
... But what if "can continue on" means "need some of those proprietary features"? And you're not there to sell to them anymore? Or you've been acquired by private equity, started charging 10^6x, and users want out? Users aren't allowed to clone the repo, remove your proprietary code, and reimplement it with their own solution, because:
> you may not remove or obscure any functionality in the software that is protected by the license key.
Is this a thing your customers are concerned about? What do you expect them to do in such a scenario?
I've sold multi-year and perpetual EE licenses for this exact reason -- to reduce risk of eventually losing EE features if Keygen LLC goes under and is unable to renew EE licenses. So in this case, if Keygen LLC goes under, they still have a perpetual EE license that will allow them to use existing EE features. But this is something I've been thinking about lately, and something my customers have been talking about. I want to come up with a better answer other than "well, pay me for a perpetual license and we'll remove that risk."
Maybe some kind of clause for a "Change License" in case Keygen LLC goes under, e.g. we go from ELv2 to Apache 2.0 if that happens. I'm not really sure what that'd look like right now, but I'll keep thinking on this and hopefully come up with a good answer eventually.
Outside of that, nothing is really stopping somebody from forking Keygen and reimplementing the EE features 'in-spirit' under a new code path, especially if Keygen LLC has gone bust. They just can't remove or copy the existing EE features verbatim.
For the CoScreen team, I'm curious how the existing competition (https://tuple.app/, https://screen.so/) factors in to your decision to build/position this - do you believe you have a different vision than they do? Features they can't match? A better team that will out-execute? Out-market?
Startup founders are often told not to launch a product that has direct competitors already, so I'm curious to hear your take!
Screenhero engineer here, and currently working with CoScreen. TBH, Tuple adn Screen both seek to re-create Screenhero (and do an amazing job of that!) CoScreen, while using similar technology, has completely rethought the UI from the ground up, and is a huge step forward that the others are going to have a hard time catching up with. Instead of one person sharing their screen, with CoScreen, each participant can share individual windows into a shared environment that feels as natural as native windows. It's a fundamentally different vision for how to do remote collaboration.
I understand it's exciting to see introductions of new machine types and new GPUs, but for it to mean anything Google should instead get its house in order on the GPUs they already offer. Getting an n1 instance with a Tesla T4 GPU in any datacenter I've tried has a <50% success rate on any given day ("resource unavailable" more often than not, they just don't seem to have enough of them), which is _hugely_ damaging to our ability to rely on the cloud for our workload. Worse, there's no way for me to work around it: I'd be willing to switch zones, or machine type, or GPU type, but there is no dashboard or support guidance that'll tell me if there's any such configuration that'll be reliably available.
Because of that, seeing this A100 announcement is just a bummer, as I fear it'll be just another "resource unavailable" GPU...
Customers can experience stock outs sometimes based on a variety of factors but we can surely help you out as we have T4 GPU capacity available and like you said, we may direct you to a different zone or region. Open up a support case on the issue and we can help you out.
How much CPU is allocated to a Cloud Run (not-on-GKE) instance while a request is active? I see that memory is configurable (up to 2G), but no word about CPU...
I have a compute-heavy and bursty workload that I'd _love_ to put on Cloud Run, but it's important to know a ballpark for the CPU I'll get to spend on my requests.
Second question: any plans to more officially support "background" workloads that consume off e.g. Pub/Sub and might be able to use cheaper preemptible compute? I guess I'm probably already able to point a Pub/Sub push queue at a Cloud Run endpoint, but having the option of cheaper (autoscale-to-zero) compute for my not-latency-sensitive work would be awesome.
I think the use case where the per-config-request pricing model could break is with serverless (like Lambda or Cloud Functions or ...). Secret management there is super important, and your solution looks great, except that what makes these platforms great for low-cost deployments is that they "scale to 0" (turn off your instances when there's no traffic), which means that each instance potentially lives just briefly. Since each start of each instance is a config request, that could in some cases become problematic.
That said, at your lowest tier you could have ~20 moments of "booting a new instance" per hour. That's probably plenty for most cases, although you may find users for whom it isn't enough.
Good point. What I'll say for now is that if anyone wants to use EnvKey with Lambda or Cloud Functions and is worried about this, feel free to reach out - dane@envkey.com. We'll make sure you're paying a reasonable price that reflects your usage level.
The reasons for OSS you list include "Bus-Factor", "Longevity", and "Continuity". I'd summarize all of those as "even if they can't do business with [company] anymore, users can continue on" - our customers also say that's very important to them.
... But what if "can continue on" means "need some of those proprietary features"? And you're not there to sell to them anymore? Or you've been acquired by private equity, started charging 10^6x, and users want out? Users aren't allowed to clone the repo, remove your proprietary code, and reimplement it with their own solution, because:
> you may not remove or obscure any functionality in the software that is protected by the license key.
Is this a thing your customers are concerned about? What do you expect them to do in such a scenario?