Ep. #35, The Open Source Journey with Tom Preston-Werner

Marc Campbell: Hi again, and welcome to a special episode of The Kubelist Podcast. While we normally talk about a project in the CNCF ecosystem, today we're going to drift a little like we do sometimes. With us today we have Tom Preston-Werner, co-founder at GitHub and a lot more. Tom is here because he has a ton of experience building and shipping open source software. Welcome, Tom.

Tom Preston-Werner: Hey, how's it going? Glad to be here.

Marc: Great. Great to have you. And of course Benjie is here. Welcome, Benjie.

Benjie DeGroot: Hi, Marc. Hi, Tom. This is the first episode we're recording in the new year. Very excited to get Tom on here and ask all kinds of questions about all kinds of things. Every time Marc talks about drifting I keep thinking about Tokyo Drift, so I'm just going to give a Tokyo Drift reference. All right. So let's get started. So look, Tom, for those that don't know, you're one of the co- founders of GitHub.

I think the way that I look at all of the CNCF and all of Kubernetes and Docker and so on and so forth, is at the core they're open source projects and really the community that was built around those projects, specifically Kubernetes and CNCF, is its strong suit. I think everyone would agree with that.

But underneath that is GitHub, and Git and all the stuff and you were a huge part of creating that, so I'd just love to hear how did it start? Let's just get started, what were you doing? Why did you start GitHub? And how did that get going?

Tom: Yeah. The ideas for GitHub really came out of my experiences at a startup called Powerset, which was brought me up to San Francisco. I was in San Diego before that. So I had some friends in the Ruby community that had come up here and gotten jobs at this company, Powerset, which was trying to be a better search engine and fight Google. Turns out that's a hard fight to fight, but it got me to San Francisco which was awesome.

In that company I worked with a fellow programmer named Dave Ferram, who was always on the cutting edge of everything, so he would introduce me to new technologies and one of those was Git. He came across Git as a version control system. We were using Subversion at Powerset, and so we started noodling around with it and playing with it and realized how great the branching and merging was compared to Subversion, which was not very good.

I mean, better than CVS if you ever used that. But much better than all of them. The only problem was that it was really awkward to set up and use, you had to have a Linux server and create user accounts and then you'd log into that and you could transfer around commits to each other through these user accounts. There was no real web product to do any of this. There were lots of things around for Subversion and you would use those and they were okay, for Subversion.

Benjie: Sorry, Tom. Real quick, not to interrupt you, but what year was this? What year are we talking about?

Tom: This is like 2006, 2007.

Benjie: Okay, so super early days. The boom, the first bust had happened, you move up to San Francisco and you're like, "I need source control," and you found Git. For those of us who don't know, do you know, Tom, where did Git come from?

Tom: Git comes from Linus Torvalds who created it because they were unsatisfied with, I believe, BitKeeper which they were trying to use and they started trying to charge money to the Linux Project. I mean, because the Linux kernel project is huge and they had certain needs and BitKeeper was meeting them, but then there was some falling out and so they, Linus, got fed up and one night sat down and hacked out what became Git, I believe.

He had these very basic concepts around what a commit was and how commits are connected to each other as this directed graph. Really beautiful, simple stuff and created a couple of command line tools to do it and I think it was pretty difficult to use. But it got the job done, and then that is the origins of Git, was from that dissatisfaction.

Benjie: It always is, it always is from some dissatisfaction.

Tom: Indeed, indeed it always is. Yes.

Benjie: All right, so you find Git and then what happens?

Tom: So we're using it internally and then pushing to Subversion, so we'd work on it together, Dave and I would work on the project that we were working on, secretly using Git and then still interfacing with Subversion because you could kind of have the two working at the same time. We were just loving it, and so I was sitting there thinking, "Why is there not an easier way to use Git? Why is there not..." I'm a web programmer, that was my job at Powerset, was to build web stuff.

I come from a Ruby On Rails background so I'd been doing a lot of that prior, and thought I have the skills to make a website that makes it easy to do Git, to share Git repositories between people and you could sign up like you do normally on accounts, like on modern web sites in 2007. Just create an account, be able to push and pull your repositories.

It didn't seem like a super challenging thing to do and it made a lot of sense to me because Git was just so obviously superior to Subversion, Subversion was not awesome and Git was awesome but too hard to use. And so that's really where the idea came from, and it was not a lot more complicated than that. It was like, "Hey, let's make this new technology easier to use."

Benjie: So there's this existing technology, it's the oldest story in the book, "Lets make it easy." So did you start working on GitHub internally at that company, or was it like a side project?

Tom: It was a side project, so I'd do my eight hours at Powerset and then I'd go home and I'd program for another eight hours on GitHub and I was new to San Francisco and so I didn't know a lot of people and I wasn't going out. I'd go mountain biking on the weekends, and that was about it. So I spent my time working on GitHub, and then I started to rope other people into it and then we started working on it together on the side, and we were all just...

Wherever we were, we were in San Francisco, and that's how we built up the initial group of people that brought the initial version out. We had an initial version out after about six months, no, three months. It was really fast, we hacked just the barest minimum of what you could do, sign up, push a repository, browse the code. That was pretty much it, and we had that out after a couple of months.

Marc: I was going to say, that's interesting that browse the code was in there in that initial first version. It wasn't just a backend that sits on a Linux server somewhere that you can Git Clone and Git Push and everything too, but it was the web UI was a key part of it.

Tom: Yeah, that seemed like table stakes. The existing products that worked for Subversion had that, so it was like, well, they've got to do some of the basic things. If you want to share with other people, you want to be able to send open source repositories to other people so that they can look at it. It's a lot easier if you can just look at the code online, right? And then see if you're interested in it or not, and then you might get involved.

So that was always there from the very beginning. I actually worked on mostly the backend stuff, so I worked on the Ruby code that would let Ruby On Rails access the Git repositories on disk. That was a piece of open source software called Grit, because it's Git with an R in it because it was written in Ruby, so it was called Grit because I'm very clever at naming things.

Benjie: Very clever, I love it.

Tom: So that was great, I spent my time doing that. Then I had the other people that were helping me with the project that came on. Chris Wanstrath, especially, we were working on the Ruby On Rails for an end part, so I was doing backend and Chris was doing more of the frontend.

Benjie: So when you started this thing, it was kind of like a need at a private company, Powerset, but was it always like, "This is a place where everything open source should live"? Or did that develop? It sounds like you were thinking about that from the very beginning.

Tom: Yeah. So one thing that I wanted to make sure that GitHub had was a business model because prior to that, and before Powerset, I had done Gravatar which is the avatars that work everywhere and is owned by Automatic, now WordPress. That's WordPress' avatar system. So I had built that and it was costing me a ton of money and just a huge emotional drain when it would go down and I didn't have a way to monetize it or couldn't think of one because I didn't have any skills to do anything but write software back then.

So I eventually sold that to Automatic around that same time, and really freeing that up allowed me to spend time on GitHub. GitHub was like my next side project, because I always have a side project. There's always something that I'm doing as my main thing and then there's always something I'm doing on the side to explore personal interests.

So GitHub became that side project and it was great because I thought there's a clear business model here and it's that if you put your code up here and it's open source, then you can use GitHub for free because that's great marketing. It gives back to the ecosystem. It all lined up and made sense.

