Bringing Atuin to the desktop (Interview)

27:49It's going to be quite a low amount. And we can't charge very much for it. So it's quite a niche, realistically. It also really doesn't cost very much in terms of infrastructure to run. I self-host the Postgres on a Hetzner machine. It's cheap. It's really performant. And other than my time, it's not a big sync. Desktop, I think, has a lot more potential in terms of business project. There's a very direct organization use case, potentially even stronger than the single player use case, really. And there's a lot more scope to do really interesting and flexible things with it. It is open source.

28:26It's Apache 2. What is not yet open source is the hub for syncing. um so we have two types of workspace you can have an offline workspace gives you local files on your disk you can put them in git like whatever you want basically um but the hub is the synchronizing real-time back end and it's not open source right now basically we haven't figured out what to do with it yet and i would very much rather have something closed source and then six months from now decide to open source it then open source something realize I've backed myself into a corner and then have to do a horrible license change.

29:03And it's a nightmare. Yeah, what we say around these parts is rug pull, not cool. So definitely keep your cards close to your chest. And then if you want to flip one over and show that you get the ace of spades later, fine. Go ahead and do that. And I feel very strongly that if you're running it on your machine, it should be open source. Like if it's a desktop app, you should be able to see what's going on. You should be able to change it. Yeah, I think that's a good distinction. That's a good place to draw a line in the sand, I think. And I think you're right because when it comes to run books, I just feel like anybody who's playing single player don't care that much about something like this because they got their scripts.

29:38They might have a notion or obsidian and they're just like have their docs in there if they write down or it's all living in their head. Like usually when you need a run book, it's like, hey, I put together how we do this. Now we can all run it when I'm on vacation or whatever happens when it's your turn to be working and not my turn. And so it's almost de facto team, right? Like it's going to be collaborative. Obviously there's the outliers who will be using it because they just like your software or whatever, or it's a prettier way to, to manage their own docs and scripts. But for the most part, I do think it's going to be something that organizations will adopt.

30:12Whereas the CLI is like, just like hackers and nerds, you know, sure they work in an organization, but it's going to be harder for them to get their org to, you know, sponsor. exactly and like the only the only real way i could see the cli applying to an org is like share your shell history with your team which i don't think anyone's ever going to want to do because it's weird yeah it is kind of weird it's like at first you're like that'd be great then you realize all the things you type i don't know it's like my team seeing my browser history there's not anything weird there i just don't want to yeah it just doesn't it's just useless and maybe embarrassing at times you know you're like sometimes i type things that is wrong you know or I feel like a command is going to work and it doesn't.

30:50And it's like, there it is. It's in my shell history. Absolutely. We have heard a lot of people ask about self-hosting it, which is something I really want to support, but there's also the other angle of supporting it. And I found with the CLI that it's self-hostable and has been for forever. And it's tricky to support people. Generally, the Docker Compose we provide works, but a lot of the time people want to run it differently. They want to do their own thing with it. and supporting that's super hard. So we're now kind of at the point where it's like, unless you're using our Docker Compose and it doesn't work, I probably can't help you, mostly from just a time and energy perspective.

31:28With a desktop app, I wouldn't really want to be in the same place and it is a lot more complicated to run for the backend. So if we do open source it and I would like to, it would definitely be like, you can run it, it's on you. Yeah, that makes a lot of sense versus like a GitHub Enterprise thing where you're going to go install it on their premises and operate it for them. Yeah, that makes sense. Did you, going back to the CLI and potential monetization, people are desiring to give you money, you know, and that's because they love the work that you do. And I've seen that online, just the response to it as almost universally positive.

32:10It's very good software. People love it. They seem to love you. and they just want to give you money and did you try even just turning that lever on like even though it might not be your end goal or something that we had we had for a long time and what about the self or the host like let me give you a two bucks a month to to do this i think that changes what it is maybe someday i will but i think realistically it doesn't cost me very much to run and i'm quite happy providing it as just a just a thing people can use um okay the two bucks a month i mean i i guess but then it becomes uh like supporting people because there's suddenly like you know they're paying their actual customers it's it's a strong expectation there but we haven't had any downtime in like a year so probably be fine probably sounds like you designed it pretty well and it's relatively uh efficient like you're not having to constantly be working on it and maybe upgrading whether it's vertical or scaling the other way so that's nice remember when radiohead came out with their in rainbows album and it's like pay what you want and i don't think free was an option on that one but basically i mean you could do something like that where it's like it's between zero and n dollars where n is whatever you want to give me but zero is what it costs i think you have a not insignificant amount which could also be called a significant amount of money, you know, maybe put some, put some, uh, petroleum in your motorcycle or something like that.

