The Changelog: Software Development, Open Source - Replacing Git with Git (Interview)

Episode Date: April 12, 2024

This week we're talking to Scott Chacon, one of the co-founders of GitHub, to discuss the history and future of Git and Scott's new project Git Butler, a branch manager tool that's aiming to improve the developer experience of Git using Git. We also touch on the contentious topic of open source licensing and the challenges of defining "Open Source", FSL vs GPL, and more.

Welcome back. This is the Change Law. We feature the hackers, the leaders, and the innovators in the world of software development. And Jared and I are joined by one of the OGs himself, one of the co-founders of GitHub, Scott Chacon. Scott is still into Git. Can you believe it? We discuss the history and the future of Git, the only version control system out there to most developers out there. Scott explains how GitHub helped to propel Git to success and talks about the importance of social coding and open source. We also discuss Scott's new project, Git Butler, a branch manager tool he is working on.

And we discuss the concept of virtual branches and their benefits. He shares his thoughts on the future of version control systems and the potential for innovation in that field. We also touch on a contentious topic around open source and licensing and the challenges of defining quote open source end quote and what it takes to communicate the different categories of projects that have their source code open, but they're not officially quote open source in the OSI licensing standard. Buckle up. This is a fun one. A big massive thank you to our friends and Thank you. In 30 plus regions. Launch net for free at fly.io. Okay, friends. The on-call scene is getting hot.

Literally, our friends at FireHydrant have their new solution out there called Signals. What you're about to hear are real reactions from PagerDuty users after seeing FireHydrant's on-call solution called Signals for the first time. PagerDuty, I don't want to say they're evil, but they're an evil that we've had to maintain. I know all of our engineering teams, as well as myself, are interested in getting this moving the correct direction, as right now just managing and maintaining our user seats has become problematic. That's really good, actually. This is a consistent problem for us and teams is that covering these sorts of ad hoc timeframes is very difficult.

You know, putting in like overrides and specific days and different new shifts is quite onerous. And you did the most important piece, which is didn't tie them together, because that's half the problem with PagerDuty, right, is I get all these alerts and then I get an incident per alert. And generally speaking, when you go sideways, you get lots of alerts because lots of things are broken, but you only have one incident.

Yeah, I'm super impressed with that, because being able to assign to different teams is an issue for us because like the one the one alert fires for one team and then it seems like to have to bounce around and it never does, which then means that we have tons of communication issues because like people aren't updated. No, I mean, to be open and honest, when can we switch? So you're probably tired of alerting tools that feel more like a headache than a solution, right? Well, Signals from Fire Hydrant is the alerting and on-call tool designed for humans, not systems. Signals puts teams at the center, giving you the ultimate control over rules, policies, and schedules. No need to configure your services or do wonky workarounds and just data seamlessly from any source using webhooks and watch as signals filters out the noise alerting you only on what matters manage tasks like coverage requests and on-call notifications

effortlessly within slack you can even acknowledge alerts right there but here's the game changer signals natively integrates with fire Hydrant's full incident management suite. So as soon as you're alerted, you can seamlessly kick off and manage your entire incident inside a single platform. Learn more or switch today at firehydrant.com slash signals. Again, firehydrant.com slash signals. So we are 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 Git to the next level was GitHub. Because, gosh, what year was it, Scott, when you co-founded GitHub and 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 incorporation of the C Corp, but I think we were working on it on and off or volunteer or whatever for some time before that. So, I mean, 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. A few decades. Yeah. So many times 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 A-Press for doing a third edition of the book and uh 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 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'd be fun they're so cute it's not that bad right 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 like back then there was a war over SCMs like what was going to win because Mercurial had a lot of users

you know it's funny I was just at FOSDEM conference in Belgium and I I was talking to, I was, we sort of rented out a bar and we're buying people beers and stuff. And there was this table with the guy that does Pujol, which is another version control system now that's kind of based on darks or similar to sort of patch theory, theory patches. And then the guys who are basically maintaining Mercurial these days. and we all kind of sat down and had a beer and talked, you know, we were all kind of smack talking and saying, like, what's good about that? 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, you know, the days of Mercurial and Darks and Arch and, you know,

all of these sort of bizarre, right? If anybody remembers those. Oh, yeah, bizarre. But, yeah, it's an interesting new world of just uniformity. Like, now I talk to these conferences and, you know, people at these shows, and everybody, you know, like I said, they grow up using Git, right? It's an afterthought, yeah. 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. Like, man, you know, for old guys like me or us, I suppose, you know, trying to remember what was open source like when we're sending patches to track or whatever. Oh yeah, track, T-R-A-C, yeah. What was it like before Git for you then? Like, was Subversion your thing? Was SVS your thing? Where were you hanging out at? Yeah, no, for me, you know, I graduated from college in 2002, I think.

And so my first job, actually, we were FTPing files onto the production server, right? Of course. Yeah. These PHP files, and you just, not even SCP, what was it, FTP? Yeah, you just FTP. Yeah, SFTP or FTP.

SFTP was the other one, yeah, secure FTP. And, you know, not even SCP, what was it? FTP, yeah, you just FTP. Yeah, SFTP or FTP. SFTP was the other one, yeah, secure FTP. And, you know, we would just straight into production or even, you know, SSH in and edit the files in place or something, right? And just be like, just make sure to sort of copy these files because I just edited them. So, you know, you need to, yeah. Dot back.

You put an underscore two on it, you know, on the file name. And it was one of the first things I did when I got there is I put in uh cvs i think um at the time and then we kind of quickly moved to subversion but yeah i used subversion for for a while and and when git came around actually we were using perforce at the job that i was at um which is still you know you can still do although i think now it's like get back like you can use perforce for with git clients or something every every it just pervaded, you know, sort of the whole world. But yeah, I 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.

Right. Like like 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 of just saying like this is is much, we were rolling RPMs and stuff before that. And we're like, you know, what we could do is just have them fetch. And then it's nice. It gets sort of just the deltas, right? Like it doesn't get, 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 my first, you know, sort of usage of Git. And so that's kind of what led me to, you know, write documentation for it and stuff is I learned it and I found it very cool. And I was like, you know, sort of usage of Git. And so that's kind of what led me to, you know, write documentation for it and stuff is I learned it and I found it very cool. And I was like, you know, it'd be nice to make other 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. Right. So yeah, that kind of got me into that is we were using Perforce for our 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 underscore two kind of stuff also. And so I was very much learning Git when it was, should I learn Git? Should I learn Mercurial?

You know, it was very much the VHS and Betamax, the Blu-ray and HD DVD timeframe of like, which one's going to 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 like the education guy. Like I was always like scotch a cone. I mean, you 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 get sem.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 no i i actually

