[zachlloyd]

Zach from Warp here. Thanks for the thoughtful feedback.

Re: login, I get the concern and we are exploring product options that let folks preview warp without login.

From a product perspective our goal is to make the terminal cloud-native and have a way of facilitating collaboration, and it's not really possible to build that without user identity. Specifically, login allows us to build cloud-oriented features that make the terminal have a concept of “your stuff” and “your team’s stuff” – for example Block Sharing. This is the same reason other collaborative apps like Figma and Github require login. We do get the concerns though and understand that this is not traditionally how a terminal has functioned and that it will make some users uncomfortable. But on the whole we feel like it's the right way to push the command line experience forward.

Re: configuration issues, we are trying as fast as we can to fix them. It's hard technically to both innovate on the command-line and maintain complete backwards compatibility, but that is our goal.

Re: Mac only, this is also really just a limitation of eng bandwidth, not a product strategy. We are 100% planning on bringing warp to more platforms as fast as we can.

[smoldesu]

Thanks for responding, it's good that you're thinking about these problems.

> I feel pretty strongly that the terminal ought to be cloud-native

This seems like an oxymoron to me. A terminal is not cloud-native; it does network with the host machine, but a local shell is inherently local. If you've built the cloud part first, then you're building this product in reverse.

You're welcome to explore whatever avenues please you, but I'm not convinced there's much business to be found in cloud-native local shells.

> configuration issues, we are trying as fast as we can to fix them.

No sweat, I don't actually use Warp. This isn't a legitimate concern for me to level, just an example of the infinite treadmill of issues that you need to solve in a closed-source project. If alacritty has a configuration issue, the community fixes it. The way you've structured your project makes it extremely hard for your community to help you here.

> We are 100% planning on bringing warp to more platforms as fast as we can.

I wish you luck, it's hard work carving out a market segment of your own. I look forward to how your future features stack up against other terminals.

[ushakov]

> If alacritty has a configuration issue, the community fixes it

Coincidentally, Warp is based on Alacritty

https://github.com/warpdotdev#open-source-dependencies

[picometer]

Hi - I am trying out Warp at a job that defaults to the MacOS ecosystem. But as a Linux user in all other domains I’m glad to hear that you’ll be going cross platform.

I vacillated for a long, long time before registering for an account. The distrust of cloud centralization, especially among developers who would otherwise be impressed by the “built in Rust” marketing, runs deep. Even if your intentions are totally beneficial right now, companies can change hands to people who aren’t aligned with user interest. Users who are developers are frequently in privileged positions at their workplaces, and being compromised at the level of their terminal could be catastrophic.

I’m the type of person who will take on many extra hours of configuration hell because I spurned Docker Desktop for its account requirement. So why did I end up signing up for a Warp account? Because yes, you are actually innovating in an area that desperately needs modernization. You recognize the risks and importance, at least in words, and in actions such as you have taken today. But because of the account requirement, I can’t let myself become locked in to Warp, so I’m not sure how deeply I’ll be able to explore it. And if a competitor arises that can innovate without any potential for lock in, I would jump ship without hesitation.

Thank you for your efforts and please, please, please take all the feedback here with utmost seriousness.

[jjwiseman]

~99% of people are not going to be interested in the collaboration features, and will not log in. The ~1% who are interested in collaboration will want to first know whether it's a good shell, and ~50% won't log in to try it if they need to do that first. Maybe you don't care about that, but for most products that would be a lethal problem.

[allarm]

> collaboration

While it is possible to share a session with tmux, I have never used it for collaboration - in my 20 years in the industry, no such need has arisen. I'm not saying it's not a useful feature, others probably use it, but still, it's hard to see it as a selling point. And yes, mandatory registration discourages me from trying Warp.

[arberx]

You should make users CHOOSE to provide their login/identity by giving them features that improve the experience: e.g, synchronized settings across all terminal sessions.

It should be optional.

[janef0421]

That seems quite similar to allowing developers to SSH into a development server. That option is highly mature, allows users to use a variety of tools, and is not very expensive. How does your product improve on that?

[7e]

One can have identity without centralization; look at PKI. I don’t need to create an account with some website in order to use SSH.

[rekoil]

Yeah look at how things like Brave and DuckDuckGo do it.