The Changelog: Software Development, Open Source - All things GitHub (Interview)

Episode Date: January 25, 2010

Chris Wanstrath joined the show to talk about the past, present, and future of GitHub.

Hello and welcome to The Change Log, Episode 0.1.0. It's our first point release. My name is Adam Stachowiak. And I am Winn Netherland. I'm really excited about the show today. We've got a great guest, Chris Wanstroth from GitHub. I think we're probably pretty big fans of GitHub, wouldn't you say, Winn? Yeah, pretty much 95% of what we're doing at the James Log.

Probably at least 70% of what I'm doing elsewhere. Right. We share stuff there. We connect with people there. And GitHub's been huge for open source and this past few years and what they've been doing has been awesome to see the growth

around software and the way that personal relationships and exchanges happen and the way that's evolved over the last two years of their development. Git and GitHub are both changing how open source is conducted and it's just really changing the landscape for sharing and doing what GitHub claims that they're wanting to do,

and that's social coding. It just brings an aspect to merging and forking projects that we just haven't seen before. There's lots of stuff Chris talks about, too, in the interview that kind of details on the social coding aspects of GitHub and the fork queue and how that proliferates software development in this open source landscape we're in. It's kind of wild. Yeah, it was interesting to hear some of the backstory of how GitHub got started and some

of the success they've had. It's just been quite the success story. I guess pre-interview, you were saying at least 30 years that they've been around, right? Yeah, right. Now they've been around, right? Yeah, right. Now they've been around, what, two years now? I guess if you're taking it internet years, though, it's 20 years. Right. And because I thought they were three years old, but I was mistaken.

They're actually two. And in Chris's eyes, it's actually one because he doesn't feel they really started until they start paying themselves. And so, I mean, that's kind of cool to hear him say that too because they treated it like a bootstrap company, which it was for the first year. And to them, it didn't truly become real until they started to see some paychecks from their day-to-day operations

and turning it into a real full-time, I'm dedicated this 100%, which they were, obviously, but it's kind of wild. Something else that's cool to see come from this is going to github.com forward slash explore. Welcome to all the new listeners that are coming from the Explore page on GitHub. That took us by surprise. Chris reached out to us a couple of weeks ago and said they were putting that in the works, and we were excited about having our ChangeLog podcast episodes up on github.com. But I think the cool features of that page are the trending repos and the featured repos.

Yeah, for sure. Certainly excited to see where this goes, but what I see so far is pretty exciting. Be sure to stick around to the end of the episode. We've got kind of a big announcement, some other things that we've got, some Skunk Works projects that we've been working on. So stick around to the end of the episode for a special treat. Don't fast forward. Don't even think about moving the dial.

Just listen to the whole thing and you'll catch it at the end. It's worth every minute. Sure is. You want to get to the episode there, Wim? Let's get to it. We're here with Chris Wanstroth. He is one of the co-founders of a very cool website we all know and love called github.com. Chris, why don't you go ahead and say hi to everybody. Hello, everybody.

So, Chris, we're here in this world we call open source. We all love it. We all know it. And it's a very, very tight group that's coming along. And I think that we all know that GitHub seems to be every day more and more becoming the epicenter of open source. How do you feel about that? I feel good. It makes me happy because I do a lot of open source work. And one of the reasons we built GitHub was to make it easier to send patches

and do all that sort of tedium. And I think it's coming along pretty well and a lot of people are realizing how easy it is making their open source maintenance. Like when you start having five or six or seven really small open source projects that you don't care about exclusively or all that much, but you still want to make sure they're up to date,

it can really become a time sink. You can start to have things pile up and that's what happened to me when I was consulting. And it's great that GitHub is coming along and it's still going in that direction. It's making open source easier for you as a maintainer or you as a contributor. And the fact that it's becoming so popular, not just something that actually works, but something that's popular is pretty incredible. And it's great because now that I'm working more and more and focusing on GitHub, it's really easy for me to kind of keep up to date on my hobby, which is one of my hobbies, which is programming,

because, you know, it's right there. It's easy to see, you know, what people are talking about or something cool that just popped up because it's on GitHub and I'm there anyway. So I'm pretty happy about it because it's a fun job and it's a site I think I'd really be into if I didn't work there. So let's rewind and talk about Git for a second. So why Git and GitHub and not SVN Depot or Planet Mercurial or something like that? Well, Git was the first distributed version control system that I really understood. I played with a couple before and didn't really even know that's what the, it was going on. I had used darks the summer before,

and I think I had used material to install the micro formats test suite. But with get I saw the Torvalds video where he kind of explained it in higher level terms. And it really appealed to me, the community aspect, the fragmentation of, you know, this person can fork your project and they can work on it without your permission and then they can actually produce something that has a lot of value and you didn't

get in their way. That was really appealing to me and it was also really appealing to Tom Preston Werner who started it with me and PJ Hyatt. And I think we had a lot of the same ideas and we were working with each other on a project. Well, he had a project and I sent him like two patches and it was all, it was all through Git and I was using Git for private projects. And it just seems sort of obvious that we were going to work on a site and use Git because we weren't trying to start a coding site. We were just trying to site or start a site to host Git repositories.

So it was kind of a no brainer. It was like, we have these Git repositories now. We really love the philosophy behind Git. Where do we put them? And therebrainer. It was like, we have these Git repositories now, we really love the philosophy behind Git, where do we put them? And there was repo.org.cz, which is still around, but that's sort of a single serving. You just put a project up, and you can sort of publish it there. We wanted a place where we

could sort of get involved in this distributed community of forking and all that sort of thing. So that's where GitHub kind of came from. Have you talked to Linus at all about Git Git and how GitHub may be fueling the popularity of Git itself? I haven't talked to him. Maybe someone in GitHub might have. I'm not super involved with the Git community. We have people that do that for us. Scott Chacon, who works for us, is a Git expert. He's involved in the community. He writes books on the mailing list,

submits patches. So he's more the guy that's involved with Git itself. Ryan Tomeko and Tom Preston-Warner are also pretty involved in Git itself, but I am just a happy user, really. It's kind of hard to go very far looking into Git and not see Scott Chacon's name anywhere. He's pretty prevalent in the community. Yeah, we were very lucky to get him early on. Serendipitous, really. The fates aligned. And he became a member of GitHub way earlier than we thought we would ever be hiring anyone outside of the founders. And then that's when we started doing our training business, where we'll do Git training for big companies where the CTO or someone is excited about Git and wants to start moving towards it will come in and do a couple of classes. And so we brought Scott on board and he said, you know, I have a class coming up. Can we make this a GitHub thing instead of a Scott Chacon thing? And we said, sure. Who is it? And he said, Google. We're like, okay, that works for us. They can be our first trainees. Yeah. So let's talk about the startup process, I guess, of GitHub and how that all came about. So who was your first hire and what was that like? I guess

the bootstrapping first parts of the real company formation and where that started at. Well, our first hire technically was Scott. But before that, PJ Hyatt, Tom Preston-Wern and myself had kind of started the company in our spare time and ran it for a couple months. We actually started developing it in October of 07, and we released the beta in January of 08. All the beta meant was that we had a place to host the site and you could sign up if you had an invite. That was where we drew the line.

And then we launched it officially in April of 08. And all the official launch meant is that we could take your credit card number and charge you. So in the early days, we started making money right away in April. But we also had jobs or we were living off our savings. And it was kind of a side project thing. So even then, it was a little bit difficult because you're working 40 hours or what a week somewhere else. And you have this website that's making money and gaining traction. Um, so believe it or not, that's actually pretty stressful because it seems like things are going well, but they're not really going the direction you want because you just want to be working on GitHub all the time. And from there, it just kind of grew. The site grew. Uh, we started making more

and more money. We added stuff to be more friendly to businesses. And, um, towards the end of grew, the site grew, we started making more and more money, we added stuff to be more friendly to businesses. And towards the end of 2008, we had the opportunity to hire Scott, and we brought him on board. And around that time, we started making projections, you know, how much are we gonna be making in January, how much are we making in March, given our current rate of growth. And we decided around, I guess, October, sometime late 2008, that we were going to start taking salaries. We would start paying ourselves, but we were going to do it a little bit at a time. So we'd all start out at 10% of our goal salary. And then every month, based on the projections, if we'd hit them, we would bump it up to 20%. If we missed them,

we would maybe take a month off or make it 15%. And so for the next couple months, we were all sort of watching the money pretty carefully, trying to do things to make sure we didn't regress in the growth and giving ourselves raises one step at a time until finally we all were making the salaries that we wanted to make. So that for me is really where the business started. It started at the beginning of 2009 when we all started making full salaries. And that's when it really became a grown up business. We had health insurance and all those sort of those benefits because, you know, that's that's a lot different than than 2007 working on a little rails app in your apartment. Right. So we're basically like a year old then at the point when we were all making money. Well, yeah. So based on what you just said,