when i first started at github when when I kind of joined the guys full time, I had been involved in writing documentation and stuff. I think I'd published the peep code PDF, Git internals peep code PDF before that. And I liked writing about this and trying to make this easy. Peep code. Yeah. Do you guys remember peep code?

Peep code. Oh, you're doing a Jeffrey Grozenbach impersonation. I'm trying. My best. He has such an awesome voice. He has a very specific, nuanced voice. He does. But yeah, I had this, you know, I had that and had some screencasts and stuff that I

had done for that. And a friend of mine who worked at Google, Sean Pierce, had asked me to come into Google and they were kind of switching over to Garrett and Git for their Android team. And he had asked me if I'd come in and they could, you know, Google could pay me to like do this tutorial type thing for their Android team. And I was like, yeah, that sounds fun. And then I, I decided, you know, that I would join the GitHub guys. And they were like, I was like, can I bring this, you know, income in like, well, I'll just have Google pay GitHub, right. And we'll kind of have this

education arm of, you know, me going around and like, I have a gig, right? And we'll make it a GitHub thing. And they were like, yeah, if you're coming in with Google as our, you know, your first client, right? That's right. That's fantastic. We'll, we'll, uh, yeah, we'll let you do that. Right. So it's 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, right? Like the Android team didn't use GitHub. I don't know, maybe they do now, but like they didn't at the time. Or I did Motorola or Qualcomm or, you know, there's all

these sort of Linux, like Android was going out and people like all these chip manufacturers and everybody needed to learn Git for Linux stuff and so that they could work on Android drivers or whatever. And so I, you know, 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, you know, I think it helped spread the brand and things. And then I would do lots of conference talks and all of that.

So yeah, I really, now I'm doing conference talks and stuff. Again, for Git Butler, right, like going on stage and talking about mostly Git, it's kind of the same thing, right? 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, you know, 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, these, you know, you think, you know, Git type talks, but yeah, the world has changed entirely, right? Like now everybody's

grown up with it. It's, it's such a different, different world than being like, you know why you should use Git. It's because it's good at branching or something. Everybody's like, I don't even know what to compare it to, right? Like it's because it's good at branching or something but he's like i don't even know what to compare it to right like right it's it's almost the way it's ubiquitous it really is which uh based the question like what might be next you know because at one point subversion and you know 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 said, Jared, GitHub was the killer app that made Git win, and it won for good reasons. But it was, you know, there's a lot of,

I suppose a lot of maturity around GitHub, Git, et cetera, in software development at large across the globe. Like this is a phenomenon that happened not just because Git was great, but also because GitHub is also great at social coding and connecting people and bringing projects together and popularizing open source and open source moves fast, keep up kind of thing, which is what we founded ourselves on was this open source moves fast, keep up. The keep up was actually meant to be snarky.

And that was when Netherlands addition to it. I was like, open source moves fast. This is what we should do. And he's like, yeah, but you got to keep up. You know, given that, like what might come next? I mean, we're in an AI era. something else coming what are your thoughts do you have any purview on that i guess there's two different things one is conversion control tools be better right which i think is is clearly true like i feel like the git user interface hasn't changed really massively since i started

you know for 15 years now right like it's and i think there hasn't been really massively since I started, you know, for 15 years now, right? Like it's, and I think there hasn't been a lot of innovation in that space of what can a version control system be like. There's, there's been really interesting things like, you know, Darks or Peugeot has been around for a while and they have kind of an interesting idea of sort of patch commutation or, or, you know, how they deal with merge conflicts and stuff, but it's always been so obtuse, like it's so difficult to use, right? It's not really, it doesn't make things that much easier for the user. Generally, it's just, it's kind of mathematically interesting. And so I like this idea of like, what, what could be easier on users? Actually, one of the other than, so I'm working on Git Butler,

which we're trying to do that, right, of just re-implementing the user interface and using, making sure that we're still writing out Git tree and And at the end of the day, right, like 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, right? 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 Git Butler and kind of what we're doing, but one of the other interesting projects that I've been following recently is uh jujitsu which is another sort of google project i don't know if you guys have played with that but like it's an interesting

idea of of kind of how to think about version control differently and and if it can help with sort of modern workflows of what we're really trying to accomplish so one of the things that they do is they don't have a staging area, just sort of the working directory is kind of the staging area, but they're kind of constantly rewriting commits. So it's like constantly rebasing, but like in a very easy way, right? And you can create a commit, sort of, you know, three commits down and sort of insert it into two different commits and then start moving patches sort of into that, like after the fact, and it kind of rewrites everything above that. And 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 it and it rebases everything on

top of that. But I would check it out. It's really, really interesting. But I like this idea of saying what could, like, this doesn't have to be our user interface, right? Like 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, right? 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 like how to craft that, right?

There's lots of different ways we can do that. I mean, we even see that in Git. People complaining or like arguing about merges versus rebasing or sort of PRs right like if you're taking in review are you are you read sort of rebasing a patch series and trying to keep it like a patch series like the old sort of mailing list days or are you just adding new commits onto your pr because you you figure it's sort of a squash you know unified diff anyways so it doesn't really matter like is the commit interesting is the the PR interesting, right? Like, right. There's, there's all these workflows, debate all these things. Yeah. And,

you know, I think there's, there's strengths to all of these things. And so it's really about how do we want to work, right? Like, 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? Right? Or does it get in your way? Are you getting around it somehow? And I think I think with get 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, right? And some of it is sort of AI, you know, there's there's AI stuff that I think can help with that. But there's heuristic things, you know, there's there's

algorithmic, simple things that we can do to or just UI, just user interface stuff, right. Of just, just making it easy to, to sort of absorb changes into previous commits or do fix up auto squash type stuff in a more automatic basis, right. Like, or doing, you know, sort of commit based review is a big thing that I see all over the plate, right. There's like fabricator and there's all these tools that get around, you know, GitHub sort of squashing everything into one unified div. People want to do, you know, from a, sorry, I'm talking a lot here, but I guess. I love it. You're into theory. I mean, this shows how deep you go and I love it. I, 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, right? 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, right? 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, right? 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, right? 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, right? 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 use it to save your work, right? Like you have to, this is why people do like 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. I think what would be really ideal is to separate these out. So you have a mechanism that saves your work, right? 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, right? In a way that is maybe better than the commit message and ways to share your work that you don't necessarily have to commit. 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 that works and good tooling that works for everybody, right? 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'd 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.

You were on the changelog 13 years ago talking about Git. Now you're on the changelog today talking about Git. Right. And so it was kind of funny. It's like a 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 mean, yeah, no, I'm not bored of Git.

So what happened, I mean, to answer your first question first, I suppose, is 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 kind of spun it off. It was in that, you know, if you guys are in this 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, right? Where it's like, it's not not working, but it's not really working. And so