33:40It's quite expensive these days. It is. It's not getting cheaper. Yeah. I think honestly, for me, it's like, I want to, I want to explore what we can see, what we can do with the desktop app and then, um, and then maybe, maybe the future of the CLI might change, but it's where it is now. I'm super happy with how it's going. I'm super happy to let people just have it and use it um yeah realistically my my my thoughts on monetizing open source software are more around like individuals just use it for free go have fun and then it's the companies that should be paying um they get a lot out of open source so so how has the reception then been to the desktop release because it's it's in beta it's out there it's open source and it hasn't been very long maybe a month or so that it's been out yeah it's been it's been really good we have opt-in emphasis on opt-in telemetry well nice i screwed that up it's actually opt out but you can opt out on the launcher so it's okay so it's opt out but you just click it's right in your face when you start it up so it's easy and it's pretty much what we gained a thousand signups on the hub which was really cool to see we've got people making hundreds and hundreds of runbooks which is also really cool to see i think the biggest thing for me though rather than that telemetry is more the community response.

34:58So we have in our Discord, we have a separate channel for the desktop app. And people have been in there really active using it. GitHub issues usually imply there's an issue, but it also implies that people care enough to actually tell you that something's not working for their use case or something's going wrong and provide like a bunch of steps. We've had people provide some like actually really thoughtful GitHub issues as well, which has been nice to see and nice to work on. I think for me, it's also good validation. so again i've been working on this for around a year um in one form or another and we did release in a closed beta back in april and that had a nice reception but it's it's the validation of you can go download it right now it's on the website go try it and let us know what you think and that going successfully as well which is really nice validation that the problem that i see is a problem and that i have built a solution to is a problem that other people see too yeah Well, I did download it and I'm staring at it currently.

36:00Looks very nice. I like that there's some examples because I'm a guy with zero runbooks, you know, and I can put my deploy script into here and write about it. But, you know, just trying to kick the tires. You have the Atuin desktop release. This is actually how you guys release a new version of it. Yep. We run that all the time. You run that one all the time. which looks like it's maybe like seven or eight steps updated 23 hours ago so you're still currently working on it that's always awesome and then there's also one yeah we also got one for the cli as well that was not yet open source but there's a little mostly automated like the first 80 percent of it just runs then there's a nice little step of like go look at this make sure it's correct merge the pull request and then come back to the runbook gotcha so i'm looking at the add to end desktop release runbook.

36:52And in the upper right, there is a green play button. And in front of me is notes. This runbook is a copy of the runbook that we use at add to end, blah, blah, blah. Here's your dependencies, the release process, version bumps. Like it has a typical kind of a markdown looking documentation with executable blocks in there that will run, I assume, on my local machine if I hit the execute button. That's right, yeah. Okay. The upper right-hand corner with the play, is that going to run the entire script top to bottom kind of a thing? Yeah, that's what it does. So again, it's meant to be flexible enough that you can pick an individual block to run if you need to or rerun or whatever.

37:34But then if you've built it to be sequential, you can just run the whole thing end to end. Nice. And then I assume it just stops when certain parts fail because inevitably with somebody else's runbook it's going to be like, no, you don't have this thing installed. Terminals are the only exception. So terminals need to exit in some way and they won't exit themselves. So because it's an interactive terminal, we don't know when the command you've run is done or when what you're trying to do has finished. So you either need to exit the terminal within your script or you need to press stop. And when you say terminals, you're referring to like an interactive thing that's going to go on in here?

38:10So we have terminals and scripts. terminals it will run like like your terminal emulator just in your okay so it's gonna like block and wait for a response exactly whereas scripts it's like you just it's like running bash on something basically right so in this desktop release uh the first thing i see is just a curl command that's a script right yeah and then this says terminal install cargo bump that looks like it's also a script oh that's a terminal these are terminals so if you run one of them it'll um open a terminal locally and and run the thing gotcha i'm afraid to do that oh look at this okay because i can actually stop and i can say no wish i'm glad i can because i'm gonna stop it right there okay so terminals are interactive and scripts are just going to run and whatever the response of the script yeah the cool thing with scripts is we can capture the output so if we were to capture the output of a terminal it there's like a ton of control codes and various other things going on.

