The Changelog: Software Development, Open Source - Warp wants to be the terminal of the future (Interview)

Episode Date: April 26, 2022

Today we’re talking with Zach Lloyd, founder of Warp — the terminal being re-imagined for the 21st century and beyond. Warp is a blazingly fast, rust-based terminal that's being designed from the ground up to work like a modern app. We get into all the details — why now is the right time to re-invent the terminal, where they got started, the business they aim to build around Warp, what it's going to take to gain adoption and grow, but more importantly — what's Warp like today to get developers excited and give it a try.

Welcome back. This is the changelog. Thanks for tuning in. If you're new to the pod, head to changelog.fm for all the ways to subscribe. If you're a long-time listener, hey, we love you. Thanks for coming back. Check out our membership at changelog.com slash plus plus. Drop the ads, directly support us, and enjoy that sweet bonus content. Today, we're talking with Zach Lloyd, founder of Warp, the terminal being reimagined from the ground up for the 21st century. Warp is a blazing fast Rust-based terminal and is being built as a modern app. We get into all the details, why now is the right time to reinvent the terminal, where they're getting started, the business they aim to build around it, what it's going to take to gain adoption and grow Warp. But more importantly, what's Warp like today to get devs excited and give it a try.

Big thanks to our friends and our partners Fastly for keeping our pods super fast globally. Check them out at Fastly.com. This episode is brought to you by Sentry Build Better Software,, diagnose, fix, and optimize the performance of your code. More than a million developers and 68,000 organizations. They already use Sentry, and that includes us. Here's the easiest way to try Sentry. Head to sentry.io slash demo slash sandbox. That is a fully functional version of Sentry you can poke at.

Best of all, our listeners get the team plan for free for three months. Head to Sentry.io and use the code changelog when you sign up. Again, Sentry.io and use the code changelog. Well, we're here with Zach Lloyd from Warp. Zach, thanks so much for coming on the show. Thank you guys for having me. Excited to be here. Exciting week, or last week, I guess it was, for you all. The announcing of Warp, a brand new terminal for the 21st century.

You want to tell us about your launch? It seems like it made quite a splash. I would say the launch went really, really well. Yeah, so last week we went from being in private beta to public beta. We announced the funding that we've raised so far. We had our first press. We had a TechCrunch article. We were, I would say, heavily discussed on Hacker News, which was cool.

We were at the top of product hunts. We were the number one product of the day. And generally, it was awesome. A lot of people trying the app, a lot of feedback, a lot of chat on Twitter. And so we worked really hard to set it up. It went pretty well. Well, congrats. That's no small feat. Thank you. Launches can be very, you can get very anxious during the process, right? There's so much planning involved. And it's like behind the scenes, you've seen the excitement, right? You mentioned a private base. I imagine there's some sort of excitement to kind of keep you going and prepare for it. But, you know,

launches can be anxious, a time of anxiousness. How was it for you and the team? Yeah, I would say there was definitely a bunch of anxiety. The thing with the launch is that you can kind of control the inputs, but you really can't control the outputs. There's just a lot of factors that are sort of lock-in unknowns going into it. So the thing that we sort of emphasized was like, let's do the best job that we can preparing the product for launch. Let's fix as many things as we can.

Let's make sure that we're like on top of handling all the feedback. But then, you know, you post something on Product Hunt, you post something on Hacker News, you even get an article written about it. You have no idea really what the pickup is going to be, what the reaction is going to be. And so I think the most anxiety filled part of it was probably in like the like 20 minutes or so after we went live to see if people would care or not. I think the thing that you really don't want is a launch that people just like don't care about. And that's the sort of the big risk. And so there's a slight period once you put your thing out where it's like, does anyone care? And once we got past that, it was more like, okay, people care and there's a lot of stuff that we have to do to sort of make it successful.

But yeah, it was definitely a bunch of anxiety. What was the care level, let's say? Let's use that as a barometer for the day. I would say the care level was really high. So we were the number one post on Hacker News for almost all day Tuesday. I think we had like almost a thousand upvotes and maybe like eight or 900 comments or something like that, which is a pretty insane level of engagement from that community. And to be clear, a lot, like there was a lot of stuff,

which I would consider feedback or like questions people had. Criticism. Criticism. Like Hacker News is like a, you know, an environment where people say what they think. like hacker news is like a you know an environment where people say what they think and a lot of people you know are not shy about doing that and so as a team taking the feedback trying to figure out like you know what adjustments should we make how should we respond to it was stressful but good again like i said i would much rather have a lot of people interested than people not caring hacker news i would say really really successful product hunt number one product of the day. It's like, I don't know how typical it is

for developer-facing tools to be the number one. Twitter, I think our video, like our sizzle reel has, I don't know, it's like 60,000 or 70,000 views or something like that. We were retweeted by a lot of really like prominent developer influencers and entrepreneurs. And I think people really did care about it. So from that standpoint,

launch was amazing. The one point that was missing was Jared's response back to you on Twitter. Ah, coming on this show, the biggest one. We had, we had one overall goal, which was like,

can we get on change log podcast? And like you guys reached out and I was like, okay, mission accomplished. Well, I have to say that the pump was primed. So had a listener request you come on the show and he is under your employ so i'm not sure if this is part of the launch plan or roshan just thought it was a good idea ah interesting so shout out to roshan for suggesting we have you on now this is back

this came in early march so So I didn't even, it was pre-launch. I didn't know what Warp was at the time. And actually when I saw you guys' launch, it was like the synapse is connected and fired. And I was like, I feel like this has been requested as an episode. So there was some priming that happened there and it all came together very nicely. But in addition to that, the reason why I thought this would be a good episode is because we just recently did an episode with Toby Padilla from Charm. And the Charm team is building tools for text user interfaces and all sorts of command line things. Yep. They're also VC backed. during that conversation, speaking with Toby, a lot of their hurdles are in dealing with

kind of lowest common denominator features of the existing terminals. So they're building inside of the terminals. And to him, Adam and I both said, at a certain point, don't you feel like you should just reinvent the terminal? And he said, we've thought about that. We've talked about that right now. We are not doing that and when i saw warp and there's actually adam has since pointed out a couple other people are trying to do this as well fig i think it's another one i was like well cool here's somebody who's actually going after the terminal itself so that's kind of the backstory on why you got the invite nice roshan plus some timing around the charm episode plus it seems like what you guys are doing is pretty interesting. Cool. What the charm folks are saying makes a ton of sense to me.

And it's basically the attitude that I kind of approach this with and what we're on the team thinking with there is like, what is the best possible product and user experience that someone who is using the command line could have. And if you actually want to get to that sort of end result, I feel pretty strongly the terminal is the place to focus because the terminal is the actual app. And if you're just working within the shell or like within like the CLI, and basically what you have as like the terminal is a sort of fixed rendering surface for characters. And you're just going to be sort of intrinsically limited in what you can do if you're not actually rebuilding the app.

The hard part about rebuilding the app is that it's harder. From like an engineering standpoint, it's harder. Right. From an adoption standpoint, it's harder. Exactly. How do you innovate while still making it backwards compatible is hard. And all these things are hard, but I think that, you know, we're taking a very long-term view here, which is like, what should this thing actually look like? If you were, you know, had a magic wand and we're designing like not only the tool, but also like the platform around the tool.

