Software That Doesn't Suck Building Subversion With Jim Blandy

Intro

Jim Blandy: Basically, there was a coworker of mine who said, “CVS’s repository is indexed backwards.” Right?

It’s that CVS’s repository is the software equivalent of a telephone book sorted by telephone number. And so, that’s a funny launch comment, right?

And basically I was just thinking about it myself doing the dishes every night, but the thing is you can’t just accept something like that.

You have to say, “Well, wait a second. If CVS is backwards, what would it look like if it were right?”

Adam Gordon Bell: Hey. Welcome to CoRecursive, I’m Adam Gordon Bell. Today our topic is what would it look like if CVS was not backwards? CVS is a source control management tool, think of early nineties’ Git.

Jim Blandy is my guest. And he brings us the story of making CVS better.

I would guess that a number of features of your current source control tools that you probably use every day were influenced by Jim’s work. I also think he has some interesting insights on how you build great developer tools and also how to recognize when some improvements to the existing tools will topple the current market leader, something that he’s done twice.

Adam Gordon Bell: Verify that you have the right one in Zoom.

Jim Blandy: Yes. I verify that I am using the right one in Zoom. Do you want to stay focused on the version control side of things?

Adam Gordon Bell: Well, let’s see where we go.

Jim Blandy: Yeah, we’ll just tell him to tell the story. We’ll just tell the story.

Adam Gordon Bell: We start the story, the year is 1993. It’s the year the Mosaic web browser came out. Email had been around for some time, but the web was fairly young and CVS was the most popular open source control system.

Network Transparent CVS & the Commune

Jim Blandy: So I went on this trip that I was going to go on in Europe and Japan and I came back to the U.S. and I had no job and no apartment. And my friend Karl Fogle had gotten a job working at the University of Illinois at Urbana–Champaign on a gene editing mode for Emacs. And in Emacs, you visit a file that’s full of genetic data and Emacs will bring it up and it’ll apply colors to it and you can select rectangles and stuff like that.

But he was living in Illinois at this lab at UIUC, and I was living in Indiana and so we were collaborating across the net and this was 1993. So the way you collaborated across the net was you shipped people patches, you emailed people patches, you FTP, do your sources, network transparent version control was not a thing.

But I had an old friend from college who had gone to work for a Silicon Valley startup, except he didn’t want to live in Silicon Valley. He wanted to live on a commune in the Hills of Virginia. So they ran a frame relay line, out to the commune because rural telephone access, right? And there he was on this commune, everybody else is making hammocks and nut butter and he was hacking on code for Silicon Valley and so his income was probably a significant portion of the whole communes income. But there he was, and he realized that it was kind of lousy doing this collaboration at a distance.

His name is Jim Kingdon, and he was just an amazing hacker and he sort of disappeared from the world after this and I don’t know why, because he is amazingly talented. What he did is he took the CVS version control system, this is like I said, 1993.

It was designed for a situation where you have lots of people using the same computer, right? So you have your CVS repository in one part of the file system that’s shared by all the users. And then people are checking out copies of the tree into their own home directories, making local changes, doing updates, doing commits, right? So they’re doing all of this activity, but it’s all on one machine, right? It’s all one local file system. Because people would share their computers back then because that was what you have to do.

So what Jim Kingdon did is he took this CVS version control system that was designed to work locally only and basically, by sheer force of intellectual will, he ripped it apart into a client and server and he invented a protocol to go with it and the protocol minimized round trip times to keep latency down and all this just amazing stuff, right? It’s a program that wasn’t designed to be a network program at all, and he turned it into a network program and then he used Kerberos for authentication, right? So this was real network security back in 1993, right?

Then he used it for collaboration with the startup that he was working for, which was Signus Solutions in Silicon Valley. So it was this amazing thing, but he didn’t publish it. He just used it. He wrote it for himself and for maybe other people in his company, and then he just used it. So I had heard that he had done this and here I am trying to collaborate with my friend, Karl in Illinois. So I wrote to him and I said, “Hey, do you think I could get a copy of this code?” And he says, “Oh yeah, sure. But on one condition you can’t ask me any questions.” Basically, he doesn’t want to get into the support thing. I think this is probably why he didn’t publish it in the first place.

