My take is that the hacker news crowd is not the target market for Warp. I think it does an amazing job of making the terminal easy and friendly to infrequent users. I'd recommend it to anyone who tells me they prefer a git GUI interface over the shell because of how confusing the shell is. (this is where Warp's completions really shine)
But if you're already very comfortable in the shell and have a customized setup there's some very rough parts of Warp. Lack of any compatibility with existing bash/zsh completions is the huge deal breaker for me.
Also you'd be surprised at the number of software engineers that really don't care how many sentry logging calls their apps make. I completely agree with the sentiment, and I personally just disable the Warp application's internet access to address this, but it's worth recognizing that we're in the minority of people that care.
I'm in this boat. I never understood why I should care if some website interacts with google apis or logs everything I do and sells it to marketers so they can sell me ads. I'll block them anyway so it'll never make a difference to me one way or the other.
Other DNS lookups it triggers:
api.segment.io
app.warp.dev
identitytoolkit.googleapis.com
o540343.ingest.sentry.io
securetoken.googleapis.com
storage.googleapis.comHow do you do that? I used to use Little Snitch, but not sure if it's still the best these days.
It's far far simpler than little snitch. It's intended purpose is for managing low-data connections, but I leave it on all the time and use it as per-app network permission manager. The data usage tracking is also nice. By default all new apps lack network access. Takes a little bit of work to manage, and sometimes you get unexpected issues, but it's well worth it. Amazing seeing all the network activity trying to come from apps that really don't need the network at all. Like a terminal... (though for a deeper analysis I'll bust our Charles proxy with TLS interception)
As cieplik mentioned, it's true that telemetry has not been mentioned as frequently as it has been on HN.
> I think it does an amazing job of making the terminal easy and friendly to infrequent users.
As for our users, it's a combination of newer and more experienced terminal users. More than half of them are self-reported advanced or expert terminal users.
Some more thoughts: I've tried it a bunch, and my big issue with Warp is it just throws away a bunch of the more obscure/advanced shell features and pretends like they were never there. The sheer inelegance of it just pains me. Like if Warp wants to destroy my custom zsh keybindings, ok, but at least tell zsh that so they don't appear when I run `bindkey` to list them. Or at least pass along the key events to the shell when a shortcut is pressed that Warp doesn't already know about. Right now it just eats my custom bindings and does nothing with them.
Also my fzf history searching is also thrown away along with my keybindings to kill a line AND put it in the system pasteboard. (That's an awesome feature that Warp should just do) The other big one for me is completions. It's hard for me to imagine an expert terminal user that's never written their own completions, or if they have, is happy throwing them away.
I really like the idea of someone re-imagining the shell+terminal, but Warp is occupying this awkward middle ground between a terminal emulator and a shell. I wish it would either be a new shell with an integrated GUI interface, or be a terminal emulator that actually lets the shell do everything it knows how to do.
I assume you're asking specifically about discussing telemetry and open source, not only the features. We try to be super open about collecting the data, and published an extensive list of things we report. Most of our users don't mind. Those that did, messaged us directly about it and shared their feedback. Some even decided to trust us after exchanging emails, talking to the team and seeing us improving the messaging based on their feedback.
Regarding open source - it is not just a vague promise. We do have plans on doing it, many team members joined the company because they want to contribute to the community. We actively discuss this topic with our community on Discord and Github. I'm personally super excited about our UI framework, and can't wait until we open it up to other people (we recently added some a11y support, which is super cool and not as common among the Rust frameworks). Here's the github discussion for more context: https://github.com/warpdotdev/Warp/discussions/400
However, we understand that our current mode of operation won't (and honestly, can't) please everyone, so it's not surprising that there are people who don't agree with this approach.
I think that's what is giving people a strange feeling about this. You prioritized your own desires (not needs mind you) rather than your users. And if your thinking is so off that you really think these are needs during the beta then that is even more worrying.
If I were in your shoes I'd crunch immediately to make telemetry, crash reporting, and logging in three separate opt-in features then get a build out ASAP. Prompt people to enable or disable each with clear language in a single screen (no EULAs or lawyer weasel words) and no dark patterns (like double-negative checkboxes or flipping cancel and accept button colors).
For crash reports and logins there is an even better way to handle this that is respectful of your users without being obtrusive and shows you are working hard to earn trust. Then you only need one post-install prompt to ask permission to share data which is much simpler.
1. Ask the user each time you find a crash report and let them inspect it if they want to do so, then ONLY send the content the user inspected (no hidden payloads, extra HTTP headers, etc). Include a checkbox/dropdown "Always send" or "Never send". The default is to ask the user to help you out. It gives transparency by letting them inspect the entire payload. And if/when you've earned their trust they will click Always on their own. It also covers you just in case the payload accidentally picks up something sensitive.
2. When the user invokes a feature that actually needs a login then prompt them at that time. Or if the context doesn't allow that, show an unobtrusive icon, link, or banner in a context-appropriate way that lets them create an account or login.
3. For sharing let users share things anonymously with links, no account required. Once they've started using the feature let them know they can create an account to "claim" the things they've shared. This can be a good way to show people the benefits rather than just claiming benefits exist. It makes a nice on-ramp without pestering or annoying people who never create an account. And the people they share things with may end up becoming your users.
While I'm not them, I can answer this. Users did ask for this as much as they asked for other things.
> You prioritized your own desires (not needs mind you) rather than your users.
That's an awfully big assumption to make, and one that does not conform to reality.
You could also be that special someone to trust us. Let's trust each other.
We also were expecting some of this response from the HN community, and understand it.
The short answer to your question is that different developers care about different things. A lot of developers are OK with login, telemetry etc (we are not the only tool that has these things), and they exist in our case because it helps us produce a better product experience.
That said, I don't want to dismiss your question - we needed to do a better job understanding the perspective of more developers, and the response on HN has made that very clear. We are going to take the feedback and adjust course.
Thank you!
I would not blame companies for adding telemetry for improving their product (instead of tracking user), and not explicitly tell the paranoid mob about it, as if to give them excuse not to use the product. It's not like they won't find out anyway.
It’s not hard to articulate. Here’s Der Spiegel’s 2013 reporting on the NSA’s use of Windows telemetry for passive observation of targets:
> The automated crash reports are a "neat way" to gain "passive access" to a machine, … [this] provides valuable insights into problems with a targeted person's computer and, thus, information on security holes that might be exploitable for planting malware or spyware on the unwitting victim's computer.
> In one internal graphic, [the NSA] replaced the text of Microsoft's original error message with one of their own reading, "This information may be intercepted by a foreign sigint system to gather detailed information and better exploit your machine."
Did you guys talk to real-world users while building this and before this launch?
This whole blow-up re: your telemetry / open sourcey'ness seems like it could have been avoided. I'm curious if you actually floated these ideas with real world users and a) everyone else is cool with it but the HN crowd is super put off by it, b) everyone is super put off by it but you decided to launch anyway, or c) you didn't actually check with real-world users and hoped for the best.
Sorry if that sounds snarky - it's not my intent. I'm genuinely curious here as a product person / entrepreneur / builder, etc.