39:06But with a script, we can capture the output. And that we save in our local template system. So we support Ginger, pretty much. And you can use the output of blocks to feed in as the input of other blocks. So as an example, you might have a Postgres block, and the input for that, you might need a database URI that you can only get by running an AWS Secrets Manager command or like a 1Password thing. So you can have all of the setup to get you to that point in your runbook and then you can run the query with the output of the script gotcha super cool so these examples are very useful especially if i'm going to start writing my own because they show you kind of how somebody's really using it is there going to be or is there currently some sort of like compendium of example like beyond your guys's official examples like i assume some sort of hub that's like shared coding thing so if you were to go to hub.atwin.sh slash Ellie.

40:04You can see my profile. Okay. This is a thing. Yeah. Um, she didn't ask me to ask this question. I didn't tear up on purpose. I really did not know. Yeah. Um, you can currently share runbooks only. Um, okay. And they only work for using an online workspace. You can mark them as private, public, or unlisted. Um, I might share a getting started guide or a migration guide or a self-hosting guide for something I'm sharing with the world. Maybe I'll do a build guide for the desktop app. One of the other things we want to share on the hub is actual blocks. So currently you can have saved blocks. Maybe you have something for setting up your dependencies that you do across like 10 different runbooks.

40:45You can just save that locally and then import it into various other runbooks. But in the future, you'll also be able to share those via the hub and access other people's blocks to try and kind of just speed up what everyone's doing. This is very cool. This seems like fertile ground for early adopters to get out there and build out their profile. You know, is it accessible to everybody at this point? It's just not indexed. Yeah. It's not indexed. Um, how do you do it? Like if I wanted to start publishing, what would I do? Um, in the desktop app, when you start it up, it'll often make an account.

41:24If you said no, just click your profile on the bottom left and you can register there. And that will get you set up with an account. Okay, you can actually do the desktop app. You should be good to go. Gotcha. Yeah, so I did appreciate that. One of the things I don't appreciate about desktop apps that should just be usable local without any sort of account is when they still don't tell me I can use them locally without an account. And yours does say, hey, sign up. And then it's like, but if you don't want to, click right here and just use it. And so that shows me that you're a person that I like because I do appreciate that.

41:57Just let me use a thing. And then if I want to sign up for a reason that's like having a profile, make it valuable and I'll go ahead and sign up when I want to. Exactly. I want it to be useful offline. I want it to be useful like open source. And I think one of the big things we're aiming for is like, you know, we might not be around in three years time. I would very much like to be. However, if we're not, and someone has built out their whole entire workflow on this, it would really suck if they couldn't use it anymore. So it's important that they still can. How portable do you think it would be if I was building my runbooks, assuming the worst?

42:30Like you disappear, the company disappears, the GitHub repo's gone. Like I can't run it. You know, I never got the self-hosted thing. Could I get them out relatively easily? It's gotta be close to text at the end of the day, right? Yeah, so if you're using an offline workspace, it's just YAML on your disk. And the format is quite verbose, but a bunch of scripts and you can pull it all out and it's fine. What you can also do is you can export Markdown. So it is, we don't really like the fact that there's YAML as our file format. So the end goal will be to use Markdown as the file format. But what you've probably noticed is that the editor is richer than Markdown provides sort of Markdown for.

43:14So figuring out like a very light extension we can do that lets us encode everything we need to encode, but also makes it so that you can still actually edit it in a text editor and read it and various other things. So that's not done yet. And that's something I want to do correctly and would actually appreciate input on if anyone has any thoughts. But if you export Markdown, you'll see that there is some front matter in the code blocks, which is how we're currently seeing things. Gotcha. Yeah, I think that would definitely be a huge upgrade to get that done. What else are you working on? What else is in the pipeline?

43:48Yeah, so coming really soon is a new runtime. The current runtime is very much like, let's get something that works and see if people like this. And the new runtime is going to be, let's make sure things are really, really robust and flexible and will allow you to run runbooks from the CLI, which is, in my mind, very important because then it allows you to run them in the CI systems as well. So maybe you have a readme that's getting set up and you could actually test your readme, and that would be really cool. Maybe you have a bunch of disaster response runbooks. It's really important that they actually work and you don't find out that they don't work at 3 a.m.

44:26when you need them. And if you get things set up right, maybe you could test that on a schedule in some automated system somewhere. I think it's also important just to be able to execute these things without a desktop app if you really don't want to do it. So that's what's coming soon. So when you say a new runtime, can you unpack that phrase for me? Yeah. And tell me more about what that means. So when you click play on a terminal, there's a bunch that goes on behind the scenes. Currently, the front end makes a call to the back end to ask it to open a pseudo terminal, and then it gets a handle back, and then it starts writing to that with the input you've provided it.

