there is a large segment of developers who find the command line hard to use or who just want a better, more productive experience using it. to be clear, you may not fall into that bucket, and that's OK.
the point of the login is that we have features that cost us money to provide like AI, and we need some concept of identity to prevent their abuse. i don't think that's detestable (e.g. it's very similar to cursor or copilot), but i get that's a new behavior in the terminal and am sorry it put you off.
fair criticism, and this is the reason we removed the login requirement.
just to clarify though, the point of the login is that we have features that cost money to provide like AI and collaboration, not anything more nefarious, but i get that it's a new behavior and reasonable devs might not like it.
I appreciate that you've changed it and truly wish you luck! An alternative that would've have made me immediately uninstall would be to just block those account-requiring features behind a login. Not even letting me get a local Zsh prompt without logging in was too much.
Hi HN - I'm the author of this post. It's about how productivity interfaces (e.g. Figma, GDocs, VSCode) are going to evolve in the world of generative AI.
The basic thesis is pretty straightforward: all of these interfaces are going to have to shift to be geared towards revisions of AI generated drafts as opposed to de novo creation.
Hi, author of the blog post here. Happy to address any questions or comments!
tl;dr I believe we are moving to an AI-first world in productivity, but, importantly, not an AI-only world. I think the main paradigm in horizontal productivity apps is going to be Ask & Adjust: AIs will iteratively generate drafts or edits, and humans will hand-tweak them until they are right. For activities like coding where it’s very hard to express your intent exactly to an AI, the hand-editing interfaces, along with collaborative re-use, will remain crucial.
Hi HN - I'm the founder at Warp.dev and wrote up this guide (mostly for internal use) on our product process at Warp. Would love any community thoughts and feedback.
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.
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.
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.
~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.
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.
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.
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?
That's an interesting point regarding the costs of the client vs. the cloud, and also that you can get a more hermetic experience with local VMS. Agreed on the latency concern.
We spoke with a lot of users (someone mentioned our discord which has thousands of members) and there are thousands of developers using Warp every day (prior to this ShowHN).
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.
Thanks for the feedback - I'm the founder at Warp.
There was a ton of discussion on this yesterday with our ShowHN [0] and we are considering what changes to make based on the feedback (some of which are inline with your suggestions).
And we are committed to making telemetry optional when we leave beta.
And it's definitely the case that command input / output are never sent to the server.
Login is a bit trickier as it's hard to build an app that leverages the internet and facilitates teamwork without understanding user identity. But point taken.
> Login is a bit trickier as it's hard to build an app that leverages the internet and facilitates teamwork without understanding user identity. But point taken.
I think you need to understand that this is a rare edge case and at least 95-99% of users do not want or need this. A terminal is a terminal, a command line shell. There are countless tools within it that have been developed for decades that provide collaboration: Git is a nice example. The shell itself is localized and user authentication is handled by the system.
What exactly is there to be worked on in collaboration on a command line? Only one person can type or execute commands on it at the same time, and even worse, it is a very sensitive part of any system and the whole point of TTY and session management is to NOT have it as a shared resource.
Don't get me wrong, there are features of your product that look very nice and have almost convinced me to switch to it (until I saw the SSO screen), but the way you approach this rings all possible alarm bells and demonstrates a deep and fundamental lack of understanding of what you are trying to re-invent.
> Login is a bit trickier as it's hard to build an app that leverages the internet and facilitates teamwork without understanding user identity. But point taken.
I thought the team/collab functions would just be optional features. First and foremost, isn't this a terminal still?
there is a large segment of developers who find the command line hard to use or who just want a better, more productive experience using it. to be clear, you may not fall into that bucket, and that's OK.
the point of the login is that we have features that cost us money to provide like AI, and we need some concept of identity to prevent their abuse. i don't think that's detestable (e.g. it's very similar to cursor or copilot), but i get that's a new behavior in the terminal and am sorry it put you off.