But the business model is if you want your code to be private, then you will pay us for that and who wants their code to be private? Businesses. So it made total sense, and so that was built in from the very beginning, was the idea that it'd be free for open source, it would cost money if you had private repositories.

Benjie: You're saying that like it's a small thing, but there's massive, massive industries that are completely copying that idea. We kind of are doing that at Shipyard. I'm just saying that. So you had that insight before you even wrote your first... well, at the beginning of writing your first lines of code, even? Because I don't think that existed before GitHub, right?

Tom: Yeah. I mean, maybe not. I don't remember it being a decision that we made, it just felt right. Like, "Yeah, of course this is how it should work." I'm trying to remember if there were other systems that did that because there was a group called ENTP that did some kind of a Subversion browsing piece of software that we took some inspiration from, and I can't remember how they did their business model.

So I can't claim we invented that as a thing, but it just seemed very natural to us, that that would be like, "Yeah, of course." Open source people aren't going to pay you to host their code, so why would you try? And businesses are happy to pay for things that are valuable to them, so let's just do it that way and see if it works. You need content on a site for anyone to care, and so that was like, "All right. Well, if it's free for open source then maybe people will use it."

Benjie: Just listening to the story so far, it's funny because I'm like, wow, all these massive things that have shaped our industry all were just decisions that obviously were very logical but at the time they were pretty revolutionary. So not to give you too much credit, but I think it's really cool that you just put all these pieces together and it sounds like a natural thing that was happening.

Tom: Yeah. Some of it too was a reaction to the existing open source repositories like SourceForge and Google Code, which we were very frustrated with because SourceForge, there was a single, top level namespace for projects. So if you wanted to put a project on SourceForge, they were like, "Okay. Here's how it's going to work. You're going to make a request for a name and then we're going to approve or reject it."

Which I just thought was the dumbest thing I could possibly imagine, it's like, "Really? I want to put up my project and I have to get permission from you to share that with other people?" It just was ridiculous. Then Google Code was much better and so a lot of people were using that for their open source code and it was Subversion only, of course. But they enforced very strict license requirements.

You had to had an open source license to put your code on Google Code, if I recall. I'm trying to remember how it was structured, I can't even remember. But it was frustrating, these things were barriers. It's like, "Why should you care what license there is? If you don't put a license on your code, who cares?" It's not open source, but whatever. If you want other people to be able to look at it, why not? And share it. I don't know, figure out license stuff later. It just felt overly burdensome, and overly... Why? Why are all these things necessary?

Marc: It's conflating the concept of hosting code with what you're actually going to put in there, didn't make sense.

Tom: Right. It was enforcing these opinions that I didn't think were necessary. So that really is where the namespacing by user came for GitHub, where everything is username/reponame or orgname/reponame.

That I think is one of the most impactful and powerful decisions that we made at GitHub of all of them, because that meant that everyone could put up any code that they wanted in their own little private space, and it could be code that people cared about, it could be code that nobody cared about. I could name something whatever, you could name something whatever. There would be no collisions and it just really made it possible for people to think that sharing any code was great, that it didn't have to be special.

Like, SourceForge wanted your project to be special enough to consume a top level namespace. Or Google Code wanted it to be a real, legitimate project with a real license and whatever. On GitHub it was like, "I don't know. You got a snippet of code? Put it up."

That's where Gist came from as well, really, it was an even further evolution of that idea, which is like, "Don't even make a repo. Just paste a file and guess what? Now it's a Git repository and it has versioning and there is no ceremony to your code if you don't want there to be."

Benjie: Gist, when did you guys roll that out? I remember it being a big deal, but I don't remember when that was exactly.

Tom: It was pretty early, it was within the first two years for sure. It's the project that Scott Chacon came on, one of the co founders. We brought him on to work on that because none of us were Git experts. We were Git newbies, we barely knew what we were doing. I knew a lot from having to implement the code necessary to read stuff off of the file system, but as far as more advanced Git usage, Scott was the one that knew.

He was in the Ruby community and we knew him through meetups and he was working at a company where they were using Git as a transfer mechanism to get payloads of video content out. He worked at a company that was doing... You know when you go to the mall and there's a projector screen and it projects down on the floor and there's like soccer balls and you interact with it and kick them around?

He was working at a startup that did that kind of stuff and they needed to deliver content to all of these different setups to deliver new content. Because bandwidth was still quite expensive back then and you were delivering maybe a fair amount of data, they would use Git to dedupe things and make the smallest possible deliverable bundle to these various installations.

So he knew Git really well, so we were like, "Hey, Scott. You're one of the only people that we know that actually knows Git super well. Could you come an implement this thing for us called Gist to see if you work well with our team?" This was within the first... Maybe it was earlier than that because he came one really early, within the first eight months or something. It must've been within the first year that we were working on Gist.

Benjie: Yeah. Maybe I just remember when I found out about Gist is actually what I'm talking about. I was really excited when I found out about Gist is really what I'm referring to, because I don't think it was right at the beginning when I found out about that. But yeah, taking that, making things accessible, and using Git in this way and it's not magic, it's source control. It's always been one of the things I've noticed and loved about GitHub personally.

Tom: Yeah, it was showing off the strengths of Git, that it's so lightweight, that you could make every paste a Git repository. It just, I think, blew peoples' minds and being like, "Oh wow. That's really neat. You can do that? That's not overly burdensome to do on the server side, to make every single one of these pasted files a full Git repository." Really the overhead of a Git repository is extremely minimal.

I was also upset with the PasteBin sites of the day. I was frustrated with all of them. We were like, "You know what? We're just going to crush them all by implementing this thing." That was the dream, and it worked pretty well actually. But it was really just an experiment.

So much of GitHub was just playing around in the early days, being like, "What can we do? What interesting, new things can we do to reduce friction for people to put code online and share it and work on it together?" We all loved open source, we'd been using open source for years and loved it. I loved building open source, it got me to where I am today and where I was then. Just this idea that you could give back in these ways felt really satisfying.

Marc: Tom, I want to go off on a branch for a second here because you were just talking about you love open source too, these other problems that were interesting that you wanted to solve, so in addition to GitHub there's a ton of other open source projects that you've created, right? There's SemVer, TOML, Gravatar you mentioned earlier, Jekyll.

I'm sure I've missed as many as I named. What else there? I'd love to hear more and then understand the origins, did they come out of problems that you were solving at GitHub and you were like, "Oh no, I can do this better if we actually just had a better, I don't know, a TOML, a better DSL to specify a new language"?

Tom: Right. They all came out of various frustrations or needs. The first open source project I ever worked on was called Chronic and it was a time parsing library for Ruby. There were 37 Signals, of course the people that make Ruby On Rails. They have a product called Base Camp, and in it they had this cool feature where you could write in natural language when you wanted a calendar item to be, and I thought that was really neat and I wanted it for something I was doing.

I was like, "How hard can it be to write a natural language time parsing library in Ruby? That would be an interesting challenge, it seems solvable." So I sat down and I was like, "All right, what are all the different ways that you can say a time? Okay, next Tuesday or three Tuesdays from now, or 6:00 PM last Wednesday."