you're like, I'm almost there, right? And so I, you know, we, I did that for several years, like language learning is, it's either, you know, sort of duolingo where it's very cheap and scalable, but it doesn't work very well, like practically, or it's like italki or something or what we were trying to do, which is you're talking to human beings and, and, you know, it's very difficult scale and it's very expensive for users, but it does work very well, right? It's more of an in-person language school type thing. And so I kind of got into this world of trying to figure out, can, you out, can we bridge this to some degree? Because I got very frustrated. I lived in Paris the last year that I worked at GitHub and I was trying to

learn French. And so I think, you know, like any startup-y type tech person, I was like, I can solve this problem, right? 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. Like, and I tried to tackle that and it kind of worked and it kind of didn't work. So from a, you know, sort of business perspective. And so when that, when that kind of ended and I, I spun it out, I was just kind of looking for what else to do. And, and I also do some angel investing, you know, since the GitHub exit, I, you know, 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. You know, we did it

every once in a while, which is if you could run any of these companies, like which of these companies would you find the most interesting to be a part of, right? 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, right? Of just, it kind of got me back into it. It was kind of nice to take a break for a little while of not thinking about this all the time. I was still using GitHub every day. I was still developing, you know, but I didn't really look at the problem set. And what they tried to do was more of like a Google doc. Like 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,

right? Like they, you never commit in Google Docs, right? Like, you're not, you're not sort of pushing changes somewhere. It's sort of constantly recording, it's constantly saving stuff. It's just trying to make sense of it in the background for you. And it's there when you need it. But otherwise, you're not really thinking about it. And I was like, why, you know, why don't we do that in software? Like, 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. And I found that so interesting of just looking at how come nobody's really introspective this for a while, right?

Or nobody's really tried it. Every Git client out there is, you know, it's a button on top of a command line that, you know, invocation that you would run. It's not, there's nothing new, right? Like 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? Like kind of going back to first principles and saying, let's start over, let's pretend GitHub had not sort of, you know, piggybacked on Git, right? But it created its own CLI, right? Or created its own client. Like, what might that have looked like if we had thought about it from first principles and

really tried to say, what a nice experience for what you're doing. And that was kind of what started Git Butler, right? Is my partner Creel, 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 into 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 or from Perforce or whatever.

And it always had to be Greenfield projects. It was so hard to move a whole team or a whole company or something. And so we got there, but it took a really long time and it was a fight all the time, but, but to come from scratch and try to take on Git and GitHub, right. It'd be like, you should move from that to us because we're better. Right. Like that's insanely difficult to do. And so we, we decided to kind of go the middle route of being like, let's GitHub's great. Let's keep GitHub. Let's just rethink the client side, right? Like how, how do we create stuff to push to github how do we how do we manage that information and manage that workflow and help that be better right and

i think that's 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 right and we've done really interesting things i think around virtual branches and stuff that has never really been in the git world before but there's you know now we're look i'm looking at jj and at jujitsu and saying what can world before. But there's, you know, now we're looking, I'm looking at JJ and jujitsu and saying, what can we steal from this? There's interesting ideas here, right? 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, or, you know, Mercurial or Peugeot or whatever, and kind of say what works in these systems? What is interesting? What, what, you know,

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 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, right? 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, right? These this massive monorepo with hundreds of millions of files and tens of gigabytes of data, like 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? And there's, you know, 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 like 10 commits a day on the

in the Git project, right? Like there's tons of work going into this. So it's like, let's look at, you know, it's interesting to look at what what has happened, right? And so that's that, yeah, I've been spending a lot of time on that lately. Sorry, I feel like a steamroller. No, no, no. I would love to dive right into the nitty gritty myself because I have downloaded Git Butler. I'm looking at it. And virtual branches, as you said, was kind of the thing at the forefront right now in terms of like 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? Yeah, I mean, it was an interesting, like, I'll go back to the idea of this first principles thing, right? Like, I find this really, really interesting and valuable tool in doing startup, you know, in startups, right?

Is this idea of saying, what are we really trying to do here, right, with this feature or with this tool or whatever. And we looked at branches, 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, right? And started questioning, like, why are we like, there's a common problem where you're working on a feature and then you, you notice a bug, right. 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, right. And 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 like, you know, there's not a great way of sort of solving this. And, and I was thinking that it's not necessarily, you don't need to do it that way, right? You only do it that way, because Git has the concept of head. So you're on one branch, right? There's no way of being on two branches or something. And it has this concept of an index, right? Which is sort of your next commit. But again, there's one of each of these, like you can't have multiple of these things, but technically

there's no reason not to, right? Like you can, you could, right? 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 or that context, right? And so that's really all that we're doing is we're running basically a get diff and we see every hunk and we're bookmarking each hunk for branch A or branch B or branch C or whatever. Like you can be on, 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, right? 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, right. And then they don't actually commit, like they don't push

that merge, that merge artifact somewhere, they just, they want to make sure that it all works when it's together, right. And ours is kind of the opposite, we're starting essentially with a merge product, and then extracting them out into branches, right, that we know will end up 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 as separate reviewable branches, right? So instead of stack divs, it's kind of like parallel, you know, stack branches, it's like

parallel branches. So as long as, you know, the only constraint is that you can't have merge conflicts between branches, right? Because you only have one working directory. So mathematically, you can't really do that. But that's kind of nice too, right? Then you know, all your branches will merge cleanly because you started out with the merge product. So, but yeah, really what I was trying to do is just say, how do I want to work, right? 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, right? 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, right? Or fix lots of stuff and then just sort of organize them into the branches that you want, right? 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, right? Like 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 allow us to, if you want us to use AI for your stuff, to say, give me a branch name, right? It'll be anonymous essentially until I get enough work and it can kind of recognize what I'm doing and then it give me a branch name, right? 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, right? Like there's all of these things that you just spend a little bit of time here and there and it's a little annoying, right? And you don't think about it, but there's a lot of it that isn't technically necessary. What's up, friends? I want to share an awesome new announcement from our friends over at Crab Nebula.

Crab Nebula is the official partner of Tauri. For the uninitiated, Tauri is a toolkit that helps developers make applications for the major desktop platforms using virtually any front-end framework in existence. The core is built with Rust, and the CLI leverages Node.js, making Towery a genuinely polyglot approach to creating and maintaining great apps. So building applications with Towery has always been an incredibly joyful experience. However, once the applications are built, distributing them and rolling out updates has always been cumbersome. This is why we are thrilled to be part of this announcement from our friends at Crab Nebula on their latest product, Crab Nebula Cloud.

The problem really is the cost of distributing applications, the security, and the feedback and analytics. Just thinking about cost alone to distribute new applications at scale, it can get very expensive when bundle sizes compound with the number of users, which further compounds with frequency of application updates. Always be shipping, right? A 500 meg application distributed across 500 users with nightly updates leads to a total of around 7.5 million megabytes. That's 7.5 terabytes transferred in a single month. Now, based on popular cloud pricing, this could easily lead to a bill in the ballpark of around $90,000. That's a lot of dollars. More so, distributing updates requires complex