you said, you know, early 2009. So around, let's say just January and now we're in January, 2010. So we're about a year old in your eyes. It was less than a year after we launched and we all started paying ourselves what we wanted to be paid. So that was a, that was, that was fun. That was a fun year because, um, you know, during that year though, I want to stretch, we were all sort of living off our salaries or working other jobs. So it wasn't really that great of a year, 2008, even though things were on the up and up. 2009 was a much better year. But I think that's one of the hard parts of starting a business or bootstrapping a business is it's really easy to give up. I mean, at any point, we could have

just decided, oh, you know, I'm going to take a month off and just do full-time consulting work and put GitHub on the back burner. Or a couple of us had really lucrative job offers that we could have taken and just said, you know, this GitHub thing isn't taking off as fast as I'd hoped it would. So I think a lot of it has to do with, for us, it's just persistence. I mean, at any time we could have given up and stopped, especially during that year of living off of no money or other money. But yeah, when you're boot of living off of no money or other money. But yeah, when you're bootstrapping yourself, that's a big challenge.

When did you first start seeing higher profile open source projects move their repos over to GitHub? Well, Ruby on Rails moved on launch day in April of 08. So that was the first really big one for us. But we've been kind of blessed by having major open source projects the whole way. Beta started because the Yehuda and some of the Merb team wanted to start rewriting Merb 0.5, getting it ready for Merb 1.0. So they started the Merb 0.9 branch on GitHub the night we launched the beta. So right away, we already

had a pretty awesome project doing substantial development on GitHub. And since then, it's just been kind of hard to keep track. You know, there was Rails and then all the JavaScript frameworks, jQuery, Prototype, Scriptaculous, YUI. And then from there, we're starting to see CakePHP, Symfony. There's a couple forks of ASPs, MVC.NET framework. It's kind of hard to keep track of, too, especially when you have projects that aren't the Linux kernel but are still really important to you or something you used from your past coming over. It's neat to see.

We recently had the TinyMCE rich text kind of WYSIWYG editor for HTML, which I used back in the day, and now it's on GitHub, so it's kind of come full circle there. So it's just kind of incredible the amount of projects that are moving over, both in terms of projects that have lots of downloads and visibility. We have Erlang's OTP is on our site and Clojure. And then other projects, just, you know, there's lots of really cool small stuff that doesn't really get the name recognition and isn't blogged about,

but is pretty solid code that's there. And all it has is the GitHub presence, and sometimes that's enough. Do you guys actively evangelize or recruit those projects to come over, or do they just follow the momentum? It depends on your definition of actively evangelize or recruit. How do you call up and say,

hey, Resig, you need to move jQuery over to GitHub? We hassled Resig a couple times, but that was only after we had a couple drinks with him and we became friends. In the early days, we, we, we hassled Russ a couple of times, but that was only after we, we had a couple of drinks with him and we, we became friends. In the early days, we emailed a couple of projects. We said, Hey,

check this out. This would be great for you. And they were said, they said, you know, Oh no, not now. And no one we emailed moved to GitHub.

But a funny thing happened is about 99% of 99% of the projects we emailed in the early days eventually came over to GitHub. And so we decided that there's just no point in us evangelizing the site. What's better for us is to evangelize Git, work on Git literature and books and screencasts and that sort of thing, which we wanted to do the whole time anyway. And we found that the best way to get people to use our site is to make the site really awesome. So we focus on making the site really awesome. And so far, that has been the thing that brings over the big ticket items. Well, not to mention also focusing on the user happiness. I guess that does fall into making the site more awesome is user happiness.

And if you have an army of loyalists, as a good friend of mine, Jonathan Kay, says, if you have an army of loyalists that constantly evangelize for you, they do your job. You don't have to. That is true. We get a lot of that. That's the thing, is if you're going to try and have someone switch something as personal as version control from what they're used to, what they like, what's not getting in their way, to something new and maybe a little bit harder to learn and totally radical, it's not going to be some Rails programmer on Twitter. It's going to be one of their friends or someone that they trust. So there's really

almost no point in us evangelizing at this point. It's much easier for us to, like I said, make the site really good, make people really excited about the site, including ourselves, and then get those people to tell their friends about it or tell their boss or tell their coworker or say, you know, I think that's absolutely right. You know, there cover the open source side of GitHub on this podcast, but I know Adam and I both do client work. And that's one of the stipulations I have to take on a project is your source control has to be in GitHub because I'm not going to go back to the subversion world. Yeah, I won't even work with you if you're not using Git.

Like, just get out of here. No pun intended. It does seem, this is where a lot of the the claims of arrogance come from because you say that you say i don't want to work with you if you're not using git and to a subversion user or to another version control user they see that as arrogance but a git user just sees that as no of course why would i want to use subversion that's insane it's just it's just a matter of fact it's just there's so many things that you that you want to do with git that you can do that you just can't do with Subversion.

Oh, yeah. Your workflow completely changes, like, night and day. Yeah, and I think it's a very nice tool. People complain about Git's user interface and say it's confusing. I think maybe some of the commands are confusing, but things like just automatically paging the Git log output and colorizing diffs off the bat, I think that's what makes a nice user interface. It thinks about the person using the tool. And that always impressed me. Typing SVN log and getting every revision and just seeing like R1 in my terminal, that

doesn't seem like a good user interface to me. And then merging is light years ahead in Git compared to anything else I've used. I mean, it's just, it's amazing how well it handles merging two files. Yeah, it's just really good at handling situations where you don't really know what you're up against. And there might be multiple remotes, multiple contributors. You have different patches written against different masters. And it's really good at trying to resolve the changes

or telling you exactly what went wrong and letting you fix them yourself. Yeah, that's a good segue into probably one of my favorite GitHub features, and that's the 4Q. You talk about how that came about and just how that developed. That's a good segue into probably one of my favorite GitHub features, and that's the 4Q. Can you talk about how that came about and just how that developed? The 4Q, there's a big list of things that we've wanted to have since day one.

Me and Tom and PJ are pretty good friends, so we'd hang out outside of work, outside of hobby time, and we would eat dinner and drink, and we'd talk about what do we want for GitHub in the future. And two of the biggest things early on were GIST and the ForQ. The idea behind the ForQ, for anyone that's not familiar, is you can go to a page on a repository that you own or you have right access to. And you can see a list of all the commits in your network that are unique. So if I forked your project and I made a commit, but I didn't even tell you about it and I push it to GitHub, you would see that commit in your fork queue. And you could then examine the commit. You can see what I did. You could leave a comment on it, or you could check a box and you could have that commit, if it applies cleanly,

apply directly to your master or some other branch on your repository. So in this way, you can kind of, you know, merge changes from your iPhone if you want, or you can sort of review changes that people are just experimenting with or kind of help them out if you see them making things that you don't think is right or if they're not using the right methods, even before they come ask you for help. So you can really be proactive about being a contributor if you want to take that control. And like I said, the best part of it, though, is being able to merge in changes that apply cleanly right from the web interface.

It could be documentation fixes, little changes. If you even have your project hooked up to a service like RunCodeRun, which will run your test suite on commit, you can apply changes from the site on the fork queue and then see if they pass or not on the continuous integration server, which is pretty cool too. That is very awesome. So the apply cleanly and will not apply cleanly,

is that built into Git, or did you guys have to build some features around that? We had to build a lot of features around the fork queue. The fork queue is entirely a production of Scott Chacon. When we brought him on board, some of our first hiring talks with him were us discussing how would you implement this idea we have these random not random but these connected repositories that are disparate on the site and they have unique

commits we want to apply them to each other we want to see if they work maybe they don't work how would you do that and that was kind of his interview i guess without him knowing it and he explained it to us and we had no idea what he just said. So we decided to hire him and let him implement it. And yeah, a lot of the stuff is pretty interesting. The biggest problem with the 4Q is that it uses a cherry pick, which basically takes the diff of a commit and applies it on top of your current head. So that way the SHA changes, the heritage changes and all that sort of thing, including the commit time. But what that means is that the other really cool sort of community feature of GitHub, the network graph, doesn't work right now with the 4Q.

Because the network graph works all based on merges, yet the 4Q works based on trade picks. So we're kind of still, yeah, there's lots of stuff we have to do right into our site, kind of piece bits of Git together to get the functionality we want. But it's actually not that hard when you have someone like Scott who understands how Git works. It's all just a matter of time and implementation. Talk a bit about the open source projects that you guys have had to release along the way just to power GitHub, if you would, for a moment.