And so we're just fortunate, I think, to have like the, be in a position where we can build the ultimate vision of this. And I think it will take a while for that vision to become a reality. It'll take a while for every developer to use it. But I think the way that Warp will become prevalent is just by building the best possible version of this experience. The timing aspect of a launch is kind of interesting, too. Because I'm looking on your LinkedIn, and at least by your personal resume, know, resume for lack of better terms for LinkedIn, it says June of 2020. So there's one, I want to talk about timing of like, how long has this been going on? And then two, in terms of like a launch, the hidden ingredient there, which you cannot

control really is market timing. You may have been toiling away for, at this case now, years, ready to launch, announce funding. You know, You're at a place where you can actually welcome non-internal beta users or beta users into the system to use Warp and whatnot. But timing is one thing. But in terms of time, how long has this project been going on? What's some of the backstory? Yeah, so Warp as a company started in June 2020. We spent, so it was me. And then the first person who joined me was actually

the, used to run the design team for Google Docs. My background, by the way, is I used to run the engineering team for Google Docs. I was the principal engineer there. I helped build a lot of Google Sheets. We spent, I would say like the first six months in a mode of like bringing on the first couple of engineers to join us and then doing really a bunch of like prototyping and figuring out what should the product be? How should we build it? We actually built a version, like a prototype thing and electron that we ended up kind of throwing away and

starting over and rust. And I would say like product development in earnest on like the thing Warp today that people are actually using started around the beginning, actually around the end of 2020. So probably November, I don't know, eight or nine months later where, you know, the tool was still a lot of rough edges, but we still managed to get very meaningful feedback from, we had thousands of developers using the private beta. And so we got a ton of feedback on that. And then we felt like it was good enough to go into public beta, which is what we're calling it now. Cause it's, it's still is like, this is a hard piece of software to build and get right. So there's still our rough edges, there's still our workflows that don't work for developers, we have like 400 open GitHub issues. So it's been a

long haul. And it's, it's like nowhere near actually where it needs to be like, it's only one platform right now. We haven't built a lot of like the things that I think are really going to be compelling around teamwork, and even around single user stuff we want to do. So it's just a long slog to build from scratch something that's this kind of app. It's been around for a while. It's been there, right? It's tried and true. There's a statistic out there that says 100% of developers use their terminal.

And I guess a small percentage use VS Code, you were saying, Jared, I'm not sure if that was from Warp or not, but I think Zach wrote that. Zach wrote that. We questioned that statistic, but it seems pretty accurate. Every developer, whether they want to or not, uses a terminal. It's varying degrees, or at least I've never worked with someone who can

get away with not using a terminal. I think the stat was like 60. I think VS Code now has like 70% of the IDE market. Terminal market is much more fragmented and not sort of like. To set up your environment and to install things, you've got at some point touch terminal. You may not use it as your driver,

but you definitely have touched it as part of your flow as a developer to get set up. It's likely, highly likely. What about timing? So we've talked about time involved to get here. What about timing of the market? Like why is now the right time? I suppose years later, of course,

given the time you put in so far, but why is now the right time for someone to really reinvent the terminal? What is it about today or this moment or this time? Yeah, I think that's a great question. That's a really, it's a common question that I get. The terminal has basically been unchanged for 40 years. There's been like a lot of open source projects to try and make things that are within the terminal work better. Terminal itself, that hasn't really changed much. I think that the reason that

this is viable right now is as like with our approach which is like we are a company that has like raised money and built a team and trying to take a sort of from first principles approach to redoing it is basically that we believe and investors believe there's an actual business to build around this and like that i think maybe would not be it's not so obvious and so the thing that has happened recently is that there's like a lot of companies that have taken sort of single user tools and made them collaborative and built businesses that are compelling around them. And I'm thinking of tools like Figma and design or notion for wikis, task tracking tools, linear. And so it's now plausible. I think even like not even more than plausible, just like kind of, I think it's inevitable, but that someone will take the

terminal, make it work for teams, make it collaborative. And that that will drive a bunch of business value, which, you know, is something that you could actually build a team and like have enough capital to sort of really try and redo this. And so that's kind of my answer. You know, the other thing I would say is like, there's a lot of evidence of demand around better CLI tools and better terminal environments. Like if you were to look at some of the top GitHub projects of all time, in terms of like, how star they are, you would see that some them, actually in like the top 10, I think maybe OMIZSH, are things that are just like, let me make your terminal experience somewhat better.

Like, let me give you completions or theming. And so I do think there's been demand around this for a really long time. It's just like the notion of like, you're going to totally try to change the system and rebuild it, probably takes capital. And that's why I think the opportunity is happening now. How much of this was informed by your time at Google Docs?

Because when I think about your strategy, it's very much the Google Chrome strategy, which was ambitious. Of course, they had Google.com, you know, advertising, right? They had a great distribution channel. They did, and it worked. But you're very much doing that. Brand new terminal, install base, zero, right? They had a great distribution channel. They did. And it worked, but you're very much doing that like brand new terminal, install base zero, right? Yep. And you have to get that install base out there. Otherwise you won't have the penetration that you need. Correct. Whereas you could work inside the terminals like charm is doing and work, you know, paper over certain things like people on websites do back when they had, you know, we needed jQuery because the DOM was so different in different browsers.

Yep. Well, Google came along and said, well, we'll create our own browser that, you know, they had lots of reasons to do that. But one of them probably driven by needs of like Google Docs. A hundred percent. And desire to make richer experiences, move faster, et cetera. And so you're kind of copying a little bit from the playbook or at least inspired by it. What was your experience at Google Docs and how does that inform what you're up to with Warp? Yeah, there's a lot in there.

So on the Google Docs side, I think the main things that I carried over were that from like a product perspective and a productivity perspective, the idea of taking desktop software and for Google Docs, it was Office, basically, and just making that live in the cloud, making it cloud native, making it really easy to share, making it really easy to access from anywhere. That model is just, even if your base product isn't even as good, and I think Google Docs took us a long time to get to a base product that was really good. That model is so powerful that I think it's like you could pick almost any piece of productivity software, apply it, and there's going to be some benefits. And like you've seen that, like I mentioned Figma, Notion, like pick a tool. If you make it internet native, if you make it work for teams, it's going to be better. For the terminal, I think, I really believe the same thing will be true.

I think the features might be different. I think real-time collaboration is cool, but maybe not the most important thing for a terminal. But actually, to be honest, it's not the most important thing for Google Docs either. Like the most important thing for Google Docs is actually more sort of asynchronous modes of collaboration where it's like one person creates something and then another person

builds off it and looks at it. And so for the terminal, I think there's all these other kind of modes of collaboration that it's going to be really powerful when we unlock. So that's like the Docs angle. I think the Chrome angle

is really interesting because, I mean, I wasn't on Chrome, so I can't totally speak to their motivations. But I think at some point, Google was just like, look, we want the web to be as good as it can possibly be. And without sort of taking control of the platform and building what they thought would be the best possible experience, they're kind of like stuck to like making these apps marginally better. Now, Google had, like you said, a huge advantage

