This is neat, but I'm not convinced it's going in the right direction.
It's not open source, and "maybe it will eventually be" is unacceptable for such a core component of an engineer's workflow. Most of the features on the front page are "coming soon," not actually available. There's no timeline for support for non-Mac OS systems, and it's built using Metal rather than any cross-platform API, so it will be at least moderately difficult to port. (Isn't the whole point collaboration?) It is "blazingly-fast" but has no benchmarks for latency or startup time.
The team raised money because "[b]uilding a terminal is hard," and the business model seems reasonable - build a terminal people like, and then get businesses to pay for it - but I'm hard-pressed to find a use case that would benefit from the upsides of this tool which isn't also utterly hamstrung by its shortcomings, at least currently.
Yeah, maybe you can justify it at an all-Mac dev shop, but at the last all-Mac place I worked we did everything this currently does with iTerm (free) and Tuple, and frankly I don't see this obviating the need for Tuple in that use case. (EDIT: Tuple also works fine on Linux, and of course there are myriad excellent terminals for Linux.)
Perhaps most importantly, though, this FAQ entry concerns me:
> Every session you work on your desktop can be backed by a secure web permalink. It opens into a browser tab that shows your terminal state and allows readers to scroll and interact with the read-only elements. You might use this for yourself: so you can view and run commands on it while you're away from your machine. Or you might share it with a coworker for debugging.
First of all, is this actually available at the moment? I think not, since "Web (WASM)" is still on the roadmap.
Second, "secure" is doing a lot of work here. What's the threat model Warp considers themselves secure against? How are these sessions allocated? Does every terminal start in a connected state, or is the connection only made once the user opts in? Are the terminal sessions E2EE? Are they exposed to Warp's internal systems? If so, what is stopping any attacker who makes it into Warp's network from remotely monitoring and controlling user machines? If Warp says it _is_ E2EE or otherwise secured in this manner, how can we trust them when it's not open source?
This seems too risky to be worth using seriously, and perhaps too risky to even try out.
Yeah, I just got an invite code yesterday, but given this I may opt against using it - this seems like a real risk for leaking env vars, credentials...I don't so much mind stuff like Segment and Sentry, but I'd love to see some details from someone familiar with the project around the same questions you raised regarding the web-integrated functionality.
1000s of developers use Idea's IntelliJ, Webstorm and GoLand. Only the community edition of IntelliJ is open source.
Software doesn't need to be open source for it to be adopted, if they have the right security practices and I'm sure for enterprise contracts they will have the right level of information available under NDA when GA.
Enterprise contracts also include clauses spelling out financial consequences of major screwups. If Jetbrains screws up and a customer's passwords go everywhere, I'd bet the contract makes Jetbrains at least a bit liable.
You're comparing a 10+ year old company with a company that has a product in beta. I don't think this is a valid comparison. I'm sure they'll provide enterprise level contracts and support for large installation at some point.
Yes, I am. You're absolutely right. I'm doing so in order to illustrate what it is about mature closed-source enterprise software offerings that makes them acceptable to use.
Otherwise it amounts to using a random binary blob and hoping it does what you want it to. Without any ability to check its internals yourself (short of RE) or any legal backing.
Some might opine that that's completely reasonable, but I think many might find it an unreasonable risk for an enterprise to take. Regardless of how new the vendor may be.
Again, you're completely right about the comparison I am making. I hope I've been able to clarify my reasons.
Great callouts, I definitely get your concern around block sharing--that feature does exist currently in Warp but it is completely opt in on a per command basis (we never collect any command output without the user opting into it first). The way this works is that if you explicitly click "Share" by right clicking on a block, we will send the contents to our server and generate a link for you. A block can also be unshared at any point to completely delete a block from our server.
Regarding the cross-platform piece, the plan is absolutely to support different platforms. In fact we've built our own cross-platform UI framework to help us with this endeavor which you can read about here: https://www.warp.dev/blog/how-warp-works. We chose Metal to start because the Metal debugging tools in Xcode are excellent, allowing us to inspect texture resources and easily measure important metrics like frame rate and GPU memory size. Thankfully, because our graphics code is decoupled from our UI framework, porting the graphics piece of the UI framework essentially mounts to porting over a few hundred lines of shader code, which shouldn't be too difficult.
Edit: After searching for variations of “terminal” “iterm” and “tuple”, of course it’s the top hit if you just search Mac and tuple! https://tuple.app/
> What's unacceptable about it (or any other software for that matter) closed-source?
Lots of things. Lock-in for once. Warp's VC decide they want an exit and Warp becomes 50usd/month sass or some sanctions block you from using Warp. You're hole workflow, scripts etc are basically dead. Also, what is in that closed source? No one can audit it and it's literally the environment that contains all of your secrets.
It's not open source, and "maybe it will eventually be" is unacceptable for such a core component of an engineer's workflow. Most of the features on the front page are "coming soon," not actually available. There's no timeline for support for non-Mac OS systems, and it's built using Metal rather than any cross-platform API, so it will be at least moderately difficult to port. (Isn't the whole point collaboration?) It is "blazingly-fast" but has no benchmarks for latency or startup time.
The team raised money because "[b]uilding a terminal is hard," and the business model seems reasonable - build a terminal people like, and then get businesses to pay for it - but I'm hard-pressed to find a use case that would benefit from the upsides of this tool which isn't also utterly hamstrung by its shortcomings, at least currently.
Yeah, maybe you can justify it at an all-Mac dev shop, but at the last all-Mac place I worked we did everything this currently does with iTerm (free) and Tuple, and frankly I don't see this obviating the need for Tuple in that use case. (EDIT: Tuple also works fine on Linux, and of course there are myriad excellent terminals for Linux.)
Perhaps most importantly, though, this FAQ entry concerns me:
> Every session you work on your desktop can be backed by a secure web permalink. It opens into a browser tab that shows your terminal state and allows readers to scroll and interact with the read-only elements. You might use this for yourself: so you can view and run commands on it while you're away from your machine. Or you might share it with a coworker for debugging.
First of all, is this actually available at the moment? I think not, since "Web (WASM)" is still on the roadmap.
Second, "secure" is doing a lot of work here. What's the threat model Warp considers themselves secure against? How are these sessions allocated? Does every terminal start in a connected state, or is the connection only made once the user opts in? Are the terminal sessions E2EE? Are they exposed to Warp's internal systems? If so, what is stopping any attacker who makes it into Warp's network from remotely monitoring and controlling user machines? If Warp says it _is_ E2EE or otherwise secured in this manner, how can we trust them when it's not open source?
This seems too risky to be worth using seriously, and perhaps too risky to even try out.