Oh, sure. We've been releasing open source projects on behalf of GitHub the whole time, since the beginning, probably before the? Oh, sure. We've been releasing open source projects on behalf of GitHub the whole time, since the beginning, probably before the first day, really. Because we are all open source developers and it's just kind of what you do. The first one we released probably was Grit,

which is our Ruby bindings to Git. And originally it would just do a fork and exec and just return a string from a command. So if you wanted to see a git commit log message, you would just run git commit and scrape out the message. And it worked. And in the early days, it was enough. But then once the site started getting more popular, that turned out to be a really slow approach. And so what Scott did was re-implement lots of git itself in Ruby for us within the Grit library. And that's all open source, and

you can check that out. So that's kind of our first big library, because it enabled us to build GitHub. It enabled us to kind of do these major changes to Grit, like, for instance, rewriting it from Fork Exec to actually using FileRead and that sort of thing, without having to change the web app or our jobs or any of those sort of things. So that's been a real lifesaver. I mean, it would have been easy just to throw the Git calls in there originally, but that would have definitely been a pain in the long run. So Grit was a good decision early on. We've released tons of little, you know, jQuery plugins.

Some of them are released at github.com slash GitHub. The other ones we kind of just release on our own. The other, The next big project that we released was GitHub Services. This is actually a part of GitHub itself. When you make a push, there's a post-receive hook that Git runs. And so because we don't want people running code on our server that's

untrusted, what we do is we will either make a webhook to a URL of your choice with a JSON payload representing the push, or if you have your own service that is able to consume a GitHub webhook, you can write your own service. And what that is, it's a little Sinatra app plugin thingy. And then what we'll do is we'll list it on the site

and people can enable it. So for instance, if you have Campfire and you want to get your push notifications in your Campfire chat room, you can turn on the Campfire service and type in your username and token and all that stuff, and it'll work. And so the actual GitHub services, like Campfire, IRC, all those things, are all open source. So in many cases, we've had people like Amy Hoy and Thomas Fuchs's Freckle, where they contributed their own service hook for their service, and we were able to roll it out

into the site. And that's really awesome for us us because a lot of times we'll have people saying, you should really support Freckle, you should really support Pivotal Tracker, and we don't use the tool. I mean, if you don't use the tool, it's not going to be as good as it would be if the maintainer was someone who actively used it. So we don't use Pivotal Tracker, for instance, even though it's a good project. So the Pivotal Tracker hook would never really be that great. We wouldn't really know when it broke. It just wouldn't be a good kind of display of GitHub. And I think what's more GitHub-ish and a better display is making it open source so people can either fix it themselves or if they don't even know Ruby, we can kind of say, here's the code, here's what it's doing, did the API

change and work with them. And everyone kind of has the same thing in their site, which is the code. So that project is really an exciting one. And then some of the other big ones we have are Jekyll, which is Tom Preston Werner's static site generator. And that's actually integrated into GitHub. So we have this, one of these other things we always wanted to do was static site hosting, which we call Pages. And so you can put your index.html, whatever you want, into a Git repository, either standalone or on a special magic branch called ghpages. And what we'll do is we'll publish the HTML and all the assets and everything as a static site.

So it'll be fast. It'll be whatever exactly what you want it to be. But if you want to use it for publishing a blog, we actually run it through Jekyll. So you can go to pages.github.com and get the scoop there. If you follow a few conventions, give us a special layout, that sort of thing. We'll turn your dot markdown or dot textile posts into HTML just the way you would want to publish it either as a static site publisher on your own or through WordPress or something like that. So we have a ton of blogs from hackers hosted at GitHub, which is pretty cool.

And Jekyll is one of the biggest projects on GitHub. People fork it, they add features, they, you know, fix bugs. And that's because they know it's being run when they push and it's running their blogs on GitHub. And, you know, they can add stuff they want, which is pretty awesome if you think about it from a hacker perspective, because, you know, a lot of the problems I have with sites like WordPress and whatever is I can't modify them or I can modify them after paying them money. So at that point, I'd much rather just go build this huge 10,000-line system on my own than pay them $5 a month to modify the CSS. And so having Jekyll open source is pretty cool.

I use Jekyll for my blogs, too, reluctantly. I have my own static site thing for a while, but I finally switched to Jekyll because it's easier. So we have to do a lot for user evangelists though, right? Like if everybody is using something that's already on GitHub like Jekyll, it's already open source and they're always putting the fork me badge up in the top right and they're always putting

attributes back to the Jekyll repo, it's always going to drive more and more traffic back to GitHub. Yeah, that's true, but we don't really think of it that way, though, because you can try and do user evangelism actively. You can have the 4Q badges,

and you can have sort of like an open source Jekyll. But people aren't going to care if it's all crap. So I think the more important thing is making something really, really good, and then in the spare time, trying to put together a little bit of user evangelism stuff to let them do what they want with it. So the Fork You badges didn't take more than an afternoon for Tom, or Fork Me on GitHub badges.

But the thing that took all the time was making Pages really, really good. One of the cool things about Pages that people don't realize is we had a period of time last year, we had lots of downtime. And our site was always crashing, and it was because of some of our data storage problems. But throughout that time, Pages was always still up because it was a different machine. It was Nginx. It was all cached. It was all static. So GitHub itself would be down and flailing, but your blog would just be running fine and no one would notice. And even on the current setup, that's how it is now. We have things sharded in such a way that if the web app falls over, your Pages will be fine and they'll probably still generate too. That might be a nice segue into those trials and tribulations of switching hosts.

Is there a possibility you could talk about the transition and the relationship ending with Engine Yard and what that took you into with Rackspace and why that came about? Yeah, sure. We posted about all of it on our blog. There's so many reasons going into it. We used Engine Yard since almost the very beginning. We've got lots of great relationships with those people over there, especially people like Yehuda and Ezra and Atmos. There's a lot of really smart, really awesome people over at Engine Yard.

And they are able to recognize, I guess, up-and-coming projects in the Ruby world really well. When GitHub was still just a baby, really, they saw it, they latched onto it, and they really wanted to help make it something great. They are really behind the idea of Git. They're really into the future of open source. And I think they're really invested in open source in Ruby, making sure that Ruby continues to be an open source-driven community,

even though they're a for-profit company. So we were a part of that for a long time. We had a good relationship with them. Randall Thomas over there took great care of us and is a pretty cool guy. And then eventually it came to a point where we decided on our own that we didn't want to run on virtualized hardware anymore, really. And, you know, Engine Yard can host us on our own machines without virtualization, but that's not really their business. It's like, yes, you can do a subversion import to GitHub,

but we're not going to keep two-way, you know, just go to a subversion host pretty much is what it boils down to. So for us, we wanted to find a host that was designed to deal with the setup that we wanted to move to. So for us, we wanted to find a host that, you know, was designed to deal with the setup that we wanted to move to. And, you know, it's not Engine Yard. We wrote them an email. We talked to them. They said, yeah, we understand that works for both of us really well. We talked about a migration strategy. They helped us by dumping all of the repos onto databases, which

we then flew to Virginia for our import, kind of a sneaker net operation. And yeah, so then at Rackspace, things are really great. We have too many machines right now, which is good. We have way too much power, and we've got a pretty good relationship with those people. And we have Anchor, which is a company down in Australia doing our support for us. So Rackspace handles the hardware, and Anchor, which is a company down in Australia doing our support for us. So Rackspace handles the hardware and Anchor handles the software. So it's really great to have someone who is really, really invested and interested in software systems administration.

So now we're all set up with Puppet and all of that sort of thing. And the guys at Anchor, they have checklists and all these sort of procedures in place. It's very professional. People are on call 24-7, and they're always there to help us out in case there's a problem. So it's really great because Engine Yard provided a lot of that, too. We had sort of an Engine Yard chat room or a private GitHub Engine Yard chat room. And if there's a problem at any hour of the day, you can go in there and you can say, hey, something's busted. And that's kind of the appeal of Engine Yard is they always have people around that are familiar with the setup because all the setups are very similar,

and that's what you pay for. And so we didn't really want to lose that because that's really one of the most awesome things about Engine Yard. And Anchors really helped that, and they've really stepped it up. And they have some really great people down there. Matt Palmer, Womble, has totally led with Tom the re-architecting of the site, and it's just been fabulous since then. So I think the Engine Yard and Rackspace move just boils down to like finding the right tool for the job. You know, Engine Yard knows that, I mean, they don't even try and advertise

