Replacing Git with Git

So we’re here with Scott Chacon, who has been a Git mastermind since the old days, at least in my mind. You taught me about Git…

THE days.

Yes, the original days of Git and GitHub… Not exactly of Git, but what took it to the next level was GitHub, because - gosh, what year was it, Scott, when you co-founded GitHub, and you came on board, and started teaching all of us about Git? This was a long time ago.

Yeah, I mean, 2008 I think is sort of the incorporation of the C Corp, but I think we were working on it on and off, volunteer, whatever, for some time before that. I was doing Git Community Book and working with Git in 2005-2006, I think… So yeah, it’s been a –

That book was so amazing to me.

…few decades.

Yeah… So many times that I was like “That was better than documentation”, because it was like examples of how to use things, and what to expect, versus like documentation is kind of sterile…

Yeah. And it continues to this day, actually. I’m talking to Apress for doing a third edition of the book. And every single time it’s almost – you know, it’s like having a kid or something, where you’re like… It’s a huge pain, and then you have them, and then you kind of forget sort of how painful the early days were, or something… And you’re like “You know what would be fun? Do that again.”

“They’re so cute!”

“It’s not that bad…” [laughs]

But then you’re like “Oh, they are that bad.” Anyways, I love my kids…

This might be a surprise to some of our listeners, but Git was not just a de facto tool. Back then there was a war over SEMs… Like, “What was going to win?” Mercurial had a lot of users.

You know what’s funny - I was just at the FOSDEM Conference in Belgium, and we rented out a bar, and we were buying people beers, and stuff… And there was this table with the guy that does Pijul, which is another version control system now that’s kind of based on Darcs, or similar to sort of patch theory… And then the guys who are basically maintaining Mercurial these days. And we all kind of sat down and had a beer and talked. We were all kind of smack-talking, saying what’s good about the –

For sure.

It’s like the old days, right? Like, I haven’t really argued about version control systems in such a long time that it was fun to think about the days of Mercurial, and Darcs, and Arch, and all of these sort of – Bazaar, if anybody remembers those…

Oh, yeah, Bazaar.

It’s an interesting new world of just uniformity. Now I talk to these conferences, and people at these shows, and everybody – like I said, they grow up using Git.

It’s an afterthought, yeah.

It’s the first – they used it in college; it was the only thing they’ve ever used. Software programming has always been getting GitHub with them, and open source. Man, for old guys like me, or us, I suppose, trying to remember what was open source like when we were sending patches to Trac, or whatever…

Oh, yeah, Trac. Yeah.

What was it like before Git for you then? Was Subversion your thing? Was SVS your thing? Where were you hanging out at?

I graduated from college in 2002, I think, and so my first job - actually, we were FTP-ing files onto the production server.

Of course. Yeah.

[00:08:00.12] These PHP files, and you just - not even SCP; what was it? FTP. Yeah, you’d just FTP files.

Yeah, SFTP or FTP. Yeah.

SFTP. Yeah, Secure FTP.

And we would, you know, just straight into production. Or even SSH in and edit the files in place or something, and just be like – just make sure to sort of copy these files, because I just edited them. So you know, you need to –

[unintelligible 00:08:15.15]

You put an _2 on the filename. [laughter]

And it was one of the first things I did when I got there, is I put in CVS, I think, at the time. And then we kind of quickly moved to Subversion. But yeah, I used Subversion for a while, and when Git came around, actually, we were using Perforce at the job that I was at… Which you can still do. Although I think now it’s like [unintelligible 00:08:38.22] You can use Perforce with Git clients, or something. It’s just pervaded sort of the whole world.

But yeah, actually the first things that I did with Git, the reason why I got into it was because we were using it for content transfer. We wanted to essentially get media onto this network of servers that we had for like an advertising display network, and we were using Git for that. We were rolling RPMs and stuff before that, and we were like “You know what we could do, is just have them fetch, and then it’s nice; it gets sort of just the deltas. Like, it only gets the files that it needs.” It was very good for this sort of content transfer mechanism. And I grew up using it that way. That was that was my first sort of usage of Git. So that’s kind of what led me to write documentation for it and stuff, is I learned it and I found it very cool. I was like “It’d be nice to make this easier for other people, because it’s so obtuse at first.” And then once you get it, then it’s very simple, and it’s very interesting. So yeah, that kind of got me into that, is we were using Perforce for version control, and we were using Git for content management.

Well, of all the GitHub founders… So Adam and I were both around. I mean, we’re early GitHub users… The podcast picked up, I think, in ’09, so slightly after GitHub was launched and started to gain some traction… I was very much – I came out of college in ’05-‘06, and was using Subversion a little bit, but also honestly just doing like the _2 kind of stuff also… And so I was very much learning Git when it was “Should I learn Git? Should I learn Mercurial?” It was very much the VHS and Betamax, the BluRay and HD DVD timeframe of like “Which one’s gonna win?” And I think that GitHub ended up being the killer app that made Git actually just launch into the stratosphere.

But of all the GitHub founders, you were the education guy. I was always like “Scott Chacon…” I mean, y’all honestly taught me a lot of what I knew for the first decade of my Git skills… Which - at a certain point you just learn like seven commands, and you kind of understand how it works, and you’re good to go… Which is nice. But gitscm.com… When you guys started GitHub, were you very much like “Okay, Scott’s gonna be –” I mean, this is kind of like early days of like tool evangelism, or tool education… Which is so commonplace now, but was kind of new back then, to a certain degree.

Yeah, actually when I first started at GitHub, when I kind of joined the guys full-time, I had been involved in writing documentation, and stuff. I think I’d published [unintelligible 00:11:08.25] before that… And I liked writing about this, and trying to make this easy.

[unintelligible 00:11:13.23]

He has a very specific, nuanced voice.

He does.

[laughs] Yeah. But yeah, I had hat, and I had some screencasts and stuff that I had done for that… And a friend of mine who worked at Google, Shawn Pierce, had asked me to come into Google, and they were kind of switching over to Gerrit and Git for their Android team… And he had asked me if I’d come in and Google could pay me to do this tutorial type thing for their Android team. And I was like “Yeah, that sounds fun.”

[00:11:53.01] And then I decided that I would join the GitHub guys, and I was like “Can I bring this income in? I’ll just have Google Pay GitHub, and we’ll kind of have this educational arm of me going around and teaching… Like, I have a gig, and we’ll make it a GitHub thing.” And they were like “Yeah, if you’re coming in with Google as your first client, that’s fantastic. Yeah, we’ll let you do that.”

So actually one of the first things I did for GitHub is I went to Google and I helped teach Git to the Android team. And I ended up doing that a lot, actually. We did a lot of corporate stuff, where – and a lot of it, they weren’t even using GitHub. The Android team didn’t use GitHub. I don’t know, maybe they do now, but they didn’t at the time. I did Motorola, or Qualcomm, or… There’s all these sort of – Android was going out, and all these chip manufacturers and everybody needed to learn Git for Linux stuff, so that they could work on Android drivers, or whatever… And so GitHub actually made a relatively good amount of money of me traveling around and teaching all of these teams how to use Git… But also, I think it helped spread the brand, and things. And then I would do lots of conference talks, and all of that.

So, yeah, now I’m doing conference talks and stuff again, for Git Butler, like going on stage and talking about mostly Git… It’s kind of the same thing. I didn’t really talk about GitHub most of the time; I would just talk about Git and teach people Git, and then just assume they’ll kind of flow over into GitHub at some point, eventually. And it worked out really well for us, and so… But yeah, now I’m getting back on stage and kind of doing that type of thing, and teaching Git again, and… There’s a lot of stuff that’s changed in the last five years, so it’s been kind of fun to do these “You think you know Git” type talks… But yeah, the world has changed entirely. Now everybody’s grown up with it. It’s such a different world than being like “You know why you should use Git? It’s because it’s good at branching”, or something… [laughter] And everybody’s like – I don’t even know what to compare it to, right?

It is the way.

It’s ubiquitous. It really is.

Which begs the question, what might be next. Because at one point Subversion and those others essentially was all we knew, and there was a war, and there was sort of like this competition between what would actually win. And as you said, Jerod, GitHub was the killer app that made Git win. And it won for good reasons, but there’s I suppose a lot of maturity around GitHub, Git etc. in software development at large, across the globe. This is a phenomena that happened not just because Git was great, but also because GitHub was also great at social coding, and connecting people, and bringing projects together, and popularizing open source, and “Open source move fast. Keep up” kind of thing… Which is what we’ve founded ourselves on, was this “Open source moves fast. Keep up.” The “Keep up” was actually meant to be snarky. And that was Wynn Netherland’s addition to it. I was like “Open source moves fast. This is what we should do.” And he’s like “Yeah, but you’ve gotta keep up.” Given that, what might come next? I mean, we’re in an AI era… Is something else coming? What are your thoughts? Do you have any purview on that?

Yeah… I guess there’s two different things. One is “Can version control tools be better?” Which I think is clearly true. I feel like the Git user interface hasn’t changed really massively since I’ve started – for 15 years now. There hasn’t been a lot of innovation in that space of “What can a version control system be like?” There’s been really interesting things, like Darcs, or Pijul has been around for a while, and they have a kind of interesting idea of sort of patch commutation, or how they deal with merge conflicts, and stuff… But it’s always been so obtuse. It’s so difficult to use. It doesn’t make things that much easier for the user, generally. It’s kind of mathematically interesting. And so I like this idea of “What could be easier on users?”

Actually, other than – so I’m working on GitButler, where we’re trying to do that, just reimplementing the user interface and making sure that we’re still writing out a Git tree. At the end of the day you need a tree. You need to have “Here’s what a directory looks like of code.” But I don’t think it really matters how technically you put that together. As long as at the end it’s a Git tree, you can kind of use parts of Git, and then rewrite other parts of Git without anybody knowing.