in that they could not only spend a ton of money building a browser, which is very expensive, and in that sense, Warp is actually not as hard as a browser, but it's kind of hard. But they also have this amazing distribution channel, which we don't have, and so we have to figure out another way to sort of get the product to grow. But yeah, there's similarities and takeaways from both.

You got any plans? Got any ideas? On how we're going to grow? Yeah, because I mean, you got a good splash. Yeah. The changelog episode is going to get you some downloads, but those are one-hit wonders. They're not going to sustain.

So you have to have some sort of way of getting it out there to folks. That being said, you probably don't need 60%, 100% market share to be successful business, right? No, we don't. But yeah, I can tell you the way that we're thinking about it. So there's sort of three prongs to it for Warp about how we're going to grow. So the first is really like something that's called product-led growth these days, where the idea is there will be sort of ways within the product where if you use warp you create something that's valuable not just to you but to people on your team and then you share it and you know sort

of person to person or person to team sharing is to me like if we can get to that that'll be the best way for warp to grow because it'll sort of be growing itself. The more people use it, the more valuable it gets just because like we have collaboration features or we have things that people can do in Warp that are useful, not just themselves, but to their teammates. So that's like one way. And I would say the primary way that we care about. The second way I think is really through trying to build out sort of an ecosystem and extension points, meaning like,

you know, we felt like a very general purpose horizontal terminal. But if we can build things that enable developers to take what we've done, tailor it to their own use cases, build in things that are useful to their teams, or just to the public at large, I think that building like community and ecosystem, plugins, extensions, that type of thing, there's a sort of network effect to that, which could help us grow. And then the third thing is sort of stuff like what we're doing right now, which is like, we need to find ways to get in front of developers, make them aware of the product that could be on social, it could be through podcasts, it could be through us like producing

great terminal content that lives on TikTokok or youtube and just sort of positioning the company as like a leader and like hey if you're doing anything related to the command line you know warp is where you want to be so those are the three ways that i think we can actually get warp to grow and it's working so far like we had a big splash but we're getting you know more and more people to use it which which is pretty cool. Sure. Well, I can speak to the stickiness of Google docs back when it was like the only collaborative office type of thing. And just the fact that,

like you said, that feature alone, like the web native features of sheets and docs, even though office suite was like better native software, which is like, yeah, but I can just collaborate with this so easily. Right. So I just share a link and now we're both working on it. Like that is a viral, right?

What do you call it? Like product-led growth. That is product-led growth. Yeah, 100%. And then B, it's like so compelling that you put up with shortfalls or shortcomings elsewhere just to have that one thing. So if you can get to that collaborative bit and if people want to collaborate inside their terminals like they do on office documents, then I think that is a nice strategy for growth.

Yeah. I mean, the thing is, so I think you also, you can't really start with that for the terminal because I think you have to, it's just hard to get a group of people to adopt a thing at once relative to an individual. So what we've, you know, if you look at the features that we have today, it's actually not so much about collaboration. It's more about like, how do you make the terminal more usable? How do you make it more powerful for an individual just so an individual has some reason to use warp and immediately gets benefit out of it? So there's like this sort of, you got to make it awesome even for individuals to start, I think, for the terminal. Whereas for

like, Google Docs, that was going to be a very hard value prop because, you know, Office had a 20 year lead on terms of features. And like, I actually think the terminal, it's feasible to do it the way that we're doing it because the existing terminal experience, in my opinion, is really not good. And so we can actually sort of get a lot of traction just by like improving that.

And then we can continue to add on features that are for teams. This episode is brought to you by our friends at Square. Millions of Square sellers use the Square app marketplace to discover and install apps they rely on daily to run their businesses. And the way you get your app there is by becoming a Square app partner. Let me tell you how this works. As a Square app partner, you can offer you how this works. As a Square app partner, you can offer and monetize your apps directly to Square sellers in the app marketplace to millions

of sellers. You can leverage the Square platform to build robust e-commerce websites, smart payment integrations, and custom solutions for millions of businesses. And here's the best part. You get to keep 100% of revenue while you grow. Square collects a 0% cut from your sales for the first year or your first 100 Square referred sellers. That way you can focus on building and growing your Square customer base and you get to set your own pricing models. You also get a ton of support from Square.

You get access to Square's technical team using Slack. You get insights into the performance of your app on the app marketplace. And of course, you get direct access to new product launches. And all this begins at changelog.com slash square. Again, changelog.com slash square. so i guess the question is you said the existing terminal experience isn't that good so what's the baseline for what you say the terminal experience is? Because you've got terminal app on Windows. You mentioned you're not multi-platform yet, but obviously terminal is multi-platform. So there's a terminal experience per operating system, Windows, macOS, Linux. So what's the baseline for what you think terminal's experience is not good enough?

What is that baseline? Yeah. So I think the things that are, from a user experience standpoint, not good are it's a hard tool to learn. So when you open it up, you're literally just looking at a black screen with nothing in it. You don't know what to do. In order to actually get it to be useful, you typically have to do a lot of configuration. So it's like the defaults that ship with it out of the box aren't very good. It's a tool that it's very easy to make catastrophic mistakes in. So people will cause outages because they have one

or two characters off and what they're doing. It's a tool where it's totally single player and non-collaborative. So it's like, you're using it on your own. You don't know what you're doing on your team. It's totally ephemeral in the sense of every time you close it and reopen it, you're basically starting over. If you switch computers or switch contexts, it doesn't switch with you. The basic UI paradigms are very weird, meaning like input in the terminal doesn't work how it works in every other app. It's not mouse accessible. You can't click and put the cursor someplace. If you select text and hit delete, it doesn't delete what you have selected. It deletes a thing at the end of the line. If you have multi-line text hitting up or down,

you can't always edit it. The output is very hard to use. It's one just big stream of characters. And so there's no like logical delineation between the different things that you've done in the terminal, even though for the most part, people are using it as a sort of like REPL,

like run a command, see an output, run a command, see an output. And so, I mean, that's, those are just things that I'm scratching the surface with. But if you start thinking about it, I think you're kind of like, why is it like this? Because this is not what you would build if you were trying to build a tool for like interactive text-based apps. So that's my take on that.

It's a pretty good list. I find myself going down the list with you thinking like there are solutions to each individual problem but they're like even those are esoteric solutions you know like you have to discover those things for sure and i think it is like the first one is like nail on the head is like discovering how to use the thing is darn near impossible and takes years to like master a certain part that's why we have like yeah what is it command line food.com and like all these like mastery things and courses and cheat sheets and like all this stuff yeah

everything has a sort of point solution so it's like documentation okay you can like run a man page or you can go to Stack Overflow, completions, you can go to GitHub and install some third-party GitHub thing. If you want to like keep your stuff in sync, you can make a.files repo on GitHub and sync it across computers. It's all just such a pain to do and it's unnecessary. So it's like,

these are the things from a product standpoint that initially just got me really excited about like why is this thing like this and so yeah and by the way you know part of the reason why it's like it just to diverge for a second is the historical architecture of like what is a terminal and what is a shell and what like the terminal that you're using when you open a terminal app on your computer you're running like an app say on your mac that is emulating the behavior of a physical hardware terminal that hasn't been i don't know made or used since the 80s which is it's doing that because that's what the shells and all these command line programs expect