that they, that they do what we want. And so it just didn't seem like a good fit. Whereas Rackspace, that's their whole business right there, or at least most of it. Now they're trying to do the, or they're moving into the cloud space, which Engine Yard is too. So that's interesting because I guess now they're more competitors than they used to be. But for us, it's mainly about the dedicated hardware and the control over exactly what hardware we have and when we get it and that sort of thing. Let's talk about the very extremely short tagline

that GitHub has, which is just social coding. Can you talk about that and where that came from? Sure. I think we had a couple of taglines. I think this one best reflects everything, the whole universe. The first couple of taglines were just something like, Git code hosting, and then I think that was it, Git repository hosting, something like that.

Because that's really what it was at the time, and that's what we wanted it to be. That's what we were advertising. It says, hey, if you use Git, come to GitHub, because we can host your stuff. And that was sort of the origin at the time. And that's what we wanted it to be. That's what we were advertising. It says, hey, if you use Git, come to GitHub because we can host your stuff. And that was sort of the origin of the site. And then after that, when we started realizing what was going on and the sort of how this collaboration stuff was actually working much better than we had hoped or thought it would, we turned it into social code hosting, I think, because, you know, we were starting to get compared to Facebook and MySpace and all this sort of

jibber-jabber with the Web 2.0 social sphere. So we added social code hosting. And finally, Tom and PJ decided that they didn't like that tagline because it gave the logo sort of a tail, and they needed to come up with something shorter. And in a moment of inspiration, they came up with social coding, which kind of perfectly explains what GitHub is about. Because it's not even really about the hosting anymore, because that's kind of, you know, you can get hosting anywhere, probably for free. It's more about the socialness and just actually coding, not any sort of really like politics or organizational

stuff or hierarchies and all that sort of procedure that you find in other organizations that do open source stuff. It's about coding, really. Just throwing code up there and working on someone else's code and that sort of thing. We wanted it really to be about code and people more than projects and organizations. So two big aspects of that social coding philosophy

is following users and watching repos. Were those just no-brainer features out of the box, or how did those come about? Yeah, I think those were just – yeah, we never – it's funny. I don't know. I don't have an answer for that. We just added them because it seemed like what would be the point of the site if you didn't have those things. I mean, originally the dashboard wasn't really like a – I don't know what you would call it, a Facebook-style feed. Or really like a Twitter feed with different event types. It wasn't like that originally.

It was just, you know, here's some repositories that you're watching that have had updates recently. And, you know, here's information about the repository. And it was very, you know, to the point. And then we made it a little bit more kind of like stream of consciousness, fire hose. And that's when we realized a lot of these social aspects really coming into play, because now we had this place where we could show you stuff that's going on. A lot of stuff really quickly, a lot of different types of stuff. And I think watching and following kind of necessitated that because, you know, oh, well, you know, I want to see what Tom is following. I want to see what he's watching.

And the dashboard really lets you do that in some instances. And, yeah, that's really where it came from. But watching and following, those have just always been in there. And we've always had the distinguishment. We've always distinguished between the terms because otherwise we thought it would get confusing. If you watch people and repositories. Sure. So what do you think the fork term means on GitHub

to be popularly forked as the Explore GitHub tab shows? Is there a certain point where being forked too much may be exposing some flaws in your particular project, or how do you see that? Well, I think it depends um a lot of right now forks are all weighted across github fairly equally so if i fork a project and i make no commits to it nothing i don't add anything unique that's pretty much seen as the same as someone who has a fork where he rewrites functionality for the better and submits it back and gets it included in the

main line and so i think one of the things we want to do in the coming year and the future with GitHub is sort of focus on forking in a way, make forks that have unique content, make forks that are good, more prominent, and make forks that are, you know, have no unique content, less prominent, especially old ones. Just, you know, get them out of the user interface and get them out of the network graph, get them out of everywhere. I mean, the network graph and the fork queue already do a good job of that. You don't see forks that don't have anything unique in them. But in other places like the popular fork and in the little network count in the repository information or the network tab itself with the count there, you still see how many forks

there are. So I think that's one of the things I would like to change. I want forking to be about contributing more than just clicking the button, which it is now. But obviously, counting how many people click the button is an easier technical problem than counting who actually has a valuable fork. But now that we have resources and people, that's one of the things we want to focus on. How active is a project based on commits, not just people forking it, that sort of thing. And so I think for things like Homebrew, you're going to see that this is a project that has a ton of super active forks because people are contributing formula

and that sort of thing. But for a project like Rails, maybe you won't see as many forks as there are now because it's so popular that there just have to be a bunch of forks people made intending to make a patch that never panned out. There's still going to be a ton of forks, but I think the more popular a project is like Rails,

the less forks are going to have something substantial in it. I mean, I even fork projects intending sometimes to contribute to them and nothing ever happens and I end up deleting them later or I think, why did I ever fork that? And that happens and the system just has to be set up to deal with that. But I think we can do that.

You know, that's one of the things we discussed on the last show is oftentimes now with moving to Git, the lead project for a particular fork is basically the one with the most momentum. And that's kind of a challenge when you find a project on GitHub is sometimes you may stumble upon a project and it's a fork of a fork of a fork. And so just following the fork tree back to the original and then trying to look at the 52-week participation just to see where's the momentum for this particular project is often a challenge. Yeah, I usually take the network graph for that stuff

because even on the fork of the fork, you'll be able to see if the upstream route has forward momentum. But yeah, that's something you shouldn't have to do. That's something that should just be obvious. And I think we want to make the networks a little bit more cohesive in the future too and say when you hit that fork of a fork of a fork, say, hey, you're in the defunct slash rescue network. Adamstack slash rescue is the blessed fork right now.

Even though it might have been my repo at one point and I publicized it and I was the contributor or the main maintainer, Now it's passed on to Adam stack and that's where all the momentum is. And GitHub is able to detect that because it's really not that complicated. We just need to, to detect it and show it. And I think that would be really awesome for people is to say like, Hey, you're here, but this doesn't matter as much as this one, which you might be looking for. Or, you know, if you land on, uh on the fork of a fork and it tells you that, you can compare what's the difference between this fork and the upstream and kind of get an idea for what's going on that way too,

which I think would also be cool. We're talking about the social aspects of GitHub.com and what's going on there. How has the explosion of social media and this constant real-time connection between developers, for example, when we had Nathan Weisenbaum and Chris Epstein, the core contributors to Hamill, Sass, and Compass, when we had them on the podcast, it was actually the very first podcast from Changelog. When we had them on, they said one of the biggest things that helped their project was the activity on Twitter. How has that impacted GitHub?

Well, for GitHub itself, since the very first days we were using Summizer at the time, just to see what people were saying about GitHub, whether it was good or bad. Because it's so much easier to tweet, what the heck's up with GitHub's login screen? It's broken. Than it is to find out where the support email address is,

email it, or make an account on the support help desk and all that sort of thing. So we got lots of good feedback from Twitter in that way. We're able to see projects that are being publicized really easily because people will tweet about it. It'll have github.com in the URL, and we can see that get passed around. We're able to see tutorials or blog posts that pop up talking about GitHub just because it's in the name of the title or something like that, and it pops up on Twitter under the search.

And even when we do a deploy or we make a new blog post, a lot of times we'll have a blog post that'll get two comments, but it'll be tweeted about 30 times. And so it's a lot more useful for us now just to look at what people are saying on Twitter than it is to depend on them to make a comment on site because that's where it's happening anyway,

whether we're looking or not. So it's really up to you, I think, if you're trying to do a bootstrap business or you have an open source project to be proactive about finding that stuff because with the Hamill guys and SaaS, people are talking about that stuff whether they're watching or not. So they can either use it to their advantage and help shape the project or help improve things. Like, I don't know, someone says Hamill's documentation sucks because they couldn't find X. Now that's an opportunity for them to fix that there. Whereas before, they would just be thinking, no one ever complains about Hamill's documentation, so it must be good enough. We do that same thing constantly. Every day, people are checking Twitter. I'm sure people have

different schedules. I check it normally towards the evening. I just read what's going on and get a feel for what was happening that day, either with the site itself and with the ecosystem around the site. Is that something that everybody does, or is that just something you do? I'm sure everyone does it a lot. Yeah, I mean, we all use Twitter a lot, so it's really interesting to see what other people are saying about it and that sort of thing.

So, yeah, I mean, if anyone mentions GitHub on Twitter, there's a good chance someone at GitHub is going to read that. I mean, we don't all read all of them because it's gotten to the point where, I mean, Twitter is so big and GitHub is getting big, and there's just a lot of tweets, especially in other languages. But, yeah, I mean, especially in the early days, we did lots of support and stuff that way. We still do.