cryptography to ensure that an update is the original safe artifact for users to download, install, and execute. And then collecting meaningful analytics is more challenging with desktop applications compared to web-based services, impacting the ability to make informed updates and improvements. So at the heart of Crab Nebula Cloud is a purpose-built CDN, ready for global scale, ensuring seamless integration with any CI-CD pipeline, and first-class support for GitHub Actions. And security updates are a first-class citizen. Leveraging the power of Towery Updater, Crab Nebula Cloud provides an out-of-the-box update server

that any application can call to check for signed updates, and if the update is available, immediately download and apply it in an instant over the air. And of course, Tauri is open source and Crab Nebula is a company born out of open source. And they're giving back to the open source community by giving steep discounts and subsidies to open source projects built with Tauri. To learn more, get started and check out the docs. Go to CrabNebula.dev slash cloud. That's crab, C-R-A-B, nebula, N-E-B-U-L-A dot dev slash cloud. Once again, crabnebula.dev slash cloud. 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. And then, yeah, absolutely. The ability to just take a particular change and apply it to multiple 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 like drop all this go over there do the thing do another branch get that upstream come back over here oh actually they'd be useful to have on this branch now i got got to 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, it's, you know, it's interesting to what I found most valuable, I think, is going out and doing these conferences. And, you know, 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. 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, you know, what is frustrating and what is difficult and what could be easier in the way that you work

in this manner that they haven't really questioned in a decade. So Git Butler right now is a desktop client. It calls itself a branch manager even. It's not even a full Git client, right? Like you're really focused on branches for now. There's lots of things we don't do. Yeah, yeah. And it's, you know, it's beta.

It can be slow on some repositories. Like 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 and making sure it works everywhere, you know, perform it to a degree and trying to get a Windows build out and stuff like that. But, yeah, it doesn't do everything, right? There's lots of stuff it doesn't do. What it does do relatively well is this virtual branch thing. So, you know, I've been using it essentially as my only Git client for five months now.

But again, 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. 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. You can do different tools on these different things, as long as you're using the same database, right? 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, you know, there's like 145 commands in Git, right? So it's just like, what, 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 to each time question, what are people really trying to do with this? And 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, right? Or might be faster, might be easier. So to answer Adam's question from the original question was like, you know, 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.

Because first principles is too hard to compute with GitHub, and Git and GitHub is too hard. It's just... Well, it's also, you know, it's about how much better can you improve something, right? Can you make it twice as good

or 10 times as good or something like that, right? 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. And so it really depends on what it is that you're trying to do. I think it's very... 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 problem sets is 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 that 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 is something that everybody's hated forever and nobody's made better. GitHub's barely approached this at all, right? So, 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, right? There's nothing that makes this particularly easy. And so that's something that we really want, like, I mean, even the most basic thing,

right? Like, you don't know if your branch that you have a PR open on and your colleagues branch that they have a PR open on merge cleanly or not, right? Like GitHub could very easily just do in memory mergers of every open PR and say, this one's, you know, problematic with this one. You might want to start talking to them, but they don't do that. And so I'd like to see that, like, 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 is 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 had in centralized version control systems,

you know, two decades ago of saying, hey, you know, we don't have to be so bad as to lock a file, but we can at least let you know, you're editing that file, they're editing that file. Like, 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, right? Like it's always first person wins. Right. In Git, in decentralized merge conflicts. So I think there's a lot of work to be done there. It'd be really not like, how nice would it be to have that and to have some tooling where you could collaborate on merge conflicts, right?

Or have like the, so like Git has this concept of re-re-re, the reuse recorded resolutions. But if you have these resolutions that you can share and kind of network and talk about, right, 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, right? If you can't avoid the conflict. I think that would be a more ideal world, right?

So the question is, how do we make tooling that makes that good, makes it easier? I think AI actually has a good application here as well of, of theoretically, you could train a model that could be relatively good at merge conflict resolution, at least on smaller scales, because, you know, GitHub is a database of hundreds of millions of merges, right? Like so much data. And you can, 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, right? So you have this massive database of millions and millions of attempted merges that resulted in conflicts

and how they were resolved, right? And so 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, you know, just general tooling that 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 can be done entirely in memory. So you can do it and then see, hey, was there a conflict or not, right? Historically, with the older three-way merge 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, right? There's a new merge strategy called ORT, which was, I think was released a couple of years ago. And the entire point is that you can do it without a working directory or an 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 LibGit2 and stuff now, which is super nice, right? 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, right? And tell you what his name, Bonnie Chance. He's the creator and inventor of SQLite.

Oh, yeah. But he also created Fossil, which I didn't hear you mention in terms of an SEM. And Jared and I had a pleasure talking to him back. It's been a couple years now, Jared. It's almost time for Richard Hipp to return again. It is. the title potentially for that show if we do it but fossil had this same idea where every change i'm not sure if it's streamed and you can probably correct me jerry because you probably paid attention closer to the 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 on every machine you know 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 a decade ago

probably. It's been around for a long time. I haven't used it recently, so I don't know what the tooling or 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 Jiu-Jitsu or Darks or Bejewel 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. 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 sync and it says fossil supports auto sync mode which help keep helps keep projects moving forward by reducing the amount of needless forking emerging this is what we're talking about often associated with distributed projects and so like this needless forking emerging and branching and and you know is there a conflict it really is the ultimate question right once you Once you decide to merge and resolve the code back to production or production worthy, is 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, right? So there's obviously a lot of things we've all moved to decentralized version control. That was the whole thing in, you know, 2005, 2006, seven, eight, is sort of this rise of decentralized version control systems. But with it, I think, comes more by default, by definition, almost more forking, right. And more merge conflict problems, right. Because, because you can keep things sort of separated from each other. That that's how the systems are designed, right. To, to have some advantages, but the disadvantages are they're

not in sync all the time. Like you can't have merge conflicts with Google docs, right. It's a perfect separate thing to compare it to comparison, right? Is you can't have everybody's, it's always 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, right? And yes, the power of that is that you can experiment in a way that is completely freeing, right? And you can say, don't need to worry about what trunk is or whatever, if this is mergeable or 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, right? But it allows you to do that. Google Docs, you can't have merge conflicts, right? Which is, you could mark that up as a win. But on the other hand, it's very difficult to experiment, right? To sort of fork it and do something different and say, what if it was like this, right? And so I find that very, very interesting. Like, 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, what the feature is, what the project is you're trying to do. And I don't think there's a great answer, right? 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, right? 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 invested in and said, this is the one I would like to run. And you think this is a super interesting problem. I do.