Adam Gordon Bell: That makes sense. Yeah.

Jim Blandy: So I said, “Oh yeah, sure, fine.” Give me a copy. And so he sends me a tarball of it and other sources. So immediately I asked him a question and he’s like, “I told you not to ask me any questions.”

So Karl and I started using it we’re like, “Holy cow, this is amazing.” Because you set up a server on some machine somewhere and you do a checkout and you get the sources and then you work locally and nobody gets in your way. Then you just commit and poof, it’s there for everybody else to see, right? It’s just a whole new world.

So we were just blown away at how much better it was to collaborate over the net using network transparent CVS.

Adam Gordon Bell: So since CVS is GPL, Jim takes these improvements and he releases them to the world as a fork.

Waiting Tables & Drug Testing

Jim Blandy: At first, the official mainstream CVS distribution was like, “Oh yeah, interesting work. But we have our own ideas about how we’re going to do things.” Because nobody likes existing code. Everybody likes imaginary code because imaginary code is always perfect.

Adam Gordon Bell: Yeah. And you’re like, we already have this. It’s done you can use it.

Jim Blandy: Yeah. You could use it, but they didn’t want it because they wanted to do their own thing. But after a few months it becomes clear that they don’t have network transparency and we do have network transparency and basically everybody is switching over to cyclic CVS, which was what we called it.

They capitulate and they say, “Okay, I guess we’ll merge your changes.” And that is how network transparency CVS came to be. And within a year, all of the open source world was using this because when you think about the kind of collaboration that has to happen with open source, it’s all distributed teams, it’s people from everywhere.

You get volunteers, you have no idea where they’re coming from. There’s no physical locality to it at all and it took over the open-source world by storm and within a few years, pretty much CVS was the standard.

Adam Gordon Bell: This network transparent CVS became such the standard, both in open source and in the corporate world that Jim got some interesting contracting work just helping people understand how to use it.

Jim Blandy: One of the biggest thrills I ever got was when I was just going around to different companies and government groups and teaching them how to use CVS.

And I got an invitation to teach for a few days, I think it was a three day course at the Goddard Space Flight Center out on the East coast. So here I was teaching these folks who were doing satellite development and doing weather analysis. I remember one day over lunch, one of them said, “We’ve been having this bug with CVS. I wonder if you could help us out with it.” So I said, “Sure.” So we walked down to his cubicle. So we just check something out and just checks out a tree with CVS. And I say, “Well, what is this?”

And he says, “Oh, this is stuff that analyzes satellite data, satellite images to analyze hurricanes and predict where they’re going to go.” And just seeing that checkout, right? CVS listing each file, as it downloads it from the server and checking it out, it’s like, “Whoa, I’m actually helping people do stuff.”

Here’s this person who is just trying to track hurricanes, right? And because we made this thing, they were able to do that, right? That is a really exciting feeling, right? That they’re not really interested in your software, they’re just using it to get something done and that because you were there, they were able to do it.

Cyclic Software

Adam Gordon Bell: Jim and his buddy, Karl, they don’t let this good opportunity go to waste. So they start a business Cyclic Software that offers support for cyclic CVS, for network transparent source control.

Jim Blandy: Our little business failed to die in the first four horrible ways that businesses always die. We paid ourselves a salary. We earned back our initial investment. We actually made a little bit of money beyond that and we had customers. One of our clients was Goldman Sachs. Goldman Sachs was using CVS internally and they really liked network transparent CVS. So Goldman Sachs wanted us to port it. I think they wanted reserved checkouts or something like that.

So here we are two guys basically we’re grad student age and we’re like, “Okay, we’re going to write a contract with Goldman Sachs.” So we go consult a lawyer and stuff like that. And we sent Goldman Sachs our little contract. And their full legal department comes to bear on this thing. Everything that we wrote them becomes exhibit A, and then they have this big, whatever it is, 15 pages of boiler plate that we have to-