One of the interesting – I can talk about GitButler and kind of what we’re doing, but one of the other interesting projects that I’ve been following recently is Jujutsu, which is another sort of Google project. I don’t know if you guys have played with that… But it’s an interesting idea of kind of how to think about version control differently, and if it can help with sort of modern workflows of what we’re really trying to accomplish.

[00:16:21.07] So one of the things that they do is they don’t have a staging area. It’s just sort of the working directory is kind of the staging area, but they’re kind of constantly rewriting commits. It’s like constantly rebasing, but in a very easy way. And you can create a commit three commits down, and sort of insert it into two different commits, and then start moving patches sort of into that after the fact, and it kind of rewrites everything above that. It creates merge conflicts, and will keep the conflict as sort of a first-class artifact within the commit, and then you can go to it at any point and kind of fix, and it rebases everything on top of that. Check it out, it’s really, really interesting… But I like this idea of saying “What could –” Like, this doesn’t have to be a user interface, right? Our user interface could look like just about anything, but at the end of the day, all we’re saying is “Here’s what I want the code to look like.” And I want to be very specific that this is what every version of every file very specifically looks like. And Git is very good at that. But how to craft that - there’s lots of different ways we can do that.

I mean, we even see that in Git, people arguing about merges versus rebasing, or sort of PRs… If you’re taking in review, are you sort of rebasing a patch series, and trying to keep it like a patch series, like in the old sort of mailing list days? Or are you just adding new commits onto your PR, because you figure it’s sort of a unified diff anyways, so it doesn’t really matter? Is the commit interesting, is the PR interesting? There’s all these workflows –

Right… We debate all these things.

Yeah. And I think there’s strengths to all of these things, and so it’s really about “How do we want to work?” What’s actually easiest for us on a day to day basis as software developers to say “Here’s what the problem is. Here’s how I want to work.” Does the tool kind of help you do that, or does it get in your way? Are you getting around it somehow? And I think with Git all of us are getting around it somehow. It’s certainly better than anything I used before, but I can imagine a world where we have much better tooling than this. And some of it is sort of AI – there’s AI stuff that I think can help with that, but there’s heuristic things; there’s algorithmic, simple things that we can do, too. Or just UI, just user interface stuff, of just making it easy to sort of absorb changes into previous commits, or do fix-up auto-squash type stuff in a more automatic basis. Or doing sort of commit-based review; it’s a big thing that I see all over the place. There’s Fabricator, and there’s all these tools that get around GitHub sort of squashing everything into one unified diff. People want to do – sorry, I’m talking a lot here, but I guess…

I love it. You’re in a theory. I mean, this shows how deep you go, and I love it.

One of the things that I’m really fascinated about is what we’ve really done with Git is we use the commit for several orthogonal things. For several things that really aren’t directly related to each other. So we use it to share work, to actually put – you have to commit something in order to push it over the wire. So you cannot have your code reviewed unless you’ve committed it. It doesn’t necessarily mean that that’s – in fact, almost by definition, it’s not what you want to push to production. You want to push it to somebody else, so that they can look at it and give you feedback and say “Okay, here’s how I would change it.” So it’s kind of like what the mailing lists were used for before.

And then – so you use it to share your work, you use it to document your work… So the commit message is really used in blame, or in these sort of archaeological tools to document the work that you’re doing… And you use it to save your work, right? This is why people do Work in Progress commits that they’re not really attached to, is they just want to make sure that Git saves it somewhere, that it’s recoverable. And I think overloading the concept of the commit with these things makes all of them a little bad, right? All of the tools that do these things a little bad.

[00:20:02.05] I think what would be really ideal is to separate these out, so you have a mechanism that saves your work, maybe even automatically in the background, or something; you have something that helps you document your work, or helps you answer questions about your code in a way that is maybe better than the commit message… And ways to share your work that you don’t necessarily have to – like, none of these things… Like, it’s weird to have them all together, and I think it’s what makes it difficult to have a good workflow and good tooling that works for everybody. So I think separating those out as concerns would make the user interface for a version control system much, much better.

I think that’s interesting. I never thought about it like that. I think that’s on point; you obviously have thought deeper on this subject than I have… Which isn’t hard, because I don’t think about it very much. I think about it very pragmatically, like “Should I share this code? Should I push it to production? Should I document what I just did?”

We just recently did a show about generalization and specialization, and I’ve always been an advocate for and a generalist in general. However, Scott, I feel like you are kind of the anti to that; you have specialized in Git specifically. I mean, you were on the Changelog 13 years ago, talking about Git; now you’re on the Changelog today, talking about Git… [laughter] Right? And so it’s kind of funny, it’s like deja vu all over again. I mean, from my perspective, publicly, you kind of disappeared for a while, and then you emerge talking about Git… And so I would love to hear what happened in the meantime, but also just like your fascination, or your interest, or your curiosity about one specific thing that has lasted for so long. Are you not bored of Git?

I’m not bored of Git… So what happened – I mean, to answer your first question first, I suppose… I left GitHub and I started another company, which was in language learning. And so I kind of got deep into the world of language learning for about five or six years. And then that company - I kind of spun it off… You guys are in the sort of startup world a lot, right? I think there’s two good outcomes for a startup. One is it absolutely does not work, or it absolutely works great. And the worst place to be is in the middle, where it’s like “It’s not not working, but it’s not really working.” And so you’re like “I’m almost there.” So I did that for several years…

Language learning is - it’s either sort of Duolingo, where it’s very cheap and scalable, but it doesn’t work very well practically. Or it’s like [unintelligible 00:22:29.10] or something, or what we were trying to do, which is you’re talking to human beings, and it’s very difficult to scale, and it’s very expensive for users, but it does work very well. It’s more of an in-person language school type thing.

So I kind of got into this world of trying to figure out “Can we bridge this, to some degree?” Because I got very frustrated – I lived in Paris last year that I worked at GitHub, and I was trying to learn French… And so I think like any startuppy type tech person, I was like “I can solve this problem. This is a very difficult problem. It’s one that I feel there must be millions of people that feel this, that need to learn a language for some reason”, and I tried to tackle that. And it kind of worked, and it kind of didn’t work from a sort of business perspective.

And so when that kind of ended, and I spun it up, I was just kind of looking for what else to do… And I also do some angel investing. Since the GitHub exit, I’ve been angel-investing in some companies, and things like that. And my partner and I kind of looked at all of the companies we had invested in, and kind of asked ourselves this kind of fun party question… We did it every once in a while, which is “If you could run any of these companies, which of these companies would you find it most interesting to be a part of, or to lead?” And mine came up with a version control system that we had invested in. And it hadn’t quite worked, but I found it so interesting… It kind of got me back into it. It was kind of nice to take a break for a little while, not thinking about this all the time. I was still using GitHub every day, I was still developing, but I didn’t really look at the problem set. And what they tried to do was more of like a Google Docs – they really looked at version control of saying “How come Google Docs essentially does version control, but does it very, very differently than how software projects do it?” You never commit in Google Docs. You’re not sort of pushing changes somewhere. It’s sort of constantly recording, it’s constantly saving stuff… It’s trying to make sense of it in the background for you.

[00:24:20.00] And it’s there when you need it, but otherwise, you’re not really thinking about it. And I was like “Why don’t we do that in software? Why don’t we just run a daemon and we don’t have to worry about it anymore? And whenever we need information or something, it’s just always kind of been running there.”

I found that so interesting, of just looking at “How come nobody’s really introspected this for a while, or nobody’s really tried –” Every Git client out there is a button on top of a command line invocation that you would run. There’s nothing new. Nobody’s doing anything you can’t do in the CLI. And so yeah, I started thinking about this more philosophically, of like “What are we really trying to do here?” and then kind of going back to first principles and saying “Let’s start over. Let’s pretend GitHub had not sort of piggybacked on Git, but had created its own CLI, or created its own client.” What might that have looked like if we had thought about it from first principles and really tried to say “What would a nice experience for what you’re doing be?”

And that was kind of what started GitButler, is my partner Kiril, who had started Sturdy, and done this other version control system - they hadn’t worked largely because they were trying to move people from Git onto like a brand new version control system. And that’s very, very hard to do. GitHub ran into this all the time - we would go in and try to move people from Subversion and from Perforce or whatever, and it always had to be greenfield projects. It’s so hard to move a whole team, or a whole company, or something. So we got there, but it took a really long time, and it was a fight all the time. But to come from scratch and try to take on Git and GitHub - it’d be like “You should move from that to us, because we’re better.” That’s insanely difficult to do.

So we decided to kind of go the middle route of being like “GitHub’s great. Let’s keep GitHub, let’s just rethink the client side. How do we create stuff to push to GitHub? How do we manage that information and manage that workflow, and help that be better?” And I think that’s a very interesting question, and it’s one that we’re still kind of debating. We’ve been working on this for a year, and we’ve done really interesting things, I think, around virtual branches and stuff that has never really been in the Git world before.

Now I’m looking at Jujutsu and saying “What can we steal from this? There’s interesting ideas here, that can make your workflow easier. Can we pull in some of those ideas?” Can we look at all of the version control systems, whether it’s Google Docs, or Mercurial, or Pijul, or whatever, and kind of say “What works in these systems? What is interesting? What would make my job easier on a daily basis?” and steal that and try to incorporate that and make it approachable and easy to use.