to interact with and so all the shells and command line programs just treat the terminal as a very simple like character input and output device so it's like characters go in characters go out and like the shell can basically say and the draw character on the screen at x place and so that's sure kind of some of the historical baggage of why it's like that. I feel like we need a detox session or a, what do you call it? Like a user group where we all hold hands and talk about what's good about a terminal because I love them

and I agree with every point that you made there. And it's like, why do I like it though? Surely as a person who wants to reinvent, you have a love a love hate relationship with the terminal itself. Like what's good about the terminal? Why would you want to bring that to modernity versus like GUIs? Just throw it out. So that's a great question. So I was pointing out the things I think are wrong with it, but the things that are, are right with it are, it is the fastest way to do a lot of things. So if you're a keyboard person and you want to just use text, it has just ergonomic benefits.

Terminal apps, command line apps, are the easiest apps to write by far. So you always have people writing command line apps because it's just so much easier to write a text-based app than to write a GUI. And so probably more text-based apps are written than any other kind of app. Most of the internet runs on text-based apps. Every Docker container is just running a bunch of shell script underneath that is running, launching a text-based server. And so it's very powerful for controlling those types of text-based apps. Text-based apps themselves have nice properties in that you can super easily script them.

It's really so much easier to program a series of things that are text than to program a bunch of GUIs. They are like composable, meaning like you can easily take the output of one and put it in to another. And so for that reason, it's like it's a super fast, nice, minimal interface where for a lot of the tasks that developers are doing a lot of programs they're running it's like it's the ideal way to do it it's just so much nicer than like pulling open a gui to do it and so i think the command line is awesome in fact one of the like product principles that we started with was like i've always worked with engineers who are really good at using the terminal and the idea was like, I've always worked with engineers who are really good at using the terminal. And the idea was like, can you just make that power accessible to a much larger group of developers

with a lot less work? Because I think that's where a lot of the leverage from building a better terminal is going to come from. As you're going down that list, I was also nodding my head, but at the same time, not emming you at all. I was thinking like, this is an absolutely hard job and i applaud you and the team for taking on this challenge but i think it needs to be done but wow i'm just

taken aback by the mountain that you must climb well i mean what's really hard is like you know we're talking about reinventing it but we we're trying to do that within a world where we are largely backwards compatible like Like we could just be like, oh, we're going to write a totally new system, new terminal, new shell. Everyone who uses it has to start over and Warp's so great, they're going to want to do it. That is not the approach that we took. We took the approach that Warp is going to, as much as possible, work with people's existing shells and their existing scripts. And we're going to kind of bridge people into a better product experience. And so that's actually harder because it's easier if you fully control the system.

You're inheriting the baggage. Exactly. And so, you know, this was a conscious decision that makes it even harder because like we have to support really a lot of things people expect to just work there's an analog that i'm drawing in my mind with databases and the approach that fauna db is taking versus cockroach db which fauna is saying like hey we got a whole new query language and you gotta use it it's great they have the reasons why it's great and then other companies like cockroach is like we are postgres wire compatible, right? Like we have our own language, but also here's the things that you're used to,

because we think that's going to help adoption. And I respect both approaches. Like one puts the stake in the ground and says, no, cause we can do it better if we forget about all this other stuff. Clean break. And the other one says, yeah, but we're not going to get anybody to come along unless they have some sort of path towards that. And so that's a tough call and probably one you had to make early on. Yeah. And I mean, by the way, this Google Docs have the exact same set of questions with office compatibility. You know, there were arguments to be made like, hey, just forget office compatibility. It's a albatross. It's like it's like a cost that we always have to to incur and we can innovate faster

if we put it aside but we decided then and i took a similar approach with warp that it's better to try to bridge people into the experience now i do think you know there's trade-offs yeah it's kind of the simplest way both approaches are cool there's trade-offs but it is a conscious decision that we made to try to to try to bridge people into warp yeah did you consider both paths at one point and say okay well with the bridge we have these benefits and we can sort of predict this future and with without the bridge with throwing the baby out with the bath water we get this you know a brand new approach brand new thing forget everything else did you consider both paths and sort of come to a conclusion or did you just sort of like go one direction no we we considered both so what it would mean for warp to not be compatible i really think is probably we would write our own shell right and we may

eventually do that the real downside well there's a bunch of downsides to doing that. The downsides are people having existing configuration and setups for their shells. So we'd have to have some way of importing that, which I think is maybe, actually maybe doable. The real thing that's very, very hard with it is the remote shell use case, where we want Warp to work if you are connecting to a remote machine and the person who's running warp on their Mac might not actually be able to install or configure anything on that remote machine. And so that sort of necessitates some level of compatibility because sort of SSH and remote work is, is important to people who use a terminal. And so that kind of made the decision, okay,

let's start with the compatibility approach. And then I think at some point, we will write a shell at some point. And I just think we'll have to, we'll probably do it at a point where Warp has enough traction that we feel like we can ease people into that rather than betting

sort of the whole product experience on it. So you set out to build a terminal, you're making these hard decisions at the time we got to make them. But what is that process look like? So I like ambitious people and the way they take on projects. I just, I appreciate it. I like to think, how did you come to this decision?

And then the next thing I think is like, and then what did you do next? You know, because here you stand, you know, I think I just said this last episode, Adam, or maybe it was on a different show. How do you eat an elephant one bite at a time? It was kind of like, well, we take that next step. But you also got to decide which part of the elephant you're going to bite off first, I guess, if you're going to keep the analogy. Like, when you face this mountain that Adam's described, I'm going to build a terminal from scratch. Yeah.

What do you do next? Like, what do you start building first? Yeah. So, okay. So, it's a great question. So we started with sort of the fundamental UI things in a terminal. So we started with like what people really do in the terminal. They, you know, they work with input and output is the predominant use case. There's a second use case, which we actually don't do much with right now, which is like

they run like full screen terminal apps like Vim or Emacs or something. Warp right now doesn't do, there's not much special in Warp with those apps. But for the type of usage that we were looking at, which is like, what do people do all day in a terminal, they run commands. We were like, what is that fundamental experience like? And how could it be better? And so we started thinking about like, well, on the input side, for instance, the input editing experience is not good. Like what would actually be like a very good input editing experience? And we decided it would be something that's much more like what you would get in VS Code, basically.

Like why isn't that experience exists in the terminal? On the output side, we were like, what are the problems with it? And, you know, it's sort of like what I talked about before. It's like you can't really tell what command produced what output. So that means you can't like navigate around your terminal on a command by command basis or copy paste what you want or share one specific thing you did from the terminal. And so we took inspiration from VS Code for the input. We took inspiration from notebooks for the output where you have structured sort of sequence of things you do. And then our bet was like, you know, if we're doing this for real with a long-term vision, let's just start with the fundamental things and try to like make them as good as possible. And so we had ideas around that because we're developers and we use

the terminal every day, like nonstop. We talked to a lot of developers about this. And then, you know, our goal right at the beginning was like, we need to get to a feedback loop. So when you're like starting a company and like, we knew we had to build for a while before we'd have even something people would give us feedback on. So we did that. But then the first big milestone was like, can we ourselves use it was actually the first one. And then secondly, it was like, we had external people giving us feedback. And now that we have a lot of feedback, we're in a mode where we're much more easily able to do like sort of planning and prioritization based on what users are saying. And so that's like, you kind of get into a mode where it's like, it's no longer just us guessing,