Adam Gordon Bell: They faxed it to your lawyer?

Jim Blandy: Yeah. I think they emailed it to us or maybe they snail mailed it to us, I think. Those were the days. But fax would be reasonable, we might’ve had a fax machine. But anyway, I’m reading through this contract and I get to paragraph 15 and it says, “Contractors agree to submit at Goldman Sachs’s requests to drug testing.” I don’t know where this comes from.

So Karl and I are about as square as you could possibly get. I mean, we don’t even drink, right? Not because of any moral issue. We just don’t, right? That’s not our style. So we would have completely passed any test that they could ever get us to take, but also that’s just obnoxious, right? What do they care?

So I go back to Karl, I walk back into the other room carrying the contract and say, “Karl, they want us to take drug tests.” And Karl says, “Oh, we won’t sign that. We can wait tables.” And I’m like, “You’re the best.”

So we write Goldman Sachs and email back and say, “This looks great. We’re ready to sign it. However, paragraph 15 has got to go.”

So without any comments at all, we just get back another copy of the contract from Goldman Sachs with that paragraph gone and we sign it and we do the work. And that was that. But we did hear from the hackers at Goldman Sachs later, the people that we ended up doing the work with, they told us later, “Nobody’s ever done that before. Nobody ever complained about that. That was cool.” So that was kind of nice.

That’s the kind of thing that you can do when it’s just the two of you, right? I mean, if I had had a family at that time, or if we’d had employees, right? Then you start to have to worry about other people. And it’s like, it’s not just your choice to do something or walk away. But when it’s just the two of you, it’s really nice. You can really just do whatever you please, and you don’t have to do anything you don’t want.

Adam Gordon Bell: So let’s fast forward. The company was a success, but eventually they move on to other things. And Jim joined Sigma Solutions where he was using CVS every day. And he starts to notice certain things about the tool that he does not like.

Jim Blandy: So this is actually interesting. When you think about a Git repository or something like that, you think about it as a database, right? It’s a database where you put in commits and you check out trees, right?

And one of the most common things you’re going to want to do in a version control system is you’re going to say, “Hey, I have this version of the code, and I want to pull all the changes that have happened since then. So please send me the diffs between this prior date and this current date.”

Ideally, if only three files have been touched between the old date and the new date, you should only get data about those three files. And the backing database should be organized in a way that makes that efficient, because these are very common things.

This is a diff query, a diff between two revisions. This is a checkout. This is a merge, right? This is, this is the common operation. The way CVS stored its data was as a gigantic directory tree shaped the same way as the sources that you are managing except each individual file was an RCS file that held all the different revisions in it. And there was no connection between the set of revision stored in one file and the set of revisions stored in another file. If you did a commit that touched two files, there was no indication anywhere in that data that those two commits had anything to do with it. It might have the same log message and the dates on them would be about the same, but there was no indication that was a single atomic commit.

Adam Gordon Bell: That is something that we take for granted right now, atomic commits.

Without atomic commits, you can introduce inconsistency issues, especially if somebody is doing a slow operation, like creating a branch, which is going file by file and somebody else is pushing changes at the same time. You’re not guaranteed that the branch will get all the files from the commit since they’re happening in parallel, interleaved. Also, in this case, the lack of being structured as an atomic commit actually made the implementation slower.

Jim Blandy: So when you did a CVS update, the way CVS decided which changes to ship to you was it would scan the entire directory tree. It would open up every single file in the directory tree to see whether this might have been changed since the date that you asked, and actually what you had to do when you did an update, you had to ship to the server, the current versions of all of your files. Then it would actually check to see whether any of those files had new versions, and then it would ship you the diffs back. So that’s terrible, right? Suppose you’ve got 10,000 files, but only three of them have changed. You have to check every one of those 10,000 files when somebody does a pull, because the data is organized in a way that doesn’t give you any sort of centralized indication of what changed.

