Andrew: Before we’ve get started, tell me if you have this problem. You’ve got a great product, but you’re not getting people to even try it, let alone buy it. Well, the problem is probably that you’ve got too much text on your site. But check out what these startups have done. Here’s SnapEngage, they’ve got a video explaining their product right underneath the free trial button. Here is, SendGrid, right next to the get started button is a video explaining the product. Video, much more than text helps people understand what you’ve created and convinces them to try it and buy it.
And the company I recommend that you turn to for this, it’s Revolution Productions, the same company that did both those startups’ and many other videos. Revolution-Productions, and when you go to their site, revolutions-productions.com, and contact them, I want you to talk directly to the founder, Anish Patel. I want you to tell him I sent you. He’ll take care of you and make sure you have a great video that convinces people to try your product.
Next sponsor is Grasshopper.com, and I want you to think of them as, like, adding superpowers to your phone. Want extensions? You can add it. Want a phone number that catches you anywhere you are? You’ve got it. Want to take your voice mail messages, maybe, and convert them into text? You’ve got it. Anything that can be done with a phone, pretty much anything- I can’t imagine what you can’t do- grasshopper.com will do it in a very user-friendly environment so you can just keep adding features and adjusting them yourself: grassshopper.com.
Finally, Scott Edward Walker is the lawyer that I’d been recommending long before he even paid me for a sponsorship, I don’t even know, Scott, why you keep paying me. I’ve been telling people for years to try you, but you do. So I’ll tell my audience right now: if you need a lawyer, if you’re an entrepreneur, especially if you’re a tech startup entrepreneur, go to the lawyer I recommend, and as you can see on this website, Jason Calacanis, Neil Patel, and many other entrepreneurs recommend, Scott Edward Walker of Walker Corporate Law. All right, I’ve talked too fast and for too long, let’s get right into the program.
Hi everyone, I’m Andrew Warner. I’m the founder of Mixergy.com, home of the ambitious upstart and a place where entrepreneurs come to tell the stories behind their successful businesses. How do you bootstrap a profitable company and get nearly a million developers to sign up? Well, joining me today is Tom Preston-Werner, co-founder of GitHub, a site that allows developer to collaborate on code, and it’s growing and attracting developers really quickly. Tom, welcome to Mixergy.
Tom: Thank you Andrew, it’s great to be here.
Andrew: OK. A million developers, almost. I mean, you’ve got the exact counter on your website. I’m not going to go into the specifics of the number, ’cause it’s so close to a million.
Tom: Almost there.
Andrew: How many developers are there in the world? How big is a million?
Tom: I’ve seen numbers that vary, but the one that I see the most centers somewhere around 15 million, and that would be the number of active, paid, professional developers. And how that number is calculated is a little bit fuzzy, so you can kind of start with that as a beginning point and say, OK, well there’s going to be an additional bunch of students, there’s going to be a bunch of people who do programming-like things, and so, it expands from there. But the number is really not as huge as I thought it was, according to this report. But, yeah, we’re starting to get a lot of developer attention, and one million people is not an insignificant portion of developers in the world.
Andrew: These guys are working on your site, counting on your site for their work. We’ll get into what they’re doing on the site. Let me ask the big question that a lot of people in the audience are wondering. What’s- I know you and I discussed how you’re not going to reveal specific revenue numbers here in the interview, but can you say- are you guys doing over a million dollars in revenue?
Tom: Yes, absolutely. I think we cleared one million in revenue in 2009, so we’ve grown well, well past that. We’re doing extremely well money-wise.
Andrew: And that’s annual revenue, right?
Tom: What’s that?
Andrew: Annual revenue, not overall?
Tom: Yes. Annual. Annual revenue, yeah. So, right now, the company’s 35 people; we’re growing, we’re adding- we started this year, to give you some idea of the growth patterns that we’re experiencing right now, we started this year with 14 people, and we just hired our 35th, and we’ll be adding four more this month.
Andrew: And how many people are you adding, how many registered developers are you adding to site every day?
Tom: The numbers usually clock in about 2500 new user sign-ups per day. That number is interesting. It’s very consistent. During the weekdays, that number is almost always exactly the same. Which is really interesting. I think it speak to the power of statistics, that things really do average out. As people are using Open Source, they’re coming to GitHub to get things like jQuery, MooTools, Erlang Operating System, Closure is hosted on there, Ruby on Rails, all of this great open-source software that people use on a daily basis and want to contribute to, they end up at GitHub for that. They see it, they’re browsing the code there, they’re looking through the issues, they’re seeing, hey, what’s a pull request? They start to get drawn into that world and it inevitably leads to a signup so that they can start participating in this new world of collaboration that they’ve never seen before.
Andrew: You know, before we answer the question of what’s a pull request, do you have a simple way to explain what GitHub is, for someone who’s non-technical?
Tom: Sure. You could think of GitHub as a bit like Wikipedia in that you have a bunch of people coming together, working on the same document, to make it better, to make it work for them. In the same way Wikipedia allows many people to edit the same file and keeps track of who made what changes, when those changes were made, and allows you to go back in history and see exactly what that set of changes was to get to the current version. GitHub is like that, but for larger source code projects. So people who are developers write codes and they’re not just working on one file, they’re working on a bunch of files. So really a project is like a whole Wikipedia of content.
Tom: In order to do this people need to synchronize those files to their local computers to work on it and then get them back up somewhere central to share them around and something to act as a collaboration point. So the software called Git, which is a version control system created by Linus Torvalds, that is what we built GitHub around, so that’s open source and preexisted us. We thought it was pretty cool, but it was hard to share those repositories, so we built a website that lets you host the repositories on GitHub, on the Web, handles all the permissions around it, lets you do open source stuff for free, closed source stuff for companies and whatnot you pay for, and then we just built this whole collaboration model on top of Git. Git really makes that possible, so in that sense it’s like Wikipedia.
Andrew: OK. I’ve never used it directly and I don’t know I could do a better interview with you about the technology behind GitHub and the way the developers use it. I don’t think I could do a better interview on that than others already have. What I’m going to focus this interview on is the business behind it, where the idea came from, how it evolved. How do you get customers? How do get someone who is a stranger to even bump into your site and then how do you pull them in to use the site?
So, to understand how you got here, let’s go back in time and how about we talk about the business you had before GitHub, to get to know you. You’re the found of, actually, why don’t you say it? What’s the business you launched in 2007?
Andrew: Oh, excuse me. No, wasn’t 2007 Gravatar?
Tom: 2007, well it was well before that. Here’s the thing about Gravatar. Gravatar was never really a company. It was more of a side project that kind of got out of control. So I started that around 2004 probably. I was working for myself, doing consulting, doing a lot of graphic design, website design for various clients down in the San Diego area and this was the time when Web logs were starting to get really popular.
People like Dan Cedarholm, The Man in Blue, Stopdesign, all of these guys were doing semantic Web kind of stuff, or just like semantic markup, right? Jeffrey Zeldman, I read that book and it changed my life, Zeldman’s book that so many people have read and it was like, oh wow, the semantic markup really does have value, so this is the way of the future.
So I read those books, I started blogging about design and other things I was doing and blogging was just exploding at the time, it was becoming huge for the first time ever really. I said, I want to be a part of this ecosystem. I want to contribute somehow and make a name for myself with the blogging, so I tried out a bunch of different ideas.
I did some templating for movable type, re-designed my site all the time, was active in writing blogs. My friend, Rob Cameron and I created something called WacFR, which stood for Werner and Cameron, his last name is Cameron, Werner and Cameron Flash Replacement, which is a precursor to SiFR, which was the Shaun Inman Flash replacement, which kind of became the de facto standard of how people replaced the HTML titles in blog posts with any font that you wanted and it used flash to do that. It was a precursor to that, and he built upon that. He said, hey, [??] is pretty cool, but it doesn’t do resizing very well and it doesn’t do line overflow, I think, very well. There was a couple of things. It’s a little fuzzy now as it was a long time ago.
We did some stuff like that and started to get a taste of what it was like to be participating in this world. And then, one I was… I worked from home, and so I would kind of sleep in late, and I would spend an hour in bed and just think about stuff. I’d think about ideas. I’d stare at the ceiling, and I’d just think about how I might do this, how I might contribute to the blogging ecosystem in some way.
An idea came to me which was very simple. It was really just, it’s cool to have avatars on web forms, so on every form you went to you had a little picture of yourself up here and then your comment was over here. It was really cool because you could very easily see who was making what comment. This was something that web blogs didn’t have. I said, “Well, what if there were a way for your avatar to follow you around between web blogs.”
What is common that people have that ties them together, no matter where they go, and that’s clearly your e-mail address. That is the one thing, really. Now, maybe it’s your Twitter or your Facebook, but e-mail is so much more solid. It’s been there forever. What if you attached somehow a look-up where you can take a person’s e-mail address and then make a call to some service and then get back an avatar of a certain specific size, just like a phone book directory where you get someone’s phone number by looking up their name, right?
So, I came up with that concept. And then, everything just tumbled from there. I wrote the whole thing in basically a week. I wrote it in PHP back then, and really all it was was you take the MD5 hash which is just a one-way hash so you couldn’t extract the e-mail back out of that hash. It makes it so that you can’t spam people if you have a bunch of these MD5s, but it means you pretty much guarantee that you have a unique string that corresponds to their e-mail address.
What that lets you do is that every single blog that you go to has a plug-in or something that takes a person’s e-mail address because you’re generally putting that in anyway. In a comment form, it would be like what’s your name, what’s your e-mail address, and then what’s your comment. Usually, they wouldn’t display the e-mail. They just wanted it for whatever, right?
You take that e-mail address, and the plug-in would just run through MD5 and then make a service call to gravatar.com with that little string there, and then it would send back the response which would just be a small 80 pixel by 80 pixel image. And it was always 80 by 80.
I said, “Let’s just do it and make it standard. That way people can design their templates and stuff very easily, so you get back this little image, and then people started… I wrote a couple plug-ins. I wrote one for WordPress, one for Moveable Type, one for Text something. God, that was so long ago now. I don’t remember what they called it. I wrote a bunch of them, and I started trying to spread it around, like I e-mailed Dan Cedarholm, and I e-mailed probably Shawn Inman. I was like, hey, I made this cool Gravatar thing. You can create avatars on your web page, and people can sign up for it and upload their image, and it would be awesome. It will go all over the web, and everyone will have it on their web blogs, and it’ll give us a stronger sense of community in the web blog commenting ecosystem because I was also really big into commenting on blogs.
It’s like, I commented on your blog and said something interesting. You should come and read my blog, too. So, I did that. It started very small, and a few people started using it. And then, the beauty of that system though is that it’s perfectly viral. You see it on a web page, and if you have a blog yourself, you’re like, how is this guy doing these avatars?
Tom: This is pretty cool. I want my image to show up there.
Andrew: If I’m a user, I see that there’s just a generic image for myself, but everyone else on the blog has real pictures, real avatars. I want to figure out how they do it, right?
Tom: Exactly. You want to strengthen your brand on your Internet when you’re commenting. It’s to your advantage.
Tom: Let me ask you something. I’m trying to understand the people who I interview and the motivation behind what they do. I don’t understand the motivation behind creating the projects that you’ve described up until now and Gravatar. I know that when I even comment on Hacker News or someone’s blog, I want recognition yes, but recognition towards something, recognition towards having people eventually come to my site and either become followers of my work or become customers of mine. Even that little thing doesn’t take much effort. I don’t just do it. There’s that kind of mental processing going on.
What about you? Beyond just saying I want to put this stuff out in the world, what’s the motivation?
Tom: Well, the motivation back then was really to just be a part of it. I didn’t want to make money from it. Honestly, Gravatar, I never even imagined monetizing, not in the early days. Not before I started spending a bunch of money on servers and was like, “Oh, crap. I sure wish I could monetize this somehow.”
Honestly, it was just a cool project. All my life, I’ve been interested in cool projects that are useful, that people will enjoy, more than extracting the most money out of those ideas. That’s a little bit naive in that, if you have an idea that becomes popular and you don’t have a way to make money from it, now you’re in a pickle. That happened with Gravatar.
But at the time, I just wanted to be part of it. I just wanted to participate. I hadn’t done much of note, not really, back then. When you’re young, a lot of people want that. It’s not about money; it’s more about recognition, about leaving your mark on the world. It’s only later that people start to be like, “OK. I’ve gotten a little bit of success, now let’s really just pump the money out of this thing.”
Andrew: OK. You see that your servers are getting more and more expensive. You decide at some point to add a revenue model to it. What was the revenue model?
Tom: For Gravatar?
Andrew: For Gravatar. I don’t want to spend too much time on Gravatar, but I do want to get the back story before we go into GitHub again.
Tom: The only way that I ever even tried to monetize Gravatar was through premium accounts. A premium account got you multiple avatars. This was much later in Gravatar, when I had redone the site. You could get multiple avatars and then easily switch between them. It wasn’t much.
This was the problem. I wasn’t thinking of it in a long-term business way, so the monetization strategy didn’t get you enough value. People didn’t really pay for it; nobody bought these premium accounts. A few people. For a long time I survived just on donations. I said, “Hey, I’m paying a lot for these servers. You guys like the Gravatar service . . .”
Andrew: I remember that.
Tom: I was like, “If you would like to donate some money, that would help me keep the servers going.” I got a fair amount of donation money through that, which was awesome. People really cared about it.
Andrew: What do you mean? How much donation could you get from people who don’t have to pay anything, and just get keep freeloading if they want to?
Tom: It wasn’t a lot. I think it might have been a grand, maybe. But it was enough to run the servers.
Here’s another thing that’s interesting about not making a lot of money on something. It makes you a more clever person. When you don’t have money to throw at a problem, you have to come up with an intelligent solution to solve the same problem.
Andrew: For example?
Tom: For example, with Gravatar, it was that I basically have no money to spend on this except the money that I’m making, and a little bit of donation money. How am I going to keep serving the increasing demand on these avatar requests, while not driving myself to the poorhouse, just because I’m trying to make this idea not explode? I mean explode in the wrong way, in the way that your servers are crumbling.
So, instead of just buying more servers and setting up that same architecture across all of them and being like, “OK. I’ll scale with money,” I redid the entire architecture of Gravatar to produce static images that were then served with lighttpd, which is a web server much like Apache, but super-fast; and used a language called Lua, with mod_magnet, which is a plug-in for lighttpd, to script some intelligent commands into the normal processing of the request itself, to then look up those images.
You could change the size; you could request a default avatar, at that point, if a person didn’t have an avatar; and a couple of different little tweaks that you can make on it. It was pretty complex to do it that way, but it required time. I traded spending a bunch of money on it for spending a bunch of time on it.
I think that was a good exercise, especially doing GitHub now. We’re bootstrapped; we haven’t taken any funding yet. It’s been great, but it means that we don’t have this padding of millions of dollars in the bank account, in the early days, to where in order to scale, we were just like, “Let’s throw money at it,” and buy these big fancy NetApp file servers and all this really expensive hardware.
Instead, we solved the problem in a way that let us scale horizontally and more cheaply, because I had experience in doing that previously when it was absolutely necessary.
Andrew: The date that I had earlier, that I mentioned earlier, 2007, that’s when you sold to Automatic, the guys behind WordPress. Why did you decide to sell?
Tom: I wanted to be done with Gravatar. Like I said, I couldn’t figure out a way to monetize it, number one. I was losing money on it every month. Every month, I was losing like, a couple hundred dollars on service fees. It was just out of pocket. Number two was I was now full-time employed up here in San Francisco at a place called Powerset that was doing semantic search, so a search that would try to understand the grammatical structure of what you were searching for and then index in the same way.
Tom: Crazy, cool stuff. I met all kinds of cool people there, but I was doing that full-time, and I was also trying to keep Gravatar running. It was just getting super popular. Everyone was using it, and the servers were struggling, and I had to do the whole infrastructure. It just felt like it was going to be a never-ending struggle that would just end in my own poverty. And the other problem was that I don’t have the contact that I do now, like I wasn’t hooked into the VC world. I didn’t feel like I could just go out and raise money for it. That seemed impossible. That seemed like an idea that was absurd to me at the time. And so, I started looking around for some people that might want to buy it, and I don’t even remember how I hooked up with Matt and the Automatic guys, but I had actually talked to them when I was back in the San Diego area.
I came up here to have a lunch meeting with Automatic and also ended up interviewing at Powerset on that same trip. It was a very successful trip. Automatic had turned down Gravatar at the time. They were like, this is cool, but we don’t actually need it right now. So, that was disappointing, but I kept working on it. When I had moved up to San Francisco, I kept working on it. It was draining; I would just work on it.
People would get really angry about it when it was down because it would have some down time, and I’d be like, relax, I’m working on it. It’ll be up soon. It’s going to be great, and the new version’s coming. I had been working on that new version for a long time, and some of the comments on the blog posts were just really disheartening. They were just like, you’re terrible, your service is horrible, you ruined my life, just like really dramatic stuff. People were personally offended that Gravatar was down, and they couldn’t use it. They felt helpless, and it was like they had come to rely on this service. Even though it was free, people had gotten so used to free stuff, like with Twitter.
The same thing happened with Twitter which was Twitter was free, Twitter was having scaling issues, Twitter was down a lot, and people just hated them for it, like just hated them. I can understand how they must have felt because I felt the same way with Gravatar, which was just, why am I doing this if all that’s going to happen is people are going to write me hate mail when the service isn’t running as well as they would like.
It was a lot of things that built up. I had been doing it for a long time, and I didn’t see much of a future in it the way that I would have wanted to do it. And so, I just wanted to off load it. I just wanted to be done with it so I could work on something new. I just wanted to move to something new, but I didn’t feel like I could do that while Gravatar still had its strangle on me.
And so, then I contacted Automatic again a little bit later, We met up, and they were like, you know what? This is actually perfect timing. We could integrate it with WordPress.com and have it be its own thing and go across all these properties to tie them together, And then, they did acquire it at that point. That was in late 2007.
Andrew: That was nice that every time you added a comment to a wordpress.com blog, your gravatar, the avatar you put up on the Internet just once, showed up over there. And then, of course, other sites were using it, too, like Stack Overflow. If you added a question or answered one, you didn’t have to upload a new image to them. They just grabbed it from you guys.
Andrew: What did you sell for?
Tom: I am not allowed to say that number.
Andrew: Can you give us the neighborhood, the way that you did before with the revenues? What’s the neighborhood?
Tom: The neighborhood? I was once told by someone that when you sell a company, there’s four levels of money that you can make from it. When you sell a company, you can get new shoes, a new car, a new house or a new life. And so, I guess Gravatar was a new car.
Andrew: All right. I like that.
Tom: And take that for what you will, whether you think that’s a Pinto or a Maserati. I’m not going to say.
Andrew: Let me ask you this before we get into GitHub. I read on your blog that you said, “Before you launched GitHub, you had a lot of debt. Now, you’re a developer, right? You had an exit. You were working at a great company at Powerset. What kind of life are you living that you end up with debt? I’m not putting you down. At the age you were, I had debt, too. I’m just wondering, where did it come from? What was it?
Tom: Sure. Well a lot of it came from…so for three years I worked for myself down in San Diego, right? Doing consulting. The thing about consulting is that, when you’re well known, you can make a zillion dollars consulting. When you’re not well known, well, you don’t make anywhere near a zillion dollars consulting.
Tom: So really it was, I wanted to do my own thing down in San Diego. I wanted to run my own business. I wanted to be my own boss. I wanted to take my own clients. I wanted to run the business myself, and it was a struggle. It was a struggle to find clients that needed work. It was a struggle to do all of that work by myself. You know, it was just really hard to make the margins that one needs in order to really do well. Also, at the same time, I had a very expensive- I have an old Jeep CJ5, 1978. It ends up you end up shoveling quite a bit of money into a project like that.
Andrew: I see.
Tom: So, on one hand, while I was not making a ton of money doing the business stuff, on the other hand I was like, ‘ahh, I want to do this other stuff’. So it was just, irresponsible financial management, I think, would be the [??].
Andrew: You were married at the time, right?
Tom: Yeah. I got married in 2006.
Andrew: You also talk about on your blog how, we’ll get to it in a moment, how you had an opportunity to make a lot of money, and you went to your wife and you said, ‘I think, you know, we’ve got that, but I also have GitHub, and I think I’m going to go towards GitHub’, and I thought, wow, that it’s impressive that you were married to someone who could support that move. But is sounds like even earlier than GitHub, she was supportive of you going into debt to build up your business. Describe that kind of relationship. I hate to go too far off of the path of the thing we started on, but that is important. Right? You end up married to someone who needs security and you can’t go and start a business and come home at night, feeling comfortable with it, and feel supported when things aren’t going strong, and it damages things. So, tell me about that relationship, and why she’s so supportive.
Tom: It’s great. My wife Theresa is great. She’s an anthropologist. She’s doing her PhD work out of Northwestern University in Chicago. She’s always been really supportive. It’s just, she knows me, and she knows that I need to follow what I think is interesting. And sometimes, that’s going to be not the greatest thing in the short-term, but I think she trusts me enough that in the long-term, she knows, that things will be OK. And, you know, we never suffered. Well, that’s the great thing about debt, right? Is that while you’re making a negative net income, in the long-run you’re like increasing the amount of debt that you have, but you’re still living a decent life. Right? You’re not out on the street. So that’s the beautiful thing about that, and also the really dangerous thing about that.
Andrew: I see.
Tom: So on one hand, it was like, yeah, financially we’re not in the best situation we can be in, but as long as, as long as it’s not going to cause us to be destitute, then she kind of went with it. And I think that’s, I think it just comes from trust. It comes from knowing that eventually, things will work out, and I guess, just, hope. Right? Hope that things will work out. Sometimes, you have to fool yourself, right? But, no, she’s always been super supportive, and when the time came to make a choice between staying at Powerset, which was being acquired by Microsoft, or leave and do GitHub full-time, you know the Gravatar thing helped a lot, because that kind of took care of all of the debt.
Andrew: Oh, I see. It did?
Tom: That I’d incurred from… yeah, pretty much. That I had incurred from the, previous, like, five years.
Tom: And so, that put me in a much better position. So that was nice. That helped a lot in that decision. But again, it was…I was just like, I said, ‘I think that GitHub is the way to go’. Microsoft was offering me a fair amount of money over the next three years, and that’s attractive, but at the same time, nothing is as attractive as running your own business.
Andrew: Where did the idea for GitHub come from?
Tom: The idea really came from frustration. It came from being frustrated about wanting to use this awesome version control system which was Git, which had started to just kind of roll around in the Ruby community, and I’m a Ruby developer primarily, and so I hung out in the Ruby groups here in San Francisco. At Powerset one of my friends there, Dave Farrem, he introduced me and a bunch of other people to Git which was this kind of esoteric, weird virtual control system. It had these branches that worked really well. It was distributed and the command set was kind of complicated. We started playing around with it and I was like, this is crazy. The system is so unlike Subversion but I can sense that there’s some power in here. If only I could figure it out.
Over the next five or six months, whatever it was, at the Ruby meet-ups people would talk about. They’d be like hey, I’ve started using Git for these projects. You’d be like OK, what does that mean? Where do you put that in order for other people to get it and share those repositories? Really no one was using it much for productive work, for practical things, because it was really hard to share.
In order to share a Git repository back then really you had two ways that you could do it. You could set up a Lenox server and give people user accounts and be like OK, you log in here and the repositories over here. Maybe you run their web front end which is just, like, terrible. That’s one way you can do it and the other one is there was a hosting service called Repo, Repo.or.cz. Which was basically just that really terrible front end that comes with Git that was just running and had some additional stuff that you could sign up and have user accounts and do stuff.
It was so primitive and done so badly, no disrespect to the guys that were running it. They just weren’t web people. These were Lenox people trying to run a website and it just wasn’t right. Like, if you wanted to reset your password you had to email them and they would manually reset your password and email you. It was terrible and it was slow and it looked like crap. It was bad.
Andrew: Can I say this, by the way? To the founders of that site, if you want to do an interview here I’d love to find out what happened behind the scenes there. I’m sure that there’s more to it than we can figure out on the outside. I wonder if they’re kicking themselves for not having developed it further or if it was just kind of an aside project like Gravatar was for you. OK.
Tom: I honestly don’t even know. We’ve talked to them a little bit. The problem was really, mainly, that they weren’t web people. They were Git people that were trying to make this thing happen on the web and they just didn’t know how to do it well. These guys worked on Git Core. These guys are awesome. They’re awesome at working on that stuff and less awesome at working on web stuff. That’s OK, right?
But what I am, and what the other founders are, is good at working on websites. This is where we come from. This is our background. We’re very good at websites and less good at the hardcore Linux, Git kind of stuff. That seemed like a tractable problem. If we could make this website we could probably figure out how to integrate all this back end Git.
Andrew: You’re saying we. Who created the first version of the product?
Tom: The first version was Chris Wanstrath and myself.
Andrew: You were designing the front end, he was designing the back end. Is that right?
Tom: We kind of split it like I started working on the rooting library called Grit that lets you access Git repositories programmatically from Ruby. I worked on that and then I worked on designed the UI, the interface, the web, kind of what it was going to look like. Then Chris would take those pages, the mock-ups that I did in Photoshop, he would cut them up, turn them into HTML. Actually, I think I did a lot of the HTML and CSS. I guess I did most of the HTML and CSS, to cut them up. Then he did all of the rails. It was written on Ruby on rails and still is. He would do all of the rails work to hook the front end up to the back end and deal with any of the caching and all of the database stuff, and all of the rest of that middle. I did kind of the top part and bottom part and then he just filled in that middle part.
Andrew: You mentioned how you guys just met at an event, I Can Has, whatever, was the name of the event. You say on your blog, I don’t even remember.
Tom: I Can Has Ruby.
Andrew: I Can Has Ruby is the event. You guys just meet up and decide we’re going to work on this project? That’s another thing I don’t get. Don’t you sit down and say look at how big this can be? We’re going to collaborate on this, be 50-50 partners? Mention how the break up will be, how the ownership will break up? Have vision for where it will be in the future or who your customer could potentially be? You don’t do any of that. Why not?
Tom: Not really. Again, it was because we just wanted to do something cool. This is a problem that some of us developers have in that we will very much disadvantage ourselves by spending a lot of time on something that may or may not be worthwhile, in the long run, simply because we can try out new ideas. That’s also the beauty of programming; in order to go from idea to prototype can be very short.
It wasn’t like we sat down and were like, “We’re going to quit our jobs and we’re going to build this company, and here’s who the clients are going to be, and here’s the revenue split, and here’s how the equity’s going to be.” It wasn’t like that. It was just like, “Hey, let’s just do this cool weekend project, and maybe it will be awesome.”
That’s all it was. That’s how it started. It never started out as this big thing, because we stayed doing what we were doing. I kept working at Powerset. Chris was working at a consultancy of his own, called Err Free, with PJ, who ended up being the third co-founder. He came in very shortly after we started.
They were trying to do another project, called FanSpam, which was a family-oriented messaging kind of thing, to keep families together, so they could email back and forth, and have message forums and stuff. Those guys were doing that, and they were making a little bit of money through that, and then through doing standard consulting for companies.
While we were doing GitHub, we kept doing what we were doing on the side. We just worked on it nights and weekends.
Andrew: I see. Maybe I’m trying to take away too much from these interviews. Sometimes, I just need to let the story unfold and figure out where the usable information is later on.
That’s why I’m asking questions like: if it just came to you, how does someone who’s watching us right now follow in your footstep? How do they say, “Hey, this guy created a great company that’s influencing a whole industry. I’m willing to put in the work. I’m willing to learn from his experiences. What do I take from this that I can use in my business, in my life?” What do you say to that, before we continue with the story?
Tom: I think it’s not so difficult as you think. For me, it has always been just “What do I find frustrating or lacking in the world, and how do I fill that hole?”
With Gravatar, it was the idea itself that made it compelling. It was, “Holy crap. You could tie an avatar to an email address, and put it on any page on the Internet.”
You have that little thought in your head, and then, all of a sudden, you can go and write that system. Whether it will work, and be popular or not; who knows? That’s a lot about execution, and who you know.
It was more sophisticated with GitHub, because I learned a lot from Gravatar. It wasn’t 100% like, “Hey, look at this cool side project!”
In the back of our heads was, we think Git is going to be huge. Let’s be there when it is. Let’s start this now so that if, as we predict, Git will become super-popular–and we think it will because of things like branching, and you can commit offline, and it’s distributed, and super-fast–when it becomes popular, if we start building our site now, when nobody is using Git, and we just do it as a side project, because it’s not time critical right now, so we don’t have to blow it out all right away–let’s just do I on the side. If we do that, and our prediction is correct, then let’s make sure we have a business model to make it sustainable.
That’s what I learned from Gravatar. If you’re going to do a side project that you think might become popular, then you’d better damn well be able to make money from it. Otherwise you end up with a Gravatar, where you just don’t even want it anymore, and now you’ve got to do something to get rid of it or otherwise deal with it somehow.
That was also part of the inception of GitHub. We are going to charge for this thing; it’s not just going to be this free service. Let’s figure out how to do that. We talked about that over the next several months, after we started working on it. What is the pricing model going to be like? Are we going to charge for people to use it for open source? Are we going to charge companies? Are we going to charge on a subscription basis, or a one-time fee? There’s so many questions.
In retrospect, it seems like we did the obvious thing, but we talked about it endlessly, for days.
Andrew: Let’s talk about how you made those decisions. You knew you needed to get revenue somehow, so you could afford to focus on it. You weren’t sure whether to charge a one-time fee or monthly fee. I’ll ask you in a moment about who to charge. How did you decide to do a monthly fee instead of a one-time fee?
Tom: That one is more obvious. If people are going to be using your service, people are already accustomed to paying subscription fees for hosted-type, SaaS-model services. It doesn’t make sense to give us a bunch of money and then be like, oh no I can use this forever. What does that mean, what if you use it, what if you need more of some resource, what if you have more people that are using? Whatever, you need some way to be flexible on that account.
So really the subscription model seemed obvious, it was like it’ll be a subscription model and then there was no more said about that. To do it monthly that’s easy, because the account sizes — the costs were going to be pretty low and people had credit cards. Initially it was going to be mostly individuals and maybe some small businesses, so doing a monthly credit card type billing situation is better for us because we get our money every month on a very predictable basis and it’s good for the users, because they’re just like, oh $7 a month, no problem that’s cool. So the subscription part of it was very simple that was an easy decision.
Andrew: So, knowing who to charge and what to charge for, how did you come up with that?
Tom: That was much more difficult. A lot of it was around who we were going to charge and a lot of it was around how much, so those were both of the parts. It seemed after some discussion, it seemed silly to try to charge people who were using it for open-source stuff and we really wanted to do open-source stuff, that’s why we created GitHub initially, because we, Chris and I were working on a project in Git and we had it up in Repo and it was just terrible. So we wrote to Hub to replace that to use it for open-source so we could collaborate on this open-source stuff. We’re very much in the open-source community, had all kinds of open-source code, knew all kinds of people doing open-source, and one of the really big things we wanted to do was make GitHub really great for people to work on open-source.
So, if we’re going to do that then are we going to charge those people? We said no, because that would mean that people aren’t going to use it for open-source, right? That is what that would lead to. You’d be like, oh, I got to pay $7 a month to work on open-source stuff, no, thank you very much. We said, OK, let’s consider that an advertising expenditure, really having open-source on the site is, you can consider an advertising cost. It costs us money to do that, to host those repositories, those projects, and all the issues and everything around it, but it means that a lot of people are going to be coming to the website to look at, clone down, collaborate, and read that code. We can live with that trade off.
Now who does that leave? How are we going to make money on this? How do most companies make money? They charge businesses that’s the easiest way to make money. It’s hard to extract money from individuals, it’s very easy to extract money from companies. So let’s make the model be, we charge for privacy. If you want your repositories to be invisible to everyone else except the people you give the permission to, then you will pay us for that privilege.
Then the discussion becomes around which metrics do you base the payment levels? There is a couple of different ones you can consider, it can be like the number of repositories, how many people are allowed to see that code, disk space usage, number of commits you can do, there’s a bunch of different metrics, how you could cut it down and make the different plan levels and we wanted plan levels seem obvious. You have a subscription service, you have multi-plan levels very common scenario and we decided we didn’t want to be just premium disk space, being premium disk space is a bad proposition. You don’t want to be like, oh $7 a month for 50 megabytes of disk space that’s –
Andrew: Why not? Someone actually on Hacker, really ripped into guys for charging so much. He said the amount of disk space that he is using on your system is so small compared to what he’s charging, that you guys are just being outrageously expensive.
Tom: Right. Here’s the thing, if you are, here’s the reality of it, when your putting your Git repository up on GitHub that is almost completely unrelated to just storing your bits of codes somewhere. That’s not at all what we’re about. That is one tiny sliver, one very tiny sliver of what GitHub is about. GitHub is about a collaborative platform on top of Git that allows you to work on source code together. It’s not code back-up, it’s not EC2 block storage, it has nothing to do with that in that repositories take up disk space is almost incidental to what we’re doing. If you pose your business as oh, we are some mark-up on disk storage, you’re never going to make any money also –
Andrew: Why, because disk storage is so cheap?
Tom: Well, because you pose yourself in terms of disk storage and everyone knows disk storage is cheap, or at least they think it is. Now disk storage, for us, is not cheap. The type of disks that we have to buy for our file servers–that costs real money, because everything we do on the website is about getting Git information off of disk and onto your screen, or onto your local computer, as fast as possible. We buy very expensive file server hardware to be able to do that.
For us, first of all, it is more expensive than people would think. They’re like, “Oh! EC2 blocks storage is only two cents per terabyte,” whatever. I don’t know. They get in their minds that your service is only Worth, “What’s your premium on top of disk space? It must only be a 100% markup, right? That’s insane! That’s a lot of markup on disk space, so I should probably only pay you six cents per gigabyte or something.”
Guess what? Git repositories are very effective at storage, so now you’re going to be like, “I have a thousand repositories on your site that only take up 200M, and I’m paying you six cents a month.”
There is no multiplier that you could put on top of disk space that would be any kind of reasonable number for us to run a business.
Andrew: I see. You had to reframe it. I understand how that frame doesn’t make sense. How did you pick the right frame?
Tom: At first it was mostly just an educated guess. We want to pose it in terms of repositories, because that’s a very easy-to-understand unit that is not hard drive disk space. In the early days, we did actually put disk space numbers on the plan accounts. We removed them because that’s not what anything is about.
Andrew: That’s like me charging for a course based on the disk space that it takes up, not based on how useful it is, how much work went into it, what’s on there.
Tom: Exactly. That’s like buying a car based on how much it weighs. It’s irrelevant. That unit of measurement is there, but it has nothing to do with the end product.
Let’s use the one I used before. You could have a Pinto and a Maserati, and maybe they way the exact same amount, but guess what? One of them is definitely better than the other.
So much more engineering, and time, and effort, and skill; the user experience of driving a Maserati, and all of the cachet it gets you; everything that you. That’s where the value is. That’s the value; that’s what you’re paying for. You’re not paying for pounds of steel.
Andrew: I want to understand more of the business. Let’s talk about the product first, and then about how you got people in the door, and how you marketed the product. The first version of GitHub; after you launched it, what did you think, “Boy, we have to add this,” or, “Boy, we made a real mistake by adding this other thing over there.”
Tom There’s two really great things that we did. This is not quite an answer to your question, but I think it gets there. There’s two decisions that we made that were fundamental to what GitHub is today.
Number one is, let’s add social features: following users, watching repositories, getting a dashboard feed of what’s going on with those repositories and those people. Just building in very basic social features similar to what something like Twitter has.
Let’s add on a social layer that’s not super-deep. It doesn’t have to be deep; it just has to get you involved. It just has to give you access to see what’s happening on the projects that you care about. That was the number-one fundamental thing that we did that was new.
Number two was the URL structure. Our URL structure on GitHub looks like github.com/username/repository. That’s much different than what all of the other hosts at the time were doing, which was whatever.com/project. What that means is that people, all of a sudden, feel like they can upload whatever code they want because it’s namespaced to their user.
You don’t have to get permission from us in order to put that code up. On other code-hosting sites, you would have to propose that you will create a repository named something. Then the administrators would look at it, make sure it’s not spam, make sure it’s whatever and that you’re awesome enough to have that top-level namespaced thing, because you’re going to use up a very valuable top-level namespace. You had to go through this permissions process, and when you did that you had to feel like whatever you are going to put up there was important enough to consume a top level namespace. So now developers get into the mindset of, oh, only my really important projects go on Sourceforge or Gluecode or whatever, right? Because you are using up a top level name space and there is this application kind of rejection thing that you have to face. Somehow we did was screw that, put up whatever you want. It’s your user namespace, that’s what it is the person’s [??]…
Andrew: So make it easy for them to add to the site, and encourage them to add more and more.
Tom: Yup, yeah…
Andrew: I see.
Tom: … and to also what their friends are doing so that people start, you see something new come up, you go investigate it and maybe you want to contribute to that.
Andrew: I see.
Tom: And so let’s make that easier too and that’s where all the collaboration stuff comes into place.
Andrew: I see, OK. The marketing then, I understand the product and I didn’t recognize the value of what you just talked about. When you are talking about your [??] structures, where is he going to go, is it like an SEO thing that he is about to reveal to me? It seems so, it doesn’t seem as significant as I am realizing now it is. All right, so what about the marketing, you are saying that you are thinking that, you want someone to come into the site and find different hooks to get them engaged. What are some of those, and how did you figure them out?
Tom: I think the biggest one is just having a ton of open source on the site. That is the number one most important engagement advertising thing that we do. Because when you have a product like jQuery or Ruby on Rails, that you are hosting the code for, zillions of people are going to search for that code or what documentation or whatever. If they want to see that code, they are coming to GitHub, and when they do that they are seeing a site that’s nicely designed. So they are not, you know, they are not shocked into leaving by how horrible it looks, which many code hosts have a tendency to do, because we are developers, and developers often don’t think about design. And that is something that we really are trying to do different is really focus on design, like, really make it usable and really put the time and energy into those usability UX decisions.
So you come to the site, you see things, you can find the code, and here is another thing, when you go to a project, when you go to github.com/jquery/jquery, I think it is the URL, then you see the code, the first thing you see is a code listing, you see a listing of files and then below that you see the readme. And that is another thing that we did that nobody else did at that time was show people the readme. Show them the code, and show them the readme. Get them involved in the code…
Andrew: Oh, the readme file, that describes what the code is.
Tom: The readme, yeah, yup, yup. So the readme just contains something about the project, maybe how you install it, how do you contribute, what the licenses maybe, stuff like that. So that you don’t have to click an additional link in order to start reading immediately about what that project is and all of this is designed for developers. So if you are not a developer and you go to GitHub, you probably will be very confused, because you see a list of files, you don’t, you know, there is a like a download link up here, you are just like, ‘Oh my God, it’s source code, I don’t, how do I install it, how do I, how do I download my mp3s?’, you know. And so it is very much designed for developers and we have stayed very focused on that. We haven’t deluded it with lot of more frilly user, user centric kind of things, like, if you make the Wiki page the top most thing that people see, well, now you got to fill that out, it’s going to be, that’s going to be more user centric than developer centric, like the end user, the consumer right? And so now you have to dig through to find the source code, like another code host. You have to click five or six links to even see a single source code file, and GitHub does the first thing that you see and developers really appreciate this. They are like, ‘Wow, finally, a tool that’s designed for me instead of the end user.’ Like this is my playground. End user…
Andrew: How do you know that?
Tom: … stuff should be over here.
Andrew: You keep mentioning design and you keep mentioning how the site is meant to, into it what your, what your developer users need. How do you know that? When I understand you are developers, so you can develop something for, you can design something for yourself, but, that doesn’t seem like it would be enough. Is it? Because, we are all, even though we are similar to other people we are all individual in what we want, and what we want maybe completely different from others, so what do you do?
Tom: Well it’s, let me tell you, it’s challenging, and we have to make decisions that are going to exclude what some people want. But that’s, you just have to. If you are going to build a product that people really love, then you are going to have to cut out a lot of the crap that some small percentage want desperately but really focus on the things that are generally applicable.
Andrew: So, how do you know what’s generally applicable?
Tom: How do we know?
Andrew: Yeah. Surveys, reader interactions, something else.
Tom: No. Mostly we just, mostly we just talk about it internally and we use intuition. You know, what do we want? What do we think is most important? If it works for us, then it should work for a lot of other people in a similar way.
Andrew: Let me close the loop. Oh, sorry Tom. If you post something, and it doesn’t, it makes total sense to you and it’s intuitive to you, but you post it and it doesn’t work for others. How do you know that? Is it based on stats of how much interaction there is with it? Are you looking for feedback?
Tom: We do, we do a lot of that. You know, we blog about all of the new features and everything and when we launch a new feature we’ll often get 100 comments on that blog post. Of people who are either like, wow this is really awesome, I’m going to use this every day. Or, why did you take away my favorite little feature that I used, and now the site is useless to me. So, you’re going to see both of those. And you’re going to see them in some proportion. And you have to weigh the negative ones with the positive ones because people are much more prone to say negative things than they are to say positive things. So it’s just about knowing what’s customary for yourself. So over time, you know we’ve been doing this for several years, you kind of get a read on the customer feedback.
Or, you go on Twitter and you say, you know, what are people thinking about this new feature that we put out. And you kind of like have to let it settle down. Like, on that first day, there’s going to be people who’s, you’ve shattered their entire world. No matter what you do. Any interface change that you do, you’re shattering someone’s entire world. Like, they had some very specific work flow that involved this esoteric set of things. And you changed it because that was unintuitive and you made it a lot easier, but to them all you did was just completely like ruin what they used to be able to do. Even if they can do it easier now, at first they’ll hate you, because you moved their cheese. Later on, they’ll probably realize that there’s a better way to do it, or some alternative way to accomplish the same thing that just requires a little bit of a mental tweak.
Andrew: Do you have an example of that?
Tom: An example of that specifically is when we launched Issues Two. So we had a very basic Issues System Four. It kind of looked like gmail. It just had the list of issues and then you could label them and you could use keyboard shortcuts and you could move them around. And there were only a few fields. You could have the title, and you could have the description, and you could have like the descriptioning comments, and you could have labels. And that was, you could also sort them. So you could drag them up and down and give them a priority. And you could vote on them. You could be like, I like this issue, you know, like read it or something.
Tom: So when we redid issues, we removed voting and we removed sorting. So you could no longer specifically order the issues, they would just be ordered by some filter. You could order them by date, you could order them by the, I don’t know, a couple different things, right. And then we removed voting, because voting is really not very useful, honestly. In that type of situation.
Andrew: Really? I would think that it would be. That the more people to have a specific issue with the piece of software the more likely it is to fix it.
Tom: You would. OK. Well, yes. That’s true. The more people to have an issue with something, the more important it is. However, that does not necessarily mean that the number of votes is how many people having that same issue.
Andrew: I see.
Tom: You can’t draw that conclusion. And so now you start drawing a false conclusion about how, you know, was this issue pasted through Hacker news. And did someone incite the mob to upload this thing. Which is actually not that important but just really resonated with the mob. OK?
Tom: So for us, this concept of like plus oneing something, or voting on something. Less useful then just measured discussion around it and saying what the merits of the change are, from that perspective. And you should be able to get a concept of how many people are interested in something. Just by virtue of how accurate the discussion is. That’s a valuable metric of how important something is. Are people talking about it? Are people proposing ideas? People will always still come in and just plus one stuff. So you’re still going to have that type of voting thing, you’re just not going to see it along the left. But for me, the number of comments, the activity of the discussion and the quality of the discussion, those things are much more important to me.
Andrew: OK. So, you got a big firestorm when you made that announcement. And then what happened afterwards?
Tom: So, so we launched it, without those features. A bunch of people exploded their minds and their worlds had shattered and fallen apart and it’s hard because a lot of people, there was a fair number of people that were displeased with that decision. And so you have two choices at that point. One of them is be like, oh my god, I’m really sorry, you know. Let’s roll back to the old version or make the old version and the new version available so you can pick which one you want. Or let’s add these new features to the new version, which will probably is going to have some impact on the usability because that interface was never designed to have those elements in it.
Those are kind of your and then the fourth option is just leave it the way it is. Right? Leave it the way that you designed it and the way that you think it should be. And so for us, when we do stuff like that, we usually give it a week or maybe two in the new form that we’ve designed, that we think, that we’ve put a ton of thought through this. It’s not like we just erased these features because we’re callous or negligent. It’s because we very specifically thought that the value of them was not warranted, was not enough to warrant complicating the interface.
Tom: That’s always what these decisions are. Features come at a cost. They come at a very high cost. The more features you have, the more complex something is. The more complex something is, the less pleasant it is to use. The less pleasant it is to use, the less likely you are to use it. The less likely you are to use it, what are you even using that site for, right?
Andrew: So a couple of weeks after that firestorm, what happened? What did people say?
Tom: After that, we left it the way it was. We didn’t change anything. Tickets would come and we’d say, you can emulate your priorities that you had before by using also what we had was a new milestone feature. So we added milestones and we added user assignment. We removed some features but we added some different ones. We said, you can model priorities with milestones by saying here is your next two weeks of work. These are the priority items. They go in there. They are all important. If you want further granularity of priority, then you assign a label or two or three. Let’s say you have three labels: critical, normal, and low.
Now you can further priority within your milestones those issues. Now, instead of just having a priority, you actually have some semantic value around what those types of issues are. You can emulate priority in what we think is a better way through milestones and labels. As far as voting, we just thought that voting was not a very valuable concept. Mostly, it was around the sorting. Mostly, the reaction was around the removal of the sorting feature. Much less so around the removal of the vting feature.
Andrew: And then in time, people understood that that was a better way to do things and that’s the way it’s lived on since then?
Tom: Yeah, yeah. Not all of them will still think that that’s a better way to do it but it makes the interface much more intuitive because the sorting thing had all kinds of problems. You have a list of things and now you want to be able to prioritize them but now you, how do you get the thing from one page to another page because you have paging?
Andrew: I see.
Tom: It just wasn’t a very elegant system to begin with. The interface was confusing and weird from the very beginning.
Andrew: All right. I got a couple more questions to ask you about. The first one is this. The guy who introduced us, Shawn the founder of Spree Commerce, when he and I were talking about GitHub, he was excited about all of it. One thing that he kept coming back to was the Mac client and how this is the future of your business. Can you talk a little bit about that? Why is the Mac client so exciting that he would talk to me about it over drinks instead of talking to me about women and all the other stuff that we’re supposed to talk about?
Tom: The Mac client is far more interesting than women, obviously. The reason that the Mac client is so important is that it really represents our first big push into a new market of user. Up to the point before the Mac client was launched, GitHub was really focused on very skilled, deeply technical, probably most Unix style operating system base developers. That’s what they did. They were developers. They knew how to use version control. They were using the command line “get client” or maybe some of the other gooey applications that really just tried to take all of the command line client and expose a button for every single one. You still had to know and be skilled with Get on a deep, technical level to use to GitHub as effectively as possible.
Andrew: Bottom line, it’s kind of like using DOS as an interface to your computer with maybe a shell on top of it but it’s still a shell on DOS. For many people at work, you’re saying something new had to happen. What was the new thing?
Tom: Yep. The new thing was, start thinking less about Git, and how Git works, and think more just about versioning as a concept. And, instead of talking about pushing and pulling, which are what you do in Git, you know, push commits to the server, and then you pull down the commits from the server, and then maybe you’ll have to fix merge conflicts. And all of this kind of stuff. Instead, let’s replace all of that knowledge about server client interaction and, instead, build a native MAC client that you can long into with your GitHub credentials, and we’ll just show you your list of repositories. That you can click on one, hit clone, it will pull it down, right? Single button, it will clone it down. You’ve got it locally, you can make some changes, do your programming, and then see those changes very easily in a graphical format, and just scroll, you know, the normal way. See your exact list of changes, the diff between what the old and the new is, and then make a commit, right? Just put in your commit message in the little box.
Hit commit, you’ve added a new commit. And now when you want to get that back on the server, instead of having to know all of this stuff, like it’s automatically hooked up to GitHub so you don’t have to enter your remote, you don’t have to know anything about how that stuff works. All you hit now, is you say, sync. And that’s it.
Andrew: That’s it. I see.
Tom: And now that will go, and push those commits back to GitHub. If there are new commits on the remote, it will pull those down and do a rebase of your local commits before it pushes them back up. So you don’t even have to know how to do merging or rebasing type stuff or any of this complicated stuff that Git makes possible, that’s like amazing. I love it. Right? And, here’s the thing to understand. GitHub for Mac is not for me. It is not designed for me. It is designed for a new class of user that does not want to or care to use the command line client, right? It’s going to be people more like designers, developers that are not used to doing a lot of command line type stuff. They just want version control stuff, but they don’t want to hassle with this esoteric system that they need to learn a bunch of commands for. It’s for business people. Like if you have a business document of some sort that ends up being in a repository, and you want to edit that, you can do that with a Mac client, without knowing much about version control at all. Because it’s really about taking that versioning interface, and making it intuitive. So that you don’t have to read a giant manual before you start operating. And, that’s what . . .
Andrew: Designers that you and I talked before the interview about how they might be in your future, what are you thinking?
Tom: Mm-hmm. So there’s a lot of things we can do for designers. One of the things we’ve already done, is when you go to the diff page on GitHub. If you see, if you’re looking at a diff of code, then you’ll just see the red and green of the lines that were added and removed. Now, one of the things that one of our designers added, was the ability to do visual diffs of images. So if you do to a diff. A commit, right, was made where an image had changed. So, let’s say, you had a logo and you resized it. You made it bigger. Now, there’s a bunch of different ways that you can see that visually. You’ll see, you can see it on a left version, and a right version, and it will be like, old logo, small, new logo, big. Now you can also turn to several other different modes of comparison. And this is all done with Java Script and Canvas. You can have one that’s an onion skin. Where, you have a slider that goes back and forth. And when you slide it to the left, it’s the old version, and when you slide it to the right, it’s the new version.
Andrew: I see.
Tom: And it will just fade between them. There’s another one that just has a little slider, like a windshield wiper. On the left half you’ll see the old one, and on the right half, you’ll see the new one. And so you can very easily, switch back and forth. And so maybe with the resizing, that’s not very good. But let’s say you have an image that you touched up, right? You have an image that you wanted to photo shop, you removed blemishes, you augmented this, and you de-augmented that, and you want to see what that change was. Because looking at the left one and the right one, that’s like those games at bars, where you’ve got to, like see what changed . . .
Tom: And that’s like a puzzle. Now with the little slider, you can easily just slide them back and forth, and visually, we’re very good at, in that regard . . .
Andrew: Noticing when things are changing.
Tom: Changing. Yep. And then there’s another mode that is strictly just exclusion. It will apply an exclusion algorithm to the two on top of each other, and show you anything that’s black, will be stuff that didn’t change, and anything in white, will be stuff that did change, right? So, now you can very easily pinpoint each of the little things that changed in that image. So, this is, and this is only the beginning of what we can do for designers. And other type of people as well. Anything that . . .
Andrew: The future is just being in versioning. You want people to collaborate and see what’s changed, and contribute changes.
Tom: Yep, exactly. Across, across all format types. Not just text and images but imagine if you’re working on hardware, and you have a 3D definition file of a specific part, what would happen if we did image type diffing with 3D images? Could you drag and spin that part around and see… Let’s say you have a left and a right. Now, you drag one of them around and it rotates both of them. So you can see around this whole part, visually, left and right. And then combine that mode with the same type of thing, maybe a slider, or maybe the exclusion algorithm, to be able to visually see.
And I think where this starts to get interesting, for other types of people than strict coders, especially in things like the open hardware market, is you can go to a project, view the files, and see previews of parts and schematics and stuff, electrical schematics, in the browser without having to download a bunch of proprietary software, figure out how to get them installed, download the whole code base and open up those files, look at them, know how to use that program enough to be able to actually inspect them, you can do it all from the browser. And as more laypeople are getting involved in open hardware and electrical Arduino stuff, people are going to want to get previews of things more easily, and then it goes from there.
Things like making it easy to version Photoshop documents… What if we had a way for people to interface Photoshop and GitHub? I don’t know what that means, but I think it’s pretty compelling.
Andrew: As I’m hearing you talk about all these big things, I’m remembering what you said earlier. You said, “We don’t have funding yet.” The rumors I’m hearing are, ‘There’s funding in the future, actually.”
Tom: You’re hearing rumors, are you?
Tom: Interesting. It’s hard to say…
Andrew: Are you having conversations about it?
Tom: We’ve had conversations with people from the very early days. I mean, VC’s have been coming to us for 2 and a half years. They come to us and they’re like, “Hey, let’s talk!” and we’re like, “OK, let’s do that.” And this is really valuable; It’s very interesting to meet venture capitalists and talk about what they’re doing, and what they’re interested in in the future, and it’s useful to have those contacts for if we want to take money in the future to really super-accelerate what we’re doing. I’m not going to say whether we’ve decided one way or another, this is something that we talk about all the time, but here’s the thing… We’re a fiercely independent group of people. If we were to take money, it would be on our terms.
Andrew: And they’d have been OK with that, right? I don’t think, at this point, that investors are arguing with you about that.
Tom: Perhaps not, but things change when you take money. I just love this company so much, and the things we’ve been doing, and the team that we’ve built, that for that to change in a bad way, for me, would be tragic.
Andrew: Since you said that, I’ve got to ask this question. A lot of people have your background, whether just trying stuff, putting it out in the world and seeing what happens, when they get this far on something that’s really powerful, they somehow decide they need to get carried away with the new shiny object, go play with that, and ignore this. Do you have any of those wrestling matches internally? The need to go and play with something brand new and put it out in the world versus the desire to also stay here at GitHub?
Tom: Not too much actually. I mean, I love playing around with stuff, I’m doing some stuff with Arduino and hardware stuff…
Andrew: So what’s keeping you from doing that?
Tom: What’s keeping me from doing that?
Andrew: Yeah, from getting distracted the way others do. Am I misreading the personality type, or…
Tom: No, I’m very much that personality type. The reason why I’m not is that GitHub is so awesome.
Andrew: Why? What is it about GitHub specifically that captures someone like you, who can get into so many different projects?
Tom: I think a huge part of it is that this is something that I built; that everything that is here in this office comes from a small moment, 3 and a half years ago, where I sat down with Chris and said, “Let’s try out this thing and see how it works.” And it’s really very personal. This is something that’s more fascinating than anything else I’ve run into. That’s really what it is.
Andrew: Do you get to try so many new things here that that part of you is satisfied?
Tom: Yeah. That’s a big part of it too. I mean, I’ve been throughout the whole stack, I’ve done front-end stuff, I did back-end stuff, I did some rail stuff, I try not to do any rail stuff. I’m getting into more business-y stuff now, business development meetings with VC’s, dealing with hosts and vendors, I created the GitHub merchandising shop, shop.github.com. There’s all kinds of stuff there, and now that’s moved off and other people are dealing with that now, but I created a lot of the initial products in collaboration with other people on the team and really set that up and got that going, and it’s kind of doing it’s own thing now.
I’ve got my hands in so many different parts of the company, and I have such flexibility to dictate my own terms, I’ve done a lot of traveling for conferences. GitHub is the avenue, for me, to really do what I’ve always wanted to do, and at the same time, be surrounded by the best people that I know, the best developers, the best designers, the best everyone that I know, and just have a really freaking good time doing it.Why would I leave that? Tell me, ’cause I don’t know.
Andrew: That’s a great place to leave it. Inspiring story, you’re touching so many people’s work and I appreciate you coming here to tell the story behind the business.
Tom: Yeah, absolutely. Thanks so much for having me.
Andrew: Thank you, Tom. Thanks all you guys for watching. And as always, if you connected with Tom in any way, I say, next time you see him in a conference, [??] He goes to conferences a lot, go over and say “Thank you” for doing this interview, or just say, “Hi, I heard your story, and I’m inspired by it.” Or you can shoot him an email, or find some way to let him know beforehand. I always say, “Don’t just be in the audience.” The way that Tom wanted to participate in the world and it ended up leading to a gravatar, participate in the conversation. Find a way to connect with Tom. And I don’t know what it’s going to lead to, but I think it’s good stuff. Thank you, Tom.
Tom: Thank you.