45:01That's like a special case. So the front end knows that it's a terminal. It knows that it has to open a PTY and do X, Y, and Z. What we're trying to do is get it to the point where the front end just says, run this block. And that's it. and that means that the front end doesn't have to be a desktop app it could be anything and it also opens the door to a lot more flexibility in how blocks are defined so we're not there right now however i would love for people to be able to write their own blocks their own integrations whether these are backed by a shell command or some big set of code um doesn't really matter but right now it's very much like every block works but it's like a nice sort of combined effort between the front end and the back end.

45:45And we'd like it to be the front end as minimal as possible. Is more minimal, does less heavy lifting so that a different terminal could call Runbook and run it from there. Is that going to require you to first figure out a more permanent serialization format or you already have that? No, so the serialization is, there's like the in-memory format and then the on-disk format. The on-disk format's the one that's up for change, the in-memory one we're happy with. Okay. Right on. It is open source. Is it open contribution? How do you, why do you, when do you, how do you? Like, tell me more. So we accept contributions from anyone.

46:28We accept fixes, especially, like quickly. Features, this is something I never really planned out with the CLI because I didn't think anyone would care when I first released that. we never really thought about how to accept feature requests from people. And in the early days, I was very much like, oh, my God, someone's built something cool. Let's merge it and let's go. And towards sort of more recently, it's been, you know, is this something I want to maintain long term? Is this something that people actually want or is this just bloat the code for no real reason? For instance, there's been a pull request open for a really long time that I feel kind of bad about.

47:05But someone's added PowerShell support, which is super cool. However, when he first opened the pull request, I hadn't seen very many pull requests from the guy. And if he's listening, I really appreciate your work and thank you very much. However, when he first opened it, I didn't know if he'd stick around. And I made it very clear that I could not maintain a PowerShell integration. It's not something I have any familiarity with. And the dude stuck around for like six months making fixes to various things, making other PRs. And now it's like, well, I have trust in your code. And I also have trust that when you say you're going to stick around and keep it going, you probably will.

47:42So that's also a consideration I never really had originally. But jumping back to your original question, open contribution, fixes, like anyone fix anything and open a pull request, I'm super grateful and we'll review it as quickly as possible. Features, if there's like an open issue for something and someone really wants it, wants to make a PR for it, that's awesome. um but i do generally prefer an issue before someone makes a pr purely because it really sucks to say no to something someone's put a lot of effort into right it's a lot easier if it's just an issue yeah there's code behind it you're like oh you spent all this time yeah you spent all this time on it and then that's not something we're going to merge and i'm really sorry um do you communicate a roadmap or like a a place where you're headed because sometimes it's hard to know like i have a feature request obviously i could just ask but if i knew there's like here's our direction i could at least say if i'm tangential to it or not so a roadmap is on the roadmap um okay i'm planning on doing it soon yeah you have a roadmap that includes to create a roadmap yeah i like that um so soon we'll be writing a ton of issues realistically i've got like internal notes and various other things and what needs doing and now that we're open source that needs to be made public.

48:56The format of the roadmap will probably be mostly GitHub issues just because that's what's accessible to most people and pretty much everyone has a GitHub account. But we will be using the forum and the blog more too. So a lot of the development so far has been on the forum. It's generally where we've found discussions live best. GitHub issues, I tend to prefer keeping actionable. Like, you know, there's a clear reason to close one because a PR has been merged or something like that. GitHub discussions never really did it for us. They felt like an afterthought from GitHub, to be honest. Well, it came years later.

49:35Exactly. So Discourse, we host a Discourse forum, and that's been a nice place to host discussions. What about the CLI? Do you consider it mostly done? Does it have major feature requests? Is there a roadmap for that? Or what's the status of the CLI tool? Yeah, there's less of a roadmap, more of a bug fixes I will try and get to as soon as possible. Features, I tend to prefer features a lot of people ask for or that I personally really feel the need for, which a little bit selfish, but you know. But it's very much, I would rather see enough demand for a feature before bringing it in, unless it's very, very obvious that it's needed.