Well, the performance was so bad that when Sigma solutions wanted to cut a branch, they would announce it ahead of time. They would schedule the branching because you didn’t want anybody else committing while you were branching, because that would totally screw things up. Right? And I said, “Okay, Friday at 2:00 PM, we’re going to cut the branch.” Then all activity would stop, access to the server would be cut off. Now, remember, this branch requires walking through, however, a hundred thousand files you’ve got. Sigma did GCC, GDB, GNU Assembler, GNU linker, basically the entire gnu toolchain.

So they had hundreds and thousands of files and so they would walk across these hundreds and thousands of files and make a branch in every single one of them. And it would take 45 minutes to cut this branch. And then you’d say, “Okay, we’ve opened up the branch. Everybody can start working again.” Right? That’s crazy.

Adam Gordon Bell: That does seem a bit crazy, right?

Jim is talking about how in CVS, the performance degraded based on the size of the repository, not based on the size of the change set.

This is something we kind of take for granted today, but now the performance is related to the size of the change set. Change one file, that should be cheap. Change all of the files, that should be expensive. And branches, you’re changing no files that should be free.

Enter the Rewrite

So Jim had been thinking about this design for a better system and his buddy Karl, he got approached by company looking to shake up corporate development by introducing ideas from open source software development.

Jim Blandy: This was around the time that the cathedral and the bizarre essay was being written. There were a lot of companies that were saying, “Wait a second, why isn’t our internal software development as dynamic as what we see going on there? What is it about that dynamic that makes it work so well out there? And how can we bring that into our own in-house development?”

But what CollabNet was interested in doing, they saw CVS and they knew that it sucked and they were willing to fund writing a replacement for it. So they approached Karl or Karl approached them.

I don’t know exactly how that happened, but anyway, they ended up working with Karl and Karl and I had already started drafting ideas for replacement for CVS, because there’s something that a friend of mine said to me once, “CVS is the worst piece of software I use every day.” That’s a very interesting sentence because it’s got the word worst in it, right? This is the worst piece of software. And it’s got the word every day in it, right? It’s like, if it’s so bad, why are you using it every day? The answer is I need this so badly that I’m willing to put up with the crap. When somebody says that about a piece of software, that’s a good target for a rewrite.

Adam Gordon Bell: This mythical rewrite that Jim started planning, he called it Subversion and he started talking about it with everyone. This whole thing predates Git and Mercurial by five or six years, by the way.

Jim Blandy: So when I told the Signus people, “Oh yeah, I think Subversion’s going to be able to cut branches pretty much instantaneously in constant time. They didn’t believe me.

They said, “Well, we’ll believe that when we see it.” Cutting a branch is nothing. It’s just creating a name for a particular revision. It’s a free operation. So it was a big deal.

So we had already started working on this new design for Subversion, and then CollabNet said, “This is great. We’ll fund you. And we’ll get other people to do the network stuff for you.”

Adam Gordon Bell: There’s a step missing or something. When did you come up with this design? Did you email Karl and say, “I have this idea?”

Jim Blandy: Yeah. Basically, there was a coworker of mine who said, “Yeah, CVS’s repository is indexed backwards. CVS’s repository is the software equivalent of a telephone book sorted by telephone number.” It’s just exactly the wrong thing. So that’s a funny launch comment, right? Somebody says it and you’re like, “Oh, that’s funny. It’s really true.”

But the thing is, you can’t just accept something like that. You have to say, “Well, wait a second. If CVS is backwards, what would it look like if it were right?” What’s the proper organization for a version control repository? Basically I was just thinking about it myself doing the dishes every night. I ended up coming up with a design that actually other people have come up with, it’s not original to me.

I hadn’t read about the other things, but it turns out I think Perforce actually has a very similar repository structure to Subversion. But basically the idea is that whenever you have a commit, and the commit changes say one or two files. You want to recognize that the directory tree before the commit and the directory tree after the commit are almost identical. The only difference between them is that there are these two files that have changed. So what you actually want to do is you want to share as much of the structure between those two trees as possible. Go ahead and represent both trees, but have them share as much structure as possible.