Obviously. I mean, you nerd out hardcore on it, I can tell. I do. 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 Scene that's based out of Berlin that my partner and I run. And, and of all of them, I think I was the most annoying investor

to these guys. Right. Because as soon as I heard it, I was like, I want this. It's, I don't even know if I want to use this. I just like the idea of questioning this. Right. And I found that so interesting. And I, 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. Right. And here's all of, here's, here's my treaties on, on, you know, sort of versioning data, right. And versioning information. Did they ever just give you your money back? They're like, all right, Scott, we've heard enough. Thank you. Yeah. Well, I know. So he, he ended up, uh, sort of shuttering that because he had to pivot it to something else and was starting to gain traction.

But I approached him and I was like, I really want to do this. And you had pivoted away from this. Right. And so do you want to join me? Right. And we can sort of co-found a new company together and work on on this from the slightly different angle. Or can I take it? Right. Because I don't want to be the investor that then like comes in and then starts a company that, you know, competes company that competes with something they might want to go back to or something like that. And 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. Maybe they pivoted because they didn't spend your money properly. I mean, gosh. You got half to give back. Okay, I'm just speculating. I'm not talking to Boo. I'm just... It's actually very, it's very interesting because he had started this company and he knew what it looked like to start a company in the version control space, right? And then we did it again with a slightly different angle. And we've seen how different our community is, how different the adoption of the tool is, and it's working much better than the original one, right? 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 the space that people are using and people are adopting. And it's very energizing, right? It's very fun to try to reimagine the future and then be able to do it piece by piece and use it yourself energizing, right? 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, right? Like it's another fun thing of having a startup

where you work on a tool you use every day and you dog food it every day, right? And so having built a new version control system that I'm, or client that I'm doing all my version control stuff with on a daily basis and being like, yes, this is, it would suck to not have this tool anymore, right? Which is kind of what you want the benchmark to be of a tool that you're building.

Did you found this, I guess, then by yourself again? Or did you, like, what's the formation? Do you have a we, keep saying we, who's involved in GitButler? Is it you solo? What's the scenario? Yeah, so it's Kirill, 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, so it's, it's this, this, it's in the fun startup phase, right. Of, of, uh, 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? Like, you know, what's the team look like, right. That, that we want to have for the next 10 years, if things go well, right. Like early employees are so important. And so, yeah, it's, it's a, it's a very energizing, fun time of, of a startup life. And, and, you know, I'm not quite too old for it yet. So I figure, I feel like I have at least one or two more of these, you know, to go if needs be, but, but, you know, if we're, if we're reminiscing about, about what, 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

slash podcast slash 49 and just there's first of all our show notes back then were spectacular compared to today so that's uh 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's an animated gif of you i believe on the show talking to 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 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. As a baby. But I didn't hear you still have energy left. Curious about centralization, decentralization, not in version controls, but in product creation. I mean, you mentioned earlier how well-positioned GitHub is decentralization, not in version controls, but in product creation. I mean, you mentioned earlier how well positioned GitHub is in particular ways of reinventing things because of the data, the access, all the things they have. And I'm wondering, here you are trying to somewhat reinvent Git via a 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, you know, Borg to like actually invent it or go back to GitHub and build it inside there? Did that cross your mind or that's just too much?

I mean, it's hard to, GitHub, anytime that you're really big, right? It's hard to, it's hard to steer a rocket ship as opposed to a skiff or something, right? Like, like I think we're 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, right? Like when GitHub was small and we were essentially competing against, you know, Google Code or SourceForge or, you know, kind of whatever was on the horizon at the 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, right? And try to figure out if that's better. I think it's very hard to do when you're large and, you know, GitHub's large now. And I think they still do a fantastic job, right? And I still use it every day. I still pay, I've paid for it, you know, for 20 years now. I paid for it when I was there. I thought you'd have like 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, you know, that the payment process worked well, right? We kind of wanted to dog food everything about it. Good excuse. Yeah, good reason. Right. So, yeah, I mean, I think we have advantages in some areas of saying, if GitHub tried to do a client now, right, and try 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, right? It's like 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 world, right? It's like 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 and I kind of want to see who adopts

and if that gives them an advantage. And so I 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, you know, worst case scenario is, you know, you get acquired or something, right? And then you're part of a big rocket ship that's been going longer. I was going to say, like, would you get acquired by GitHub? I mean, I honestly don't.

If we came up, this is the challenge, right? You have to come up with something that gets product market fit and becomes a little bit threatening, right? You have to come up with something that gets product market fit and becomes a little bit threatening, right? You know, 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 the space still. 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 the 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? Like, how could I share my work with you?

Like, start from first principles. Like, 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, right? Like, can we come up with a thing that's 10 times better than the way that GitHub's been doing pull requests

since, you know, honestly, since I helped write it, right? Like, like I was not involved, not, not involved. Like anything that I, that I say bad about GitHub, I'm partially responsible for. So it's hard for me to, yeah, to run it too much. But, um, how much code do you think you still got going there? How much code do you have yours? yours you know lines of code still acts still running when i hit oh i hope i hope nothing uh not much then you can wash your hands of it okay well not my code yeah no i i you know hopefully i mean there's certainly influences of of things that i work like just i i think just was entirely my project so anything that's that's there might be some code still running on just and i still and just has gone largely untouched for years. I mean, it probably still is your code. It could

likely be. And I still use it, right? It's still great. I actually still really like it. 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. And 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 like this okay what was it previous to this version right and kind of step through it it's it's a very nice user interface for that but it's hard to do in vs code um through any of the plugins so right um yeah i mean there's yeah there's stuff but i i have to imagine that they've ripped most of my crap out right so you mentioned server-side stuff that like if you were at github there would be server-side things involved in any sort of client-side experimentation so what what's the git butler server because i imagined that you're building entirely on top of git and it sounds like you do have some git butler specific server things going on or what yeah so i like I said, separating out the various functions of what you

use a commit for, I think is, is important. And so what I really like is more of a streamed sort of backup, right? Where it's, it's like anytime that, that code changes on disk, have the ability to push it some, 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, right? Like, and I think that's, 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, right? Without having to kind of reroll commits. And so, like, 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, 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, there's so many, some of these things we even talked about at GitHub when I was there, right. And just, it just is too difficult to kind of, to kind of implement or it's too niche or whatever. And so I'm looking forward to, 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 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'd 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. And I don't want to commit this code. I don't want to do a PR necessarily, but can I get 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, just me a a feedback on what i'm writing here is it the right direction it's quite wise because you take you said you want to compete and i like the way you clarify with i want to 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, 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 the GitButler way naturally is very small until you gain critical mass. Yeah, everything that GitHub or Google or Microsoft or whoever does, they have to do at scale out of the gate, right?