it's more like, we know users want X. And so we can sort of prioritize those things. And somewhere along the way, you also had to select the technology choices. You said you started off in Electron and switched to Rust. Do you want to tell that story? Yeah, so we were, you know, my background is engineering web technologies. Like, that's like what I know best.

First couple of people we hired were also coming from that background from Google and other places. And so we started off in Electron using Stack, we kind of knew, and then we made the decision to switch to Rust because we thought that would produce a much faster app. The app in Electron was kind of slow. And my experience from docs was that you pay a very big performance penalty when you use the web platform, like web platform is awesome in a lot of ways. But, you know, we spent so much time on say, Google Sheets trying to optimize like, what should the memory layout be

for a spreadsheet cell and like web platform and JavaScript, you actually just couldn't control it. And so it became it was very hard to build a high performance app and so the reason we chose rust was primarily performance second to that it was performance with like a decent actually not a decent like a really nice actual like language design which you could be productive in and so rust is it's not quite as easy to work in as like TypeScript or Python, but it's really ergonomic and really like you can be very productive in it. And then thirdly, Rust had like a great cross-platform story for how we want to eventually do cross-platform, which was we do want to support the web. We do want to support Linux. We want to support Windows

and Rust can sort of cross-compile to all of those. And so we ended up just thinking that for the best product experience, that that was the way to go. Cool. And it sounds like you were using some other open source stuff as well under the hood, one of which surprised me.

We had them on the show. NewShell. Is NewShell like a part of Warp? No, not... So we worked with... Or just for inspiration. I'm on your readme looking at your open source dependencies so there is well it's slightly complicated we

worked pretty early on with one of the uh creators of new shell andres uh robolino and he actually helped us build out some of our completion engine using some piece of, we basically forked a little bit of new shell code and turn it into like terminal completion. But we don't, yeah, we actually work, unfortunately, at the moment doesn't really natively even support new shell. It's something we would like to support. New shell is a pretty cool product, but it's also, it's built in Rust. And so we have a relationship with them. Gotcha. Yeah. I was just looking at your open source dependencies and I was like, I thought there's no shell inside yet, but you're going to have your own shell eventually. But then I saw a new shell and I was like, wait, is there a shell in there?

It is it. We run right now bash, CSH and fish are the shells that we support. Okay. So my next line of questioning is around kind of the user experience of what's currently available. But Adam, do you have anything else on the history of that or the architecture that you want to squeeze in here first i think just recapping really the how it works from the from the site really you know warp is a fully native gpu accelerator i think you know talking about gpu acceleration while that's important those are part of user experience obviously there's a reason you chose, but the reasoning for being 60 frames per second friendly on 4k screens, why no electronic kind of answered that. Why web tech

obviously being web native, but the GPU accelerated and the 60 frames per second, I think can use an explanation in terms of the user experience. Sure. So we're truly like full stack native app in Rust. And we so not only is like our terminal code written in Rust, but we actually have our own UI framework that's written in Rust that interfaces directly with Mac's graphics library, which is called Metal. Metal is sort of like the OpenGL equivalent on Mac. Again, this was all done from a user experience standpoint

to I think think, terminal. Terminal needs to be fast. The things that are likely to be slow in a terminal are really like rendering a ton of text. So laying out rendering text can be very, very slow. We had that problem on Docs. And so just being able to do everything directly on the GPU through our own UI framework makes it, from a stack perspective, as fast as it can be. You can still write slow code, whatever stack you use, like you can write an algorithm that runs slowly, but we're not limiting ourselves by like the actual sort of framework that we're working in. The other reason we did it that way is like, when we do go to like Linux or the web,

it's pretty clear in our code what parts are platform specific. And so for instance, on the web, rather than using Metal, we'll use WebGL to do the rendering. So that was like why we picked the technical architecture we did. So how heavy a lift will it be when you decide to do Warp for Windows?

Will it be 30% of the existing code rewritten or 60 like probably more like 10 okay so probably like probably like 10 of our code is platform specific and so the code that's platform specific is is the rendering code it's like the windowing and event handling code it's the things like system notifications and build pipeline and that type of stuff. But I would say 90% of our code is not platform specific. That's a good percentage. Yeah. I mean,

it's like most of the stuff is like about the terminal, not the platform. I would feel pretty good about that. 10% of our sitting where you're sitting. That's a good number. I would expect you to say 30. So 10 is actually pretty nice. Yeah. So for most products, you go iOS, then Android, nice yeah so for most products you go ios then

android you either go windows first or you go mac and then windows and then like linux is always like the thing that you're quote-unquote working on but for developer terminal tool you almost think like linux is actually a pretty important platform for you guys right you almost might want to do that one next what are your thoughts linux if you look at look at our GitHub issues and you sort them by number of requests, Warp for Linux is number one. So from what users are asking for, Linux would be next. I think Windows will be last.

I don't know if Linux will be next or the web will be next. Those are the two that we would potentially do next. Of the two, Linux would be easier and users clearly want it. Web, I think, is maybe more interesting for us from a product standpoint, from like what are the sort of features

that are unlocked if you have a web-based version of Warp. And then the reason we started focusing on one platform is just like I would rather have a killer product on one platform than like a okay product on three. And so it's just like, it's faster to iterate on, you know, getting the product perfectly right on one platform before we spread out. Well, I think your move away from Electron pretty much made that bet, right? Like you just, you made that decision at that point.

We made a bet. By the way, that bet I feel, I feel 100% that we did the right thing with that bet, right? Like you just, you made that decision at that point. We, we, we made a bet that by the way, that bet, I feel, I feel a hundred percent that we did the right thing with that bet. I don't think developers want an electron based terminal. Yeah. Hmm. I guess, would you get the GPU acceleration? Would you get the, you know, 60 frames per second, you would lose that electron. It depends how you did it.

You could always technically run like a web gl app in electron which is a very contorted way of doing it but it's like that's actually a figma if you look at like what they do their code base i believe is c++ and then they compiled a web assembly and what and web gl And then they run that, like their like Figma desktop app is running that WebGL and WebAssembly stuff. And so you can get good performance, but you basically would still be doing it via like a native code path.

This episode is brought to you by our friends at FireHydrant. FireHydrant is the reliability platform for every developer. Incidents, they impact everyone, not just SREs. They give teams the tools to maintain service catalogs, respond to incidents, communicate through status pages, and learn with retrospectives. What would normally be manual, error-prone tasks across the entire spectrum are responding to an incident. They can all be automated in every way with FireHydrant.

They have incident tooling to manage incidents of any type with any severity with consistency, declare and mitigate incidents all from inside Slack. Service catalogs allow service owners to improve operational maturity and document all your deploys in your service catalog.

Incident analytics allow you to extract meaningful insights about your reliability over any facet of your incident or the people who respond to them. And at the heart of it all, incident runbooks, they let you create custom automation rules to convert manual tasks into automated, reliable, repeatable sequences that run when you want. They can create Slack channels, Jira tickets, Zoom bridges instantly after declaring an incident. Now your processes can be consistent and automatic. The next step is to try it free. Small teams up to 10 people can get started for free with all Fire Hydrant features included.