There's a million different ways that you can say these things, so I wrote down every example I could think of how to do that, and then categorize them as far as structurally how are they different and then I wrote this parser for those and constructed a time from that. It was a lot of fun, and I learned a lot about Ruby in doing it. Then I showed that off at the local Ruby meetup in San Diego where I'd go for the Ruby meetup.

It was called SD Ruby. I loved it, it was amazing, it was the best of programming, the best. The quintessential of if you love programming, that's the kind of thing to me that was pure joy. It's just like you have this abstract problem and you figure it out and then you write the code to make it work and then you share that code freely with everyone and then talk to people about it, and then other people start using it. It was amazing.

So that was how I started my open source journey, and that was a really great project for that. It just came out of a need, and the great thing about new languages, when new languages come out there's no libraries and so you can come in and be like, "I'm going to write the library that does Random Thing X." And you get to do that, and then you get to become known for doing that and you get the experience of doing it and the experience of creating an open source project and sharing it and managing it, leading it.

There's so much that can be learned on that open source journey that no one has to give you permission to do, you just decide to do it and you go do it.

Marc: Yeah. I think that's true, and there's other opportunities, not just when a new language comes out but big platform shifts. Kubernetes, we talk a lot about Kubernetes on the podcast and I think there's a lot of opportunity to take problems that were solved but aren't really good in the Kubernetes ecosystem and reinvent them. Or, coming back to the language thing, I think some of that's happening right now around Rust. I don't know, Tom, if you're still writing primarily Ruby or if you're using other languages. Where else are you seeing that innovation happening right now?

Tom: Yeah. I spend most of my time writing JavaScript these days, actually. I still love Ruby, don't get me wrong. I'm doing some electronics, some embedded electronics stuff so I'm writing some C++ which is weird. Yeah, I think it can be anything where there's a tide coming in that changes the whole industry. There's always opportunities, there's always things that are missing, there's always the beginnings.

You can look right now and say, "Okay. Well, what are those places?" Let's say a couple of years ago it was maybe the world of crypto, which I have many misgivings about. But there was this open territory, completely blank, a blank canvas to go into and be like, "This part of this is terrible, so let me write something, let me come up with an idea. I know the pain." If you work on something you know the pain that's there and then you write something to solve the pain.

That, to me, has always been the process and that's always where there's opportunity. Where is the pain today? Maybe it's in AI. There's so many cool opportunities there and things are still really challenging to do and there's still all kinds of issues with the way that we do AI, and so there's tons of opportunity there. In the world of VR and AR, is that going to go somewhere?

I don't know, but there's a lot of challenges and opportunities in that world as well. In any of the infrastructure stuff, we're still trying to figure out infrastructure in general. In the Kubernetes world, you see all the jokes about how complex it is. Of course there's mountains of improvements and things that can be done in that world, so to me it's always embed yourself in a thing, figure out where it hurts, and then write something to solve that pain.

Benjie: Pretty sage advice, I think. All right, so I want to bring it back a little bit to the GitHub origins story because I still have questions. So you're working on this project, this side project. When did you decide with your co founders, like, "Let's go do this as a full time thing?" What were the signals? What happened that you were like, "Okay, it's time"?

Tom: So we did our public launch, I think at about the six month mark, and that's when we started letting people sign up freely. We had a closed, a private beta. It was the Gmail launch thing where it was like, "All right, everybody who gets in, gets five invites and then you can send out invites and then everyone is asking for invites." It worked really well. So we opened up the doors publicly, I think it was either six or nine months in, but at that point we had the business model embedded in it already.

Everything was free up to that point and then after that point we said, "Okay. Now you're going to pay for private repositories, and here's a couple of private plans." It was like you can have three private repositories for $7 a month and then there were a couple more plans higher than that. Then on that first day that we started charging, people started paying. People signed up. And even before that, people were like, "Hey, can I pay for this? Because this is awesome and I want this to be around and keep using this, and I get value so I want to pay you."

So people were asking to pay for it before we had even launched, which was amazing. All of these were signs that, "Hey, there's something here. Let's keep going and see how far this thing can go because it seems like it's working." We were using it to build GitHub right from the very beginning.

We used GitHub to build GitHub, so we were experiencing the pain of using the system itself, the dogfooding. That's maybe the most important thing you can ever do with any project people you're working on, is to dogfood it, is to make sure that you are using it and experiencing it every day so you know exactly where it sucks.

At that point I think we were all like, "Yeah, let's keep going." Then it was maybe at the nine month mark of working on it then, a few months later, that we... Three to six months after that we were making enough money that we could stop doing what we were doing and work on it, and I was still working at Powerset. Powerset got acquired by Microsoft and some of that technology got rolled into Bing, and so GitHub, we were already doing okay with GitHub and so I was like, "I'm going to quit Powerset at the acquisition."

So I never became a Microsoft employee, but it kind of lined up right there. I was like, "I'm going to go do GitHub full time." And I have a blog post about this, you can go read that. It's called, I think, Why I Gave Up $300,000 To Go Full Time On GitHub, or something. Because they were offering me over some number of years, three years or something, 300 grand to go work at Microsoft.

That was a hard decision, that's not nothing, it's a good chunk of money and this was like 15 years ago. But GitHub was so promising, it was like, "I want to work for myself, I want to do this. There's opportunity here." So it was a gamble, but it wasn't that much of a gamble because it was already making money.

Benjie: But you saw it working, the signals were coming in. You took the dive, and then obviously you just kept plugging away. Did you guys not ever raise money? Did you guys ever raise money from VCs for GitHub or no?

Tom: Eventually, yeah.

Benjie: Okay. But not at the beginning, you guys were just a bootstrapped company, dog fooding. Now all this stuff is a little cliché, but you guys innovated on a lot of it. I guess not all of it, but a bunch of it is pretty cool. So you're working at GitHub, you have some co founders, you guys start going. When did you start going parabolic? I guess is my next question.

Tom: Well, I don't know that we ever did, honestly. Here's the weird thing, is that our user growth was never exponential like you see some companies, where it just takes off and it's insane. It was always fairy linear.

There was some curve, obviously, in the earliest days. The slope increased, but it wasn't like you sometimes see where it's just like overnight, wham, the growth rates go through the roof. It was always more steady, and I think that's because we didn't take venture capital. We never felt super pressured to go out and do giant marketing campaigns or do the kinds of things that a lot of startups today do because you have a runway and a limited timeline. We were profitable, we didn't have to do anything that we didn't want to do.

We only hired when we had enough money to hire more people, except for in the very... There was once early on for our first two main hires that we did at the same time, we stretched and went unprofitable for a couple of months, but we were growing quickly enough revenue-wise that we could hire when we had the money to hire so we tried to stay profitable.

That was true up until we took money, and that was four or five years in that we took the first outside money from Anders and Horowitz. It was just very satisfying to be fully in control of our destinies. It was something that I'd always wanted, that kind of freedom, I think we all did. We tried to really do things from first principles, we tried to think through everything from scratch. Maybe too much sometimes.

But you don't know where the line is until you cross it, so I think there were occasions where we crossed the line into ridiculous... As an outsider, you'd look at it and of course the VCs would come in and we'd tell them how we were doing things, and they were like, "What? What? No, you can't do... No." We'd be like, "This is what we're doing, man. Get onboard or get out of our way."