And that's really hard. And, you know, there's also a thing of, it's hard to do stuff in larger corporations, right? Like, it's hard to have freedom. It's hard to have people be like, you know what, try it, right? Like, it's not really, I think the Microsoft, well, I've never actually worked for Microsoft, but I have to assume that things are a little bit more difficult to, you know, get through or there's some politics, there's some stuff like that's always like that, right? If you get, you know, if you're lucky enough to be successful, then, you know, you

have to do stuff at scale and it becomes difficult, right? 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, right? 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, right?

But if it's just, let's try out some code, like it's easy to write code, right? If it's small scale and see if it works what's up friends this episode is brought to you by Coda. Coda brings teams and tools together for a more organized workday. It's your all-in-one collaborative workspace. They bring together the best documents, spreadsheets, and apps into one single platform. And best of all, Coda helps you stop playing ping pong between different tabs and tools. You centralize all of your processes and shared knowledge. And now is the perfect time to get started with Coda, especially its extensive planning capabilities.

With Coda, you can stay aligned by managing your plan cycles in one location, set and measure OKRs with full visibility across teams, communicate and collaborate on documents, roadmaps, and you name it, instantly. You can access hundreds of templates and get inspired by others in Coda's gallery. So if you want a platform that empowers your team to collaborate effectively and focus on shared goals, you can get started with Coda today for free. Head over to coda.io slash changelog. Again, that's coda.io slash changelog, C-O-D-A dot I-O slash changelog.-o-d-a dot io slash changelog and you can get started for free

is there a an opportunity given your history with github being a 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't do. Here's my pitch. Would you give me access to not so much resources,

maybe 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, you know, how would it be valuable, right? Like, like I think with any, 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 to partner with them? I mean, you know, one of the things that we're really trying to do is, is to make

our client at some point, somewhat server agnostic, right? That we could work with GitLab or we could work with Bitbucket or whatever people use or like internal, you know, sort of deployments. And so, you know, the question is, do we want to have a partnership with one?

Like, do we want to tie ourselves to GitHub or something like that? Obviously there's advantages to the gorilla, right? But how, you know, does that really help either of us as opposed to just working independently and learning from look seeing what each other is doing and you know stealing stuff from time to time right like i'd be tickled if github thought that something that this little tiny company was doing was was good enough that they they felt it was worthy of stealing, right? How much do you pay attention to Zed, the editor? I love Zed. I actually, I

just, you know, this is a whole other thing down the sort of open source route, but Zed and Gipbler made their source available, I should say. We use the functional source license. Yeah, I know. So we're not OSI approved, right? But we have our source code available, and it's on GitHub. And we have a community that's sort of built around that

and said the same thing, but they did use OSI licenses. And I need to use Vim mode, right? Like 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, right? At least once an hour, there's a replace mode that I use. They didn't have 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 a 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, right? 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, you know, I paid him 500 bucks. And I was like, this is great. Like, it'd be interesting, I think, to have open source be a little bit more this route, right? 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, you know, like we actually, Gibbother is a sponsor of Tori because we depend on Tori and we want work to go into Tori. And so we're paying them like, I don't know, 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 Tori guys. And later on, they found that we were

doing that. But just to be, like, I want, 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, X, Z, X, Z, like the X, Z problem, right? Like, 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 burnout, right? Like, it's just such a hard hard job and GitHub's made it better and made it worse, right? Like it's made it better in kind of expanding this world

and it's made it worse into expanding it into people that are kind of dicks about it and come in and are mean to you or are demanding changes, right? And you have to deal with this expanded community that aren't all hobbyists, right? And in their basement being nice, right? You know, I came out of the Ruby community.

It was very friendly and very easy to get into and stuff. 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 decided to go with the FSL is licenses like this, like 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 sort of open of a project being open source or an app being open source, but some protection as well. So, you know,

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, right? So for example, you know, we're talking about GitHub again Again, I don't think GitHub really cares about us, but, like, if they wanted to take it and be like, okay, well, this is, instead of GitButler, we're

forking it, and now this is the GitHub client, right? And we'll put a bunch of resources on it, and we'll just take it from you and, you know, change your server backend out with ours or something like that. Like, our license specifically prohibits that, but essentially nothing else, right? Like it's, it's really just, you can't take this and compete with us on a monetary basis. So, you know, it helps with like, I think like Redis just kind

of switched licenses as well to something similar that tries to avoid this, this thing of Amazon coming in and just hosting their, their stuff. Right. And, and so that they can compete. So again, like what, what we didn't want to do is do this rug pull of saying, okay, it's open source. Now it's not right 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, you know, 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 the community is 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, right? But still let people have access to the source code and contribute to it if they want to and stuff like that. Like 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, right? Because I want to use it, right? Like I find value in most of it. I'd like to even pay them to, you know, 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? Like, do you like that or dislike that? I don't particularly care. I think people that are, you know, OSI heads, right, that really care about sort of, you know, like it's people who know who Stallman and, and, you know, like the, who know sort of the figures in this or know what, you know, the history of GNU Linux or something

like that. Right. Those guys really care, right? Like it's, it's kind of, there's this small percentage that really, really care and get real mad. There's the vast majority, I think of, of people who use GitHub that don't know the difference, that don't know what the definition is, right? That don't know free software versus open source software, for example, right? But really just think of it as source available to it. Or really think of it as it's on GitHub as a public repo, right? That there needs to be sort of a definition for that. Because honestly, the license makes a big difference.

And the OSI approved licenses don't differentiate in the way that people think, right? So it can be open source, it can be under an OSI license, but it makes a huge difference if it's GPL or if it's MIT, right? So you still have to look at the license and see what the license terms are. And so I find that kind of a useless definition of like a border of a definition of saying this is an open source project, right? I still need to care what license it is under like which osi license it is right and they're not even all compatible with each other like so i think it's very confusing and

osi people think it's very clear right like they i i didn't even really i think i used open source one time usually i said i'm we're opening the the source code or something right um and they don't want me to use open either. And so, you know, like this particular community cares very much about the terminology, but all I care about is practicality, right? Like 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 know what the open source definition is, I think they're like, why don't they call it open source? Like, is there 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 the level of Stallman and whatnot that you think that 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 right or 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 quotes 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 get a public, I guess, like that's, that's really what I want, right? Like, like be aware, like, you know, there's, there's, is it beer where is it, you know, is it FSL? Is it OSI? Like, 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? Right? Like, easily. I think source available does that job pretty good, 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 tar it over the wall, right? Which is a little bit different. So it's, it's, it's like saying, we're going to do a tar ball dump every month, right? So the source code is available, not, 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, license is generally permissive and most people don't need to care, right? If you're not, especially in our case with the FSL thing, if you're not competing against that with almost nobody,