No credit card is required. Get started at firehydrant.io. Again, firehydrant.io. And by our friends at MongoDB, the makers of MongoDB Atlas, the multi-cloud application data platform. Atlas provides an integrated suite of data services centered around a cloud database designed for scale, speed, and simplicity. You can ditch the columns and the rows once and for all

and switch to a database loved by millions for its flexible schema and query API. When you're ready to launch, Atlas layers on production-grade resilience, performance, and security so you can confidently scale your project from zero to one. Atlas is a truly multi-cloud database. Deploy your data across multiple regions simultaneously on AWS, Azure, and Google Cloud. Yes, you heard that right. Distribute your data across multiple cloud providers at the same time. The next step is to try Atlas Free today

and have a free forever tier. Prove yourself and your team that the platform has everything you need. Head to mongodb.com slash changelog. Again, mongodb.com slash changelog. Well, they say if you're not embarrassed by what you ship, then it took you too long. You guys launched, had a great response, a lot of interest. If I'm picking up a little bit of your vibe, it's like still early days. You're putting that out there. Fair enough. You know,

get it out there. Yeah. Obviously there is a warp.app you can go out and get on macOS today and try public beta. Whenever you compare a thing and maybe consider adopting it, you compare it to what you're currently using and you're like, okay, which one's better? Which one do I like more? And while the future, I think, is bright, there's a certain feature set today of what it looks like, how it works. Is there anything in there that's like killer right now

that I'll be like, okay, I got to try this because it has this thing that my terminal doesn't have, even though it may not have the collab stuff yet and some of the stuff we've been talking about, what's WarpLite today that will get people excited to give it a shot? Yeah. So the feedback that we get as far as like what people love the most today are actually the most basic features we have, which is input is a real text editor, which means fully mouse accessible selections work, you can do multi selections, you can do multi line, it's just like much nicer experience to edit a command and warp.

The second thing is a feature called blocks, which when you run a command and warp, we give you something that looks like a notebook output, where it's like, the command and its output are connected together. And you can do things like copy paste the output you can create a permalink of the output which you can then share to anyone on your team or put in a wiki or whatever so basically anything you do in warp today you can opt in to share it we have awesome features around command entry And so we ship with about 500 built-in completions, where we give you visual completions as you type things in a tab. And we don't just give you completions, we give you inline documentation, which is super cool. We have a feature called

workflows, which doesn't exist in any other terminal. And the idea there is, it's basically a searchable library of saved commands for things that would be annoying or hard to figure out on a word by word basis using completions. So like a good example is, how do you undo your last git commit, I always forget how to do that. And so for workflows, there's a specific workflow, like it's like git reset dash dash par carrot head or something, where you can now semantically search for workflows. You can save your own, which is really cool and share them with your team. So if your team has a bunch of like private commands that they typically do that are hard to remember, you can bake them right into warp and keep them up to date that way. And then we have one really amazing feature, which is,

it's called, it's basically natural language command search, which uses OpenAI codecs. So kind of like, if you are familiar with like Copilot and GitHub or something like that, we have something where you can opt in on a command by command basis to ask OpenAI to generate your commands. And that's really, really cool. And it works actually like remarkably well. So those are all, I would say, reasons to use it today. Beyond that, it's just like,

it's a much nicer, more polished terminal experience. We have like a command palette. We have built-in themes that are super nice. But if I had to summarize the pitch to a developer right now, it would be like, Warp is like something that's going to make you significantly more productive without breaking your workflow

with a big asterisk next to it, which is that there are certain workflows that we don't yet support because we're public beta. And so, you know, for instance, if you use like Tmux, you're probably not going to get a ton of value out of Warp right now. And we are, you know know working through things that don't work that well to try to make them work better for everyone what's it going to take to support vim emacs tmux things like that so vim emacs tmux just to be clear they all work like if you run

vim and warp you get the exact same vim that you would get in like your normal terminal app. Tmux, I say, like needs more work because when you run Tmux, what happens in warp is it basically takes over the full screen and you lose all the cool features around better input and output that you get with warp. And so for Tmux, we're either going to sort of build something on top of Tmux that gives you the warp features, or we're going to basically replace that Tmux functionality with something that's native to warp, which I think is the more likely way that we would do it right now. So it's going to take some time for us to support the full range of tools that people use totally natively.

But I would say for most developers today, you're not going to hit one of those issues, but there are some people who will. You were saying, too, before that one of the user experience issues that you kind of encountered was this blank screen, which is a challenge for those who are new to terminal or those who don't use it too often. So dare I just say newbie or someone who doesn't use it that often, a novice in it. Whereas I'm curious, like this roadmap you're focused on, is it focused on more of like, I currently use terminal and I'll get benefit from these initial features. So it's easy to adopt,

or is it more like attract those who never have used terminal? Like if you had to skew your percentage of focus, would it be on the current terminal users, but maybe not like the team mugs Vim users who, cause cause they're obviously not supported right this moment. Or is it more like brand new to terminal focus features? How would you skew that? It's professional engineers.

So it's people who are in a terminal who depend on the tool, who want a better experience from it. There are going to be some people who are like, the current terminal is perfect. I've spent the last 20 years learning it and I've configured it exactly to my taste, who probably are not the initial users

that we want. But we're building this primarily for professional developers who want to be much more productive and effective in the command line. That said, we do have a lot of people who are like college students or in dev boot camps who terminal is a very unapproachable tool. Warp is a much nicer experience for them. But we're not, we're explicitly, you know, trying to build something that is primarily targeted at people who need to be in a terminal a lot and will benefit most

from these types of productivity gains. So I've been using it off and on here today and as we talk. And the blocks feature is, I guess, a little difficult to explain just in conversation, but it is really cool after you issue a command let's just do a basic ls and you know it lists the things in the current directory well that whole the input the command and the the directory listing are blocked off with like basically a horizontal rule you know

a border a one pixel border basically for web dev talk. And you can highlight them all together. And then on the upper right, there's the three dots, you know, menu. And you click on that, you can copy the command, you can copy the output, you can copy them together. And so it treats them as this almost atomic unit. And that is a cool thing. It looks nice.

It actually encapsulates mentally as a person who's been using the terminal for 20 years the way that i think about it anyways and so yeah first run from that perspective from a professional is like this is just a nice looking and has some cool ideas terminal as it stands today now the one thing that kind of stopped me on first launch is sign up with GitHub. Yeah. That to me seems like a business part of Warp and not really like for me. Is that for you or for me?

So great question. This is one of the things people gave the most feedback on on Hacker News. Short answer is it's for you. It's not so much for us in a sense that, but it's a little bit more about where we want to go than where we currently are. But the place that we want to get to with Warp is that there's a reason that like, we need to know who you are in order to keep your things, sync them across computers, make it so you can work with people on teams. And if we don't have a sense of like who's using the product, I think it's just really hard to do that.