50:15There's been a lot of, I think recently I saw someone talking about being able to add comments and tags and various other things to commands. And I think that is useful. However, my thoughts there are that the interface for actually searching them needs to be really good because there's a little point in adding organizational metadata and not being able to search through it effectively. So I think that's quite a large change and therefore one that unless a lot of our users want it, it's not necessarily worth doing because then we have to maintain it too. and are those conversations going on in the github issues or is there a separate place for those uh usually github issues people will make a feature request and then it can be discussed but yeah um i need to get better at managing those because it's a bit of a mess fair such as life you know it's it gets messy and sometimes it stays messy especially when you have a shiny new object that you're paying all your attention to right i mean this thing is a big lift i can tell you put a lot of work into this and you can't you can't spend all your time on the cli when you're building a desktop app right yeah i think it's definitely i don't want to neglect the cli uh we had one of our users thank us for not neglecting it which was nice because i'm glad people feel that way um but the cli is definitely much more mature uh we've noticed you know when i first released it a lot of the early issues were very this does not work at all on my system because of xyz and now how it's very, this does not work with a very, very specific setup and very specific set of use cases, which is sort of for us more of a signal of maturity and less of a like, I just broke everything and more of a, we need to figure out how to integrate with something I'd never considered.

51:53Something new or something obscure. Yeah. From my perspective, I mean, I just been using it kind of how you built it on day one originally, just ever since. And it just does what it does. And it's mostly invisible. I don't think about it very often. I use it all the time, but without thinking about it. Like you do good shell tools, right? Like you're like, well, I don't think about LS very often either, but I'm going to use that one all the time as well. We have a lot of people tell us that they didn't realize how valuable it was until they didn't have it. Oh, yeah. That's going to feel good. Yeah, that's cool.

52:20And who knows, when I get a new machine, maybe I'll finally get the sync to be useful for me. I'm like the only person that doesn't care about syncing things. Well, let me know if you do. It'd be cool.

52:32And I'm going to try to find a way to use the desktop app. You know, I love your work. I think you put a lot of thought into the way you go about building software. And I think that that's rare and just refreshing. And it just makes tools that are delightful to use. And I can tell you put a lot of love into this one, even though it's not exactly right in my daily use wheelhouse. Still look for a reason to go beyond kicking the tires. Yeah, I think in terms of, I hope you do, but I think in terms of users, it's like the CLI has very broad. You know, if you use a terminal, it's probably useful. whereas the runbooks app is like maybe less broad use case but in terms of the actual use it's much deeper so well for sure if you're a user of this it's going to be like part of your daily job you know and exactly your team will rely upon it it'll be very valuable for the people who do use it so i agree it'll go deep and these are people who are generally well employed at places that have complicated infrastructure and they need tools like these to make their job not miserable all the time, you know?

53:36Exactly. Yeah. That's what we've been seeing. Very cool. It was awesome to catch up with you. You've been doing a lot. Anything that we didn't talk about with regard to Add2in, the CLI, the desktop, San Francisco, motorcycles, anything else? I think we covered pretty much everything. It's been a good chat. Absolutely. Well, the website Add2in.sh, there you'll find both the desktop app and CLI. Maybe you'll use them both. Maybe you'll use one of them. Maybe you won't use either one, but you can check them out. They're open source. If you want a good Rust code base to check out and maybe contribute to our listener, I would submit that to you because she makes good software, folks, and she pays close attention to the details that matter.

54:21So check that stuff out. Ellie, thank you so much. I wish you all the best with this new endeavor. And definitely keep us in the loop, especially if the self-hosted thing comes out. as more things are released and open sourced. Don't be a stranger. Thank you very much. It's been great talking to you.

54:41So Ellie pronounces it Atuin, which does sound a bit like Tatooine, which if there's a bright center to the universe, Tatooine is the planet that it's farthest from, but it does have a useful spaceport in Mos Eisley, but you'll never find a more wretched hive of scum and villainy. So be cautious, but not with Atuin desktop, which seems like a pretty safe bet. Give it a try and let us know what you think in the comments. We hang out in Zulip. Head to changelog.com slash community to join. It'll cost you exactly$0. Thanks again to our partners at Fly.io and to our sponsors of this episode, augmentcode.com and agency.org.

55:21That's A-G-N-T-C-Y dot org. And thank you to Breakmaster Cylinder. We'll never find a more mysterious hive of beats and boops. That's all for now, but we'll talk to you again on Kaizen 21 on Friday.

56:19So you said something about DevOps being dead, or I can't remember exactly what you said, but you have feelings about DevOps either as a term or as a, as a thing. What is that? I mean, correct me if I'm wrong, I thought DevOps was originally meant to be bringing.

56:36It's better.