Adam Gordon Bell: It sounds the same as like a persistent data structure.

Jim Blandy: Yeah, yeah. You mean persistence in like the way functional people use that word?

Adam Gordon Bell: Yeah.

Jim Blandy: Now this is a persistent, persistent data structure. Right?

Adam Gordon Bell: The terminology is very confusing, I think. Yeah.

Jim Blandy: It’s persistent in the sense that it saved to disk and it’s not going to go away when you exit the program, but it’s also persistent in the functional programming sense.

Adam Gordon Bell: Yeah. If you have an immutable tree in whatever programming language of choice, when you make changes to it because it’s immutable, it will make a copy, but only of the elements that you need to change, right? And kind of update the pointers.

Jim Blandy: Exactly. Have you ever heard of Chris Okasaki’s book Functional Data Structures?

Adam Gordon Bell: I’ve seen the picture of it. One of my friends bought it and said he couldn’t understand it.

Jim Blandy: That’s too bad. Yeah. Because Chris Okazaki goes into all this stuff and it is hard to understand, but once you get it, it’s kind of mind blowing. I think it’s a good worthwhile investment because a lot of those algorithms play well with incremental contexts, right? That is if you’re making a series of small incremental changes to a large data structure, then the way that the persistent data structures are trying really hard to share as much data as possible really works in your favor.

Building Subversion

Adam Gordon Bell: So you have this idea and what happens next?

Jim Blandy: So I had this idea and Karl and I had started working on it and then Karl gets this funding from CollabNet and so that’s fantastic. And suddenly, we have a guy who’s a web dev expert to do the protocol for us. We ended up getting an office in Chicago. So I’m traveling up from Indiana up to Chicago to meet with Brian Fitzpatrick and Ben Collins-Sussman.

And we agreed early on that we wanted to break it up into a nice reusable set of libraries, right? So if you want to work with subversion working directories here is the working directory library that accesses all of our metadata. If you want to speak the protocol, here’s a library that does the protocol. If you want to have different backends for storage, here’s the interface to the backends.

Adam Gordon Bell: You had your design and then what? There was a couple of you working on it?

Jim Blandy: Yeah, there was about five of us, I think.

Adam Gordon Bell: Did you split it up into modules? And you’re like, “I’ll work on the working directory part.”

Jim Blandy: Yeah, I was working on the server part. So other people took sort of the command line part. There’s somebody who took the working directory library and things like that. So I think that for another kind of project, you have to be much more careful because there’s drift between one person’s understanding of the design and another person’s understanding of the design because the thing that you’re building doesn’t exist yet. Right?

But in the case of Subversion, we had this very clear goal, which was to become a properly designed modern network transparency CVS. And the fact that we were imitating or replacing something that already existed, I think created a lot of clarity in people’s minds.

So I think it actually was a project that could be undertaken with a lot less coordination than you would normally need for something that size.

Adam Gordon Bell: Yeah, that makes sense. So not only did you have an existence proof of something like this existing you knew it, you were using it. I assume you were using it for Subversion source control.

Jim Blandy: Yeah, we had to use CVS at first. But then there was the day of when we started being able to dog food and that was a really great day.

Celebrating Success

Adam Gordon Bell: How did you guys celebrate?

Jim Blandy: We would go up to Chicago. We had this great office, I think it was called Printer’s Row in Chicago. It’s a whole bunch of old buildings that all used to be full of printing presses for newspapers and stuff. They had this cage elevator, where you could see the elevator shaft through the iron bars of the cage. And if you looked down, you could see these gigantic relays that controlled the elevator, and it was a relay driven elevator. And yeah, we partied. I would drive up to Chicago quite frequently and we had a bet that whoever wrote the first security hole had to buy everybody else dinner. I don’t know if you want to call that a celebration or losing a bet or something like that.

So I worked on it for a year, but then I actually found it kind of exhausting. So after a year, I really wanted to go back to working on GDB. I think Subversion started self hosting within the next year after that.