We'll help people complain on Twitter that something is broken, and then we'll use a GitHub account on Twitter to at-reply to them and try and figure out what's wrong or try and get more information and help people that way. We had a couple times, a couple really bad incidents. Last year, our DNS provider went down, and so GitHub.com was just erased from the face of the universe. And one of the things we did was we posted a workaround,

a temporary workaround to edit your Etsy hosts. And there was an OSX script and I think probably a Linux one. And people were complaining on Twitter about GitHub being down, and we were able to write a little script. So if anyone had a complaint with DNS, GitHub, whatever, we could send them a link as an out reply on Twitter to the fix. And so that was pretty awesome. So we ended up sending out, I don't know, an annoying amount of tweets, 300, 400 tweets in an afternoon, all with the same content. You're like, check this link to fix it. But it actually worked. And for a lot of people, it helped them get around the DNS outage and get some stuff done.

So for things like that, I mean, I guess you could say social media, but for us, it's mainly just Twitter is pretty crazy. I mean, we check, I find Twitter more reliable for finding blog posts about GitHub and that sort of thing than I do like Google blog search or anything like that, Technorati. Twitter is definitely where it's all out. And same thing for projects. I mean, if you have a project, pick a unique enough name where you can either search for the name on its own or your username slash the project name and see what people are saying about it. But that, I think a lot of times, when you have a smaller project, it is more just ego surfing than it is anything else. I mean, when you have a small project on GitHub,

and it's just you and maybe a couple watchers or even a couple hundred watchers, a lot of those people are going to know what to do. They're going to know to go to your issue tracker. They're going to know to go to your readme to look for the issue tracker. They're going to know to look for your mailing list. And're going to know to go to your readme to look for the issue tracker. They're going to know to look for your mailing list. And when they have a complaint with your project, something won't work, they're going to go to the mailing list and try and make it work. Or Google a blog post and try and make it work.

I don't think you see a lot of Twitter complaints for that kind of stuff. But when you have a product or a website or a company, I think it's a lot easier. Just for someone to say, you know, because you're just saying if something's broken, you're saying screw GitHub. Whereas if you're using one of Adam's projects and it's broken, you're saying screw Adam. So I think it's a lot easier for people to kind of critique a website or product on Twitter than it is for them to do that same thing with an open source project that has like a single main owner. You know, GitHub's also giving you another response to that type of

trolling. You know, the amount of complaints about free open source software just never ceases to amaze me. But, you know, you have the ability to say, fork it and send me a pull request. You know, it's just that easy. Right. And it really is. I mean, because we do that to each other, too, even in our company, someone will complain and someone will say, well, you know, you can always send a pull request. And that usually ends the conversation pretty quickly. But yeah, where do you take it from there? If you can fix their problem and you're complaining about it, just do your job. Yeah, exactly.

I've always contributed to open source, but a lot of times, sometimes I'll just add features or fix a bug that I wouldn't have added otherwise just because I have my GitHub workflow down pat and it's really easy for me to fork it and contribute a patch. And that's kind of the goal is to get that way with as many people as we can. Let's talk about that for a moment. So we talked about watchers and the projects that you followed on GitHub.

Adam and I often talk about the best way to find the folks and their projects to follow in open source, and usually that means GitHub. What's the best way to gauge someone's participation, even if they may not be an active organizer of a particular project? How can you gauge someone's participation with patches and commits across GitHub? I think one of the things that I like about GitHub is that it doesn't try to be everything. It's not trying to be the entire world of open source. I think, like I was saying with Twitter, a lot of GitHub users, probably most of them, have Twitter accounts. And so we don't want to have you leave Twitter to tweet about open source in 140 characters or less on GitHub exclusively for GitHub users.

We don't want to add a Twitter component to GitHub that's just for you talking about whatever. Maybe we'll do updates for repositories so you can say there's a new release, but not in the way that Twitter just lets you communicate openly, because Twitter already exists. And I think what GitHub should do is work really well

with Twitter. And I think what it should also do, in sort of a way of finding what's the canonical Capistrano repository right now, is it should work with Google. And I think what it should also do, in sort of a way of finding what's the canonical Capistrano repository right now, is it should work with Google. We should have ways to promote the most active fork in Google to be the first search result from within GitHub. And so what I really want GitHub to do is sort of play into this ecosystem of what people are already doing. People are already contributing, people are already making patches, people are already doing this stuff. You know, how can we either have them do it on GitHub

to make it easier, or how can we kind of hook into it, like with the service hooks and that sort of thing? So for finding out someone's, you know, worth, I guess, in open source, or not their worth, but just how their weight, how active they are, I think GitHub's one part of it. And we want to do, we want to put more stuff on the profile to say, you know, you go to Defunct and you see he

does Ruby, Python, and JavaScript primarily, because we detected that from my projects. And he's contributed to these projects. And so I could have jQuery slash jQuery on my profile, even though I don't own it, because I submitted a patch and they accepted it. And I think that'd be really awesome, because if you want to be like a Rails contributor or something like that, we could show this guy, he doesn't have commit access. He doesn't own the project, but he's contributed 14 patches that have been accepted to, to Rails or something like that, which I think, I mean, that's what it's all about is, is just doing code. It's not about, you know, collecting, uh, badges or karma or getting upvotes or downvotes. It's about getting your patch

accepted or rejected. And we really want to base your merit in GitHub on that sort of thing. So I think the ways to do it right now is just to kind of check what they've been doing on Google, check what they've been doing on Twitter, and then check what they've been doing on GitHub. What have they been forking? Who are they following? What are those people into? And sort of dig around that way. And ideally, I think we'd like the profile to show you a lot

more of that information right there. Just this person has done these things and they're awesome or they're not. Any plans to link a Twitter account in your public profile on GitHub? I don't know. It's never come up. Maybe. Sure. I mean, we've talked a lot about the updates for repositories because it'd be useful to say, you know, check out this version of this. I mean, you might see a tag, but is that really good enough? Maybe it is, maybe it isn't, but that's kind of on the drawing board for now. But for users, I don't know, that's a good question. You know, it's funny because when the site started on your profile, we had a little, in the very, very early days, there was a spot for you to put like your name, your company,

and instead of your URL or a homepage, it just said blog. And now I think it says blog slash homepage. And we thought it was like, well, everyone on GitHub is going to have a blog. But even as late as 2007, I think we were wrong. It should have just said Twitter account, right? It should have been when you sign into GitHub, when you go to edit your profile, give us your Twitter account. And then we'll do some cool stuff with that in the future. Just your username.

But yeah, I think that would be pretty interesting. Because a lot of times I see someone will have as their blog homepage just their Twitter URL. And then you'll go to that, and then they'll have as their Twitter URL, as their homepage, they'll have their GitHub account. So they go in this little circle. And so I think, yeah, I think it's pretty cool. If we could tie in Twitter a lot more. That would be useful. I use both sites a lot for open source stuff.

That would be pretty cool. So we just turned a new leaf. We have this brand new year come up. It's 2010. It seems like everybody's made this list of reservations they're going to do this year. And where they're taking their company, or they've just had this 2010 planning meeting and they've realigned their goals. What are GitHub's priorities right now for 2010 and what's in your extreme focus? You know, we don't, it's always the same thing it's been. We don't make a lot of plans. We don't make a lot of long-term plans because,

you know, if I had tried to plan five years ago what I'd be doing now, it would have just been a miserable failure. And if I had stuck to that plan, I what I'd be doing now, it would have just been a miserable failure. And if I had stuck to that plan, I would not be talking to you guys today, probably. So what we try and focus on is really just making the site polished, making the site good, fixing bugs, adding awesome new features. One of the things I'm really proud about in our company is we can have a whole feature almost ready to go. And if we decide that it's not worth it or it's going to take the company in a bad direction, we'll just scrap it. And we've done that a couple of times with some pretty major things. And I think when you're planning and you have a lot of really solid deadlines for no reason, it's really easy to get trapped in.

We're like, oh, well, we need this done next week, so why don't we just push it out anyway? Because otherwise we'll miss our next week deadline. But we don't do that, and it's great. Things are done when they're ready. Things are done when they're good. Things are done when they're good. We're constantly trying to improve things. We kind of allocate time. You know, we want to revisit the API later this year and then, you know, make it even better and add more features like trending and that sort of thing.

But, you know, in the short term, it's all about making the features that exist better and adding new features that are really useful to people. So that's what we're trying to do this year. As far as growing the business, we probably want to hire a couple more people, maybe. We hired four people last year and they're all amazing. And so things are going really well right there. And I think we just want to keep growing the site in the direction it's growing. The stuff about having a fork that has unique commits

be weighted higher than a fork without them and things like that, that we've been talking about since day one, we want to do that and just make it seem really obvious. And so that's, that's really the plan is make the site really good. Make sure we still love using the site, you know, fix any pain points and that sort of thing, and just concentrate on, you know, the rise of Git. I don't think that this year or even probably next year will be the year that Git peaks just because subversion and everything else is just so unbelievably massive.