There's some use cases that you can do anonymous, but what we're trying to do is build a cloud-native terminal that works for Teams. And without someone logging in, I think it's going to be very hard to move past just basically to get to that product experience but it's it's a question like you know we we got a lot of feedback on this especially on hacker news full honesty if i wasn't compelled to do it because i want to talk to you about it i probably would have deleted it right then because i have a terminal that's pretty good in my opinion yeah and i don't need to sign into it yeah and so when i have to sign into i probably would have stopped but i pushed through because i really wanted to try warp and once i I got in, I was like, this is cool. I like this, but I probably wouldn't have gotten this far if I wasn't

talking to you about it. Yeah. Yeah. So, I mean, just like we're, we're, we're talking about this. This is literally like the thing that I, before I got on podcast. Had some meetings today. Yeah. I mean, I'm like trying to put together my thoughts on what makes the most sense. You know, my sort of feeling here is that anytime, you know, you've tried to facilitate the move of something from like local to the cloud, there's going to be some uncomfortable moments where people like, I don't want this, I don't want anything to be like, I don't want to log in, I don't want any like facilitation going through servers or anything like that. My feeling is that from a product perspective, ultimately the benefits of the collaborative model and the cloud model always are big enough to justify like a login or something like that. I also want to be super clear, like, Warp is not sending or storing any of your commands to our server. Like we collect telemetry, which was another sort of

thing that people were pushing back on AcroNews, which I understand. That's all metadata around like, hey, did a user do a split pane? Or hey, did a user open the command palette and the intent is to understand how people are using the product we don't store any of your command data any of your output anything like that we don't want to store it's too sensitive but uh yeah my sense is that ultimately to get to the best product here we're going to need people to log in but i will say that we are discussing this pretty actively on the team right now and so i I don't quite know. I don't know exactly where it will land. I understand the concern, by the way. I have a somewhat of a theory, and it's just really based upon your own words. And in one case, like the reason why you've gotten here is because you looked at the landscape and you said,

when I look at developers doing their thing in their work environments, they're using two applications. They're either using VS Code or something like it. Yes. Or they're using Terminal. And so when you look at those two applications, well, VS Code itself doesn't, last time I checked, at least maybe it's changed, I don't know. It's not a daily driver for me. But the last time I checked, it doesn't require you to log into it to begin to use the application.

So I think there's a case for, especially on the adoption front, like if you want to be the Terminal use no matter what, if you have the need for the team features, sure. I think there's an opt-in and then obviously signing with GitHub totally makes sense. But I think for adoption, just simply for adoption's sake, if you want to be the terminal of the future, current terminal doesn't require to know you. Right.

Know your customer, you know. KYC is a big thing, I think, in this current world. KYC is a big deal. Yeah, so in this current world. KYC is a big deal. Yeah. So it's like we could do what VS Code does, which is I think the moment you have to log in on VS Code is maybe the moment you want to use like live share or something like that. I'm speaking for myself. I think that's a bad product experience. And I think it really limits the utility of any kind of sharing feature

if you push it off until really late in the experience. I can't think of another like sharing-based app where you don't log in. I mean, VS Code is a good example. I just think it really makes the experience worse. And it also creates a speed bump at the actual time where I want to create the most value for people using warp which is like okay someone wants to like collaborate and it's all of a sudden you're putting a log in front of them

that said i have no doubt that we would get more adoption if we did what you said adam where if we just made um sort of log in optional i just i don't know that it sets us on the path to building a really great sort of collaborative cloud connected terminal. So we're weighing it. It's kind of a short answer. Yeah. Yeah. Well, that's part of the journey is figuring that out.

I think Jared's sentiment, I concur on that. Like that was my first thought too. Like initial, like what I want to see from the terminal of the future is the terminal, not a request to show you who I am, which I totally understand your reasoning for from a product standpoint. Right. Totally get that.

We're going to figure this out. It's really super interesting. Yeah, I mean, I think if the collaborative features existed today, then the justification exists today. Like if you launched with Collab and it was like cloud native immediately and you put a little note there and it's like, hey, this is so you can actually do what the thing does. But the fact that it's like for a future makes me think this is so you can know how many people have it installed. And I can get cynical and I'm pretty typical developer in that sense because it's not by it's not winning me anything today and i actually like

that flow when it's like just in time when it comes time for me to use collaborative features hey you would sign in you have to have an account to do that now i actually have a justification i'm like okay because it's not even like the github sign-in thing that irked me as much as it is like i like to open up a terminal and see my home directory, you know, this is great feedback. All right. I mean, I don't know what we'll do on this. We're taking all the hacker news feedback and bringing it to the podcast. I didn't read that thread. I did not read the hacker news thread. I swear. This is all said with love. This is all love and respect.

My goal here ultimately is just to do the best thing for the, for people using the product. Yeah. So I I'm totally down to hear the feedback thing for the for people using the product yeah so i i'm totally down to hear the feedback and i actually like hearing your viewpoint on like you wouldn't mind a speed bump at the time of doing the collaboration i get that if you i get what you're saying i don't know what we're gonna do it's gonna be a spirited discussion within the team on this even a short-term move put a little note there just put a note up that says why and even if it's like we promise this matters but not right now but just go ahead and do it like something like that might even be

like tongue-in-cheek about it that's coming that'll be there within a couple days actually gotcha on that note though that would be a great spot to point your roadmap to like make your roadmap more public if it's already public yeah it's like hey this feature and this is the dream which i think is kind of what we've done in the shows, like what's real today for warp and what's the dream, you know, what's the feature you're driving towards. And I think that's part of your narrative and your story. And if you share that with developers who are inherently not very trustworthy, inherently semi-cynical, like Jared is suggesting here, you know what I mean? If you incorporate them into your story, they're going to, they're going to believe in what you're doing so much more it's so interesting i mean because that is

not my default sort of outlook but it is like i think the default outlook of a large percentage of developers and so that makes a ton of sense tell them your story yeah i think i agree with that 100 and like the terminal is so close to us you know like it's yeah it's inscrutable it's got a lot of problems like you've stated but like once you're lived there day in day out like it's a pretty close-knit tool and so i even switching terminals is kind of a big deal and like if i switch to warp i want it to be my terminal for N years, right? Like, and if I feel like, well, it's tied, and maybe we can get into the business proposition next, because I feel like if warps success is tied on the business's success, that also gives me pause, even though

knowing like, I just go back to terminal.app, life would go on. Yeah. But I think also is like telling warps story, not just roadmap, but also like, is this terminal.app, Warp.app, is this terminal application require VC hockey stick growth? Because as a person who's been a developer for 20 years, I've seen so many businesses come and go. And so many tools that I love don't exist anymore. In fact, somebody in our change out community Slack was just lamenting today that one of their favorite tools just disappeared. No reason why the servers are gone, the website's gone, just gone. And so these are things that, you know, it's hard not to be cynical over time, just because not because of bad intentions or anything

like that, just like stuff fails, and then we're left in the lurch. And so some sort of sustainability story, I think is also important. Yeah, I mean, so I think that the thing for that that makes the most sense, which, you know, we're not yet open source. And I think like if we were to essentially open source the client, I think that would probably go a long way

towards alleviating people's concerns around like, is this thing going to go away? I don't want to like publicly fully commit that we're going to do that, but it's probably something that we're going to do. It's certainly something that I think there's a lot of, it actually aligns our users' interests and the business interests in a lot of ways.