Things were working well enough that we were maybe a little cocky about it, maybe a lot cocky about it. But, I don't know, it was awesome. We really focused on making a great company and building an environment that people wanted to work in. We wanted to build a company where we would have wanted to work as employees. We'd all worked other places and all had bad experiences working other places, and we wanted to make something different, and I think we succeeded in that.

Benjie: From the outside looking in, I can concur with that assessment. I do like how you would tell them, "Git 'er done." Did you use Git or did you say get?

Tom: I probably spelled it with an I. No, I wouldn't do that, that's insane.

Benjie: Okay. So four or five years before you took any outside investment. So the last big piece before we maybe move onto some of the newer stuff you're doing, when did big projects start moving their source code onto GitHub? And what was the first holy bleep moment that you had where it's just like, "Wow, Linux is on here," or whatever it was?

Tom: Well, Linux was never and probably will never be on.

Benjie: Yeah, sorry. I actually knew that one, sorry about that.

Tom: They love the mailing list. I could tell you stories about trying to contribute to Git Core via the Git mailing list. Man, talk about stress. You craft your email, your pull request via the mailing list and you go over it like 37 times because you don't want to get yelled at by these super hardcore... They're all Linux Core kind of people, the Git team. Anyway, that's another story. But the first big project that came over was Ruby On Rails, the first big one.

There was Merb, Merb was a kind of early Ruby framework that had some notoriety that came over fairly early. That was being led by this guy Yehuda Katz, who's amazing in the Ruby community, and he was actually user number four on GitHub. So he was there from the very... It was like me and Chris and PJ, and then Yehuda for some reason was user number four which was always hilarious because we would have these bugs in the early days of GitHub where some random commit would show as being authored by Yehuda, even though he didn't have permission on the repository or anything.

It was like, "How? Why is it showing Yehuda as the author of this commit? Is this a security issue? What is going on here?" It turns out that in Ruby, every object has an ID, even the nil object has an ID, and guess what the ID of nil is? It's four. And so when there would be a nil object and you'd try to call because you thought it was a user object, and you'd call user.ID normally. If the object, if the user was nil, you call them nil.ID and it's four, and it's like, "Oh, that's Yehuda." So we had these hilarious bugs called the Yehuda Bug.

Benjie: So the most prolific contributor is Yehuda, actually is what you're saying.

Tom: Yeah. Well, he was at one point.

Benjie: At one point.

Tom: So he was associated with the Merb project and he helped bring that other, and that then I think paved the way for more Ruby projects and we were all really embedded in Ruby and so that's a community that we knew, that's where we evangelized it early on, that's where projects started to come over. We actually asked the Ruby On Rails project to come over and they said no.

This was very early on, they were like, "No, we can't." They were using Subversion and they had all their systems and everything built up around that, and it just wasn't going to work and we were like, "Oh, all right. Fine." But then like three months after they, they came to us and they're like, "We want to move over," and they moved over. This was, since inception, maybe this was seven months.

This was I think shortly after the public launch that we did, seven months or something in they moved over. Which was, in retrospect, a really bold move because GitHub was not very fleshed out. There wasn't a lot there at the time. But people in the Ruby community were really discovering Git, that was the first community that moved over to Git, was the Ruby community. Ruby On Rails moving over, that was the holy bleep moment. It's like, "oh wow. This is a big deal." There's, I don't know, at least thousands of programmers using Ruby On Rails for legit stuff and we've got to make this thing work for that, and it was huge.

Benjie: Yeah, I mean that was Fail Whale time. So that was Twitter was all Ruby, I remember, back then.

Tom: Yeah, there were big companies that were built with Ruby and Ruby On Rails so it was legit stuff. That was huge, that was definitely a moment, that was a moment in GitHub history because that brought over then the rest of the Ruby community because people were like, "Oh geez, if Ruby On Rails is using this, then I got to get on board. I got to figure this out."

Benjie: So that was probably the biggest or the earliest inflection point from an open source perspective?

Tom: Yeah, for sure.

Benjie: Then when did the floodgates open for all these other... I mean, looking back from my perspective, I'm like, "Yeah, if I was ever going to start an open source project I'd go to GitHub." And I'm trying to think of what I would do before that, and the answer is SourceForge, I guess. But I never did anything with SourceForge so I don't even know. The consolidation and the social aspect that GitHub brought to the open source community, did you think that it was going to go bonkers and these massive, massive, amazing projects were going to come out of there? Did you know that this was going to happen or was this just insane?

Tom: Well, I think at first we didn't know anything was going to happen. But when things started happening and Ruby On Rails came over, I think we were like, "Yeah, let's go get everyone. Everyone should be on GitHub." That was the goal. It seemed like it could happen because the alternatives were terrible.

Benjie: Yeah, I'm trying to remember SourceForge and I don't really.

Tom: SourceForge was a disaster, even then. It became progressively even more disastrous after that, they started pushing download links and malware. Man, it became very dark in the SourceForge history.

Benjie: Yeah, anyway, anyway.

Tom: We would reach out to projects and talk to them and be like, "Hey, what do you need? We'd love you to be on GitHub. What can we do for you? Can we help you import into Git?" Because getting your history over was a big deal so we built tools that would help people migrate over. My favorite of all time is one of our April Fools jokes. April Fools is always terrible, right?

That's the day that you just stay off the internet because everything is fake and dumb and whatever, you don't want to be that idiot that thinks something is real and gets excited about it and then everyone is like, "You know it's April Fools, right?" And you're like, "Oh." So we, as we thought everything from scratch, we wanted to do something that was better for April Fools so Scott Chicone had this notion that he was going to build the Subversion bridge for Git and that we would release that for GitHub.

And so on April Fools for whatever year that was, probably 2009 or something, we had this blog post and we were like, "GitHub now does Subversion. It's SVN Hub or something." Which was hilarious, right? Because we spent all our time talking about how terrible Subversion was, so we were like, "Now you can use Subversion to check out a repository and work on it and make your commits and get them back into your repository. Ha ha, right?" And that was the blog post.

It was like, "Here's the URL," or whatever the connection string was in order to pull your repository from GitHub and have it turn into a Subversion repository and it was like, "You should try this on your repository." And it worked, he built it and it worked, it was a working thing. It was real, and it just blew everyone's mind because it was an April Fools joke but it was actually real. So that was then the bar for April Fools jokes, it had to be that good if we were going to do future April Fools jokes.

Benjie: I remember, Marc, you remember that, right?

Marc: I remember when that came out I was also exactly like what you just described, confused. I'm like, "Wait, these are normally just joke blog posts by companies. This thing actually works." I think it might even still be in GitHub right now as a thing. There's probably people using it, Tom.

Tom: Well, I know. Then people started, they're like, "Oh, we can use this as a way to transition from using Subversion to using Git."And I think you're probably right, it was improved over time, but I think it probably is still there.

Benjie: That's pretty cool. Well, I just have to say I'm speaking on behalf of the Kubelist community, GitHub is dope, we all love it and good job and good job to all the co founders and everybody. It's really cool to know that the origin, it's really cool. I had no idea that you guys understood what you were trying to do and the goals were there, and it just all aligned very well. I could go on for 10 more hours trying to hear some cool GitHub stories, but we can talk about some of the other stuff that you're up to. I'd love to hear a little bit about Jekyll, I mean, you did Jekyll. That's pretty cool. Maybe tell us a little bit about Jekyll and then maybe we can skip forward to some of the newer stuff you're working on.