And Git still has a really young ecosystem. The whole idea of distributed version control is right now different and scary to people. And so we just want to be ready when all these people start coming over and start seeing the value of it. We want to be there. We want to make it really easy.

We want to make it newbie-friendly, and we want to make it really good. And so that's what we're trying to focus on. So your homepage has 180,000 coders on GitHub. How many repos, approximately? Oh, repos, I don't know. I mean, it depends on how you slice it. I think overall there's about 350,000 maybe, maybe 400.

And then not that many forks, maybe 120,000 forks out of that. This is public stuff. So yeah, I mean, we've got a pretty good ratio of repos to users right now, which is pretty awesome. So we've

obviously all been enjoying the new UI that's been coming out of Kyle. I remember actually looking at this article recently that was on 37signals that there was a guest blog of you talking about the early days of GitHub. And I remember I just looked at the screenshot of the old view of a repo, and I was like, oh my lord, what is that? And it's only been about maybe a month and a half now since the new UI has been in place for the repos.

But how has that impacted the, I guess, just overall user experience of GitHub users? I mean, you tell me. I think from our perspective, we went from people talking about how good GitHub is and how much they like it or how much they hate it. And, you know, those sort of things to now we've added a new class of of of Jabber, which is just like it or how much they hate it. And those sort of things. So now we've added a new class of Jabber, which is just like, it's so beautiful. I love the new UI. I just love the way it looks. I just want to lick it and that sort of thing. So that's really awesome for us is to not just have a really great site that people are really into, but have a site that a lot of people really like.

We've also had people tell us they hate the UI, but that's kind of... Kyle was kind of waiting for the first haters, because that's how you know you did a really good job with anything, really. Yeah, I saw his reply on the blog post, like, yeah, that's how I know I did my job because you don't like it. And it's true. We were... I mean, for a long time GitHub, there was a lack of

criticism, and it was really starting to worry us because we thought it was going to be mediocre. But then it all came flooding in, and we felt much more confident. Did Tom get bummed out by that? Because I know that Tom was, he's the UI guy of the team, right? He was. Tom Preston Werner was the original designer and he did the logo and all the GitHub, all the designs until we brought in Kyle. And Tom is the CTO. So he's really been moving in more of a technical direction and that's what he wants. So he's really been moving in more of a technical direction, and that's what he wants. So when we moved from Engine Yard to Rackspace, we also did a lot of

re-architecting of our site. We changed a lot of the ways in which we store data. And Tom kind of led that. He was in charge of running libraries, hooking it into the site, making sure the web app needed as few changes as possible, making sure it still runs well in our GitHub firewall install, which is the downloadable version that you can run. And so Tom has been moving in a more technical direction the whole time. He's always been great at both. He worked as a developer for many, many years, and he's worked as a designer, print designer for many, many years as well. But I think right now on a site as technically challenging as GitHub, he's going to really take over in the CTO role and help lead us in the direction we need to go to, which is dealing with terabytes of data

and hundreds of thousands of millions of users and that sort of thing. So if anything, he's ecstatic. Him and Kyle work really well together. Kyle is doing a great job, and Tom's able to focus on what he's really, really interested in and good at. We've been talking about GitHub for a long time.

Maybe we could talk about just you for just a second. You know, I guess wrapped up in all this talk about GitHub for a long time. Maybe we can talk about just you for just a second. I guess wrapped up in all this is you, Tom, and PJ, and some of the new hires that you brought on, like Scott and whatnot, but you guys have all been leading this, and you said in a previous chat, you guys are all, you have to be Superman.

How can you be Superman in a small, lean company like you are, going in a profitable state, and still keep up with your hobby and run the business. How do you do that? Um, I mean, when you say it like that, it sounds a lot more incredible than it really is. This is really, this is just a job if you think about it. And that's kind of how you have to treat it. When you get up in the morning, you have to have time when you're not at work, you have to, you know, take a shower, do whatever you do in your daily routine, make your coffee and you're not at work. And have to take a shower, do whatever you do in your daily routine, make your coffee,

and you're not at work. And you can be thinking about a cool feature or a cool idea, but that's what you should be doing at your job anyway. You can't let it kind of take over in that regard. And then you get to work, and then you just focus. I mean, you don't focus for eight hours a day, just like you didn't do that.

You don't do that in your normal job. And you don't have the best day of your life every day. But one of the advantages, and one of the things that I think you have to be good at is if you get on a roll, let's say you had a horrible day and you didn't even get anything done until 4 p.m. and you don't even know where your morning went. But you start getting into a groove around 4 and then 5 and you're making test pass and that sort of thing. I mean, I think with our team and with small teams, it's really important. The ability to stay on task until, you know, 2 a.m., until you finish what you're working on and until you're really, really happy with it

is probably the most important trait. It's just to have, just to know when you need to focus. It's not focusing all the time or anything like that, but knowing when you need to focus and when you need to get something done, knowing when something is done and just doing everything so that it's good, not half-assing stuff like that. I think that's what's really important for our small team. And, you know, that is really hard because you can't work till 2 a.m. every day. And otherwise you just get burnt out. And then, you know, the next day your sleeping schedules all mess up. But I think being

able to identify and kind of build your day around, you know, in the morning I'm going to do these like support work and that's going to not require long periods of time of attention. And then in the afternoon I'm going to have a meeting and then I'm going to work on this feature I've had in the back burner. And then tomorrow when I have most of the day open, that's what I'm going to spend the whole day crushing this really huge feature that we've been working. And I'd really like to work on it today because we're behind on it, but I can schedule my time so that I can just work on it tomorrow and it'll be worth it. Changeover's kind of important, right?

Absolutely. I'm pushing back so much stuff right now. That's awesome. I think the Superman part isn't from being able to do everything. It's just being able to know what needs to get done in a small company. I think the most important thing there is you're not working until 2 a.m. because your boss is telling you this needs to get done tomorrow a small company. I think the most important thing there is you're not working until 2 a.m.

because your boss is telling you this needs to get done tomorrow. You have to recognize what is important because when you're a small team, you can't have babysitting be one of your jobs. You can't be managing a team when there's only eight people on there. They all need to be pulling their full weight, and they need to be able to be self-starters and be self-motivated in a way. One of the great things about not having an office for so long is that we found people that can work at home alone.

Just like, Kyle, go make the site look pretty. And then two months later, he comes back, and it's amazing. We need people like that. And that's really what you need to have, and it's really hard to find those kind of people. But I think once you do, it shows in the product. And we've been working very hard to find those people, and I think we're doing a good job of it. Absolutely. So passion is where it all comes from.

I think so. I think it might be that, but I think, I think what it is for a lot of us is that we use the site and it's not even passionate about loving working on the site. It's that I don't want to settle. You know, I don't want to build something that I'm going to use that I'm not going to like. So if it's going to be crappy, just don't even bother with it. Only spend the time on it to make it really good. And in a lot of cases, let's say you work on something for two weeks, you know, it could, it might only be an extra two days to make it really, really pop. And that is always worth it. It's always worth it. And I think that's what it's about is, you know, making something for yourself that you want to use.

And I don't even know if that's passion. That's just being practical in a lot of ways. It's like, I don't want to have broken stuff. And if it's up to me, if I'm the reason that it's broken or not broken, then there's only one real option there. I need to make it not broken. And I think a lot of people on our team feel the same way. That kind of leads us into this other larger question I wanted to ask before we

start tailing this off with no pun intended for a later conversation. But I wanted to ask you about this. I mean, many have sat, you know, kind of just sat back in awe about your ability to fund this business without VC. And I'm sure that so many people ask you this question whenever you're keynoting or speaking at a conference. How did you guys truly go and build GitHub.com without any VC funding? What does it take to do that and how did you do it? Well, we had a lot of help from people.

For instance, Engine Yard, like I said early on, helped us out in a lot of ways. They covered our hosting and that sort of thing. So when we were growing, they were really there supporting us. And it helps to have a partner or someone else, co-founders, because then, like I said, it would have been easy to say, I'm going to take a month off and just focus on consulting full time. It's a lot easier to let yourself down than someone else. So you can't really say that if you have someone else who's working on it every weekend. You kind of need to, I mean, if you have any sort of shame or guilt, you're going to feel like, well, you know, Tom is working on this.