actually, even for apps or for almost any application, there's almost never somebody that's competing with you, right? Like it's really just for things like server, like things that you might, that Amazon might take, right? Like things like Redis, things like open search, right? Right, which is why I was kind of interested because you're a desktop app. So it seems like it would be less of a concern for you.

It is less of it. Like I honestly, we were really on the fence. Do we just AGPL this, which is what most of these companies do, right? Or do we do this other thing? And we just wanted to reserve some options. But, you know, in the end, our community is exactly the same. Like nobody's really cared about it. 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, for, you know, security problems or whatever, right? Which we've, there have been some, 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, that it's, you know, freezing speech, right? Like that,

that's not what's important to them. To most of the. It is important to some people, I understand. Sorry, I really do want to debate this a little bit. I don't really care in the end. 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 product. Or think about this project. right? Or think about this project. And we really do approach it like it was AGPL or something, right? Of just being like, we're going to give it a license that we think is going to 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, right? 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, right? Like I know it, you know it, right? Like, like there are people that do and 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, you know, the seventies, right. When, or I guess, I guess technically this was probably defined in the eighties, right? Like I forget exactly what the, well, so there's two, the free and Libra.

And so, so the, the FOSS thing, right. So like the, the Stallman style open free as in freedom that was in the eighties and then open source definition, which was a second group of people, was 90s. And so even though those two groups don't agree on the point, they have different views of the world, but they are compatible views, I guess. really interesting is this new wave of sort of commercial open source, right? So there's a lot of companies like ours where we grew up in an open source world. We depend on open source for everything. We build everything on open source. There's all of our library, like GitHub,

GitHub is a fantastic example of this, right? Like GitHub is not open source. The core, right? They've opened. So we've open sourced hundreds of libraries, everything that we built that was somewhat generic,

right? Like Libgit2 or, or, you know, MySQL2 or like all these Ruby libraries or, you know, whatever, all of these utilities and things, they're all open source. They're all MIT, right? The only thing that wasn't is core GitHub. And I'm fascinated if something like the FSL had existed at the time, if we, if GitHub would be open source, right, under this type of license, where you couldn't sort of host it and compete with us, right? But like, you'd have all of the benefits of having an open source project. We debated this a lot internally at the time,

should we open source core GitHub, right? And in the end, we felt like it wasn't worth the risk. And it wasn't worth sort of, you know, 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, you know, at the time that GitHub was coming out, and there weren't really a lot of, oh, we're going to be an open source sort of core company, right? And give us investment money, right?

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, right? There should be Free Libra. I actually think there shouldn't be any closed source. It'd be a fantastic world to just be like, you know, what license is it under? But basically, every piece of software that you use, you can inspect the source code. It just, it just, you 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 then 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 that maybe functional source is, I don't understand how source available sounds like throwing over the fence, and you're not that. And 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, for too many of us, the things that really matter. Yeah, no, I had a long, interesting fight with people online about this. 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, right? Of just emphasizing availability, that people conflate public on GitHub with open source, right? 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

or, you know, 10 bullet points of OSI definition or whatever, right? Like, 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, right? Like, like, it's not, it's complex thing to understand. And most people just don't spend that kind of time or, or, or whatever. And so I think that conflation is problematic, right? So if we come up with something else, then, then people are like, well, how is that different than, than what my understanding of open sources, even though there is obviously a long sort of held definition of, of anyways, whatever it's, I don't really care. And it turns out, it turns out at the end of the day no like our community doesn't care either most of them probably think it's under an open

source license because you know they don't really look at it and it's just the one time i use the phrase open source that i people who yelled at me and i've you know i don't use it after that um actually what's interesting is i realized i've been callingGit open source for a very long time now. So it's very interesting, right? Because it's under a Creative Commons license, but it's a Creative Commons non-commercial, right? 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, to not call pro get open source.

Right. Because if it's under a creative commons license, it's not, I guess it's not open source. Like some of it is right. Like if it's CC zero or whatever, that is an OSI one. Right. But like, um, I guess the other ones aren't, or I don't know, this is part of the complication, right. Is that I'm fairly sophisticated in this, in this matter.

And I, I still get confused sometimes. So, but I have, I have definitely been calling the book open source for a long time. And a lot of people do because it's, you know, it's available, right? But it is technically non-compete. And there's not really a OSI non-compete license, right? And I find that, so there is a movement

by the century guys to try to use software commons as sort of in this realm, right? Of source available, but, you know, sort of being engaged in the community. But again, there's people that 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 like that? Who knows? But I think if we zoom out one second on this, I think the matter really is, and I think, so you mentioned pro-get-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 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, right? Like nobody is like, oh, I'll use that because it's open source or something. gets any market share from that. Nobody cares, right? Nobody is like, oh, I'll use that because it's open source or something. 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, in quotes, open source, and you know what it means, then you're using it incorrectly because you know. Yeah. Right? 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. Open TF, 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 however 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, you know, donated 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. I do want to double down on, I think we all agree that there needs to be a third term for this thing, right? But I do agree. 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, right? Which cannot be GPL or, I mean, in lots of cases, right? Because you really if something's GPL, a GPL 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 to the app, right? So it really did like OSI is not the important definition it is, is it copyleft. So copyleft is an important definition to me. The other is infrastructure, right? And so if it's an infrastructure tool, I think, or if it's something you want to build infrastructure tool off of, like, you know, I mean, I would even argue Redis or OpenSearch 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, right? 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,

is that 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, right? And I don't think everybody, I don't want to use, you know, like, I think I want to use the one that I have in my AWS instance or whatever that I've already built off of, right? 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, right? And applications, I think, are different than infrastructure because you can't, like, you know, what is competition in that, in that sense, right? Like it's a very different thing than trying to build something on the sort of infrastructure,

you know, sort of tool to say, okay, it's the, the get client or, you know, some desktop application or your web browser or something like that. Right. Like of saying, okay, only Google can distribute Chrome, right? Like, yeah, that has implications, right? But I don't think anybody that's contributed to Chrome, or people who wanted it to be brave or something, right? Like had that in mind, it was like, okay, if Google switched to being okay, Chrome's FSL or something, I feel like most contributors, maybe some, right? But I feel like most contributors don't care that much, right? Because that's not really what the value of it is. The value of having it having the 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. 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. Yeah, I don't disagree. 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.

Is GitHub.com 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.

This is the way it's been for a long time. You mentioned copyleft. 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 like 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 really interesting. Yeah, I don't even want to get into licensing and our code stuff with GitHub and stuff. No, let's not. We've done it before. It's a rattle.