Tom: Yeah. Jekyll was fun, that's another one of these scenarios where I was frustrated. I was using WordPress for my blogs for many years, I used movable type and all kinds of other stuff in my blogging past and I'd have them on random servers, hosted at random places. Then I'd blog for a while and I'd forget about them, then those companies would shut down my server and delete my whatever because I wasn't paying attention and so I kept losing my blog content which I was very unhappy about.

Or I'd get a database dump and then I'd have to recreate it somewhere else. It was just horrible, all that ceremony around keeping my blog working just felt really ridiculous. So I had the notion that if I could write my blog in, I think it was probably Textile at the time. Do you remember Textile? What Textile was? It was the Textile versus Markdown war.

Benjie: Of course, yeah.

Tom: So originally it was probably Textile, but whatever. So I was writing, I was like, "What if I can just write my blog as text files in a Git repository? Then I would never lose them, because everything that I ever put on GitHub will be there for the rest of my life and it will never be lost. That would be cool, right?" But how am I going to take these Textile and Markdown files and turn them into a website and push them up? There was one or two static site generators out there at the time that I looked at and they were not super what I wanted.

I was like, "Okay. I could just write a simple Ruby script that takes Markdown files and smooshes them into a template and then creates HTML pages." Then if I could take that Git repository and get that online really easily, that would be cool. So we were talking about this and we were like, "What if there was a system where you could get arbitrary Git repositories and have it published for you? That'd be neat, right?" If you could just take a GitHub repository, it'd be like, "Take everything that's in this repository and just shove it into whatever web server."

That's pretty simple. But you need to be able to do more than that, you need to be able to... What if you could push up the repository and then run the converter on the server side, so you didn't even have to run the converter locally? That would be extra cool. So I was working on this, what became Jekyll, a little static site converter for my own blog, so I created it.

Then I think we were at the same time noodling with the GitHub Pages idea, and I was like, "Hey, I wrote this thing. What if we included this by default? Then every repository that you put on GitHub Pages would be run through Jekyll, and if it doesn't look like it... It'll only convert when it's in the Jekyll format or whatever." So if you have a bunch of static files there it'll just leave them alone and publish them, but if you have the Jekyll style directory setup and whatever, then it'll just convert them for you automatically.

That would be a cool way for me and other people to make a blog or every open source project needs a website, right? So let's make it easy for people to do that by just doing that right, then you could have a GH Pages branch on your repository, so all these ideas kind of came together and became GitHub Pages, and it became powered by Jekyll because I had built that for myself and was like, "What if we did this? Right?"

And then we just did that and that's the reason that Jekyll became popular. Nobody would use Jekyll if it hadn't been part of GitHub Pages, but if you wanted to leverage GitHub Pages and have free hosting for your open source project, you could use Jekyll for free. It all just came together beautifully. Just another one of those things that was such a satisfying programming journey.

Marc: Yeah. I think it was the early implementations, not only in Kubernetes but really popular in the Kubernetes ecosystem right now is the concept of Git Ops where you have all of the declarative manifests that say, "Here's what I want to deploy, push them to a repo." Then you have something that's polling that repo or a web hook or some sort of an interface there to get it actually deployed to the cluster. Jekyll sounds like the same idea for your blog.

Tom: Yeah. I'm trying to remember the discussions that we had around this. Someone may have been like, "Would there be a way for me to SCP or SFTP or use FTP to get some additional files up to GitHub or something?" Or maybe we were talking about hosting, web page hosting as a thing we could offer and someone was like, "We could just have an FTP server and then people could FTP their files up for their website and it would work."

Then we were like, "Why would we use FTP when we have Git?" It was like, "Oh, that's a good point!" That idea really then, for people, that let people think that way. It was like, "Oh, Git is a transfer protocol and if I already have repo hosting, that next step of just taking those files and publishing them, now you push to publish. That was what we called it, push to publish. That idea became all of Git Ops, it was like, "Oh, what else could you do if you paid attention to when a repository was being pushed to GitHub? You could trigger all kinds of stuff."

Marc: Yeah. Heroku can come out and all these different... Yeah, it becomes the source of truth and it's such a powerful concept actually. I'm actually curious too, Jekyll, where did the name come from for Jekyll?

Tom: Jekyll was originally called, I think, Auto Blog because that was... When you come up with a project and you're like, "All right, I got to name my directory something." And that was the first thing that I thought of.

Marc: Jekyll is a better name than Auto Blog.

Benjie: Yeah, everything you've said has been super impressive, but that was not impressive, Tom.

Tom: That was a terrible name. Well, at least I recognized it was a terrible name. So I was like, "All right, I can't call this Auto Blog. It's a terrible name, so I need to come up with something else." I don't know, whatever. I let my brain do whatever my brain does and it just suggests an idea for things. It's like it's transforming your blog in one format to another format, what other kinds of things transform?

Well, there's this story of Dr Jekyll and Mr Hyde, and the former is all straight laced kind of doctor and then he converts into this monster creature, Mr Hyde. So that's like a blog, it's all straight laced in the Markdown format and then you convert it into a monster of a website that's super awesome. So what if I just called it Jekyll? And I looked is there anything else called Jekyll? No, I don't know, good enough, ship it.

Benjie: Well, that is a good name. I will say that at some point in your career, if you want to do a follow up and you call it Hyde, I think we all support that. I don't know what it would be.

Tom: So there is a Hyde project, which it was a different language, it wasn't Ruby. But it was essentially a clone of Jekyll in something else. I don't know, go look it up. Go look up what Hyde is. But someone came out with Hyde I think pretty quickly thereafter.

Marc: So moving on, another project I think that we use pretty regularly, project, maybe it's just a spec. I'd love to hear how you think about it actually, it's SemVer. Semvyr.org. I think you created that document.

Tom: Correct. That actually comes more out of the Powerset days than the GitHub days. I wrote that down while at GitHub. I can't remember if there was a specific thing that I was frustrated with. But definitely at Powerset, Powerset was doing some ridiculous things with versioning internally so every package that we used was versioned and this was everything. Every package across all package managers were rolled up into this super package manager that could package and you could specify dependencies on everything that everything was using, which was pretty cool.

The problem though was you'd get into these scenarios where something would over specify a dependency on something and now you've got different things you want to use, specifying different versions or dependencies. And now you can never resolve them, and now you can never reuse these two different things together. Anyway, so I wrote about it, I was like, "This is frustrating. It's frustrating that we have versions, but that they don't mean anything so that when people make releases they're just like, 'I don't know. What does it feel like? Does it feel like a major versioning kind of thing? Does it feel like a minor version thing? Do people even know what a..."

There was no rigor around it, it didn't mean anything, not really. It was A.B.C but they didn't really have defined meanings, and that was really frustrating because then you'd get someone rolling a major when they really shouldn't and now you're like, "Ah. Ulch, now these two things aren't going to work together anymore." Anyway, it was super annoying and frustrating so I sat down and I was like, "There's got to be a better solution to this, there's got to be. We could at least agree on what the different parts of the versions mean, right? At minimum we could do that."