He's been working on this for the past four weeks and I haven't done anything. I really need to catch up. I really need to work on this. Or maybe I shouldn't take off for four weeks and that sort of thing. So, you know, I think a lot of it was being in the right place at the right time. We were just building a site for ourselves that we wanted to use. And we have done that a hundred times before. We've built between me, Tom, PJ, and even if you want to count the other people in the company now, Brian, Kyle, Tecca, Melissa, Scott, you know, we've all built stuff countless number of times for ourselves.

And with the same philosophy that I'm sure you guys have, you know, I'm going to build it for myself. I don't want it to be broken. I want it to be awesome. And GitHub was just the one time where it happened to work. Everything just lined up. We're in the right place at the right time. We had the right kind of jobs, the right kind of money in our bank account.

And it just worked. And so I think a lot of it is just persistence. It's sticking with something until it does work and also knowing exactly when to kill something, exactly when to not launch that feature because it sucks. PJ and I had another startup before GitHub called FamSpam and it launched in December

of 2007. The GitHub beta launched in January 2008. We were working on GitHub on the side. I think by February 2008 or March 2008 we just knew that we had to stop working on FamSpam and work full-time on GitHub because it was obvious that this was the thing that was going to lead us to financial independence. And we were right. And I think because we had invested so

much more money and time in FamSpam at the time, and it would have been easy for us to say, oh, well, we already have this thousands of bucks wrapped up in this other thing. Let's just see it through. And maybe it would have been a colossal success, but it wasn't at the time. And I don't think we would have been happier doing that than we are right now. You know, you've said persistence, I think, early in the podcast in regards to something I can't recall exactly what. But I think it was like what keeps you up at night, what keeps you going. But a good friend of mine, Kevin Mildon from New Leaders, I'm not sure if you're familiar with him, but he's not far from releasing this book called Lesson for Leaders.

And there's one quote in the very opening of this book that says, persistence always triumphs, never give up. How do you feel about that? I have mixed feelings on that because if we had persisted with FAMSFAM, where would we be right now? I think it's about not – Makes feelings on that. Because if we had persisted with fam spam, where would we be right now? I think it's about not... Persistence, I guess, maybe with an understanding of where you're going. Yeah. I think not giving up on something that you have a good feeling about is very important. And that sounds sort of stupid and obvious.

But how many times have you had a New Year's resolution where you wanted to do something and then you stopped after a month? Or how many times have you decided to go try's resolution where you wanted to do something and then you like stopped after a month or how many times have you decided to go try some new hobby and stopped after two weeks. And even though you want to, you want to learn guitar better or you want to just do better, you just didn't, you just didn't stick with it, you know,

and for whatever. And I think that that's, that's the thing you have to fight against is even though you're in week four of, you know, playing guitar every day and you don't really want to do it, you'd rather be watching TV or something, or you'd rather be even working on your website, just stick with it because in the end,

you want to hit your goal, or it will be worth it in some way. And I think for us, that was it. I mean, a lot of times it would have been easier just to not work on the site or just go back to making consulting money, but we stuck with it because we had the goal in mind. And so yeah, I agree with that. Well, I know you're West Coast, but so we're not here after dark. Let's go ahead and ask you, what's on your open source radar? I'm looking at your watch repos on GitHub, and it's almost half the GitHub list there. So what excites you in the world of open source?

Right now, I think, I mean, I've been doing, it sounds kind of cheesy. I've been doing a lot of stuff with old school Unix, I guess, knowledge mining. I just read the Art of Unix Programming by Eric Raymond. And I'm trying to get a feel for how the people in the generations before us kind of thought about software development and what tools they used, how those tools were put together, and that sort of thing. Learning about the origins of everything from standard out to standard error and what they're for. Ryan Tomeko just released this thing, Ron, for generating man pages, which I've been using on my new projects.

And sort of writing really good Unix tools that help development and can help for all sorts of things like deployment and any sort of programming task. So I've been really interested in learning about, you know, the ideas and philosophies behind some of the people that came before us in a sense of speaking, internet years, let's say, and just the origins of the internet and that sort of thing. So for me, that's been pretty exciting. It's just kind of like reading about problems that have already been solved in a way that

I am intimately familiar with that I didn't even know was a problem. Just things like, you know, just like Unix pipes, which you take for granted every day. They were invented by someone to solve some problem. And what was the thinking there? And it's pretty awesome just reading about that stuff and the motivation behind it. It's like when the guy who invented ramen died a couple years ago. You're like, what? Someone invented ramen? It's like, well, yeah, of course.

Someone has to start something. And before ramen, what do they do? I don't even know. But after ramen, it just seems so obvious. So a of course. Someone has to start something. And before Raman, what do they do? I don't even know. But after Raman, it just seems so obvious. So a lot of that stuff has been pretty interesting. A lot of college kids start. Exactly. And then other than that, as far as like...

So R2D2 is a cool project for generating man pages. It's in Ruby. So if you have Ruby scripts, I've been using them. Another thing I've been interested in is writing Ruby scripts that the fact that they It's in Ruby. So if you have Ruby scripts, I've been using them. Another thing I've been interested in is writing Ruby scripts that the fact that they're written in Ruby is incidental. So I have this script hub which works with GitHub and can wrap Git.

The idea there is that it doesn't matter if you have Ruby, if you have Ruby gems and that sort of thing. It doesn't matter. You don't need to know anything about Ruby. It should be really easy to install and it should work just like any Unix command line script that you have. And the inspiration for this is kind of ACK, which is

sort of like a grep replacement. It's better than grep.com. And it's written in Perl, but you don't need to install it through CPAN or even know what that means. If you have Perl installed in your system, you can just run his little one-liner and then now you have ACK installed. And everything's just in one script. There's no dependencies. you don't fuss with it, it just works

and so I think there's a lot of appeal to writing scripts that way in your language of choice and whether it's in Python or Ruby sort of like hide that it's tempting to be like oh I'm writing a Ruby project and I want to make it RDoC or use your RDoC and then make all these RSpec tests and then

have the readme be in RDoC and make it a gem install. And all that stuff is really awesome for Ruby developers, but there's a lot of assumptions there. And to see what I'm talking about, try diving into another language that you don't know for a while and just sort of play with some of the projects

and you'll have situations where you're like, all right, well, I don't even know how to run these tests. It doesn't say anywhere because I'm not a X programmer and this is written for X programmers. So writing projects for people that aren't necessarily Ruby programmers or Python programmers, just people that are using Unix is pretty interesting to me right now because, you know, almost everything on the command line is written that way. Every project you use, you don't care if it's in C or Perl or, or, or even both like Git, all you care about is what it's doing. And so I think there's a lot of appeal there. And it's kind of, unfortunately, a lost art to us, like mainly web developers. And I think

that there's a lot that can be done there. So other than that, I've been playing with just Node.js, which I guess is like everyone else's favorite side project right now. And it's interesting because I've always loved JavaScript. We use a ton of JavaScript on GitHub. And being able to use that in a server environment that's super fast and has tons of new libraries for interesting new tech coming out is pretty interesting. Node.js seems to be getting

a lot of momentum. Have you built anything of consequence personally with Node.js yet? Nothing public. I've worked on some IRC stuff and some buzzword-y real-time browser stuff with it, but nothing public. What is the sweet spot for this particular framework?

I think the sweet spot, well, from my experience, I think the sweet spot is when you have a lot of JavaScript, and you can share libraries between the front-end and the back-end. So your template engine and things like that, you can just load it in the back-end, load it in the front-end, and then now you're just passing templates and JSON back and forth, and you can render it wherever. If it's the first page load, you can render load it in the backend, load it in the frontend, and then now you're just passing templates and JSON back and forth,

and you can render it wherever. If it's the first page load, you can render it in Node. If it's a little snippet or a partial, you can render it in the frontend. And in situations like that, you can just sort of update your app and not have to worry about the user reloading the page. In many instances, you can just ship them updates to the HTML or whatever and not interrupt their user experience. And I think Node would work really, really well

with the NGINX HTTP push module, which is my favorite way to do comment right now. And so I've been playing with those two in tandem. The push module holds open long polling connections from the browser for you in NGINX. So it's really good at holding a lot of them open at the same time. And then it lets you send a post request to a published URL that is secret and internal to your network.

You give it a channel ID, and the browser is listening with the channel ID. When the push module gets that post, it'll give the day that you post it to the browser. In this way, you can do long polling, persistent connections, fake a socket connection in the browser, and do it really easily without having to worry about, all right, I'm starting up an orbited daemon, I'm keeping over X number of connections, I need X number of RAM, and that sort of thing. You just let NGINX handle what it's good at, which is scaling, and then you handle what you're good at, which is building your app, and then when you want to talk to the browser, you just post stuff.

So it's a pretty elegant way to do it and very simple. And I think those two technologies go together pretty well. Before we move away from Node.js, I have to mention this, that I think it's been like five or six consecutive podcasts we've done, Wynn, where Node.js was mentioned. Are we trying to make a record or something? Well, how much

