zachlloyd

As the author of the post, I think this is totally reasonable feedback and something we have discussed quite a bit on the team.

The general stance on telemetry that we have is that a) we are just starting and it's really helpful to see which of our product ideas are useful to our users (e.g. does anyone use AI Command Search? Should we continue to invest in it) b) we tried to be very explicit about what we are and are not sending - it is only metadata and never command input or output (you can see the full list of events we track here: https://docs.warp.dev/getting-started/privacy#exhaustive-tel... c) if you aren't comfortable with telemetry, then please don't use the product just yet - we will make telemetry opt-in when we have a large enough sample size that we can be confident extrapolating what's going on

For googleapis - this is for login. We use firebase as our auth provider.

For segment - this is for temeletry, as you point out.

For sentry - this is for crash reporting.

As for why we have accounts, it's because we are starting to add features for teams and it's important in that context that there is some type of identity associated with the user.

But like I said at the start - the feedback is totally reasonable and we are trying to figure out how to balance concerns here while still being in a good place to iterate on and improve the product.

Thanks for the positive feedback - let us know how it goes.

This is correct. We do not send or store any terminal contents (input or outputs) to our server.

The only case in which that is not true is if a user elects to use Warp to share the output of a command using our Block Sharing feature.

We tried to be really upfront in the privacy policy:

https://www.warp.dev/privacy

Opt-in refers to anything that sends any contents of a terminal session to our servers (as opposed to telemetry which is metadata and never contains any terminal input or output). But we hear the feedback and appreciate it.

I understand where you're coming from.

My take is that there are plenty of commercial projects that have open source dependencies so it's not quite so black and white. That said we are still figuring out the best way to proceed on open sourcing the warp client code.

it's a good question. today warp is a terminal as you say. the hope is that we can build a platform around the command-line, but we decided by trying to start with the terminal's fundamental UX to see if we could improve it. in order to make a platform we believe first we need a great product that folks want to use.

Thanks kyeb. I agree with both points here - we need to be very careful and sensitive in terms of how we build this product from a privacy and security perspective, but we see the opportunity mostly the same way you do.

There are some great open source terminals out there, but having the opportunity to rethink it with a team of dedicated full-time engineers I think gives us an opportunity to build something really powerful and useful.

It's a good question, one that we are discussing a bunch.

We are planning to first open-source our Rust UI framework, and then parts and potentially all of our client codebase. The server portion of Warp will remain closed-source for now.

You can see how we’re thinking about open source here: https://github.com/warpdotdev/Warp/discussions/400 TLDR;

As a side note, we are open sourcing our extension points as we go. The community has already been contributing new themes [https://github.com/warpdotdev/themes]. And we’ve just opened a repository for the community to contribute common useful commands. [https://github.com/warpdotdev/workflows]

yup, i messed this up, apologies. site is handling the traffic better now thanks to cloudflare

i do agree

i see the point here.

i do think giving space for hard work is important. i still more often see the opposite problem of too much silo'd work leads to wasted effort, but for some really hard problems, having a bunch of space to think them through is beneficial.

Right, we do a standup, but if you're not careful the updates can be generic enough like "making progress on X" where you still end up working too long without feedback

working on the issue with the site going down. more traffic than i expected...

Correct! IC == individual contributor. Sorry for any confusion

I'm the author of the post - would love any feedback / similar experiences / contrasting opinions!

Hi! I'm the author of the post. Glad folks found it interesting.

One comment I would add on top of what's being discussed here is that I actually am not arguing that the main engineering tradeoff is between quality and speed.

Instead, what I'm saying is the best engineers I've worked with work backwards from the user experience (the product) and engineer their system and app in support of it - e.g. they judge their work by how well the product works, not by some other metrics around the code in the abstract. They do tend to produce what you might consider great code (code that is simple, well factored, well tested), but the point to them is that they need to do that in order for the app to work really well.

Thanks for all the feedback!

Thanks Brendan!

We've been following fig and are excited to see more innovation in this area!

That's a fair point - it wasn't meant to mislead since we are using Github for feature requests and issue tracking, but I think you're right. We'll remove the link.

It's a fair point, but we don't feel ready to accept community contributions yet.

Our plan is to open source the Rust client code once it's more mature.

We are particularly excited about sharing our Rust UI framework since there aren't a lot of great options for building native UIs in Rust right now. We want to make it cross-platform first though.

We mention Rust primarily because it produces a really high-performance app and to make clear that it's not built using Electron or web tech.

We wrote up a pretty detailed technical design if you're interested in checking out how we built and why we made the decisions we made:

https://blog.warp.dev/how-warp-works/

We are building a web version now using WASM and WebGL.

Next up will be Linux, followed by Windows.

The terminal itself is totally free

We may add paid features for enterprises around collaboration, and other things on the server that would cost us money to support.

Hi HN,

I’m Zach, from Warp. Excited to get feedback on what we’ve been working on. Happy to answer any questions!

Thanks Peter for posting about us.

Hi HN,

I’m Zach, the author of the post and founder at Warp—a blazingly fast Rust-based terminal.

TLDR; The terminal isn’t built for how modern software engineers work. Software development moved to reusability, composability and collaboration years ago. Terminals are still inherently single-user, linear, and ephemeral because the terminal-shell interface was built during a time people were using physical teletype terminals. This makes it hard for teams to effectively collaborate on production issues, track what actions people are taking, and recall prior events. The terminal-shell interface, which hasn’t changed since the 80s, needs to be rethought if we want to bring the terminal into the modern age.

At Warp, we’re holistically rethinking how the terminal should work to bring it into the modern age. To start, we’ve built shell integrations into Bash, ZSH, and Fish as an additional interface between the terminal and the shell. This interface allows us to group commands and their outputs together, allowing users to take actions on “blocks” i.e. copy/paste, scrolling, sharing. We currently have integrations for bash, zsh, and fish.

We’ve also: * Replaced the prompt with a full-fledged editor * Added Visual menus for history & tab completions * Built a Command Palette to discover and access all shortcuts See a demo here: https://www.youtube.com/watch?v=X0LzWAVlOC0

Speed is our top priority and so we chose to use Rust and GPU rendering. See our engineering post for how we built Warp, including how we co-built our own UI framework for Rust: https://blog.warp.dev/how-warp-works/

Our terminal model code is based on Alacritty’s model code; we’re grateful that a few of the collaborators reviewed our early design docs. Huge thanks to our collaborators: Atom co-founder Nathan Sobo [1], Nushell co-founder Andres Robalino [2], and Fish shell lead developer Peter Ammon [3]! We hope to open source the client soon.

Ask me anything!

[1] https://github.com/nathansobo [2] https://github.com/andrasio [3] https://github.com/ridiculousfish

Yeah I think a balance is good. The point I'm making in the post though is that ultimately you ship the product not the code and I always want to work with folks who get that.

Completely agree. It's frustrating to be product focused when the company isn't.

Hey HN, I'm the author of this blog post.

In my experience there are two types of engineers: ones who care more about the code (code-first) and ones who care more about the product (product-first).

I strongly favor hiring and working with product-first engineers.

Curious what you think.