To zoom really far off, I think what is important, though, let me just say this one point and we can go any other way 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 one 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 what's interesting to me i guess is, and again, this is another down the line of GitHub helped create this problem, right? So I feel partially to blame for this is sort of genericizing source available and open source and not making it clear kind of what differences are. somebody who runs software and somebody who uses software and you know has a company that depends on it 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 i kind of separate my licenses into that right like if something's you know fsl or whatever but i'm clearly not competing then i can be like you know what i'm pretty sure'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? Right? Like, that's what I care about. I care about, I open, so everything that I do is MIT. I don't think I've released anything under anything other than MIT until this, right? From a corporate perspective, or it's been closed. But I do need to know, does a lawyer need to look

at this, right? Because even I'm unclear, sometimes, what can I do with AGPL software, right? Like, I, it's not everybody knows exactly, like you were saying about GPL, but AGPL is, in some cases, even more complicated, right? Because if you're doing a service that's doing, you know, and why, you know know why are people using it like this is this is actually kind of what came down to kip other was we were talking about you know a lot of like i think zed is agpl as well just trying to say or at least a server component is trying to say what what happens when this happens when you agpl something and somebody wants to you know build something around it or use it for something you know 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.

And so it's really just, to me, the spectrum of importance is really, do I need to care about this or do it? Does my lawyer need to care about this from a corporate perspective or do they not? And 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 there's nobody really knows what does it mean to be competing. I was going to say, you do have to get a lawyer involved because the defined competition is very difficult in the age.

You 100% need a lawyer. Yeah, you 100% need a lawyer involved with FSL, but you would with AGPL as well to a degree, right? 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, right? So take your time or don't take your time, but like try to make it simple if you do. And, you know, FSL or BSL or whatever, they don't make it totally simple. But, you know, I think of most people that are reasonable, have some clarity of whether they're competing or not, right?

Like, but yeah, it's yet to be seen. It's a new thing. But I think at the end of the day, we can all agree that like, it would be nicer to have a little bit of a different way of talking about this, right? Or a 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, right? I do really want to see a world where everything I'm using is, 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. And I find that very valuable. So I want to see that world. And the question reason, it sounded pretty good to me.

You know, like there is open source, there is functional source, and there is 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, so 13 years ago,

Scott Chacon made Git cool. So, I mean, he can make functional source cool. He can do it again. That's all we need is a charismatic leader to just champion a new term. My new banner. What's cool about functional source license, too, coming from Sentry, is their business name is not actually Sentry.

The DBA is 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 their name, the business name is actually functional something. I should look it up right now. I feel like an idiot. But it's got the word functional in it. It's not Century. Their business name, their LLC is not.

Is that why it's functional source license? 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 llc functional software inc is their official business name there you go well let's get back to get butler let's wrap this sucker up that was a fun diversion on the open source license i think we could go around

that merry-go-round a few more times we need those kind of debates i mean it's those kind of like conversations that mature our audience mature our own thinking like 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 that's good stuff. Go ahead, take us there, Jared. Back to GetButler. 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 GetButler.com. Yeah, it's, it's, uh, you can find it at getbutler.com. Actually, it's one of the funny things, you know, 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, lots of companies come in and do something that's very, very hard to Google, um, without putting, you know, app or something at the, at the end of it. But, but yeah, if you type in GitButler, you'll always find it. There's nothing else to name that. So, but yeah, gitbutler.com. And the best thing is to,

you can also find it at github.com slash gitbutler app, 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. And I think the most important thing is to come on on Discord, you know, if you're interested, even if you don't want to use you just want to talk about version control stuff, or, or talk to me about the new edition of pro get, which I'm kind of starting down the road of doing a third edition of that. Discord is is awesome. It's actually,

it's one of the things I really wished kind of was available in in sort of the open source world. A decade ago, we really didn't have Discord, right like we we had we had irc channels or things like that but i think the the level of engagement even like you know for me if i i use planet scale for a sequel right and they have a they have a room and i can go in the room and i can ask questions right and like it's such a it's such an interesting awesome new thing for companies and and for open source projects to have them all have a room that you can go into, right? Like I, like I was saying before, I got interested in jujitsu, they have a discord channel, you can go in and ask questions and try to say, how did you do this? Why? Like, you know, what, where, what's the future of this, whatever. So that's actually,

you know, if I get if anybody gets something out of this podcast, and they want to engage, I would love to talk to you, like, you know, 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, you know, 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'd love to have a beer. So who knows?

Was I in Berlin? I was somewhere in passing. The reason why I can question it is because I was actually on my way from Sarajevo, Bosnia. And I flew while 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 in like Ramstein

potentially. I don't even know where I was at. It was like all I know is it was in the country Germany. And that was it, pretty much. But you also have the Merge coming up, a developer experience conference. Oh, that's true, yes. Is that something you're a part of or what is this? Yeah, so we, you know, we were

doing all of these conferences and I was speaking at 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're like, let's just do our own conference about all of these things that we're learning now, like this Discord thing,

like how do you engage in an open source community or source medical community? How do you start a software company today, right? And there's all of these tools that weren't available at the beginning of sort of GitHub days that I'm really interested in. Like there's influencers, right? There's YouTube, there's Discord,

there's like all of these tools of how to sort of engage in the larger software development community, how to do it well, like 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 or don't think about enough, right?

Like if you like, this is one of the things that I think differentiates us from, you know, the Git CLI versus Git Butler is that we really, really care about the developer experience, right? Like 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, right? So we have some speakers from Century, from HashiCorp, you know, it's interesting, from GitHub, obviously, and we're bringing

everybody to Berlin, so it's also a good excuse to come to Berlin. But yeah, you can find that at merge.berlin, and it's in June, so June 13th and 14th. I was digging that. 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, founder of Resend, creator of Dracula. And that's the way he says it, is Dracula, because he has an accent. 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 going to 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, Jared?

Is this the end? We covered it, man. We did it. 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. Yeah, for sure. I'll see you guys in 34. There you go. So replacing Git with Git, how novel of an idea is that? Git Butler has a lot of potential.

And Scott has some big ideas he's executing on, so no doubt he'll have success. But what are your thoughts on the idea and the name of open source code? You see what I did there? Code that is open source, source available, functional source, however you want to term it, commercially backed open source software, commercially backed source available. It really is a challenge to describe it and not really step on the toes of quote open source end quote. I feel the pain, but we do need to have a line drawn somewhere. Well, I do want to let you know that we have a fun episode coming out tomorrow on Change Logging

Friends. Our good friend, one of our best friends, BMC, Break Master Cylinder, the beat freak in residence, the beat maker we call upon when we want new beats. That BMC, yes, that one. Tomorrow on Change Logging Friends. So, so fun.

A big thank you once again to our friends at FireHydrant, our friends at CrabNebula, and our new friends over at Coda for sponsoring this episode. And of course to Fly.io, the home of ChangeLog.com and to our friends at

Century. Use that code ChangeLog to get $100 off the team plan. So cool. So cool. Okay, that's it. This show's done. We'll see you tomorrow on Friends. Thank you. Game on.