100 points by joaoh82 1 day ago | 35 comments | View on ycombinator
freedomben 1 day ago |
mikeocool 1 day ago |
Seems like a real shame that they’ve been abandoning their core product that was reliable for years in pursuit of nebulous AI/enterprise routing products.
I get that dev tunnels are probably not a massive business that’s going to get VCs mouths’ watering, but maybe not every business needs to shoot the moon?
Anyway, glad competitors are coming in to fill the space.
kwakubiney about 23 hours ago |
ollybee about 24 hours ago |
veverkap about 22 hours ago |
What makes your solution better or different?
merb about 20 hours ago |
joaoh82 1 day ago |
joaoh82 1 day ago |
abricq about 24 hours ago |
search_facility about 19 hours ago |
mewrcreate about 23 hours ago |
Ended up on localtunnel with a fixed subdomain and keepalive script. It works but drops connections and requires a bypass-tunnel-reminder header on every request.
Key requirements for this use case: fixed/predictable URL so downstream services don't need reconfiguration, low latency for API calls, and auto-reconnect as a daemon. Would be interested to try Rustunnel if it supports fixed subdomains.
ChrisLanca61570 about 15 hours ago |
DeepTradeX_83 about 17 hours ago |
davidliu847386 about 13 hours ago |
basedhusky46 about 24 hours ago |
Boulos00191 about 22 hours ago |
goatyishere25 about 16 hours ago |
davidliu847386 about 19 hours ago |
jockm about 22 hours ago |
Rust is a cool and interesting language that helps solve some problems, but it doesn’t make it immune from all. But that doesn’t make it inherently better, or worse for the job. We have seen this trend for everything from C++ onwards (Java, Ruby, C#, Python, etc etc)
Please don't interpret these frank questions as criticism or mistrust up front, but we've been burned a few times with tools like this start open source and then realize there might be some money out there and go proprietary, usually with a rug pull. I don't mind offering paid hosting at all (in fact I think it makes sense to offer that) so long as the code all remains open source. The "open core" model may even be ok so long as it's truly just "enterprise" feature that are gated, though that's a hard line to tread.
What are your monetization plans? Are you committed to long-term being actually open source?
Personally, I would suggest licensing this as AGPL to ensure that if anyone does take it and try to stand up a paid/proprietary service based on your work, the license will at least force them to open their code. It's not perfect. but with MIT you have zero defense against that. It would also give people like me some peace of mind.