So I sat down and I wrote some simple document about what major, minor and patch should mean, which seemed to me to make sense and how people were supposed to use it but couldn't agree on, and just wrote it down. I don't even remember, I can't remember why I did that. It wasn't something that was useful to us at GitHub at the time, I don't think. Just a mental exercise in frustration at version numbers.

Probably someone released something as a minor that was a major breaking change and I was like, "What are you doing? Ulch. Enough, got to write this document." So I wrote the SemVer document and started distributing and started talking about it at conferences and stuff and it had a slower start, I think. But then a couple of projects started using it. I think the main, the only reason that anyone cares about semantic versioning now is because NPM took it up, and was like, "Okay, sure. Let's just tell everyone to use semantic versioning, and then everyone's lives can at least be marginally better."

Marc: Right. Because the real value is you take your risk tolerance and you say, "I'll take patch versions, I'll take minors, I'll take major versions. Whatever my risk tolerance is, I don't need to think about that anymore because I trust that you, package publisher, are honoring the contract here that lists what each of those versions are going to contain and what they won't contain."

Tom: Right. I mean, why even have a version number of that nature if you're not? Why not just start at one and count up? If you're going to have three separate bits of a version, they should mean something. I don't know. It just seemed dumb that they didn't.

Marc: Yeah. There's stuff like Calver now, which it's interesting but it doesn't make some of the same contracts with us and in Kubernetes, Kubernetes itself is not really SemVer compliant. We're at 1.25 or 26 right now, but there's stuff added and removed with different minor versions if you compare it to a SemVer spec. But a lot, it is really popular and commonly used in the ecosystem now.

Benjie: I think that at the patch level Kubernetes is good, but at the major version level, it's horrible. I'm pretty sure. But anyway, we don't have to talk about that. I like SemVer, we use SemVer at Shipyard, we love SemVer.

Tom: The challenge is that SemVer was really designed when I wrote it, it was talking about libraries, not giant frameworks. It's much more difficult to version a giant framework or something like a web browser, right? You look at something like Chrome and you're like, "Could we semantically version that?" I don't know. Because to use SemVer for real, you need to specify what your public API is, otherwise the semantic versioning doesn't mean anything. If you don't have a rigorously defined public API, or at least some way for someone to decide whether a certain way that they're using the software is supposed to be part of the public API or not, then you can't really ever say anything about versioning from a SemVer perspective.

What it means is that you end up bumping your major version a lot because you're constantly breaking something that you would consider part of the public API. Another project that I'm working on right now, RedwoodJS, a JavaScript web framework, we sat down and we were like, "How rigorously do we want to follow SemVer?" And I said, "We should probably follow it as rigorously as possible, given that I wrote the spec."

But that means something, what that means is we're going to ship major versions fairly often, which we do. We're already on major version three, and Redwood is only two years old, two and a half years old. The first entire year of that was getting to version one, and so we release a major version every couple of months because if you want to follow the spec and you're moving fast and you don't want to build up infinite amounts of cruft in your API, then you have to deprecate things.

You have to break things that you said were part of the public API, and when you do that and you're following SemVer for real, you have to bump the major version, and so you have to be okay with that. There's another blog post I wrote which was called, I believe, something about Your Major Version Numbers Are Not Precious, or something. It's just like, look, get over being afraid to bump your major version.

If you need to communicate to your users that you broke backwards compatibility on literally anything that you count as part of your public API, then bump the major version so that people know. Yes, it means that you're going to run through your major versions more frequently than it feels comfortable, but who cares? They're numbers.

Guess what? You could version 9,622 and nobody would care as long as you were communicating what you were doing with your project via that number. The only problem is that you get to not use that as your giant marketing number anymore, you don't get to be like, "Version 5, let's have a giant publicity around it."

So the way that we solved that with Redwood is that we have a thing that lives above all of that which we call the Epoch or Epoch depending on how you want to pronounce this word, E-P-O-C-H. That then is totally separate and that's just a marketing term, and for Redwood we name them after national parks in the United States. So right now we're on the Arapaho Epoch.

Benjie: Moving forward, you are now working on some new, cool open source stuff. Tell us what is Redwood? Tell us about that a little bit.

Tom: Yeah. So RedwoodJS is an open source, JavaScript and Typescript web application framework that is like Rails, right? So if you've used Ruby On Rails before, you want a full stack inclusive, batteries included, opinionated framework for building a web application, then Redwood might be really good for that. The basic technology stack that we work with is React for the frontend, we use GraphQL to talk from the frontend to the backend.

So your backend ends up being a GraphQL API, essentially. Then you use Prisma to talk to your database, and this is all in JavaScript or Typescript. Then it integrates testing, so there's a whole testing framework integrated and through the whole frontend, backend, you can test, you can mock out your GraphQL API. It includes Storybook. All of this stuff is set up and configured out of the gate so that you don't have to do all of that grunt work to get it working.

And so if you're working on a startup, we really like this for startups, and people who are building companies that are going to need all of this support and are probably going to eventually have multiple clients because GraphQL, there's some additional overhead with GraphQL. But if you're going to have a web app and you're going to have a mobile client and maybe you're going to have a command line tool or something, if you're going to have all of these things, writing your API once instead of writing your web app and then having to be like, "Oh, now we're going to have a mobile client so let me now spin up a GraphQL API or a fully separate Rest API or something."

Being able to write your GraphQL API once is some additional overhead upfront, but it saves you a lot of time in the long run by having a single API that now is your one source of communication truth. So these were learnings that came out of a startup that I did with Scott Chacon called Chatterbug which is a language learning startup. We were using a stack that was similar to this but we were having all kinds of problems, it was annoying and there were no best practices defined in how you use these things together or just the fatigue of having to choose the technologies.

Like what am I going to use for CSS? What am I going to use for my protocol? And blah, blah, blah. There's millions of choices that you'd have to make, how am I even going to layout my directories and files on the file system? Right? React doesn't care, there is no best practice for that. You're on your own, figure it out. If you create a React app, everything else is up to you. It's very fatiguing and you do a tremendous amount of integration work so we do all of that for you.

Marc: Yeah. Not only is it fatiguing, it's generally not differentiating. It's so hard to make those right decisions early on and you're putting effort into not creating Chatterbug when you're thinking about these problems.

Tom: Exactly right. Focus on your core value as a business, not on trying to wrangle your stack. You start to get bigger, you have a dedicated design team, you're like, "I want to integrate Storybook?" Guess what? Some engineer is now going to spend a week trying to get Storybook to work properly because it's a random collection of technologies you've strapped together. It's just wasted time, so we were like, "What if we do that for you? What if we build that?" And I hadn't built a web framework before so I wanted to try that out, and it's been illuminating.

Benjie: Right. The other thing is stack overflow and SEO can cause major problems for your project because something might be popular, but it's kind of outdated when it comes to how to do these things. Then someone that has worked with Marc personally, I can attest that he's always got to use the latest and greatest whatever, and there's not good, established practices so you got to figure it out yourself. So why are people doing this over and over again?