Adam Gordon Bell: So Jim’s design for a new version control system succeeds, it takes over the world Subversion, atomic commits, free branching performance proportional to change size. These were all great changes. It quickly replaces CVS.

Becoming the Leader

Jim Blandy: Then it rose to its heights within three or four years, I think. But it was really nice. We got recommendation by these consulting newsletters, like the Gartner group listed us as an essential tool or best of the breed or something like that, which is really funny because it’s like we didn’t do marketing research. We don’t have any idea. We just know what we want as hackers. And then you have these very serious businessy industry newsletters recommending you and it’s kind of ridiculous.

Adam Gordon Bell: The Gardner quadrant or something? They probably had a graphic that showed [crosstalk 00:28:22].

Jim Blandy: Yeah, it was exactly that. We were in the good quadrant. It was crazy.

Adam Gordon Bell: Somewhere there was a meeting of people in suits, figuring out how far to the left you should be and how far right.

Jim Blandy: Yeah. Yeah. It’s very silly to have those people’s attention, but that’s the way it works.

Adam Gordon Bell: But within five or so years, it started being replaced by other version control systems by Git by Mercurial. Although probably some people are still using Subversion right now, Jim really doesn’t think they should.

Jim Blandy: Yeah, they shouldn’t be. I actually had somebody come and try to talk me into consulting about Subversion for him because he had this great idea about how… But in the end I tried to really talk him out of it. I said, “People aren’t developing it anymore. It’s not actively supported. When you bring in developers, when you want to hire developers to work on your project, they’re not going to know it, but everybody will know Git.” I was in a funny position of trying to talk somebody out of using something that I was one of the original designers of. But I don’t think anybody should be using it anymore.

Adam Gordon Bell: Are you sad?

Jim Blandy: I have Git, I have Mercurial. How can I be sad? I don’t know. I mean, the nice thing was that it set a standard of usability. I think Subversion at the time that it became popular, it set a standard of usability below which people just weren’t willing to put up with, right? Git started out with a terrible CLI and now it’s only a mildly horrible CLI, right? The options are only sort of ferociously confusing and not overwhelmingly confusing, right?

Adam Gordon Bell: Yeah.

Jim Blandy: I think that’s a response to pressure from well-designed interfaces like Mercurial, which has a beautiful CLI and Subversion, which has a very fine CLI. So I think that you could have your influence in a lot of different ways and that influence outlasts the use of the actual code.

Subversion Problems

Adam Gordon Bell: So Subversion is 20 years old this year and Jim, he doesn’t want us to use it, but its influence is still out there. A question I wanted to ask Jim was if Subversion was addressing shortcomings in CVS, what were the shortcomings in Subversion that Git helped address?

Jim Blandy: You know, how Git uses content hashes to identify file contents and to identify directory contents?

Adam Gordon Bell: Yeah.

Jim Blandy: And it’s a very beautiful model. Those hashes are really essential to the distributed nature of Git, because it means that basically if you’ve got data, it doesn’t matter how you got that data everybody can tell that you’ve got this branch and you don’t need to be sent that data anymore. Somebody suggested that Subversion do this. What we were actually doing is we were just assigning fresh numbers to the nodes as we created them. So somebody basically said, “Well, we should be using content hashes.” And this is the worst decision I’ve ever made, I think in terms of impact. I said, “No, we shouldn’t do that. Because if you modify a file and do a rename, there’s no way to tell that the old version of the file and the new version of the file are related at all.”

The only kind of vindication that I can cite for this, is that even now Git doesn’t really know. It just sort of looks at the file and says, “Yeah, they look close. It seems to be right.” And you give it some cheesy parameter that says how hard it will try to look for them, right? And it’s such a kluge and it just reconstructs them post-facto. So it doesn’t even know anything about what happened. It just sort of guesses that this must be a rename of that, even if it’s not. It’s a total kluge.

The Merge