So yeah, that’s kind of the that arc, right? So now I am back in the Git world, giving talks… And it’s interesting kind of what’s happened to Git in the last eight years. There’s lots of stuff. Microsoft’s been investing heavily in Git. Windows - I think they’re using Git as the version control system for Windows. This massive monorepo, with hundreds of millions of files, and tens of gigabytes of data… Stuff that Git could never do the last time I really looked at it, or the last time I wrote the second edition of the book. And so it’s been really interesting to look at it and be like “What all changes have been made in the last decade?”

It’s funny, because like you said, you learn your seven commands, and then you never really move off of that. And then all of this – there’s 10 years of work; they’re still doing an average of 10 commits a day in the Git project. There’s tons of work going into this, so it’s interesting to look at what has happened. So yeah, I’ve been spending a lot of time on that lately. Sorry, I feel like a steamroller… [laughs]

No, I would love to dive right into the nitty-gritty myself, because I have downloaded GitButler, I’m looking at it… And the virtual branches, as you said, was kind of the thing at the forefront right now, in terms of what this thing does versus what other things may do… And I would love to hear what they are, and why they’re useful, and why this particular concept and tool is something that’s going to help people, you think.

[00:28:09.24] Yeah, I mean, it was interesting… I’ll go back to the idea of this first principles thing, right? I find this really, really interesting and valuable tool in startups, is this idea of saying “What are we really trying to do here with this feature, or with this tool, or whatever?” And we looked at branches and I started working on sort of a branch management interface for our Git client. And we were trying to figure out “Do we just do what everything else does?” and started questioning, “Why are we –” There’s a common problem where you’re working on a feature, and then you notice a bug, or something comes up, and really in Git you can only be in one context at a time. So you have to stash what you’re doing, or do a work in progress commit, or whatever, to kind of save what you’re doing… And then create a new branch, and switch to that, and then fix the bug, or whatever… Push it up, try to get it integrated upstream, switch back to your other branch… You don’t have that bug fix, so now if that’s a blocker of some sort, now you have to kind of cherry pick it out, or… There’s not a great way of sort of solving this, and I was thinking that it’s not necessarily – you don’t need to do it that way. You only do it that way because Git has the concept of head, so you’re on one branch. There’s no way of being on two branches, or something… And it has this concept of an index, which is sort of your next commit… But again, there’s one of each of these; you can’t have multiple of these things. But technically, there’s no reason not to. You can, you could sort of – it’s almost like patch-staging and then bookmarking each one for a different branch. And so when you commit, it commits to that context, with that context. And so that’s really all that we’re doing, is we’re running basically a git diff and we see every hunk, and we’re bookmarking each hunk for branch A or branch B or branch C, or whatever. You can have several of them that you’re sort of bookmarking changes for. And that’s kind of nice, it kind of ends up being actually similar to the way that a lot of people do integration work, where they have multiple branches that they’re going to want to push out, and they merge them all sort of into one working directory, and they test that out… And then they don’t actually commit, they don’t push that merge artifact somewhere. They just – they want to make sure that it all works when it’s together. And ours is kind of the opposite. We’re starting essentially with a merge product, and then extracting them out into branches, right? We know that when you merge them together, it’ll end up with what’s in your working directory right now, but you start with “I’m just going to make all my changes”, and then I’m going to say “These changes go in branch A, and these changes go in branch B, and I’ll push them up to separate reviewable branches.” So instead of stack diffs, it’s kind of like parallel, stacked branches; it’s like parallel branches.

So the only constraint is that you can’t have merge conflicts between branches, because you only have one working directory, so mathematically you can’t really do that. But that’s kind of nice, too. Then you know all your branches will merge cleanly, because you started out with the merge product.

But yeah, really what I was trying to do is just say “How do I want to work?” It’s not so much mathematically or heuristically “How do I get this done?”, it’s more “What do I want the workflow to be like?” And in my mind, what would be a really nice workflow in that previous example is to just notice the bug, fix the bug, and then go to a GUI and just drag the hunk over into branch B, and commit it and push it, and it’s still sitting there, and you can do more work on it, and you don’t have to worry about sort of the workflow upstream from that. And you can just keep working on multiple things, or fix lots of stuff, and then just sort of organize them into the branches that you want, rather than having to think about that beforehand.

And there’s all sorts of stuff that comes up from that, like having to name a branch when you create it… Mercurial has these sort of anonymous heads that you can do similar things, and I kind of wanted to steal that, of saying “I don’t want to have to name a branch. I want to just sort of have it –” This is one of the things that we do use AI for, is look at the diffs and say – you know, if you want us to use AI for your stuff, to say “Give me a branch name.” It’ll be anonymous, essentially, until I get enough work and it can kind of recognize what I’m doing and then it names the branch for me. There’s all these things that you just – you spend a little bit of time here and there, and it’s a little annoying, and you don’t think about it, but there’s a lot of it that isn’t technically necessary.

Break: [00:32:16.25]

I’m with you. Branch naming a lot of times feels like a chore, especially when I’m just starting something; I’m like “I don’t know what this branch should be named, because I’m not really sure what I’m doing here, besides fix-a-bug-that-somebody-sent-me…

Very painful.

And then - yeah, absolutely, the ability to just take a particular change and apply it to multiple branches at the same time… Like you said, “I’m working on a feature. I also have a bug fix. That’s like a single commit. And then I don’t want to just drop all this, go over there, do the thing, do another branch, get that upstream, come back over here… Oh, actually, that’d be useful to have on this branch. Now I’ve gotta cherry-pick it…” A lot of ceremony or chore kind of stuff that I’m not smart enough to fix; I just kind of live with it as an everyday developer. But happy that you’re thinking through these things deeply.

Yeah, it’s interesting. I mean, what I’ve found most valuable, I think, is going out and doing these conferences. We’ll just rent out a bar and buy beers for people, and then all the developers come out and just talk to them about “What is your workflow? How do you want to work? What’s frustrating?” It’s really interesting, because people don’t think about it that much. They’ve only had one tool. They’ve only used Git and GitHub a lot of times, and so they don’t question it, or they don’t really compare and contrast it to something else that could be available. So it’s interesting to get a couple beers in them and start pulling out these threads of “What is frustrating? What is difficult? What could be easier in the way that you work?”, in this manner that they haven’t really questioned in a decade.

So GitButler right now is a desktop client. It’s called itself a branch manager even, it’s not even a full Git client, right? You’re really focused on branches for now.

Yeah… There’s lots of things we don’t do. It’s beta, it can be slow on some repositories… We’re working out bugs and stuff, but we kind of just went from alpha to beta a month ago, or something like that, and so a lot of it has just kind of been firefighting, making sure it works everywhere, performant to a degree, and trying to get a Windows buildout, and stuff like that… But yeah, it doesn’t do everything. There’s lots of stuff it doesn’t do. What it does do relatively well is this virtual branch thing.

So I’ve been using it essentially as my only Git client for five months now… But again, it’s very much – it works well for my workflow, and I don’t need Git outside of that. Other people do. They have different workflows, and so we’re kind of learning “Okay, I do need this other type of tool.” And again, it kind of separates out – like, if you think about what Git does, it does lots of stuff. It does the sort of committing and pushing and things like that, and branch management, which our client does… But it also does a lot of archaeology stuff. You have blame, and sort of log, and all of this stuff, which we don’t do as much… But again, you can just run git commands. It’s orthogonal.

[00:38:18.12] You can do different tools on these different things, as long as you’re using the same database. And really, Git is kind of a database and a transport protocol, and we’re leaning on that, but we’re trying to rewrite a lot of the branch tooling… But there’s like 145 commands in Git, right? So it’s just like “What all are you using it for?” And we’re trying to kind of slice away hunks of what people use it for, and try to each time question “What are people really trying to do with this? Can we inject some taste, and can we do something that core Git doesn’t do, in order to have a workflow that we think might be better, or might be faster, or might be easier?”

So to answer Adam’s question from the original question, like “What could the next big thing be?” Well, it sounds like you could potentially replace Git with Git. You’re still going to be probably under the hood conforming to Git as a database, like you said, as a transport layer, but reimagining all the things that we do with version control, for a new generation, for modern workflows… But not necessarily start completely from first principles, and invent a version control system.

As first principles it’s too hard to compete with Git and GitHub.

Well, it’s also – it’s about how much better can you improve something. Can you make it twice as good, or 10 times as good, or something like that? It’s very hard to get 10 times better than GitHub for lots of stuff. I think it’s doable to get 10 times better than the Git command line for stuff. So it really depends on what it is that you’re trying to do. So the things that we hear the most, that I’m most interested in trying to rethink or come up with new ways of approaching problems sets - branching is one of them. I think that there’s lots of different interesting ways that I’ve seen in other tools, and sort of in the way that we’re approaching stuff from what core Git does… I think managing branches and commits and commit messages and that sort of workflow - I think there’s lots of improvements that can be made and continue to be made there.

The other thing is merge conflict resolution. I think it’s something that everybody’s hated forever, and nobody’s made better. GitHub’s barely approached this at all. So there’s really a huge gap in tooling for dealing with merge conflicts and merge conflict resolution in teams… And there’s just nothing out there. There’s nothing that makes this particularly easy, and so that’s something that we really want. I mean, even the most basic thing… You don’t know if your branch that you have a PR open on, and your colleague’s branch that they have a PR open on merge cleanly or not. GitHub could very easily just do in-memory merges of every open PR, and say “This one’s problematic. With this one, you might want to start talking [unintelligible 00:40:59.10] but they don’t do that. And so I’d like to see that… I’d like to see, you know, if you don’t have to do a commit and push it somewhere, if you’re just kind of streaming your changes to some central server, and that server’s testing everybody’s branches against each other and trying to tell you early “This is going to be a problem”, you get some of the advantages that you have in centralized version control systems two decades ago, of saying “Hey, we don’t have to be so bad as to lock a file, but we can at least let you’re editing that file, they’re editing that file… Why wait three days for one of the PRs to merge, and then tell the other one that now you have 100% of the work in resolving this conflict?” Like, it’s always first-person wins in Git, in decentralized merge conflicts.

