GitButler is a member of the Open Source Pledge, where companies commit to contributing at least $2,000 per year for each developer on their team to open source maintainers. Before GitButler, founder Scott Chacon co-founded GitHub; for this profile, I talked with Scott about how he 'fell in love' with Open Source, the legacy of GitHub, how AI is changing development, and what he's building today and why. Enjoy!
In talking with Scott Chacon, I realize he has a superpower: he really likes to understand why things work the way they do, and to make sure others do too.
"My first job was working at this trade show registration company,” he tells me “They were using all of these FoxPro scripts, and everything seemed so slow. Every script was just iterating over every single row.”
"I opened up the manual and found that you could just use SQL to do everything like 100x faster.” he continues. “My bosses didn't think my scripts worked at first, or that I'd written them. They were too fast."
The lesson stuck: sometimes a better solution is right there waiting. You just have to take the time to dig.
"All of those systems ran on Linux. It got me into compiling my own kernels, and looking at source code because you could mess around with everything. When there was a problem, you'd ask friends or go on the Internet and you could figure out how to fix it."
"Even through college I ran on a Linux desktop. I wanted to be ‘that guy’," he says with a knowing laugh. "I wrote all of my papers in LaTeX instead of Word. Was it harder to write my papers, format them, and actually get them printed? Yeah. But at least vim doesn't crash."
"That's where I fell in love with Open Source,” says Scott. “I got involved with PHP, I wrote some stuff, tried to share it. Eventually I moved into Ruby on Rails… and Open Source was everywhere."
"By the time I met [fellow GitHub co-founders] Chris and PJ at a local Ruby meetup, I was already kind of known as the 'Git' guy, because I was always doing stuff with Git." he tells me. "But the Git stuff is funny because… well, I actually found it really difficult at first. A friend of mine was teaching it to me, drilling it into my head, and I finally got it. I was like: wait, you know what? This is super cool."
"So I started writing. I wrote a book called Pro Git — which is still selling well, two editions and f*#&ing fourteen years later. It's fun to teach, and it's fun to write, and to make something hard into something easy. If you can help people have that epiphany about something, and they start to love it… it’s incredibly satisfying"
"I'm actually not that good at Git!" — a funny line from someone who wrote the book on it, but he continues. "I just understand what it's like to not understand something, and what it's like to get over that. I have a drive to understand how it works at a fundamental level so I can teach people."
The GitHub Effect
While GitHub itself is not Open Source, the massive impact that GitHub has made on the Open Source world — and on software development overall — is inarguable. It’s ubiquitous enough that dropping your GitHub profile in a software engineer job application is more the rule than the exception.
As Scott put it in a 2023 interview: "It’s almost impossible for most of us to remember what Open Source was like before GitHub."
I ask Scott when GitHub's importance dawned on him.
"I was prepping a talk where I was giving people the history on what it was like before,” he tells me. “I was pulling out examples, like manually attaching patches to Redmine issues, or shipping tarballs and sh*t in the Linux community. The processes were… really not good. "
"You'd start a new dev job and onboarding was like 'Here's how we do version control, here's how we do this and that. Blah blah blah.’” he says. “Now it's all GitHub, or a clone of GitHub. Git provided the tool set for GitHub to make all of it much better."
Scott Chacon giving a talk on Git in 2014. Photo by Andrés Moreira, shared under a CC BY-SA 2.0 license; the photo has been cropped.
Even 16 years after its founding, Scott thinks about the ways GitHub influenced the way people build and how the way they build is changing right now.
"When we put the 'Merge' button on the website, there was a shift. Review and integration shifted off [your local machine]. All review and integration was done locally before, right? You would pull in a branch, you'd look at it, you'd merge it locally, then you'd push it back up. The whole process was more… artisanal, I guess I’d call it.”
"Now a lot of people are integrating code that they’ve never run locally. Maybe someone wrote it locally, but the reviewer? It's too cumbersome to pull down; when it was all patch-based, you had to! There was just no way to do it otherwise. We pushed that away in the name of ease of use, so now it's easy to be like 'Whatever, looks good to me."
"I kind of like this idea of having everybody be a little closer to the code."
On AI
"With AI, vibe coding, coding agents… it's getting even further away." Scott notes. "Review is more important than ever and yet it's as weak as it's ever been, right? You see 37 files and 1500 lines changed, and you're like… you know what? I'm not going to go through that."
But if there’s one camp that’s ready to embrace AI coding tools and another that’s staunchly against it, Scott is very much in the first one — and he sees more holdouts coming around every day.
"Even in my circles, I've seen people who were like 'I'd never touch AI with a ten-foot pole! It's horrible!' now doing large refactors with it, and being like 'Eh, I was wrong.’” he says. “Everybody is learning what it's good at, what it helps with, what it doesn't help with, and where you get stuck in the loops.
“It's a slow thing,” Scott tells me. “but I think in the future it'll feel insane to not use AI for at least some of your workflow."
"That means changes to everybody's workflow,” he notes, “which means there's opportunity for some other GitHub-type thing to come in and make that workflow easier."
"Look at anything on GitHub,” he continues, “and think of it from the point of view of: is this good for teams of humans, each with agents (and agents that work by themselves in the cloud), all working on one code base? Is this the right tool set for that team? I think the answer to that is fairly clearly 'no'.”
On What's Next For Him: GitButler
Scott stepped away from GitHub in 2016, just prior to it getting acquired by Microsoft in 2018 for $7.5 billion in stock.
After that sort of exit and the windfall that comes with it, it'd be easy to disappear into some hobby you love — like, say, woodworking. Which is exactly what Scott did… for a while.
"I just really missed the startup world," he says.
His first post-GitHub company was a language learning startup called Chatterbug. It didn't work out, but he's still very glad he did it. "I came out of it learning German, moving to Berlin, and marrying a German woman. So, yeah, worth it."
His next swing? GitButler — the git client of his dreams, and, ideally, one that evolves with the way he foresees development changing.
"I look at Git, and it's somehow still this thing that people don't care about that much. Who are the GitHub competitors that are interesting today, or in the last eight years? Like nobody!"
"I can go through every GitHub page and point out seven things that frustrate me, or that should be better by now. Or you can go to GitHub Next, which is [where GitHub shares prototypes and research]... why are none of these things startups?
"I think it's because nobody finds version control 'sexy'...” he tells me. “They say 'Git? Whatever, solved problem!'”
"But there's 1000 things that are really frustrating about Git! Even I get frustrated by Git sometimes."
With GitButler, his goal isn't to replace Git — but to fix what frustrates him about it from the client side.
"I wanted a client with taste, that was actually good at what it did, and was delightful to use. I wanted a Git client, but I didn't want it to act like Git. I want it to write git objects, and write git trees, and use the protocol… but where you don't even really need to know that you're using git."
"I thought it was an interesting challenge: what if GitHub had made the client from scratch, and owned it, and could deploy features to the client… what might that have looked like?"
From there, the goal is to get ahead of where Scott sees development going with AI.
"You can see how little people give a sh*t about version control by how most of the AI companies deal with it, which is to say: they don't."
"Half the time you'll do seven prompts, change all this code, push the code, and say 'Ok! I think I've fixed it.' You've just lost everything. There's no prompt information, no context, there's nothing."
"If AI agents are generating all this stuff, we need to have save points, and for it to be so easy to revert… We need the prompt information in the commit. When an agent is working on something, we need to be able to say: why was this written? Not what was written — that's easy. But what was it trying to do?”
Scott has spent his career finding better ways to build — from those early FoxPro scripts to version control to whatever comes next. Now three decades in, as he watches AI change how the world writes code, he’s focused on making sure we don't lose something he’s cared about since day one: an understanding of why.