Episode 107 of The SitePoint Podcast is now available! This week Louis Simoneau (@rssaddict) and Dan Cheail talk with Tom Preston-Werner (@mojombo), one of the co-founders of GitHub. We talk about GitHub’s huge growth, scaling with Rails, social coding, and the importance of open source.
Listen in Your Browser
Play this episode directly in your browser — just click the orange “play” button below:
Download this Episode
You can download this episode as a standalone MP3 file. Here’s the link:
- SitePoint Podcast #107: Social Coding with Tom Preston-Werner (MP3, 44:28, 42.7MB)
Subscribe to the Podcast
The SitePoint Podcast is on iTunes! Add the SitePoint Podcast to your iTunes player. Or, if you don’t use iTunes, you can subscribe to the feed directly.
Interview Transcript
Louis: Hello and welcome to another episode of the SitePoint Podcast. With me today on the show we’ve got Dan Cheail who is the editor for RubySource which is one of our new little projects here at SitePoint, and we’re going to be interviewing a pretty impressive guest, I’m really happy we managed to get him on the program. But before we move on to the interview I thought it would be a good opportunity just to have a quick chat with Dan about RubySource and where we’re going with that, so, hi Dan, how’s it going?
Dan: Really good thanks!
Louis: So do you want to just give us a bit of background, some people who follow SitePoint might be aware and might have seen that we’ve recently launched a couple of little sister sites for more specific topics that maybe we can’t devote as much attention to on sitepoint.com as they deserve, so do you want to tell us a little about RubySource and how you got involved?
Dan: Yeah. Basically what we’re trying to capture with RubySource is a centralized place really just to talk about everything Ruby related, so tutorials, opinion articles, exploring the way different things are achieved in Ruby as well as providing a place for developers from other platforms, so say PHP and Java and .NET to who are interested in moving to Ruby and Rails who can come along and actually read some articles that are tailored not necessarily treating them like brand new programmers but as people who have the skills and experience and know the fundamentals but can actually take those skills and replicate them and reuse them in the Ruby based environment. So it’s a bit of a grab bag of trying to cover quite a few bases, but really ultimately it’s about sharing the enthusiasm me and all the writers have for Ruby and Rails and everything involved with it.
Louis: Yeah, absolutely. I had interviewed Peter Cooper and Jason Seifer on the podcast a couple of weeks ago, and if there’s one thing you can say about Ruby guys is they’re enthusiastic.
Dan: It’s a language that seems to engender strong opinions on both sides of the fence, but I think ultimately all that passion just ends up being funneled into creating amazing quality projects and top-notch libraries and platforms and everything; the Ruby ecosystem is a joy to work in, it sounds like rabid fanboyism.
Louis: (Laughter) to some extent.
Dan: It is to an extent, but I think the fact of the matter is at the heart of it all there is a quality product that people have feelings about using which is amazing for a software development language.
Louis: I think sort of segueing from that, a great place to bring on our guest is when you’re talking about Ruby as being a great way to — or that there are a lot of awesome projects and libraries that come out of it. So today on the Podcast we’re both going to be interviewing Tom Preston-Werner who is one of the cofounders of GitHub which is I guess one of the most visible Rails projects out there, at least for most developers.
Dan: Yeah.
Louis: And I just wanted to have you on the show as well so that we could really get at some of the implementation stuff and talk about maybe the challenges that they’ve seen scaling up in building something that’s that big using Ruby and Rails, I mean I’ve got a bunch of things I’d like to talk about regarding Open Source in general, but I thought that it might be cool to have a more dedicated Ruby perspective going into the interview.
Dan: For sure.
Louis: So, without further ado, I think we’ll just try and get Tom on the line. So welcome to the show.
Tom: Thanks.
Louis: How are things?
Tom: Things are well, how are you doing?
Louis: Very well. And we’ve got Dan here also who is the managing editor of our dedicated Ruby site called RubySource which just launched a few weeks ago.
Dan: Howdy.
Tom: How you doing?
Dan: Good, good thanks.
Louis: So, I guess the place to start is you are best known I guess as the cofounder of GitHub.
Tom: That’s correct.
Louis: So do you want to just for anyone who’s listening I realize that most people will probably be at least somewhat familiar in passing with Git and GitHub, but for anyone who’s not do you want to just tell us what is Git and what is GitHub and why does it have such an odd name?
Tom: So, Git is a distributed version control System, which means that software developers use it to version their code and share it with other people. Now, the distributed part of it means that every person that has a copy of that code base has the entire repository with all of its history, so you can work with it locally, on an airplane, all of the operations are fast because it’s hitting your local repository; this is different from systems like Subversion which have one single centralized place that all of the files are stored and to do anything you have to sync up to that repository. So, even things as simple as doing a log in Subversion are very slow because it’s going over the network, but in Git it’s very fast because that’s local. Git also has what are called branches so it makes creating a new branch and doing experimental work on the same code base really easy, and it makes merging those branches into your main development branch also really easy, something that other version control systems don’t handle quite as nicely. And so that’s Git, Git was created by Linus Torvalds for the Linux kernel when he was unhappy with the alternatives and so he named it Git, and the story behind that supposedly is that Linus said that he likes to name projects after himself, first Linux and now Git, which is funny because in British “git” means kind of a bastard or someone who’s full of himself. So that’s Git and that’s where Git comes from and what it’s good at. Now, GitHub obviously is named after Git the version control system, and the “Hub” part of it is what we’re all about, we’re about sharing those Git repositories with your friends. So before GitHub was around we started using Git, this was back in the early days when not that many people were using it other than the Linux kernel, and we found that ironically Git is distributed which means that it should be really easy to work on your repository with other people, it should be really easy to share those changes that you’re making around; that’s purportedly what it’s very good at. But the reality was that unless you had a Linux server somewhere and you could set up user accounts for your friends then it wasn’t really very easy to actually share that code, you needed somewhere to put it where you could transfer it back and forth so that you didn’t have to connect directly with other people’s computers which is really hard because of firewalls and things like that. And so myself and Chris Wanstrath, the other cofounder, we come from a web development background and we said hey we want to use this Git, this version control system, Git, which we started using and it was really awesome for developing and doing branches and that, but the sharing aspect of it wasn’t very good. And we said, well, we’re web developers, what if we made a website that let us share those repositories and see them online and view those commits that people are doing and trace the history of the branches and how they were branched and merged back together, what if we made something to make that really easy, and so that’s what we did and that’s what GitHub is, a place that you can really easily share your code and collaborate with other people using a lot of tools that we’ve built since we started.
Louis: And I guess one of the things that’s interesting about that is how amazingly successful GitHub has been, it’s gone from sort of everyone was sort of using Subversion and there were a few people out on the fringes in the Rails world and like you said the Linux kernel who were using Git, whereas now it almost feels like the backbone of Git, like everybody who publishes an open source library is going to link you up to a GitHub repository, and that’s happened really quickly.
Tom: Yeah, we started the site just three years ago this April, so this month, and I think it was April 10th that we launched publicly three years ago.
Louis: That’s crazy.
Tom: Yeah, I think one of the big things that we did that was different from the beginning that has allowed it to become so popular is that we don’t put any restrictions on what people put on GitHub, so unlike some earlier systems that would make you get permission to put up projects, they would have an approval process, we said well what’s the point in that, people should be sharing code of whatever nature, it doesn’t have to be a legitimate project, it could be little experiments or even your dot files, and now on GitHub there’s thousands of repositories that just contain people’s configuration files for their command line prompt. And we did that by introducing the idea of namespacing the URL by the user, so a GitHub URL looks like github.com/username/projectname, and that means you don’t have to worry about using up a valuable name for a project because it’s all underneath your user. And so that’s what allows people to be really free about what they’re putting up, and the more people put up there the more chances there are that someone’s going to stumble across it and say hey this guy is solving a problem that I have; even though that person maybe doesn’t think that it’s useful to anyone else, some of the most popular projects on GitHub are configuration files, and who would have thought that that would be really something that people wanted to share, well, not that many people before GitHub was around, but it turns out that just the serendipity of coming across something that someone else found useful even if it wasn’t intended for public consumption that’s a really powerful thing.
Louis: Did you have any idea when you were starting it that that might be the case that people might start sharing sort of these little random snippets that aren’t maybe full fledged projects?
Tom: Yeah, I think it was something that we wanted to do because we were frustrated with other sites that had these multiple day waits to just create a new project and that seemed kind of silly. And we were very big open source people and we have all kinds of repositories that have code that’s not really ready to be released in a sort of reasonable form, they’re just kind of we’ve been playing around, we started this library, this Ruby gem or something, and we just want somewhere to put it so that first of all it’s safe, I mean it acts as a backup, and second of all just so when we do want to show it to someone else we can just send them the URL, it’s as easy as that, we don’t have to email them a zip file of a big code base, no, we just them the URL and say hey this might solve the problem that you had, I’m not working on it anymore, but maybe you want to take this code base and benefit from it because I’m not going to anymore. So it was something that we wanted to do personally and that’s why we did it. So I think we knew sort of without having a lot of data behind it, I mean we just did it because we wanted to do it, and so that’s mostly what we’ve done at GitHub is we build stuff that we want that serves the needs that we have, and it turns out that we are very much like a lot of developers and other people like the same kinds of things that we do.
Louis: Right. I maybe just want to switch gears a little bit, you talked briefly about a Ruby Gem in there, I have Dan from Ruby Source on the line with us and I just wanted to maybe have you guys chat a little bit about what it was that, I mean I guess you were a Ruby guy before you started GitHub, so the decision to build GitHub in Rails was natural for you?
Tom: Yeah, absolutely. I mean I was doing tools for a company called Powerset which was doing Wikipedia search, I was doing tools there before I started working on GitHub or really while, because I started GitHub when I was still working there full time. And so I’ve been doing Ruby for several years before that and was deep into Rails and hung out a lot at the Ruby meetups that were here in San Francisco and met a lot of people doing Ruby, that’s where I met Chris and PJ, one of the other cofounders. So that decision to do that was, I mean there was no decision, it was just that’s hey I want to make this site and well here we go, create the Rails application and start coding.
Louis: Right. So when you started, right now the way GitHub works is it has a somewhat novel, I guess, pricing structure. So you provide unlimited public repositories for free so anyone can sign up with an account and if all they want to do is put up some stuff to show everybody or they’ve got an open source project that they want to host they can do that for free, and then if you want to have private repositories and just share them with your team then those are paid plans. Did you have that pricing structure in place from the beginning?
Tom: We had lengthy discussions, Chris and I, in the very early days about how we wanted to do the pricing, and one of the lessons that I learned from a previous venture that I had which was Gravatar, which is the little avatars that you see everywhere that follow you around, I did that and I created that without any kind of business model, I just did because I thought it would be fun, it was a great way to contribute back to the weblog ecosystem, and I eventually learned that if you don’t have a way to make money from your side project that eventually it becomes very costly and it starts taking up more and more of your time, and yet you’re not making a way to make a living doing it and so now you’ve basically got two full time jobs, you’re just not getting paid for one of them. And so that was a really big lesson that I took from those days, and so when we started GitHub I said well this seems like it might be a really cool side project, but if I’m going to be investing a lot of time in this then I want to be able to make money from it as well, and so that if it does become really popular then it should also be making a lot of money so that I can do it full time. So that was definitely a conscious decision from the very beginning which was let’s figure out a way to charge for it, and we talked a lot about it, and the thing that made the most sense was, well, who’s going to be able to pay for this, who’s going to have the money? Open source people aren’t going to want to pay for something like this because it’s open source, they’re doing it on the side, they’re doing it for fun, we want to encourage people to put their code up on here and share it, that’s kind of how we’re going to get exposure, and so well let’s make it free for them, who can we charge? Well, you know who has the money, companies do, so let’s charge them, right, let’s aim the pricing at the people with the money, it makes sense, right? So what could we charge for that companies will want that open source developers don’t need, and that’s privacy. So really the model became well let’s charge for private repositories, and so that was when we launched to the public three years ago; we launched with that pricing model, the pricing model hasn’t changed at all since we launched.
Louis: Right and it’s worked out really well for you guys.
Tom: Yeah, it works out amazingly well. I mean everyone’s happy, right; open source developers get it for free, companies have their privacy and they have money to pay for it and stuff, so they’re happy to do it, I think it’s a win-win for everyone, right.
Louis: And has it been, given the sheer amount of code that gets posted to GitHub so everybody’s stuff is up there, do you find that you have enough people paying for the private repos to be able to support that free ride for everyone else?
Tom: Oh, yeah, absolutely. The way that we’ve built the architecture and the costs of running the business are definitely within the realm of making that possible. I mean we are right now I think we just hired our 27th person, so essentially yes, that’s not a problem.
Louis: Alright, clearly it’s working out for you.
Dan: I know personally as a developer putting my stuff that I’m willing to share out there, especially at the low price point for the very start, it becomes a no-brainer to start putting your professional projects up there as well. I honestly didn’t even think about subscribing to the platinum plan and going through with it, so it’s really worked out well for me.
Louis: Yeah, likewise. I got to say I have a paid GitHub account as well so I guess I shouldn’t express any shock at the fact that people are out there paying for that in sufficient numbers I guess, it’s not only companies but a lot of–you have pricing plans that are accessible to just an everyday developer who, okay, I’m doing some open source work that I want everyone to see but I’m also doing a few projects for clients, and rather than just keep those on my machine I can just put them on GitHub along with everything else.
Tom: Yeah, exactly. The plans start at $7.00 a month, so that’s really easy for individual developers to get into, people who have consulting firms or whatever, presumably that would scale with the number of clients that you have, right, you have a bunch of clients, they’re paying you, and so you take a little chunk of that and you pay us for building this awesome tool that you can use to make your life easier and you can give your clients access to those repositories on an individual basis and then that works out really well for a lot of people. So, yeah, you can definitely get into it without a lot of money involved, and that was another conscious decision which was, well, we need people paying us and while three years ago not that many people were using Git so we had to make the prices low enough that people could say well $7.00 a month I can swing that, that’s not a big deal; I like Git enough to pay these guys to do really great hosting for me. And we’ve kept that philosophy around to this day which is help people get involved, right, and just make really nice low-cost plans that are still where you can get real work done, and that’s really kind of the on-boarding; just make it easy for them to get involved, because if our first plan was like $100.00 a month then no one — people new to Git they just wanted to experiment, they only have a few repositories, they’re not going to pay that, so having that nice ramp up way of doing the pricing has worked out extremely well, and we did have a lesson. When we launched the organizations feature which was some functionality around teams and organizing groups of people and doing permissions based around that, we had a pretty big jump from what the old plans were, so there was like a $50.00 gap in how much the next plan was going to cost from the one below it, and it turned out that that was too high, people were not comfortable doing that much of a jump. And so we responded and we said, okay, well let’s add another plan in between so that people can have a more streamlined upgrade procedure, and people liked that a lot and everyone said, oh, that’ll work, that’s awesome. So you do have to be responsive to those kinds of things and knowing your customer base. What we realized is that our customers are primarily small businesses, we have some larger people on there but for the most part it’s a vast number of small businesses that are our core customers, and I think we forgot that for a second; we said hey, well, they’re all big businesses, right, they’ve got tons of money, but these small businesses didn’t necessarily, they’re startups just trying to get going or they’re consulting firms that are not really doing too much profit they’re just trying to get along and we want to serve those people, they are our customer base, and so we need to be able to serve them really well. Once we realized that and created that new plan then everything’s been perfect since then, that was the correct solution.
Louis: Fantastic. You talked about how you started just three years ago, at the time was it just the three of you, the cofounders?
Tom: Yeah, originally it was Chris and I and then PJ came on just very shortly after we started.
Louis: And now you’re up to 27 staff and obviously the site and the user base has grown tremendously, maybe I’ll just hand over to Dan and you guys can talk a bit about the challenges of scaling and the actual technical difficulties you might have encountered along the way.
Dan: I guess sort of straight up Ruby’s obviously infamous in the developer community for being unable to scale, I would suggest that GitHub is proof positive that it can. Obviously you said before that because you guys are all Ruby developers anyway, was there ever a day in your mind after you started that maybe it was the wrong tool to pick or were you just happy to use it because that’s what you knew and you believed you could do what you need to do with it?
Tom: Okay, so people talk about Ruby and Rails not scaling, that’s, you know, we’ve never seen that. Ruby and Rails and that part of the site has never been the bottleneck, not ever, not once. The stuff that bottlenecks for us is the file system, getting Git repositories off of disk has always been the big thing; it’s not Rails, it’s not the database, it’s not any other component, it’s really just ripping the data from those Git repositories off disk and shuttling them up to the front end. So I mean, yeah, we have a lot of traffic now and it’s just a lot of it’s about making sure you have good caching in place using things like Memcache and we use Redis for a lot of things to get really fast retrieval for key/value types of things. And so, no, I mean we’ve been on primarily Ruby and Rails based since the very beginning and that’s been amazing, it allows us to write stuff really quickly, get new people up to speed on the code bases because Ruby is really very easy to read, and when you have a big focus on modularizing the infrastructure so that the different pieces are broken into separate libraries so it’s conceptually very simple, that’s outside of the Ruby specific stuff, but I think it goes along with the core ethos of Ruby which is simplicity and keeping things really easy to understand. So that’s all been great, I have no regrets at all as far as that choice for architecture, I wouldn’t use anything else.
Dan: Great. I guess the question that I’ve been curious about for a while as a Ruby developer and as a user of the site, how much of GitHub is Rails and how much is maybe other Ruby libraries or even non-Ruby stuff that’s supporting the background? Obviously there’s a file system bridging your front end and Git, but I wonder if you could give us a little bit more of a view of what else is powering GitHub.
Tom: Yeah, so the main website is Rails, that’s all pretty standard Rails, and then things get interesting once you start going towards the backend; one of the most interesting pieces is how the data gets from the file servers to the front ends. So the architecture is we have six front end machines, they run Rails, and then we have nine pairs of file servers on the backend and they each work in a master slave situation. So when you make a request for a repository the front end goes through this library that we wrote called Grit which is the Ruby Git bindings, and all of the methods that deal with file system accesses in that library all exist in one single class, and what we do is we stub out that class on the front ends so that it — and replace it with a new class that goes over the network and contacts a proxy, so it turns the request for a specific Git command into a call that uses a format that’s called BERT RPC, and BERT is a specific protocol that I wrote to use which is really efficient with large binaries; this was two years ago, I was unhappy with the other protocol solutions. And this is a protocol that is based off of Erlang terms, so BERT stands for Binary Erlang Term, I’m a pretty big Erlang guy and so I had written a server on the backend which is called Ernie, which is a BERT RPC server (Laughs).
Dan: Very cute.
Tom: And so the Ernie server is just an RPC server. I talked to a lot of people about potential architectures for how to do this with commodity servers, like we didn’t want to buy a big fancy sand machine to hold all the repositories and have a shared file system, that’s what we did before and it didn’t work out really well. We wanted to work with just commodity servers and have a large number of independent file server backends that are just Linux machines with fast disk in them, that was what we decided was going to be the best solution. And so instead of using something like XMPP or an asynchronous messaging system, what fits our scenario is just a standard RPC mechanism, just the front end needs to get information from the backend, it’s always synchronous, it’s always going to want to wait for that information, it doesn’t have to do other stuff in the meantime, and I was unhappy with the solution so I wrote the BERT protocol, the BERT RPC spec and the Ernie server to be able to do this. And what the Ernie server does which is kind of cool is you can have Ruby processes running behind the Ernie server, Ernie is really just load balancing to handlers, and these handlers are really just the rest of that Grit code that the front end is trying to call. So you can imagine the front ends are really just trying to execute this code in Grit, but because the repositories themselves are on file servers that are on different machines we need to be able to get that information over the wire. So it uses that remote procedure call, sends that through the proxy, the proxy looks at that RPC packet and figures out which machine that user is on because every request will contain the username of the repository, or actually we do it a little bit different now but it’s still very similar; it keys off of information about the repository user and name to locate which file server it’s one. So basically it does a little lookup in Redis and says hey you’re on server X, the proxy then shuttles the request off to there, it goes to the Ernie, the Ernie says hey you’re trying to run this Grit command and then sends it to one of the handlers and the handlers really just complete that call, so you’re basically putting a proxy in between two parts of a single library, it’s really separating that Grit library into two halves and running them in the appropriate places, so that’s kind of how that infrastructure works. And Ernie is written in Erlang and the rest of it’s Ruby though, so it’s really just a way to handle those remote Ruby calls, and it works out really well, I mean we do hundreds of millions of requests through that infrastructure everyday.
Dan: Awesome.
Tom: We also have a lot of other Ruby stuff, we have Resque which Chris wrote which is a queuing library for running jobs, so those just go into Redis and then we have different handlers, job handlers that run, and we use that extensively and that works really well, that’s in Ruby. We actually use some Node.js for the downloads for when you do an archive download so you won’t say a tag, a certain tag version of repository, that needs to be created on the fly, and so that’s a little Node.js server that Rick wrote, Rick Olson, and that’s been working really well. We have other little pieces here and there that are in different things, we just Pygments which is a Python library that does the syntax highlighting and that’s been working out really well. So, I mean we use whatever the right technology is for the job and we have things written in a variety of languages, not too many, we try not to have a ridiculous number of technologies just to make it easier to do hiring and get everyone familiar with code, but Ruby, Erlang and Node are probably the primary ones that we use right now.
Dan: Awesome.
Louis: There’s something in there that you were talking about, well there’s two things that sort of triggered into stuff I wanted to talk about. One is you were talking about Grit and a few other different libraries you’re using, and you were talking earlier about how you guys sort of were aiming to support the open source community, so I want to maybe get at the heart of that and see like what is your philosophy on open source, if the stuff that you write internally does a lot of that get put out as open source?
Tom: Yeah, a ton of the stuff that we do we open source, mainly it’s infrastructure level stuff. Our philosophy is that if it’s infrastructure code that is not really specific to our value proposition which is hosting tools for Git repositories mainly, that’s one of our basic things, if it’s not really related into that then we open source it. So, for instance, all the BERT and BERT RPC libraries open source, Ernie is open source, ProxyMachine which is the proxy I talked about that’s open, Resque is Open, Jekyll which runs GitHub pages which converts static HTML types of sites to be able to be hosted by our static HTML server, Jekyll is open sourced, because all of this stuff is not really specifically relevant to what we charge for, right, and other people can benefit from using those in different situations so let’s give those back to the community, I mean we rely on so much open source code, you know, Ruby, Rails, Linux, I mean a ton of different Ruby libraries. The whole ecosystem is really rich and allows us to do our job really efficiently because other people have contributed back, and so we have that same philosophy; if it’s not going to impact how much money we make then generally we’ll open source it.
Louis: The other thing, this is bringing it back a little bit, you were talking about very early on you were talking about Ruby and Rails and your decision to go with that and how it in some ways enables you to make very rapid changes and get your new staff up to speed very quickly. One of the things that that highlighted was I think it was towards the end of last year there was the whole Firesheep thing, and I remember being struck at how incredibly fast you guys rolled out an initial sidejack prevention system that I think was then revised to just https everything, but all of that happened very quickly while everyone else on the Internet just was like, oh, this is very interesting, we should maybe do something about this at some point.
Tom: Yeah, that was — I think being able to address stuff like that very quickly is due in large part to how we organize the company which is very—I said we’re 27 people now and we don’t have any managers which allows us to be very flexible, we also don’t have departments, so what this means is that everyone feels responsible for everything that is important; when you start splitting people up and assigning responsibilities to specific things then it’s easy for one department to look at that and say hey that’s this other department’s purview, and well they should be doing it, and that department probably thinks it’s someone else’s purview, and so it’s a lot of shuttling around of blame, it’s very easy to do. One of the things that we have here is just that everyone is working together for the same goal and we all really believe in it, and so when some security problem arises everyone gets notified via the security list, everyone in the company is on that list, everyone gets those emails and we just have a culture of addressing those things very quickly. So something like Firesheep is very problematic for us, I mean that’s a huge thing; our company is predicated on trust that your code is going to be safe, and so we jumped on that and we said hey we need to fix this and it has to be done immediately, we can’t wait a month to do this. And so we had a couple of our guys just jumped on it and they made it happen, which is generally how everything gets done here is someone says this could be a problem here, this could be better, and they’ll assemble in teams of two or three usually and then they go and do that thing. In some cases it’s security and they do it because it has to be done and a lot of cases it’s just what people are interested in working on, it’s what we identify as things that are going to be beneficial to the company and it’s just very organic, there’s not a lot of command and control that we do, so it allows for those kinds of really nice situations to happen.
Louis: It was really impressive to see, you know, you read about this–so Firesheep for anyone listening who’s not familiar was this way of hijacking authenticated sessions over open Wi-Fi and so there was a blog post by the person that’d written this little library and he was just doing it to point out a security flaw in the way that a lot of authentication happens on the Web, and within a day I think you guys had at least an interim fix that would prevent a lot of that kind of hijacking, so it was really impressive to see how quickly you guys–and it was perfectly functional and didn’t impact the site at all, very impressive.
Tom: Yeah, I think it was awesome, the was Rick Olson, Corey Donohoe really jumped on that initially and made it happen, they just — they got in there and they fixed it, and I wish more people had done that because it is a serious problem and it still affects people to this day on other sites that aren’t doing it, I mean running https everywhere is not perfect but it’s workable, and it’s not as slow as everyone kind of doom and gloom thought it was going to be.
Louis: I guess people had that argument from, you know, it was something that had gone unquestioned for seven or eight years because when we first started doing this stuff https everywhere was slow because servers were slow and no one had reexamined that and thought, oh wait, stuff is a whole lot faster now, we can do this and it doesn’t really impact it.
Tom: Yeah, it is good now. Now, it can always be better, there’s still some latency in the SSL handshake we wish we could address, and Google does some pretty fancy things with TCP packets and how they send data back that you can read about on the Internet that are really interesting, stuff that we’re looking into now because, yeah, while it’s still fast it could always be faster and we’re always looking to make stuff faster.
Louis: I guess the last thing maybe I wanted to address sort of quickly was I just happened to cross a few days ago a thread on Hacker News where someone was talking about the role of something like GitHub in I guess programmer employability, and the initial thread was just when it comes to hiring I’ll take a GitHub commit log over a resume any day.
Tom: Yeah, John Resig said that.
Louis: Right. And then there’s this massive thread following on from that of people feeling kind of uncertain about that and like well I do lots of work all day and it’s all for my employer and when I go home I don’t have time to work on other stuff and that should matter as much. What do you feel about the role that something like GitHub has in the way that people look at programmers, I mean so many programmers, all of the developers in the office here on their personal websites there’s a link to their GitHub account because that’s their public face, right; how do you feel about the role that you guys have taken in this space?
Tom: I think it’s really valuable. I mean I know that it can seem hard sometimes, but from an employer’s perspective having open source code available for potential employers to see gives them a way to evaluate you technically outside of an interview, and that’s almost really what we do. The way that we hire people is we identify people that we think are awesome that have either written open source code that we’re already using in many cases, that we know from the community, people that have gone to conferences and given talks, people that are engaging that are really passionate about what they’re doing, and people that have written open source and that do that, they find time, there’s always time available, it’s just how motivated are you to use that time to do things like code. And finding the people that love coding so much that they’ll find the time to do it, those are the kind of people that we want to hire, the kind of people whose code we can already see because that means they love what they’re doing, I mean we all love what we’re doing here at GitHub and that makes the company so much better than it would be otherwise. And so I think it’s really great, I hope everyone that has open source code puts it on GitHub or somewhere visible so that potential employers can see it, it just makes the hiring process so much easier. I mean the way that interviews are done these days at companies is really kind of deplorable, it doesn’t find the right kind of people; you don’t find good engineers by asking them riddles in interviews, I mean it’s not stuff that’s practical to the job, it has no relevance. And most of the time asking them really hardcore architectural types of questions or algorithmic questions is also ridiculous because you’re trying to hire a Rails guy and your ops guy comes in and is like I’m gonna give this guy a run for his money, well that’s not useful, and all you’re going to do is make that potential employee not want to work for you in the first place, but he’s really awesome at Rails, showing him how to optimize seek time on a serial ATA hard drive is nonsensical, but it happens all the time. And so the way that we do hiring and I think the way that a lot of people could be better at it is identify people that are good technically through their code through proven things that they have written, empirical evidence that they are good technically. Once you find those people now it’s just a matter of are they a good fit culturally, and so that’s kind of our two-step procedure; it’s really pretty rare that we’ll talk about really deep technical stuff during interviews because we already know that their code is good, so mainly at that point it’s do you agree with the GitHub vision, are you going to be interested in what we’re hiring you for. And that’s another thing is making sure you’re hiring people who are going to be interested in what they’re doing, that’s huge, just getting people who are going to be interested in what they’re doing.
Louis: Right. So do you feel like — when you talked just now about the GitHub mission do you feel like to some extent that’s part of your mission is giving developers this kind of platform to show off what they’re doing and better their careers as a result of that, is that a goal that you keep in mind or is it just sort of a side effect of what you’re doing?
Tom: Oh, that’s absolutely a goal, and it’s something that we’re working towards. I was just talking to our lead designer today and we were talking about the profile pages, and there are so many things we want to do on that page to make so that people can show off their code easier to say hey these are the repositories I’ve been working on, without you having to anything, it just automatically is there. And so potential employers or whoever comes by and says, okay, I can get a really high-level view of what this guy’s been working on, maybe he has a lot of commit to Rails, maybe it’s some other project that he started himself, those are the kinds of things that we want to make possible and expose to people because showing off what you’ve done, showing off your code, that’s what made GitHub be even possible that people really want to do that, we want to help people show off what they’ve done, that’s something that we’re all about, and any way we can do that better is fine by me.
Louis: Well, you guys do a really great job of it. It’s to the point now whenever you’re browsing around for some open source project or library and you land on a SourceForge page, or whatever, you’re always like aww, aww (laughter).
Dan: I’ve actually disqualified gems from my projects purely because they’re not on GitHub, there’s always an option on GitHub, it’s become the defacto repository for the Ruby world now, especially when you guys started becoming a Gem distributor, as a Gem source yourself, it just really opened that up to a whole new level again, you know, it made without having to deal with RubyForge and whatnot it really opened it up to a lot more people and has resolved in better code. As a Ruby developer all I can is thank you.
Tom: You’re welcome.
Dan: You made my job a lot easier. Cheers.
Tom: Thanks so much.
Dan: No, I mean sort of I signed up just after you guys really hit it big, I think it was around the time that the Rails project switched code hosting over to you guys and it was immediately obvious that, okay, this is something big and it’s actually going to make a difference in three or four years down the track where the Ruby ecosystem is, it’s huge.
Tom: Yeah, it blows me away everyday the new code that ends up there and the project we’re working on and just that we can be involved in making the open source ecosystem and just making people’s lives at the companies that they’re working on, streamlining that stuff to me is — that’s really what I love, that’s what gives me job satisfaction is knowing that we’re helping people build the stuff that’s going to run the future, that to me is awesome.
Louis: (Laughs) sounds like a campaign slogan. Alright. Thank so much for making the time to come on the show today, Tom, it’s been great and keep doing what you guys are doing as Dan said, and then I can definitely echo that, it’s really fantastic and it’s made working on this stuff a lot more fun than it used to be. And I think it’s resulted in a lot of cases in better code, maybe that’s because people know that it’s going to be visible (laughter), they’re a bit more careful. But yeah, thank so much for making the time. If listeners want to find you online where do they go, do you have a Twitter handle or maybe just your GitHub profile?
Tom: Yeah, so you find me on GitHub at github.com/mojombo, and there are some links there. My weblog is tom.preston-werner.com and there are some blog posts there that people can read.
Louis: Very cool, thanks. Dan thanks for dropping by to help us out with this today, do you want to drop some links as well?
Dan: Yeah, the best place is RubySource, we’ve got a few great articles going up this week, always looking for new authors so if you go along have a look and if it piques your fancy feel free to submit us an article and always looking for people to write about new topics, if you’re into Rails let us know.
Louis: That’s great, thanks. And RubySource is on Twitter so twitter.com/rubysource. Alright, thanks very much guys, it’s been a pleasure.
Tom: Yep, thank you so much.
Louis: Alright, thanks! Bye.
Tom: Bye.
Dan: Cheers.
Theme music by Mike Mella.
Thanks for listening! Feel free to let us know how we’re doing, or to continue the discussion, using the comments field below.
Comments