So I think there’s a lot of work to be done there’d. How nice would it be to have that and to have some tooling where you could collaborate on merge conflicts? Git has this concept of ReReRe, the reuse recorded resolutions, but if you have these resolutions that you can share, and kind of network and talk about, and say “How about if we resolved it this way?” and kind of agreed on what the resolution would be before either branch merged?” And then it doesn’t matter what order you merge the branches, because you already have the resolution; you’ve already collaborated on and agreed on the resolution, and if you can avoid the conflict… I think that would be a more ideal world. So the question is “How do we make tooling that makes that good, that makes that easier?”

[00:42:21.10] I think AI actually has a good application here as well. Theoretically, you could train a model that could be relatively good at merge conflict resolution, at least on smaller scales, because GitHub is a database of hundreds of millions of merges…

So much data there, yeah…

And you can take the parents and do an in-memory merge and say “Yeah, this was a conflict”, and you have the resolution for it. So you have this massive database of millions and millions of attempted merges that resulted in conflicts and how they were resolved. I think that type of thing could be amazing. That’s actually what I’m most interested in from an AI application standpoint and version control, is trying to help with this… But there’s also just tooling that helps, just general tooling, a UI that can help two people collaborate earlier in the process to sort of iteratively solve a conflict.

What is this in-memory thing you keep saying? You’ve said it twice, maybe three times. What does that mean?

So historically, before the – there’s a merge strategy that can be done entirely in-memory. So you can do it and then see “Hey, was there a conflict or not?” Historically, with the older [unintelligible 00:43:29.03] engines that Git had, you had to have a working directory. So this is something that GitHub had to deal with a long time ago, is we had to create a working directory in order to do the merge, and then see if there was a merge conflict… Which is a lot of – you know, you have to create space on disk, and run it, and then clean it up, or whatever.

There’s a new merge strategy called ORT, which I think was released a couple of years ago… And the entire point is that you can do it without a working directory on index; you can just do it in-memory, and have an in-memory index that says “Hey, are there conflicted entries in this? And if so, what are they?” And so you can do this with like lobgit2 and stuff now, which is super-nice. I can just have 100 branches and do cross-product merges relatively quickly of all of them, and say “Which of these have issues with other ones?” And that was something that was very, very difficult to do until a few years ago.

So we treat it like it’s expensive, but it’s actually quite cheap to do now, of just saying “Do these branches conflict? And if so, how?” And we have essentially no tooling to take advantage of that, of saying “Let’s just do this all the time, with every commit to every branch, and tell you what the problems are going to be.” I find that very interesting.

We talked to Dr. Richard Hipp a while back. I don’t know if you know his name by any chance. He’s the creator and inventor of SQLite…

Oh, yeah.

…but he also created Fossil, which I didn’t hear you mentioned in terms of an SEM… And Jerod and I had the pleasure of talking to him back - it’s been a couple years now, Jerod. It’s almost time for Richard Hipp to return again…

It is.

…if I can predict a title potentially for that show, if we do it. But Fossil had this same idea, where every change – and I’m not sure if it’s streamed… And you can probably correct me, Jerod, because you probably paid attention closer to the inner workings… But it streamed changes back to the server, to some degree, where you never had to commit. It was always just there, on every machine, where you didn’t have to do this ceremony and stuff like that. Have you heard of Fossil before? Are you familiar with it? Does it ring a bell?

I have, yeah. I’ve used Fossil, but a decade ago, probably. I mean, it’s been around for a long time. I haven’t used it recently, so I don’t know what the workflow looks like. I don’t remember it as being so massively different from the way – I feel like the workflow of Mercurial, or Jujutsu, or Darcs, or Pijul is quite different from Git in some very key ways. I don’t remember Fossil being that different, but again, I haven’t used it in a long time.

[00:45:53.23] Well, line six, when it says what it is, on line six – well, it has a list of eight. What is it? That was the question. And there’s eight things that it is. And the number six is “Auto syncing.” It says “Fossil supports auto sync mode, which helps keep projects moving forward by reducing the amount of needless forking and merging”, this is what we’re talking about, “often associated with distributed projects.” And so like this needless forking and merging and branching and “Is there a conflict?” is really is the ultimate question, right? …once you decide to merge and resolve the code back to production or production-worthy; it’s the golden nugget to fix, right?

Yeah, I mean, there’s always – I’m curious how they do it. I wish I could speak a little bit more intelligently on this particular tool, but… There’s always this issue of “What strengths and weaknesses are you choosing between a centralized version control system and a decentralized version control system?” So there’s obviously a lot of things – we’ve all moved to decentralized version control; that was the whole thing in 2005, 2006, 2007 and 2008, is sort of this rise of decentralized version control systems. But with it, I think, comes more by default, by definition almost, more forking, and more merge conflict problems. Because you can keep things sort of separated from each other. That’s how the systems are designed, to have some advantages. But the disadvantages are they’re not in sync all the time. You can’t have merge conflicts with Google Docs. It’s a perfect separate comparison, is you can’t have – people are editing the same file simultaneously, which makes it really difficult to go off on a tangent and test something out, and see if it works… And yes, the power of that is that you can experiment in a way that is completely freeing. You don’t need to worry about what trunk is, or whatever, if this is mergeable. Anything – I can do my experiment, I can test it out, I can see if it works. I might have merge conflicts later, because lots of people can do this, because lots of people can do this, but it allows you to do that. Google Docs - you can’t have merge conflicts; you can mark that up as a win, but on the other hand, it’s very difficult to experiment, to sort of fork it and do something different and say “What if it was like this?”

And so I find that very, very interesting. What is a good combination of these things where you can go more down one route or another route, depending on kind of what your needs are, and what the feature is, or what the project is you’re trying to do? And I don’t think there’s a great answer. I think everybody kind of has the ways that they like to work, or whatever… But anytime you go more towards one, you go more away from the other. You always have this sort of balance of strengths and weaknesses with decentralized versus centralized sort of concepts.

And you got here because you looked at the angel-funded companies that you angel-invested in and said “This is the one I would like to run.” And you think this is like a super-interesting problem.

I do.

Obviously. I mean, you nerd out hardcore on it, I can tell. I love it.

Actually, it was funny… I’ve helped invest in probably 30 companies or something through this angel, and maybe more personally… But through this angel thing called [unintelligible 00:49:00.18] that’s based out of Berlin, that my partner and I run… And of all of them, I think I was the most annoying investor to these guys… Because as soon as I heard it, I was like – I don’t even know if I want to use this, I just liked the idea of questioning this. And I found that so interesting. And I wrote up these long, long emails, these long paper docs and sent them, and I was like “Here’s all my ideas around this. And here’s my treaties on sort of version control, on versioning data, and versioning information.”

Did they ever just give you your money back? They’re like “Alright, Scott… We’ve heard enough. Thank you.” [laughter]

Yeah… Well, no, so he ended up sort of shuttering that, because he had pivoted to something else, and… It was starting to gain traction, but I approached him and I was like “I really want to do this, and you have pivoted away from this, right? So do you want to join me, and we can sort of co-found a new company together, and work on this from a slightly different angle? Or can I take it?” Because I don’t want to be the investor that then comes in and then starts a company that competes with something they might want to go back to, or something like that. So he ended up folding that company and returning capital. So I actually did get half my money back or whatever from the initial investment, and then we started another company together.

[00:50:19.28] Maybe they pivoted because they didn’t spend your money properly. I mean, gosh… They had half to give back…

[laughs] No, I mean –

Okay, I’m just speculating.

It’s actually very interesting, because he had started this company, and he knew what it looked like to start a company in the version control space. And then we did it again, with a slightly different angle, and we’ve seen how different our community is, how different adoption of the tool is… And it’s working much better than the original one. And it’s hard to always kind of figure out exactly why that is, but it’s definitely exciting, I think. He had this idea, he wanted to do something new in this space, and now we’re doing something new in this space, that people are using, and people are adopting, and we find – it’s very energizing. It’s very fun to try to reimagine the future, and then be able to do it piece by piece, and use it yourself every day. This is another fun thing of having a startup, where you work on a tool you use every day, and you dogfood it every day… And so having built a new version control system or client that I’m doing all my version control stuff with on a daily basis - it would suck to not have this tool anymore… Which is kind of what you want the benchmark to be of a tool that you’re building.

Yeah.

Did you found this, I guess, then by yourself again? Or did you – like, what’s the formation? Do you have a “we”? You keep saying “we”. Who’s involved in GitButler? Is it you solo? What’s the scenario?

Yeah, so it’s Kiril, the guy who had started Sturdy, that joined me as a co-founder, and then my partner Anne, who is the COO of Chatterbug as well. So the three of us co-founded GitButler. And then we’ve hired another five people or something since then. We raised some money last summer. So it’s in the fun startup phase of trying to find product-market fit, and seeing it catch here and there, and figure out “Okay, what’s the next step? What’s the next big thing? What’s the team look like that we want to have for the next 10 years if things go well?” Early employees are so important. And so yeah, it’s a very energizing, fun time of a startup life. And I’m not quite tooled for it yet. So I feel like I have at least one or two more of these to go if needs be, but… But you know, if we’re reminiscing about what I was doing in the same exact space two decades ago…