Okay. I have a little bit of a specific question, and this is just a little embarrassing that I don't actually know this, but I'm going to ask anyway. Can you explain to me the difference between Prisma and GraphQL? Or how does that relationship work? I'm just looking at the RedwoodJS site and I'm a little confused as to what the difference between Prisma and GraphQL. I mean, I kind of know, but I think this might be helpful for folks that are listening.

Tom: Sure. So Prisma is like a ORM, Object Relational Mapper. Although it doesn't really do much with the object side. Basically it's how you query your database from your backend. That's Prisma. So in the Ruby world that would be like Active Record is what takes care of that. That's taking the place of writing raw SQL queries. Prisma will construct the SQL queries for you from your nicer, JavaScripty kind of way of using the ORM.

That's Prisma. GraphQL is how you request data from the frontend to the backend, or request a change to occur and that's Facebook's thing. It's very robust technology. It's all typed. That's GraphQL. So that's how your client, your React client is shipped in a bundle to the browser, your browser executes that bundle, that JavaScript code, that frontend React code will request data from the backend via GraphQL. The backend now will use Prisma to get database from the database, format it or whatever it needs to do, and then send that back over GraphQL to the client.

Benjie: Okay. I don't know GraphQL well. I was under the impression that you use GraphQL and then you don't even have to touch your database, but maybe there's some automatic GraphQL, PostgreSQL tool that I'm thinking of.

Tom: There are a variety of ways that you can make an automatic GraphQL to your database, but it's very restrictive. You end up having, like, all right you can do basic, crud operations. But if you want to customize it or do custom business logic, which of course you're going to want to do if you're doing anything customer complex at all, then you're like, "Well, how do I do that?" So that's where Redwood solves that problem. There's a whole backend where you write your resolvers in GraphQL parlance to handle all of the backend logic.

Benjie: Okay, that makes sense. Yeah. I was just a little confused, I thought GraphQL replaces the database. But anyway.

Tom: No. I mean, it can in certain circumstances and many people have tried to make this work in a lot of databases and various companies will allow you to attempt to do that which is great for the first 10 minutes. But then you're like, "How do I do this thing?" You're like, "Oh well." You're on your own.

Marc: So Tom, most of your other stuff that you've created was in Ruby and Redwood's in JavaScript. Is it just the ubiquity of JavaScript that was driving that? Or was there a different reason that you decided, "I'm going to make this in JavaScript"?

Tom: Yeah. Mostly it was what we were using at Chatterbug. We were building things with React. At Chatterbug, the backend was Rails because we built it In Ruby On Rails, that's what we knew. Rails is great. Then we started building more and more of the frontend for that in React and so we weren't using Ruby's templating stuff as much. We were just delivering data structures to React from the Rails land, and then the React stuff would execute on the client.

Then we started, because we had a mobile client, so we built a whole GraphQL API for that in Ruby, so that was a Ruby backend that provided the GraphQL API on the frontend, then the JavaScript React code would consume that GraphQL API. Sorry, the mobile client would consume that. So now we had a GraphQL API and then we're like, "Well, why don't we just have our web application also consume that GraphQL API?"

And GraphQL works really well with React, the way that it thinks about the world, and so we were building that. We were assembling this whole technology stack, but we were using two different languages. It was like, "All right, we've got to write Ruby over here and we've got to write JavaScript or Typescript over here."

And so Redwood came out of that bifurcation, being like, "Well, why don't we just use JavaScript or Typescript for everything? Then we only need Typescript developers and they can do the whole thing and we don't have these two different languages, and Node is pretty great and there's lots of people that know JavaScript and Typescript. Way more people know that than know Ruby." So that was part of the core concept, it was like, "Can we do all this in a single language?"

Benjie: It seems like you're tackling some pretty cool problems after pretty cool problems. What else are you working on right now, professionally? Obviously you're not at GitHub anymore, you avoided working for Microsoft yet again.

Tom: Yeah, twice.

Benjie: You don't want to work for Microsoft, we get that, we know that. Which, by the way, I just have to say, call out, Microsoft has gotten... From when this all started, our internet world, to now, Microsoft is great. Especially in the CNCF stuff. So I'm not actually being negative about Microsoft, which is ironic.

Tom: Microsoft is great, I love them. Nadella completely changed that company, I'm a fan.

Benjie: Right? It's so weird that I don't have negative things to say about Microsoft. It's very jarring for me. But what else? Okay, so obviously you created GitHub, you've done so many cool things. What are you doing now? What is your day job? We're going to get to your side project at the end, but what is your day job today? What are you doing?

As I like to say, what are you doing with your rocket money? You had the big exit, and now you're doing some pretty cool stuff. I know there's some pretty interesting philanthropy that you're doing that I think we should talk about, but then there's other stuff that you're doing as well so just give us what's a day in the life of Tom? Maybe a week in the life of Tom these days.

Tom: Well, I guess there's three main categories of things that I'm doing right now. One of them is Redwood so I spend a lot of time with the Redwood team and we have a core team of about 20 people and several hundred contributors, so that project is it's own. It's not a company, but we behave as if it's a company and I do pay people to work on it.

We have a core team of people that are working on it full time, so I do spend a fair amount of time on Redwood because that's very interesting to me. I also spend a lot of time doing angel investing, though I'm trying to dial that back a little bit to spend more time doing actual projects.

So I angel invest, I do mostly seed round in developer tooling companies, getting a little bit more into AI kinds of companies. Then doing a lot of climate... trying to get more into climate tech investing, so that's through Preston-Werner Ventures is the name of that entity, so I do a lot of that.

Then we have a philanthropic organization, a foundation called 128 Collective. We have a staff of about 10 people and we do a lot of grant work and political work around climate change, so we're trying to tackle one of the largest problems of our day, an existential problem for the human race.

We're trying to move the needle with our resources. It's direct grant work to organizations that are working on climate change but increasingly more through politics as that's the largest lever, focused mostly in the United States although we do some international work as well. So I spend a fair amount of time with the team there working on that as well.

So those are the three main buckets, and you can go to PrestonWernerVentures.com or you can go to 128Collective.org if you want to read more about the two of those endeavors or you can go to RedwoodJS.com if you want to learn more about Redwood. So I'd say those are the three largest buckets of how I spend my time.

Benjie: Yeah. We're going to put the links in the show notes as well, so everyone check it out below. We're coming up on time here, but tell us a little bit about the climate tech that you're working on because I feel like that's got to be interesting. So I just want to know a little bit, tell me a little bit about the climate tech side.

Tom: Yeah. There's some really neat stuff going on out there. There's a company called Mote Hydrogen. Green hydrogen is going to be a part of our future more and more, and you want to be able to produce this hydrogen in a clean way, and you also want to sequester carbon dioxide. These are two things that you'd really like to do, and if you could do them together, that would be even better. Right? Let's sequester CO2 and let's create green hydrogen.

This company called Mote Hydrogen who we invested in has a process where they take wood scraps, let's say you've got a cleanup that you're doing in a forest or your routine maintenance along the sides of roads and you've got a bunch of scrubby, brushy wood materials that aren't going to be used for anything. They're just going to go in a giant pile and rot and put all that CO2 after they rot back into the air.

Mote can take this wood waste and burn it slowly, it's not exactly like that, but they have this proprietary process where it's kind of like burning it slowly. So it's self powered, you don't have to put any additional energy into it to run this process. You self power, it's called gasification. Basically you're turning this material into a gas and those gases turn out to be carbon dioxide and hydrogen, and you can separate them and collect them.