is he paying you guys? They're not paying us anything, but it's just funny that everybody we talk to, they're like, Node.js, Node.js, I love it, love it. This is the first episode that we haven't spelled it, so if you want to go ahead and spell it. N-O-D-J-S. N-O-D-E. The first three episodes, Adam thought we were saying Node.js.

No, I thought you were saying Node.js. That's just my accent. I apologize. Is it like NoSQL? Exactly. NoSQL. I think that's what Adam thought. So one last item. We've been working on a SkunkWorks project here at the Changelog for a while, tailthechangelog.com.

So when this audio comes out, we'll take the raps off of it. We just wanted to get your reaction because you've seen it, and if it's not favorable, we'll just cut this segment. Oh, no, I think it's awesome. It's not favorable. It must be favorable. I think it's a great site. Everyone at GitHub loves it

it's cool too because it looks very simple at first and then you hit the little gear icon or you hit the more button and you can kind of dig deeper it has that fun exploring feeling to it where you can mess around and uncover new features which is always awesome in good software and I think it's cool, it's a great way to look at everything. I wish we had built that ourselves earlier on.

And I hope we can work with you guys to make it better in the future. But I think I could see myself leaving it open and glancing at it whenever I'm a little bit bored just to see what's on the screen at the time. I want to ask you about that. I find a lot of nice projects to follow just by following what

you're following. It shows up in my public timeline since I follow you on GitHub. I wanted to know how often do you discover new projects, cool projects, just by watching the public timeline, and how much of it is just through word of mouth? I don't check the timeline that often. It used to have a two-hour cache on it, so it was usually pretty stale. I think now it updates about every five minutes. And then if you hit the RSS feed, I think it doesn't have a time cache

in that way. So I mostly, I mean, I find stuff on just mostly people tweeting about stuff, or I follow a bunch of other people. I try and follow as many people as I can on GitHub. Anyone new I see, I try and follow. And I'm on the site all day, every day

for every reason. Either I'm doing open source or I'm working or I'm trying to debug something or I'm doing a support request. So, I mean, a lot of that time, if I happen to see something cool, I'll just, you know, follow it for later or, you know, watch the project for later or follow the individual. You know, I went through a long period of time where I was just watching projects and not following people. So I was following like nine people as of a couple months ago or something like that and I realized that a lot of the value comes from letting other people do the work for you like you just said you let me do so I've definitely been trying to follow as many people as possible because that's where

you see like a lot of the new weird interesting stuff well I uh I know I speak for when I say thank you for coming on the podcast with us and certainly appreciate your awesome remarks about Tail. We were super jazzed about it. A big credit is owed to Wynn because he did a heck of a lot of work on that. I did some lightweight UI work on it, and it was definitely a labor of love for us, and we're excited about what we are doing now with it and what we definitely have planned for the future with it.

So we would certainly encourage your participation in that and however that works out. One last question. I know this is totally off topic, but I've got to ask this question before we let you go. The origin behind the Octocat? Well, Tom was looking for a mascot, and in Git there's such a thing as an octopus merge.

Gotcha. So there's different merge strategies in Git, there's such a thing as an octopus merge. Gotcha. So there's different merge strategies in Git. If you man Git merge, you can see there's a dash S for a strategy, and you can do a couple different ones. And one of them is the octopus merge. So it just seems sort of obvious to us that one of Git's cool esoteric features become the cute, cuddly mascot that we used on our error pages. Did you actually engage the artist that did that? Wasn't that from, I thought it was from an artist that was found on iStock Photo, and I can't recall the guy's name right now,

but I definitely bookmarked him in my Delicious at some point, so if you follow me on Delicious, dig through there, you'll find it. But wasn't that from iStock, and there was an artist that lives in Japan who does some very cool, unique art and that Octocat was one of the earlier versions of his art. Yeah, his name is Simon Oxley.

And he actually did the Twitter bird and a lot of the Twitter stuff. Right, right, yeah, that's true. And yeah, we got it from iStock Photo originally. Tom was looking for the mascot there and then we ended up buying it. So we own it now exclusively. But yeah, that's where it came from.

We bought it just like they did with the Twitter bird as a license. So actually for a while, people would say, can we make an Octocat t-shirt or can I put Octocat on my whatever? And we would have to say, well, yeah, if you buy an iStock photo license for it, we can't re-license it. And a lot of people did that. But now we own the rights, so we can control it. Okay, we've got another K-Outworms for you.

I'll let you go. The 4Q t-shirts that were popular a couple years ago at RailsCon. Oh, yeah. How'd that come about? Because Adam wears it like two days a week. I do not. Yes, you do. You're always wearing that shirt every time we have a video conference.

No. I'm wearing it right now. Crap. You're wearing it in your avatar, aren't you? Yeah, it's my avatar. I actually took that picture in an Apple store and I just happened to be wearing my Forky shirt.

It's one of the badass shirts I have in my closet and I got to pimp it. It's as simple as that. Absolutely. It was early on when we were doing the site. It was one of those we were doing the site. It was one of those decisions where we had the fork button, and it's different now.

Kyle made it amazingly beautiful. But I like the old buttons too, the old pill buttons we had. And what it had was a little silk icon on it of a fork, and it was in red. And the link itself was red. And we talked about it, and we decided the link should just be a normal color, and the icon should be green, because forking is a good thing on GitHub. We're going to use the same word, but it shouldn't be bad. It shouldn't be like the big Emacs fork between XEmacs and Emacs GNU

and all that sort of thing. And so one of the ways we wanted to try and enforce this idea is with the fork you shirt. So, I mean, when you see that, it looks like a phrase which is, you know, not very friendly. Um, and so like saying fork you to someone is sort of a censored version of saying something not very friendly to them, but we wanted to take that phrase and say, now, you know, now it is friendly. Now forking is a good thing. So saying fork you to someone is actually like, in some ways, a good thing. It's saying like, we are going to,

you know, send a pull request basically. Like we were talking about earlier that's what we think fork you means just like send me a pull request fork my project and then we'll work on it together and we'll figure it out instead of the old way where fork you means like you know get the hell out of here don't talk to me so that was sort of the idea is we're going to take this phrase we're going to put it everywhere we're going to put on these t-shirts and we're going to make it a good thing and i don't know how well that works i get more comments on that shirt from any other piece of clothing I wear. I know everywhere I go, if I go somewhere, if I'm like, if I'm in line, putting my name in to sit down for dinner or something, they're like, oh, I like your shirt. And I totally forget what I'm wearing. And I look down and they're like, and I'm like,

oh yeah, it is a nice shirt. And they look back at me and they're like, it's usually a chick. It's usually a chick. They're like, yeah, I like that shirt. It's a, it's, it's good. Yeah. We want to make more Forky shirts and finally Octocat shirts this year because now we can sell Octocat stuff. So that should be pretty exciting. I do have one thing to mention, though, before you guys go. Anyone listening to this right now, as you guys should know, you can go to github.com slash explore, and it will be syndicated.

It will have changelog stuff. You don't even need to go to changelog anymore. Awesome. So yeah, it'll have a bunch of featured articles that changelog has written about. It'll have podcasts that the changelog has made. And it'll also have other not changelog-related

stuff, such as trending repositories and stuff to look out for, stuff that's being forked and actually contributed to. So GitHub.com slash Explorer is going to be... You can add that to your bookmark right next to tail.the github.com slash explore is going to be, you can add that to your bookmark right next to tail.thechangelog.com as two big new time wasters in your life. Absolutely. Be sure to make episode nine sticky at the top so that people know what's up.

Awesome. Will do. Sure. Well, Chris, definitely thank you for sharing your good thoughts on tail. We're excited about what's going on with that and definitely excited about having our content syndicated onto github.com forward slash explore. So excited about the kind of relationship we can forge together

and where this can go for us. It's been awesome picking your brain about all the cool stuff you've been working on over the past three years, two years, whatever it was. Thirty, I thought. Thirty, yeah, thirty. In internet years, it's thirty years. Definitely thank you for coming on the show. Appreciate it. Thanks a lot, 30. In internet years, it's 30 years. Right. But definitely thank you for coming on the show.

Appreciate it. All right, thanks a lot, guys. Thank you for listening to this edition of The Changelog. Point your browser to tail.thechangelog.com to find out what's going on right now in open source. Also, be sure to head to GitHub dot com forward slash explore to catch up on trending and feature repos, as well as the latest episodes of the changelog. The passion show was mine alone. I'm out. I'm out.

For us to try. Bring it back. Bring it back to. I'm out. I'm out. Outro Music