It’s actually funny, if you go back to podcast 49 - I was actually on the page - of your previous appearance, Scott… Changelog.com/podcast/49. First of all, our show notes back then were spectacular compared to today. So that’s maybe an evidence of how much of a hobby and a passion project it was at the time… Because somebody put a lot of work into these show notes. But at the very bottom, actually, there was an animated GIF of you, I believe, on the show, talking into a microphone… And then it looks like somebody punches you in the face, or you get hit by a – I don’t know, by a mouse, or something. But anyways, you look a lot younger, no offense. I mean, it was literally 13-14 years ago. I was thinking about young Scott Chacon as you were talking, because I was looking at this picture of you on the show last time. I was like “Man, he was just a young buck back then.”

Yeah, I was a baby. I was a baby.

But glad to hear you still have energy left. Curious about centralization, decentralization… Not in version controls, but in product creation. I mean, you had mentioned earlier how well-positioned GitHub is in particular ways of reinventing things, because of the data, the access, all the things they have.

[00:53:54.19] And I’m wondering, here you are, trying to somewhat reinvent Git via Git client, and imagining the workflows again… And I wonder - you’re very much decentralized now as this little startup unit on their own, doing things. Have you thought maybe it would be better at GitHub to do something like this, like inside of a centralized borg, to actually invent it, or go back to GitHub and build it inside there? Did that cross your mind, or is that just too much?

I mean, it’s hard – anytime that you’re really big… It’s harder to steer a rocket ship as opposed to a skiff, or something. I think any small startup has an advantage in trying to figure out what the next big thing is, because we can iterate and we can experiment much, much faster. And we knew that at GitHub as well; when get help was small, and we were essentially competing against Google Code, or Sourceforge, or whatever was on the horizon at that time, it was much easier for us to make changes, it was much easier for us to talk to our customers and to develop a community and to figure out what people wanted, and to just be able to invent out of thin air things that didn’t exist before, and say “We think that this is better”, and try to figure out if that’s better. I think it’s very hard to do when you’re large. And GitHub’s large now. And I think they still do a fantastic job. And I still use it every day; I’ve paid for it for 20 years now. I paid for it when I was there…

I thought you’d have GitHub for life for free, you know?

No, no… Well, we made everybody pay for it. I think we even made all of our employees pay for it at the time, to make sure that the payment process worked well. We kind of wanted to dogfood everything about it, and so –

Good excuse.

Yeah, good reason to [unintelligible 00:55:34.04]

Right. [laughter]

So yeah, I mean, I think we have advantages in some areas, of saying – if GitHub tried to do a client now, and tried to do the sort of corresponding server protocols that would go along with that, I think it’d be really difficult. It’d be difficult because they have all of this legacy stuff to also keep running. And they have every workflow in the world, people are trying to do through GitHub, and they have to keep them all happy. And I think that’s very difficult to come in and say “I have a very specific taste and a very specific workflow that I think is better, that I kind of want to see who adopts, and if that gives them an advantage.” And so I’d prefer, I think, to do it as a small company, and to try to reinvent everything this way. And if we end up competing, or we end up – the worst-case scenario is you get acquired, or something, and then you’re part of a big rocket ship that’s been going longer.

I was gonna say, would you get acquired by GitHub?

You know, I honestly don’t – if we came up with… This is the challenge, you have to come up with something that gets product-market fit, and becomes a little bit threatening. The other thing that – because there are some things I do want to compete with GitHub in, to some degree, if only to say… You know, there’s an innovation to be had in this space still. I think the merge stuff is one. I think reviews are another one. Like I was saying at the beginning of this, is this idea of a PR being this sort of unified diff that you just keep adding to, and you can’t really review per commit. And there is innovation in this space that I think is not super-well done, honestly… There’s Graphite, or there’s Fabricator, or there’s more of these stack branch type things that try to use GitHub as a backend… And I feel like starting over and saying “What could this review process be like? How could I share my work with you?” Start from first principles, “How do you want to review code?” I find that very interesting, and I’d like to get into that space, to a degree, and explore. Can we come up with a thing that’s ten times better than the way that the GitHub has been doing pull requests since – honestly, since I helped write it.

Yeah. Totally.

[00:57:48.29] Anything that I say bad about GitHub, I’m partially responsible for. So it’s hard for me to s**t on it too much.

How much code do you think you’ve still got going there? How much code of yours, lines of code still running when I hit –

Oh, I hope nothing. [laughter]

Not much.

So you can wash your hands of it. “Well, not my code.”

Yeah. I mean, there’s certainly influences of things that I worked on. Gist was entirely my project. So anything that’s – there might be some code still running on Gist.

And Gist has gone largely untouched for years. I mean, it probably still is your code.

It could likely be. And I still use it. It’s still great. I actually still really like –

Yeah, it’s useful.

I love Gist.

Or the blame stuff. I think the blame stuff probably still has some of my code in it, because I remember doing that, and it hasn’t changed a lot. I don’t think a lot of people use it; I actually use it a lot still… Because it’s a nice way of kind of being able to step back from “Okay, what was it previous to this version?”, and kind of step through it. It’s a very nice user interface for that. It’s hard to do in VS Code through any of the plugins, so…

Right.

Yeah, I mean, there’s other stuff, but I have to imagine that they’ve ripped most of [unintelligible 00:58:56.00]

Right. So you mentioned server-side stuff, that if you were at GitHub, there would be server-side things involved in any sort of client-side experimentation. So what’s the GitButler server – because I imagined that you’re building entirely on top of Git… And it sounds like you do have some GitButler-specific server things going on, or what?

Yeah, so like I said, separating out the various functions of what you use a commit for I think is important. And so what I really like is more of a streamed sort of backup, where it’s like anytime that code changes on disk, have the ability to back it up somewhere in a way that doesn’t require you to create a commit… Because then you can do pre-commit review. And I think that’s – whether the review tools are better, what could be very useful is to just say “Okay, I’m at a point, I haven’t even made a commit, but I want somebody to look at this code and tell me, am I in the right direction or not?”, without having to kind of reroll commits. So I think just the ability to put your data somewhere that has a URL, without having to create a commit in order to create that URL, is highly valuable to begin with. So that’s a very sort of low-hanging fruit type thing that we’ve been that I’ve been experimenting with, but we don’t have exposed in the client right now.

But yeah, there’s so many – some of these things we’ve been talked about at GitHub when I was there. It just is too difficult to kind of implement, or it’s too niche, or whatever… So we’ve been brainstorming for a while, but I’m looking forward to implementing these things kind of one at a time, and saying “What’s interesting? What do people find valuable?”

I think your approach is quite wise, because like you had said before, if GitHub did a different client – I think they have an app - I’m not sure if you call that a client necessarily, but the GitHub way is the way for so many developers. And so for them to innovate, they have to innovate at a large scale, to some degree, or start a skunkworks project that is kind of like you, in a way. And what you’re trying to do is really, it seems like at least, create this thing that sits above Git, that writes down to Git, that has the option to do unique things, like you said, with a URL. “I don’t want to commit this code, I don’t want to do a PR unnecessarily, but can I get a code review? Can I get feedback? Can I get a loop of some sort? A human being, an AI version of something, or a junior or a senior dev step in with me and just give me feedback on when I’m writing here? Is it the right direction?” It’s quite wise, because you take a – you said you want to compete, and I like the way you clarify with “I see areas of innovation”, essentially. And I think that’s an interesting way to look at competition, is like, naturally, if you are making something new, innovating, you’re competing. But you’ve reframed it in the fact that it’s not just like “Oh, I want to like battle it out”, but more like “I see an opportunity to advance the opportunity here, and innovate, basically.”

So I think what you’re doing is pretty wise, but they can’t do that, because their way, the GitHub way is so big… Whereas they GitButler way, naturally, is very small, until you gain critical mass.

[01:02:06.12] Yeah. Everything that GitHub or Google or Microsoft or whoever does, they have to do at scale out of the gate. And that’s really hard. And there’s also a thing of – it’s hard to do stuff in larger corporations; it’s harder to have freedom, it’s harder to have people be like “You know what? Try it.” I’ve never actually worked for Microsoft, but I have to assume that things are a little bit more difficult to get through, or there’s some politics, there’s some stuff… It’s always like that; if you’re lucky enough to be successful, then you have to do stuff at scale, and it becomes difficult. But on the other hand you have the resources. So there’s resources they have that we wouldn’t have. All of these companies can do AI type stuff that we really don’t have the resources for. So we have to be fairly certain that we want to invest in something before we invest in it at that type of scale, or if it takes cash… But it’s just “Let’s try out some code.” Like, it’s easy to write code at small scale, and see if it works.

Break: [01:03:03.10]

Is there an opportunity - given your history with GitHub, being co-founder, exiting, no longer part of it - to create a linear partnership of sorts, to say “Hey, I’m one of the founders of this thing from back in the day. Sure, I’m not involved anymore, but I’ve got a big idea that y’all probably can do. Here’s my pitch. Would you give me access to - not so much resources, but even just like data”? I don’t know.

Yeah, I mean, I think it probably would – I have good relationships with everybody there that I knew, that still works there. I think the question is how would it be valuable? I think with anything like this, you have to say “How would it be valuable for them to partner with us if there was something that we were doing? How would it be valuable for us partnering with them?”

One of the things that we’re really trying to do is to make our client, at some point, somewhat server-agnostic, that we could work with GitLab, or we could work with Bitbucket, or whatever people use; internal sort of deployments. And so the question is “Do we want to tie ourselves to a GitHub, or something like that?” Obviously, there’s advantages, too; they’re the gorilla, right? But does that really help either of us, as opposed to just working independently, and seeing what each other is doing, and stealing stuff from time to time? I’d be tickled if GitHub thought that something that this little tiny company was doing was good enough that they felt it was worthy of stealing, right?