So you can collect the CO2 and pump it underground into giant reservoirs or old oil wells and it'll stay there. So you can push CO2 back underground, so that's one of the ways that you can do CO2 sequestration. Then they can take the hydrogen that they've produced in this green process and they can sell that. So there's a business model on the hydrogen side, there's the sequestration model on the CO2 side, so that's a really interesting technology to me. They're early stages, working on designing and building their first demonstration plant to do that, which will be an uphill battle and very complex.

But if they can figure it out and scale it, I think there's a huge potential there. Another quick one that I'll mention is called Renewell. This company solves the problem of all of these, not abandoned, but unused oil wells. You know you see those oil derricks that go back and forth all over Texas and various parts of California? Well, those eventually run out of oil and then the oil company has to eventually cap them, which they hate doing because it costs money and that involves pouring a bunch of concrete into them and it's an expensive process.

There's thousands of these around the United States, thousands and thousands, and they're leaking methane all the while. And so this company, Renewell, will sign a contract with the oil company and say, "Here's what we're going to do. We're going to convert your oil well." And these oil wells, generally it's a hole that's drilled in the Earth that could be thousands of feet deep, maybe 5,000, 6,000 feet deep.

And what they're going to do is assemble a series of metal tubes and connect them together and put them down into this well and then connect them to a cable, and that cable will be hooked to a motor/generator, and when there is excess electricity on the grid they're going to use that electricity and lift this giant metal cylinder weight into the air and when the grid needs more electricity, they're going to use the falling weight of this giant metal cylinder that could be thousands of feet long, that's a very heavy metal cylinder, to run the generator, and produce electricity and put it back on the grid.

And so this becomes an energy storage solution which we'll need more and more of as we transition to more renewable energy sources like solar and wind which are sporadic and need to be paired with energy storage, in order to not have to have coal and gas plants sitting around to provide the quickly needed variations in how much demand there is on the grid.

Benjie: Wow. That is super cool. I had not heard of that one at all. Yeah, a long time ago a really smart climate person that I was friends with told me that we can solve the battery problem if we dig a huge hole the size of Texas and we just put water underneath it and just raise it and lower it as energy is being used. This sounds like a little bit more practical version of that, but that's really cool and so is the other one.

We're going to put the show notes or a link to that and so people can check that out. I would like to ask you a million questions about more of the climate tech stuff you're doing, but I think we're out of time here. We did say that you always do a side project, I think that's super interesting. Do you want to tell us real quick what your side project is and then we'll wrap up?

Tom: Yes. So for the past couple of months I've been wanting to get into electronics more. I did a lot of electronics as a kid, but modern electronics is so much more awesome and interesting. I'd solder and make my own circuit boards and do things as a kid. I'd tinker, and it's been many years since I've gotten back into that so I wanted to make a project that would allow me to get back into electronics and really learn the modern stuff.

And so at GitHub one of our guys was named John Maddox, and he created this project called Magic Cards which was an RFID reader where he would print cards, RFID cards, the size of a credit card and you would be able to print album art, music album art, on this card and then you could scan it on this RFID reader and it would talk to this web app that he had built that would then correlate it to an album, that corresponded to the album art that was on the card.

Then it would play that music on his Sonos speakers or whatever he had, and I thought that was really cool. Make music physical again, bring it back into the physical realm. You could have an album that's full of these cards that have this artwork and you just scan it and it would talk to whatever his home automation system was and it would play the music.

I thought that was really cool, and so I wanted to do a modern take on that that didn't need an intermediary website to make the correlation, and use NFC cards. So now we have NFC, and NFC cards can hold data, you can write custom data to them where an RFID card is just an ID. You don't get to write anything to it, it's just kind of a number, and NFC cards you can write to.

So what I've created is a system that I called Wundercards, because I'm super creative that way. I've created a system, you write a music URL to an NFC card and then you scan it on this device that I have built using an ESP-8266 microcontroller and it then talks to... right now you have to have a Home Assistant set up in your home, a Home Assistant is an open source home automation kind of server tool. It's really neat, it integrates with zillions of things.

One of those things is Sonos, and so I have this device, you scan an NFC card, it reads the URL off of it, it talks to Home Assistant tells it to play that music on a Sonos speaker of your choosing. So I wrote the code that runs both sides of that, and then I created this nice wooden, walnut box that has a knob as well. This is the other thing that Maddox' thing didn't have, was it was you just scan and that was it. If you wanted to adjust the volume you've got to go find the volume knob for your system somewhere or you got to pull out your phone or whatever.

I wanted it so that you didn't have to use your phone at all. I have one of these in our main bathroom, for instance. I listen to music when I take a shower and while I'm getting ready in the morning, and I hate having to pull out my phone to select music and select a speaker because we've got like 30 Sonos speakers in our house. They're in every ceiling, they're everywhere. Zillions of them, it's amazing.

But it's super annoying to have to go on your phone and open Spotify and then find the music you want, and then play it and then make sure it's got the right speaker selected because maybe you were on a different speaker earlier. The whole thing just makes me not want to use the system at all, and it's like what music am I going to play? I'm going to have to think of an album or something to play.

It's too much, too much work. So with Wundercards now I have a little stand that has nine different NFC cards on it, each with an album and I have my Wundercards reader on the vanity and I grab one of those cards and I scan it on my reader and it has a volume knob as well so I can turn the volume up and down right there because the volume is never exactly where you want it.

Then when I'm done I hit the volume knob, click, the volume knob is also a push button, and that pauses the music. Then when I come in the next day and I want to listen to the same thing, I hit that button again and it starts playing that music. So with literally one second of work I can be listening to music in my bathroom again, and it makes a huge difference and it's been super fun to work on.

So I'm going to open source it all, I'm getting very close. I have now produced several of the production level version of this device, so I'm going to get that out really soon. Hopefully in the next couple of weeks I'll have something out. I think that's my goal, I'll open source, you could go build your own though I have bought probably $5,000 worth of CNC mills and laser cutters and soldering irons and breadboards to make this happen so I'm not sure if you'll want to build your own.

But the instructions will be there if you want to do so, and if there's enough interest and people want to buy these, maybe I'll figure out how to produce these and sell them.

Marc: That's really cool. It actually does sound like a cool device. Again, solving a problem that you have, an inconvenience here and make it a little bit better.

Benjie: Yeah. In five years when this is some multi billion dollar company, we'll all just laugh about how Tom was in front of this one again. Typical Tom. All right. Well, look, this was super fun, having you on. Really enjoyed this conversation and understanding about the origin story and what you're working on now, and just the way you think about things. I really appreciate hearing it and I feel confident that the audience is going to as well. But I think we're at time. Marc, I think we got to wrap up?

Marc: Yeah, I think so.

Benjie: All right. Well, Tom Preston-Werner, thank you so much for coming on. There's a whole lot of links that'll be in the show notes, and my personal note to Tom, besides all the cool GitHub, open source stuff is please save our planet. This winter has been very scary in New York. It's more like spring. So keep it up, climate tech, use that rocket money. Thanks for coming on, Tom.

Tom: You bet. Thanks for having me. I really appreciated chatting.