Like it gives people confidence that the app is like secure. It's not doing anything nefarious, that it's not going to go away. So I think it is a thing that we will do. I don't want to 100% say like, because we just haven't decided the strategy, the timing, all of that. But I think it's something that makes sense for us to do. Yeah. I guess just for me to ask you, as a potential user for a second, is that is open sourcing sort of the thing that would give you the most confidence when it comes to your

question here? Yes, I think it would. I'm not sure if the client alone would give you the most confidence when it comes to your question here? Yes, I think it would. I'm not sure if the client alone would give me confidence, depending on how much becomes collaborative requirement, right? Like what was the old Google Docs competitor as Etherpad? Yeah. Well, when Etherpad died, they open sourced it, and that was awesome. But unless there was an Etherpad service,

did it really matter? Like people could stand up their own. So like maybe like some sort of statement like by the way if warp the company disappears we'll just open source all the things and you can do what you want like that actually makes me feel pretty good you know like that's a pretty good feeling like okay if they die it'll open source and we can do it if the company goes away you can we'll give you the server too i think makes it makes sense. Right. We may even, again, it also might make sense for us at some point to just let people stand up their own Warp backends.

We don't have enough in the backend right now, or I think that totally that makes sense. Sure. But I could see a self-hosted version of Warp being something that companies want. So I guess I would just say this is all early. The concern makes a ton of sense. I think we need to figure out our story around it and kind of go from there.

Hence the mountain. Hence the mountain. This is going to be a long-term thing, but it totally makes sense what you're saying. Yeah, yeah. On these notes then, what does it take then for the company to be successful? So you're venture-backed. I think I read $28 million in funding. Is that right?

Or was it something $20 million? We've raised $23 million. $23 million. I saw, I turned to $3.28. My bad. So $23 million in funding. Is this a seed funding? Is this Series A?

We've raised both a seed and a Series A. So seed was in 2020 and Series A was in 2021. Okay, gotcha. So total raise, what's rough total raise? I'm not on your crunch base. I don't have your numbers in front of me. I, gotcha. So total raise, what's rough total raise? I'm not on your crunch base. I don't have your numbers in front of me. I'm just curious. The total raise is 23.

So that's counting both rounds. Okay, both of them. So 23 million of funding. We want a terminal for the future. So this is a desire of the developers. Totally. At large, whether they say so or not. So obviously that's why you're on this map,

on the roadmap you are. Now, given that future, given that desire from us as developers, what does it take for, one, you to create the technology, and then, two, sustain as a business? What is the business's roadmap in terms of being successful? Sure. So the business we're trying to build is an enterprise business. We're not trying to build a business where we charge individual developers for using a terminal or for buying licenses, it would be much more similar to something like Figma or Notion where for individuals, totally free. And then we're hoping to add a sort of a class of features that are around collaboration and firefighting and securing the terminal and customizing the terminal to a company's internal workflows

where businesses will want to pay for their development teams to have work. So that's the ultimate place that we're trying to get to. I think there's definitely a future in that. I like the aspect of Notion. I've been using Notion a lot more. I've been a Notion user for a long time, but hadn't fallen in love with it as much as more recently. And that's just after bouncing from one tool to the next and realizing just Notion does most of what I needed to do better than like four different tools separate. And I like the aspect of Notion because we have a changelog team or workspace or whatever the terminology they use.

And then I have a changelog team or workspace or whatever the terminology they use and then i have a personal one not that i necessarily need it because you have private but just for that encapsulation and i like the fact that it's free that being said i can see in the dev space where smaller teams like changelog for example we're a pretty small team we're not an enterprise you know we would still pay for desire to pay for 100 bucks a month or something like that for our team. Do you have an idea of what your team sizes might be? Curious about how that maps out into actual plans. Yeah, I think smallest team I could imagine using it would be two.

The sort of how much you would charge, what the exact feature set would be, basically the mechanisms of this or something that we're trying to figure out over the next six months. But yeah, I also think some of the team stuff that we're doing would probably be free as a way of like helping people understand the power of it. So it's a little bit TBD. It's not our focus right now is not on so much on monetizing

as it is on just getting the basic user experience to be something that people love and want to share. Yeah, I think you have to start there. You have to start with literally the terminal of the future, making it accessible to everybody, invitation and everyone can use it. Obviously, it's Mac first right now. Linux is likely next.

Yeah. Then web native and then Windows. But I think that's the better approach because there's a lot of virality in the way Dropbox even rolled out. Workflows, I can imagine, will be a quite viral feature for you. I see commands.dev, I believe, is something you have that's sort of pulled from. I don't know what that is necessarily. It's a web-based version of looking up all our workflows.

Right. So, I mean, I think there's going to be a virality to that, which will help you with adoption, which will help you with marketing, basically. Who are you? Why should I use it? Is it truly the future? And I think that given that, I think you'll get there. I also think it's quite smart to focus on the enterprises being the boon of the funding and the success, because I think that's going to be the easy grab, honestly. Cool. Zach, we've taken a lot of your time. Is there because I think that's going to be the easy grab, honestly. Cool. Zach, we've taken a lot of your time. Is there anything we've missed?

Anything left on the table? Obviously, this is the start of Warp's story. If you haven't been paying attention yet, it is. And so there's lots to come. But for this conversation, anything left unsaid? No, it's thank you guys for having me on. I think this was a really, from my perspective, super interesting conversation.

It's good to hear your guys' feedback as users as well. I guess one other thing I would want to get across is, so Warp is growing, we're hiring. We have a ton of interesting engineering challenges that folks are working on. We're a remote-first company. So if any of your listeners are interested in what we're doing,

I would encourage them to check us out at warp.dev. Very cool. Yeah. Well, here them to check us out at warp.dev. Very cool. Yeah. Well, here's to the terminal of the future. Hopefully what you're building actually is that. I see a lot of promise and possibility. So hopefully all this comes to fruition. And a year or two from now, we're having a different conversation,

which is like, okay, you're winning. You've won. What's next? So I look forward to that. Let's do it. Yeah, I love that. Zach, thanks so much, man. Well, thank you so much, guys. Appreciate it. Alright, this show's done. Thanks for tuning in.

What do you think about Warp? Are you going to try it out? This is something that's very cool. Written in Rust, meant to be super fast and meant to be forward-facing so we can take what is known as the Terminal into the future. What are your thoughts on this? Let us know in the comments.

Links are in the show notes. And I want to mention our master feed. If you haven't yet, you can get all our pods in one single feed. It's the ChangeLog universe as it's known right now, all in one single feed. ChangeLog.com slash master. Get them all. And I want to thank you for listening to this show. Seriously, we love you.

Thank you for coming back. If you haven't subscribed yet, easiest way is to go to changelog.fm and subscribe and if you're a long-time listener we really really appreciate you tell a friend about our show if you love our show mentions on twitter are such a big deal lots of retweets lots of new listeners come that way we love that and we always engage and we appreciate it and last but not least i want to thank our awesome partners, Fastly. They help us make this show super fast globally to download. They have an awesome CDN and we absolutely love them. Check them out at fastly.com. And as you know, we love our beats from Breakmaster Cylinder.

Those beats are banging. Thank you, Breakmaster. Thank you. And that's it. This show's done. Thanks for tuning in. We'll see you next week. Thank you. Game on.