How much do you pay attention to Zed, the editor?

[01:06:08.17] I love Zed. This is a whole other thing down the sort of open source route, but Zed and GitButler made their source available, I should say –

You almost said it! [laughs]

Yeah, I know. So we’re not OSI-approved, but we have our source code available; it’s on GitHub. And we have a community that’s sort of built around that. And Zed did the same thing, but they did use OSI licenses. And I need to use Vim mode. I’m so sort of in my way now, I just can’t edit without Vim mode. And they have one Vim mode, but it had – a thing that I use every day, at least once an hour, there’s a replace mode that I use; they didn’t have that implemented. And so I actually – since they’re open source, I’ve been wanting this forever, I’ve been complaining about it for a year now, trying to use Zed on the daily basis… And they open-sourced it, and so I was able to do a bug bounty, where I was like “I will give anybody $500 to fix this problem for me, because I want to try to use it and I can’t. It’s impossible for me.” And somebody took it, and they fixed it, and I paid them 500 bucks, and I was like “This is great.” It’d be interesting, I think, to have open source be a little bit more this route, where individuals or more likely companies can say “I’m depending on this. I want to support it. I can do bounties, I can do –” GitButler is actually a sponsor of Tauri, because we depend on Tauri, and want work to go into Tauri, and so we’re paying them like 6k a year or something, just… Not to get anything, actually; they didn’t even know we were doing that. We ended up kind of becoming friends with some of the Tauri guys, and later on they found that we were doing that.

I feel like open source needs to find a little bit of a different model of sustainability. I mean, even the – what was the X… XZ?

XZ…

The XZ problem, right? There’s so many volunteers that are working on these incredibly important puzzle pieces of the systems that all of us build everything off of every day. And they’re all burnt out. It’s just such a hard job… And GitHub’s made it better and made it worse. It’s made it better in kind of expanding this world, and it’s made it worse by expanding it into people that are kind of *beep* about it, and come in and are mean to you, or are demanding changes and you have to deal with this expanded community that aren’t all hobbyists, and in their basement being nice, right?

I came out of the Ruby community. It was very friendly and very easy to get into, and stuff… And man, if you have a big, popular open source project, you get some trolls, right? And I think it burns out some people. And that’s vectors for problems like this. And I think it’d be really nice to figure out a way to really support the community more, to have more code open source… This is kind of why we’ve decided to go with the FSL; licenses like this, the Functional Source License, or like business source licenses I think help maybe bridge that gap a little bit, of being like, you have a lot of the niceties of a project being open source, or an app being open source, but some protection as well, so we can make sure that we can thrive and make a living off of this.

So what does the FSL, the Functional Source License, what does that provide you, that for instance the GPL would not provide?

So it’s essentially just a non-compete. So for example, we’re talking about GitHub - again, I don’t think GitHub really cares about us, but if they wanted to take it and be like “Okay, well, instead of GitButler, we’re forking it and now this is the GitHub Client. And we’ll put a bunch of resources on it and we’ll just take it from you, and change your server backend out with ours”, or something like that. Like, our license specifically prohibits that. But essentially nothing else. Like, it’s really just “You can’t take this and compete with us on a monetary basis.” So it helps with – I think Redis just kind of switched licenses as well to something similar, that tries to avoid this thing of Amazon coming in and just hosting their stuff, right? So that they can compete.

[01:10:02.15] So again, what we didn’t want to do is do this rug pull of saying “Okay, it’s open source. Now it’s not, from this version forward”, which I think the community really hates. So we started a little bit more conservatively, of being like “We could switch it to Apache”, or something, at some point, if we wanted to do that; maybe we will, who knows. But it’s nice to start out with this and see what communities like, and see what adoption is like, and then decide “Okay, do we want to become more sort of liberal with this, or do we want to keep it under this thing where we can control it a little bit, but still let people have access to the source code, and contribute to it if they want to, and stuff like that?”

Zed is a perfect example. It could be under this license, and I don’t care. I’d still pay somebody to fix this bug for me, because I want to use it. I find value in most of it. I’d like to even pay them to improve it in ways that I want to see, and I think if we can find better, or more broad ways of people making money in open source, it’s better for the entire community; for the open source community, but also for the corporate community that uses open source, which is essentially every corporation on the planet now, right?

Does it bother you that you can’t call it open source then? Do you dislike that?

I don’t particularly care… I think people that are OSI heads, that they really care about sort of – it’s people who know who Stallman, and… Who know sort of the figures in this, or know the history of GNU Linux, or something like that - those guys really care. There’s this small percentage that really, really care, and get really mad. There’s the vast majority, I think, of people who use GitHub, that don’t know the difference, that don’t know what the definition is. That don’t know free software versus open source software, for example. That really just think of it as source available, or really think of it as “It’s on GitHub as a public repo.” There needs to be sort of a definition for that. Because honestly, the license makes a big difference, and the-approved licenses don’t differentiate in the way that people think. So it can be open source, it could be under an OSI license, but it makes a huge difference if it’s GPL or if it’s MIT. So you still have to look at the license, and see what the license terms are.

So I find that kind of a useless definition, like border of a definition, of saying “This is an open source project.” I still need to care what license it is, like which OSI license it is. And they’re not even all compatible with each other. So I think it’s very confusing, and OSI people think it’s very clear. I didn’t even really – I think I used open source one time; usually, I said “We’re opening the source code”, or something. And they don’t want me to use “open” either.

This particular community cares very much about the terminology, but all I care about is practicality. Practically, I want people to know that the source code is available. And you can use “source available”, but that sounds – to people that don’t know what the open source definition is, I think they’re like “Why don’t they call it open source?” Like, there’s some other string that I don’t see attached, right?

I don’t know about that. You’re talking to two folks that really care about it, too. We’re not quite at the level of Stallman and whatnot, that you think we are, but we definitely are people who guard that line, I suppose, is probably the way to say it. And it’s not even like you’re wrong or right, and we’re wrong and you’re right. It’s just more like there has to be a definition of what open source is, and OSI has been the ones who have guarded that definition, for all the reasons that open source has benefited. Right? And so you have to have a quote around that; you have to have quotes around that. It is in “open source”, because open source has a meaning.

What I’d like is to have a phrase that means source available, that doesn’t have what I think people find a negative connotation, right? Like GitHub public, or something, right? We’re “GitHub-public”, I guess. That’s really what I want. Is it beerware, is it FSL? Is it OSI? I have to care about the license, but that’s kind of a separate step. One is “Can I get access to the source code at all, easily?”

[01:14:14.14] I think source available does that job pretty good though, doesn’t it? I mean, it’s pretty clear. Source is available.

Yeah, I mean, I think people don’t read into it the way that you do if you know what the open source definition is, right? So if you don’t know what the open source definition is, and you think open source essentially equates to public on GitHub, then if somebody says “We’ve made the source code available”, then what it sounds like, at least to me, to people that I’ve talked to, is that it sounds like you’re throwing it over the wall, right? Which is a little bit different. So it’s like saying “We’re going to do a tarball dump every month”, right? So the source code’s available. Not “We’ll take pull requests, we’ll be an active member of the community, we’ll work with you to incorporate features.” Like, yes, the license is generally permissive… And most people don’t need to care. Especially in our case with the FSL thing, if you’re not competing against [unintelligible 01:15:02.23] with almost nobody. Actually, even for apps, or for almost any application, there’s almost never somebody that’s competing with you. It’s really just for things like servers, things that Amazon might take. Things like Redis, things like open search…

Right. Which is why that was kind of interesting, because you’re a desktop app, so it seems like it would be less of a concern for you.

It is less of a concern. Honestly, we were really on the fence. “Do we just AGPL this?”, which is what most of these companies do, or “Do we do this other thing?” And we just wanted to reserve some options. But in the end, our community’s exactly the same. Nobody’s really cared about. We’ve gotten tons and tons of pull requests. People just want to be able to fix their tool if they want to adopt this as a tool; they want to look at source code for security problems, or whatever, which - there have been some things that have come out of that, that have been really nice for us, and really nice for our users… And they don’t really care that it’s [unintelligible 01:15:58.18] That’s not what’s important to them. It is important to some people, and I understand… I think, actually – sorry, now I really do kind of want to debate this a little bit, because I…

Throw it out there.

…I don’t really care. All I want is for it to be clear to our users what it’s going to be like to interact with our community. Or how us as a company think about this project. And we really do approach it like it was AGPL, of just being like “We’re gonna give it a license that we think it’s gonna be hard to compete with us”, but if you’re not interested in competing with us, which almost nobody is, it’s essentially the same community that an open source community would be. And that definition doesn’t really exist in the vernacular. And the problem is that most people think that open source is not strictly defined. I know it, you know it… There are people that do. And I know the value of it, especially historically. But also, what’s interesting I think historically is that the landscape has changed so much from the ’70s. Or I guess technically this was probably defined in the ’80s. I forget exactly what the –

Well, so there’s two – so the FOSS thing, so like the Stallman style open, free as in freedom, that was in the ’80s. And then open source definition, which was the second group of people, was ‘90s. So even those two groups don’t agree on the point. They have different views of the world. But they are compatible views, I guess.

But what didn’t exist at the time, and that I find really interesting, is this new wave of sort of commercial open source. So there’s a lot of companies like ours, where we grew up in an open source world, we depended on open source for everything, we built everything on open source… There’s – all of our libraries… GitHub is a fantastic example of this. GitHub is not open source, the core. We’ve open-sourced hundreds of libraries. Everything that we built that was somewhat generic; libgit2, or MySQL 2, or all these Ruby libraries, or whatever, all of these utilities and things, they’re all open source. They’re all MIT. The only thing that wasn’t is core GitHub.