Adam Gordon Bell: When I started using Git, people were talking about this distributed case and I guess it does happen. But the big thing that seemed different to me was merging was free all of a sudden, merging and branching. So you’re the guy to answer this. Why is that? It doesn’t seem like there’s some reason that distributed makes merging better because if you have to do it a lot-

Jim Blandy: No, this is kind of a sad story. The great thing about merging in Git, and I’ll just pick that as an example, but Mercurial is the same. The great thing about merging in Git is that it’s just like… What is a merge? A merge is what I say it is, right? I say, I have this parent and I have that parent, and now here’s a new change set that’s got both of them as it’s parents, right? There’s no restriction on what a merge means. The mistake that we made in Subversion is that we thought merges should actually mean something textually, right?

That actually there should be a way to say, here is the reconciliation of these changes with that change. I think we really just over-thought it a lot. All you need to do is have some good textual merge tools that use whatever heuristics they want, whatever heuristics work well for your project. We’ll have some off the shelf mergers that do a great job in most cases. But if you want to have a specialized tool, you just drop yours in, and you could do whatever you want. And then when you say it’s okay, that’s the end of the story.

Adam Gordon Bell: It’s interesting. Almost what problems you decide not to take on can kind of define things, right?

Jim Blandy: Very true.

Adam Gordon Bell: Or you just get punted on this. They’re like, “Let’s not worry about it.”

Jim Blandy: Yep, absolutely. Absolutely.

Building a Tool To Do Its Job

Adam Gordon Bell: So better merging of branches, Git was distributed, it had content hashes, but better merging was really the big difference. Subversion was huge in its time though. I imagined being the developer behind the tool that most of the developers are using many times a day must be like being a celebrity. Jim said it wasn’t like that at all though.

Jim Blandy: Although, I do remember one time that I had moved on to another company and we were using subversion to hold a copy of the entire gnu toolchain, GCC GDB, BFD, the linker, Assembler, so on and so forth. I think also a copy of it could do a C library. So it was a very large repository, and we used it every day and it was fine. The founder of the company said to me one day, “You know, Jim? Subversion doesn’t suck.” And he said, “I hope you understand the way I mean that.” And I said, “Oh no, no, I definitely get what you mean. Yeah. Thank you very much. I’m proud of it.”

Adam Gordon Bell: The greatest of compliments.

Jim Blandy: It really was though. Right? What more do you want than to have somebody say I use your stuff every day and it’s okay.

Adam Gordon Bell: I want more. I want more than that.

Jim Blandy: Well, I don’t know. Everybody wants to get five stars, everything like that. I mean, when is anything actually five stars, right? Like if I go to a bike shop and I’m trading in my bike and they treat me decently, I give them five stars because that was what I wanted from the transaction. But it’s not like I’m skipping home, right?

Adam Gordon Bell: Yeah.

Jim Blandy: It’s just a transaction. I think a lot of software is there to get help you get your work done. It’s here to help you get through the day.

Adam Gordon Bell: Especially at developer tools, right? A tool, just by definition a tool. Like you don’t want your hammer to do something crazy. You want it to hammer.

Jim Blandy: You don’t want to maximize engagement with your hammer. That’s stupid. You don’t want to maximize engagement with your version control system. You just want it to do its job and get out of the way. And so [inaudible 00:36:16] somebody to say, “This doesn’t suck.” That’s actually pretty much exactly the right thing.

Adam Gordon Bell: All right, that was Jim. The first three-time guest writer of software that doesn’t suck. The thing about Jim’s story that will stick with me besides the guy at the commune making nut butter, but also building distributed software. The thing that will stick with me is Jim’s question, what’s the worst software that you use every day?

Also, this idea that software is just a tool and it should get out of your way. That’s interesting. Nobody ever says that, right? Everybody wants to change the world. He’s like, “Ah, I just try to build things that don’t suck.”

If you liked this episode, if you liked the podcast, tell your coworkers, I don’t really know how podcasts spread. People say word of mouth. So tell your friends, tell them to open up their podcast app search for CoRecursive or search for Adam Gordon Bell and hit subscribe. Until next time, thank you so much for listening.