[01:18:17.05] And I’m fascinated, if something like FSL had existed at the time, if GitHub would be open source under the under this type of license, where you couldn’t sort of host it and compete with us, but you’d have all of the benefits of having an open source project.

We debated this a lot internally at the time. It was “Should we open-source core GitHub?” And in the end, we felt like it wasn’t worth the risk, and it wasn’t worth the community management, once we got large enough, to say “No, we don’t want that feature, and that feature, and that feature.” But if we’d done it early, I think it could have been much closer to kind of how Sentry does it, which I find much more interesting. And they’re the ones that are kind of innovating in this space, saying “We need different options. There’s lots of companies like us that need different options.” And at the time GitHub was coming out, there weren’t really a lot of “Oh, we’re going to be an open source sort of core company. Give us investment money and we’ll just ignore the risk of kind of competition and people taking this.”

So I think there just needs to be another way. There should be free/libre… I actually think there shouldn’t be any closed source. It’d be a fantastic world to just be like “What license is it under?”, but basically every piece of software that you use, you can inspect the source code; you just have limitations on what you can do with that, right?

Right. I think you and I agree on this point, Scott. I would much rather have Sentry and GitButler and Github.com open as in functional source licensed, than closed. I think you and I are both 100% there. I do think that we need a third term for that style, which is open but with restrictions on use… And I think maybe functional source is – I understand how source available sounds like thrown over the fence. And you’re not that. So there’s definitely – I understand that push and pull. But I do think that words need to have meanings, and open source has a very strong definition, which has existed for a long time, and we can’t simply redefine that term, even though we want to, because there’s so much goodwill alongside it… But I think we need to educate, and advance a new term or a new way of talking about projects, which aren’t under the open source definition, but share these properties with open source projects, that are to many of us the things that really matter.

Yeah, no, I had a long, interesting fight with people online about this… [laughs] And mainly, my thing is I don’t care what it’s called, I just want to be clear in what we’re offering, and what the community can expect. And there isn’t a good phrase for that. And in a problematic sense, I think there is, I would argue, a majority of the software development community, largely because of GitHub, not really emphasizing license, just emphasizing availability, that people conflate public on GitHub with open source, because they don’t know the history, or they don’t know why it’s called that, or they don’t know what the definition is, the 10 bullet points of OSI definition, or whatever. It’s a complex thing to understand, and most people just don’t spend that kind of time, or whatever… And so I think that conflation is problematic. So if we come up with something else, then people are like “Well, how is that different than what my understanding of open source is?”, even though there is obviously a long held definition of – anyways, whatever. I don’t really care. It turns out at the end of the day our community doesn’t care either. Most of them probably think it’s under an open source license, because they don’t really look at it. It’s just that one time I used the phrase “open source” and people yelled at me. And I don’t use it after that.

[01:21:58.25] Actually, what’s interesting is I realized – I’ve been calling Pro Git open source for a very long time now… So it’s very interesting, because it’s under a Creative Commons license, but it’s a Creative Commons non-commercial. And so by the OSI definition, you can’t have a non-commercial writer in an open source license. And so technically, it’s not open source. And I’ve been trying to now change to not call Pro Git open source, because if it’s under a Creative Commons license, I guess it’s not open source. Like, some of it is. It’s CC0 or whatever; that is an OSI one, but I guess the other ones aren’t, or… I don’t know. This part of the complication, is that I’m fairly sophisticated in this matter, and I still get confused sometimes. But I have definitely been calling the book open source for a long time, and a lot of people do, because it’s available… But it is technically non-compete. And there’s not really an OSI non-compete license.

So there’s a movement by the Sentry guys to try to use software commons as sort of in this realm, of source available, but sort of being engaged in the community… But again, there’s people who have problems with the commons phrase as well. And the argument is that Creative Commons has a non-compete license as part of its suite, and so if that can be a commons, then can this be a commons…? Who knows? But –

I think it’d be zoom out one second on this, I think the matter really is… So you mentioned Pro Git, your book, and you calling it open source… And this is a great example to juxtapose these two arguments together, because they’re both centered around you. Because you said one thing on one side, and you said another thing on the other side. I don’t think anybody cares that you accidentally call your book open source. And the reason why is because you’re not trying to use the quoted term open source and what it means as marketability for a commercial project. That to me is the offense. And I don’t even think you try to do it. That’s the thing I think the people who care about it is trying to protect, is trying to prevent folks from operating a commercial company with commercial interest and the marketability of the term open source, and what it means for their thing to use it incorrectly. That I think is the challenge.

Yeah, I guess my only pushback on that would be I don’t think any company that accidentally calls their thing open source because it’s under BSL, or FSL, or whatever, gets any market share from that. Like, nobody cares. Nobody’s like “Oh, I’ll use that because it’s open source.” I don’t think it helps the marketability of something.

I don’t know about that though. I mean, I think there’s a maturity level. If you are mature enough to know and use the FSL or the BSL, or a particular license, then you’re mature enough to know what open source means. And when you say “open source”, and you know what it means, then you’re using it incorrectly, because you know.

Yeah. So here’s an example, Scott. So we had Josh Padnick on the show, talking about TerraForm; you’re aware of the whole HashiCorp relicensing situation with TerraForm…

Yeah, yeah.

OpenTF, which became OpenTofu. And I asked him specifically - he’s a longtime contributor to TerraForm, and he’s part of the fork in the wake of that relicensing. And I said “Josh, if TerraForm had been FSL from the start, Functional Source License from HashiCorp, eight years ago, or how many years ago was when the project came out, would you have contributed in the way that you did?” Because he has hundreds of contributions over the years to the open source TerraForm project. And he said “Absolutely not. There’s no way I would have put my time and effort and skills, donate it to a functional source-licensed project.” And so he was offended, of course, because of the rug pull. But that was a situation where TerraForm being open source got him involved, whereas with functional source it wouldn’t have. Now, there’s lots of people that don’t care, but there are also people that care, and they won’t contribute for that reason.

[01:26:01.03] I do want to double down on – I think we all agree that there needs to be a third term for this thing.

Oh, I do agree with you. Yes.

But I do want to differentiate a little bit, in that I think one of the things that we miss from this conversation a lot is the differences between I think three functional classes of software. One is libraries, which cannot be GPL. I mean, in lots of cases. Because if something’s GPL or AGPL in the library – like, we run Cargo stuff on Rust all the time we’re distributing a binary. We need to be very, very, very clear that there’s no GPL code that we’re linking into the app. So OSI is not the important definition. It is “Is it copyleft?” So copyleft is an important definition to me.

The other is infrastructure. And so if it’s an infrastructure tool, I think, or if something you want to build infrastructure tooling off of, like – I mean, I would even argue Redis, or Open Search or something goes under this, right? Like, is it okay for you to change licenses at some point? Because I think that the answer is generally no, because people assume that infrastructure is going to be available in the way that it’s available. And the downside for somebody building it – like, this does create a marketability thing - somebody will adopt it because it’s under a specific license. And then you can’t have that market share unless you’re really, really good at it. And I don’t want to use – I think I want to use the one that I have in my AWS instance, or whatever, that I’ve already built off of. So that does feel like a little bit of a rug pull, because it makes me do work when they change that, theoretically.

And then the third class that I think is really important is applications. And applications, I think, are different than infrastructure, because you can’t – what is competition in that sense? It’s a very different thing than trying to build something on this sort of infrastructure, a sort of tool, to say “Okay, it’s the Git client, or some desktop application, or your web browser”, or something like that. Like, of saying “Okay, only Google can distribute Chrome”, right? Yeah, that has implications, but I don’t think anybody that’s contributed to Chrome were people who wanted it to be Brave, or something. Like, had that in mind. If Google switched to being Chrome’s FSL, or something, I feel like most contributors - maybe some, but I feel like most contributors don’t care that much, because that’s not really what the value of it is. The value of having it source available is a little bit different than being able to depend on it for being able to deploy infrastructure, or build infrastructure around something.

Anyways, I don’t know really what the answer is, but I do think that when we talk about licensing and commercial licensing and open source licensing, that it’s important to sort of differentiate these classes of software, because they have very different implications of what licensing means in those contexts.

Yeah, I don’t disagree. I think there are a lot of nuance, and there’s a lot of different categories of projects… And I think that you could define them differently. Like, one man’s application is another man’s infrastructure. Like, is github.com – it’s an application, right? Or is it my infrastructure? It depends on which perspective you have it from. But I definitely see where you’re coming from, and I agree that we are lacking the facilities to properly communicate… Which is why you do have to drill down. I mean, this is the way it’s been for a long time… You mentioned copyleft, and there are many developers that don’t know that if I pull in a GPL library into my work, there’s a lot of implications there. I didn’t realize that. Many developers do know that, and then they teach the other developers, or maybe the CTO teaches the team leader, whatever it is, and eventually you figure it out, or not… Hopefully, there’s policies and stuff… But this stuff has never been simple, and I feel like it’s just gotten more complicated as software has gotten more pervasive, and had more use cases. I think AI - we don’t need to go here, but AI makes it even more complicated, because it’s not merely code, right?

Yeah, that’s a really interesting… Yeah, I don’t even want to get into licensing our [unintelligible 01:30:04.14] with GitHub, and stuff…

No, let’s not. We’ve done it before, it’s a rathole…

[01:30:11.09] To zoom really far off though, I think what is important though – let me just say this one point, and we can go any other way where you want to go. I think the important thing is that I’m not offended by you, personally. I’m not angry that you said what you said on Twitter. I’m not mad at you a little bit. I’m thankful that you care enough to show up and care so deeply about Git 10 years ago, or whatever the number was, to now even, that you’re contributing back. I think the contribution is what we should honor, not so much the way in which we do the contribution. You’re trying to innovate, you’re still showing up, you’re still doing things, and you’re still offering a way for people to be involved… Whereas you could just sort of be like “No. Proprietary. Everything behind the scenes. No can play.” Now, you may not get adoption; that’s a whole different animal. But the point is that you are showing up, you are innovating, and you are providing a path to have community and share.

I mean, what’s interesting to me, I guess, is - and again, this is another down the line of GitHub helps create this problem. So I feel partially to blame for this, is sort of genericizing source available, and open source, and not making clear kind of what differences are. Because to me, as somebody who writes software, and somebody who runs software, and somebody who uses software, and as a company that depends on and produces in the same ways, licensing-wise, I care about essentially “Does a lawyer need to look at this, or does a lawyer not need to look at this?” And I kind of separate my licenses into that. If something’s FSL or whatever, but I’m clearly not competing, then I can be like “You know what, I’m pretty sure that a lawyer doesn’t need to look at this, and I don’t need to care.” If it’s OSI, I still need to care, “Is this copyleft or not?” That’s what I care about. Everything that I do is MIT. I don’t think I’ve released anything under anything other than MIT until this, from a corporate perspective. Or it’s been closed. But I do need to know, “Does a lawyer need to look at this?” Because even I’m unclear sometimes, “What can I do with AGPL software?” Not everybody knows exactly – like you were saying about GPL, but AGPL is in some cases even more complicated… Because if you’re doing a service [unintelligible 01:32:18.20] And why are people using it. This was actually kind of what came down to GitButler, was we were talking about a lot of – I think Zed is AGPL as well, or at least the server component… It’s trying to say “When you AGPL something, and somebody wants to build something around it or use it for something, in a sophisticated organization, you have to get a lawyer involved”, or you need to have a relatively sophisticated understanding of what you can and cannot do with it.

So to me the spectrum of importance is really “Do I need to care about this?” Or “Does my lawyer need to care about this from a corporate perspective, or do they not?” So I love MIT, Apache, I love anything that doesn’t involve lawyers, or give lawyers money. Those are my favorite licenses. If a lawyer needs to be involved, then I’d rather have it be simple. And I think the FSL is somewhat – I mean, it has been argued to me that there are complications here as well, because nobody really knows what does it mean to be competing.

I was gonna say, you do have to get a lawyer involved, because to define competition is very difficult in the age of –

You 100% need a lawyer involved with FSL. But you would with AGPL as well, to a degree. And so the question is, what makes the lawyer’s job easier, or what makes you easier if you do have to interact at this level? And I care about that, because that takes time. So take your time or don’t take your time, but try to make it simple if you do. And FSL, BSL, or whatever - they don’t make it totally simple, but I think of most people that are reasonable have some clarity of whether they’re competing or not. But yeah, it’s yet to be seen, it’s a new thing, but at the end of the day we can all agree that it would be nicer to have a little bit of a different way of talking about this, or way of trying to figure out “What can I do? What can’t I do?”, and give companies a path to make source available on more of their things.

[01:34:13.15] I do really want to see a world where everything I’m using is on GitHub, or wherever, but I can look at it and if there’s something I want to change, or fix, or whatever, I’m not worried about my freedoms and IP and stuff, I just want to make sure that I could fix it, and it could theoretically be accepted somewhere. I find that very valuable. So I want to see that world, and the question is “How do we get there?”, I suppose.

Yeah.

Well, Jerod, you said functional source earlier, and when you said it, I don’t know if you said it differently than just simply “functional source”, but for whatever reason, it sounded pretty good to me.

[laughs]

Like, there’s open source, there’s functional source, and there’s proprietary source, which is actually no source. There is no source to look at. It’s just proprietary. You can just drop the source.

Well, I mean, 13 years ago Scott Chacon made Git cool. So he can make functional source cool. He can do it again. All we needed a charismatic leader to just champion a new term.

That’s my new banner! [laughter]

What’s cool but functional source license too coming from Sentry is their business name is not actually Sentry. They DBA as Sentry. And I know this because we do business with them. And their business name is actually Functional something or other, but their name, the business name is actually Functional something. I should look it up right now, because I feel like an idiot. But it’s got the word functional. It’s not Sentry; their business name, their LLC is not –

Is that why it’s functional source license, because it’s –

That’s right. And I think that’s why they went with functional as a result, because of that reason. Let me pull this up… Yeah, Functional Software Inc. Sorry, they’re not an LLC. Functional Software, Inc. is their official business name.

There you go. Well, let’s get back to GitButler. Let’s wrap this sucker up. That was fun diversion on the open source licensing.

That was fun. I dig it.

I think we could go around that merry go round a few more times…

We need those kinds of debates though.

We do.

I mean, it’s those kinds of conversations that mature our audience, mature our ow thinking… My position is layered on from years and years of these conversations, really…

For sure.

And learning, and listening, and then challenging whenever I feel conviction etc. And we only get there because we together push back on what everybody should do to get to where we’re trying to go.

Yeah.

It’s good stuff. Go ahead, take us there, Jerod. Back to GitButler.

Well, I would just like to let Scott tell folks how to find it, where it’s at, how they can get involved… I’ve downloaded it, I’m trying it out for the first time this afternoon… And I’m sure he’d probably like some more people to kick the tires, right?

Absolutely. Yeah, you can find it at GitButler.com. Actually, one of the funny things, if you have a bunch of sort of startup people listening to the podcast - if you start a company, try to name it something googleable, which I feel like lots of companies come in and do something that’s very, very hard to Google without putting app, or something at the end of it. But yeah, if you type in GitButler, you’ll always find it. There’s nothing else named that. But yeah, GitButler.com. And the best thing is to – you can also find it at github.com/gitbutlerapp, which - /gitbutler was not available. And download it, or try it from the source code or whatever if you want to… And I think the most important thing is to come on Discord, if you’re interested; even if you don’t want to use it, you just want to talk about version control stuff, or talk to me about the new edition of Pro Git, which I’m kind of starting down the road of doing a third edition of that… Discord is awesome. It’s actually one of the things I really wished kind of was available in sort of the open source world a decade ago. We really didn’t have Discord. We had IRC channels or things like that, but I think the level of engagement, even – for me, I use Planet Scale for SQL, and they have a room, and I can go in the room and I can ask questions. It’s such an interesting, awesome, new thing for companies and for open source projects to have them all have a room that you can go into.

[01:38:08.07] Like I was saying before, I got interested in Jujutsu. They have a Discord channel; you can go in and ask questions, and try to say “How did you do this? What’s the future of this?” or whatever. So if anybody gets something out of this podcast, and they want to engage, I would love to talk to you. Come to the Discord channel. There’s a link off of the homepage. And what’s really important to us in this sort of beta phase is to talk to people.

Absolutely.

Or if you’re in Berlin and want to get a beer or something – if you guys are ever in Berlin and want to get a beer, let me know.

I’ve never been to Berlin, but I would love to go, and I would love to have a beer.

Same.

So who knows…?

Was I in Berlin? I was somewhere in passing. The reason why I can question it is because –

Are you asking us?

…I was actually on my way from Sarajevo, Bosnia, and I was bused to Germany, and flew from Germany back to the States when I was in the military… And I was young, obviously, and I like to party a lot, and so I just partied. I think I was at like Rammstein, potentially. I don’t even know where I was at. All I know is it was in the country Germany, and that was it, pretty much. But you also have the Merge coming up, the developer experience conference.

Oh, that’s true. Yes.

Is that something you’re a part of, or what is this?

Yeah, so we were doing all of these conferences, and I was speaking in lots of places - I still am - and we were sort of buying beers for everybody and finding this really valuable. So we kind of had a dumb idea, and we were like “Let’s just do our own conference about all of these things that we’re learning now”, like this Discord thing. How do you engage in an open source community, or source available community? How do you start a software company today? And there’s all of these tools that weren’t available at the beginning of GitHub days that I’m really interested in. There’s influencers, there’s YouTube, there’s Discord… There’s all of these tools of how to engage in the larger software development community, how to do it well, how to communicate effectively, how to communicate authentically… And so we’re bringing together a bunch of people to talk about developer experience, which I find very interesting. I feel like people don’t know very much about it, or don’t think about it enough.

This is one of the things that I think differentiates the Git CLI versus GitButler, is that we really, really care about the developer experience. We want to make sure “What is your workflow? What are you doing? How can we engage? How can we make this easier?” And so I’m trying to find all of these companies that do really great developer experiences, or have great sort of communication with developer communities, and try to learn from them. So we have some speakers from Sentry, from HashiCorp (it’s interesting), from GitHub, obviously… And we’re bringing everybody to Berlin, so it’s also a good excuse to come to Berlin.

There you go.

But yeah, you can find that at merge.berlin, and it’s in June. So June 13th and 14th.

Let me suggest one more name to your list, if the person’s name has not already been on your list… And that name is Zeno Rocha, the founder of Resend, creator of Dracula, and - that’s the way he says it, is Dracula, because he has an accent, and I love his accent… Big fan of DX as well. He’s got some thoughts and some philosophies he’s shared, so… If you don’t know him, you should add him to your list, at least to check out… And he’s actually gonna be on the podcast here short enough, because that’s the next episode coming out.

Nice.

Very cool. The Merge, Berlin, all the fun things. What else is left, Jerod? Is this the end?

We covered it, man. We did. We’re here, we’ve arrived. We’re at the end.

Well, it’s good to have you back after all these years, Scott. Keep in touch…

Let’s do it more frequently than every decade or so. We should do it more often.

For sure.

Yeah, I’ll see you guys in ’34. [laughter]