small medium large xlarge

An Interview with Tom Preston-Werner

Chatting with the CEO of GitHub

by Jack Kaufman

Generic image illustrating the article
  The co-founder of GitHub chats about being an entrepreneur.  

Jack Kaufman has created a book filled with interviews with tech entrepreneurs. This interview with the CEO and co-founder of GitHub is from that book.

jk: Why did you decide to raise $100 million dollars for GitHub?

tp: Well, there were a couple of reasons. A big one was we’re growing as a company. Around the time we took the investment we were around 100 people. So leading up to it we spent a lot of time talking to various VC’s over the years, just kind of seeing what they were like, seeing what they thought about the landscape of software development and developer tools. So we got a good sense of the variety of venture capitalists and how they might be able to help us.

About a year ago now, almost, we started thinking more seriously about the size of the company, where we were going, what our ambitions were, and what the best way to achieve those dreams were. Being a bootstrapped company, we were making money. We were hiring really well. We weren’t constrained so much by money but the ambitions that we had. What we wanted to achieve we felt could be done more quickly if we removed money as a limiting factor.

So if we were able to invest more, more quickly, then we could build out the enterprise, offering additional products, be able to hire for a wider variety of things, and just invest more in research and development-type efforts more quickly to do all the things that we had in our minds.

So we met all the best VC firms that we could. We got introductions. We’d been around for long enough at that point that we could reach out and get introductions to pretty much any of the VC firms that we wanted to, so we went for the very best ones that we could find. We contacted them, some we’d already been talking to, some of them were new.

We just started having dinners and talking casually with various people from these top-tier firms and kind of feeling out where they were at as far as what they believed in. A lot of it was looking for a philosophical mesh, someone that had the same kind of view of what the future of software development could be.

Over the course of about six or seven months we talked to a variety of them and got to a point where there were some really excellent partners. A huge piece of it was finding the right person that would come on our board, what their background was, what the background of the VC firm was, how they worked together, what their offering was as far as what they get you, their connections, how much noise can they make for us, all these kinds of things went into that equation.

So we looked at our situation and we said, well, the landscape was really excellent for taking investment. This was in early to middle 2012. We’ve been profitable for a long time so the VC firms already knew about us. They already knew that we were capable of running a business. We knew that they weren’t going to come in and start interfering.

Another thing that was on our minds was being able to be independent, not giving up control. So that was a big part of it, just feeling out the various firms and seeing what their perception for founder-led companies was. None of us had any interest in stepping down or hiring an external CEO or executive team or anything like that. We wanted to maintain control so we needed to find a partner that had that same type of viewpoint.

When we came across Andreessen Horowitz, they matched all of these criteria. Just having people like Marc Andreessen and our board member, Peter Levine, who’s been a CEO before, ran Xen-source, and was a big part of their toss before that. Having these guys available to us to ask questions and for them to look at what we’re doing and offer suggestions about how we might accomplish what we want to faster and easier, it has been awesome and that’s exactly why we brought them on board.

The money is great. The people are even better. Combine them both and you get a future of GitHub that is much richer and happens much faster than it would have otherwise. At the same time, we’re not giving up any control and we didn’t have to give up that much of the company for it. So at the end of the day, it’s a win-win for everyone.

jk: What are some of the ways that you and your team market GitHub and grow GitHub?

tp: The biggest thing for us was getting it used in our programming community, which was the Ruby programming community, in the early days. So finding people that are close to you and being part of the community is a great way to get started when you don’t have much of a product yet and you don’t have much money to market it properly. Then integrating into a community and sharing it with that community is really powerful.

We went to programming meet-ups, that’s where our community was here in San Francisco. I guess that most people can find a community, whether it’s in person or virtual, that you can start hanging out with, figuring out what people’s needs are. When you build a product, those are the people that are going to be most interested.

If they find it useful and they start using it, then they’ll want to tell their friends about it. So you can start spreading it in that kind of way; starting with a community that really cares, that you can talk to in person.

From there, what we did was we started going to conferences. We started talking about it publicly after it had publicly launched. In the early days too, we used a strategy that’s pretty common in these days, but that was really effective, which Gmail used very effectively, which was during the private beta phase, we made it so that you had to have an invite to get an account. You could use the site from a consumption perspective but you couldn’t upload any code or anything unless you had an account.

To do that, we invited our friends, the people that we knew initially, and we said “Here are five invite codes that you can send to your friends.” So it creates an artificial scarcity of invites that makes two things possible.

The first one is it prevents too many people from getting on your system too quickly. This is especially important if you haven’t figured your back-end out completely yet and you don’t want to suffer scaling issues. You can see problems as they arise instead of just being covered [in] an avalanche of people all at once. That’s not a good experience for anyone.

And number two, it makes your site seem more attractive. This is the “you want it because you can’t have it” kind of mentality. This makes people tweet about it. People are tweeting about wanting invites, seeing if their friends have any. So you get a bit more exposure that way than you would otherwise, I think. That worked really well for us. I mean, you’ve got to have some traction for that to work but if you can get to the right place, then it’s super effective.

So we did that in the earliest days. Once we publicly launched, we started going to conferences, internationally too, this was big for us. We started traveling internationally to a bunch of conferences talking about GitHub and holding what we call “drink-ups,” which are essentially meet-ups but we just meet at a bar and buy developers beer and they are immediately our best friends and they check out the site.

They like us because we do that and we get people together that wouldn’t normally be together to talk about being developers and programming and everything so it’s just a very good social way to bring people together. Which is what we have this for, bringing a group together, making it easier to work together. We’ve been doing that for years and it’s been really effective. It’s an incredibly cheap way to do very strong loyalty-creating advertising. If you can buy someone something, whether it’s with beer or... well, beer works really well.

We haven’t done much traditional marketing. We don’t do advertising, really, anywhere. We gave out shirts and things at the conferences. If you’re going to give out stuff, having it be really good quality is super important because nobody’s going to wear a crappy t-shirt that has a crappy logo on it. You have to think about the design and the quality of the shirt. Since the very beginning, we’ve only ever printed on American Apparel shirts, which are quite expensive from the giving-them-away standpoint. Wholesale, those shirts are like $8 and something and then it’s another couple of dollars to get them printed. So at the end of the day, you’re talking $10 to $15, depending on the design, per shirt.

So if you go to a conference and you give away 300 to 500 of those, it’s not cheap. It’s a significant investment but it’s worth it because then people will actually wear the damn things instead of just putting them in their closet and using them as rags for changing their oil.

So you can either invest a small amount and get zero return, or you can invest a more significant amount and get a real return. For us, we chose the latter and that’s been really effective too because people care about your brand and over time if you are cheap about marketing kinds of things, people will realize that, and they’ll associate your brand with just cheap, crappy merchandise. So if you’re going to do merchandise, you’ve got to do it well, otherwise just don’t do it at all.

Now we sell hundreds of thousands of dollars of merchandise through our store every year. People buy this stuff willingly now because they like the brand. They know that we create quality merchandise. From a marketing perspective, they’re happy to pay for it because they know that it’s good and that we care about that stuff. The only way that that can happen is if you care about it and if you spend some money on it.

jk: Why did you decide to use a freemium model for GitHub? How do you think the freemium model has helped grow GitHub?

tp: We decided to go freemium when we launched initially. There were a couple of different ways that we could have charged for GitHub. Chris and I sat down when we were first starting it and talked about what the billing model was going to be and we looked at who the users were going to be. There are really two kinds of users at GitHub. There’s open-source users and then there’s private, company users.

We said, well, we could charge everyone to use GitHub, including both open-source people and regular-company people, but the problem is that kind of sucks for open-source users. I mean, they’re doing open source, a lot of them, in their free time. The whole point of open source is that it’s free and it’s open, everyone can do it. So we said it would make more sense to make it free for people doing open source because otherwise they’re probably just not going to use it for that at all and that would be terrible.

Having a lot of people use GitHub for free for open source would get us a significant advertising surface area; this ties into the last question. Another huge way that we advertise is by making it free for open-source users. Because now look at all the open-source on GitHub that people from around the world are searching for and ending up on our website. That only happens because so many people can use it for free. So that’s an investment in open source, really, and it has an advertising outcome and that’s worked really well too.

So having it be free for open source users has a lot of benefits and it allows us to contribute back to the open-source community, which we love. We are open-source developers ourselves, we come from that, and we would never have been able to build GitHub without all of the open sources available. So any time we can contribute back to the open source world, we do.

So we said, okay, if it’s going to be free for open-source people then the way that we would make money is by charging company people using it for private repositories. So what’s the best way to do that? The thing that is really limiting for us, the thing that’s most important for us, is this concept of the project or a repository. This is how Git works, really.

So let’s make it really easy to understand and, say, free for open source users and if you want private projects, then you pay for those. And the more private projects you have, the more that you pay so let’s have some plans and then let’s charge a pretty reasonable amount for them so that people can get started really easily.

You have to remember, five years ago nobody even knew what Git was, so the only way that we figured that we could get people on board was by making the cheapest plan super affordable, give them, I think, five repositories, which is enough to get started, and charge a small enough amount per month that basically you don’t notice. Then the reasoning that it ended up being $7 a month was that, well, you think $5 is small enough that most people aren’t going to worry about it too much. That’s pretty easy to get into, $5 a month.

Ten dollars a month is probably the point around where people start noticing. It’s like $10 a month, that’s significant. That’s over $100 a year. That’s something I would notice, $10. And if anyone’s going to pay $5 for something without worrying about it, then they’ll probably pay $7. The difference is too small to be really noticeable. So we went with $7 because it was not $10 but so little over $5 that it’s indistinguishable.

And that’s worked super well. We have a ton of people paying $7 a month and it represents a huge amount of our user base. It makes us really strong: because we have so many customers paying a small amount, it means that if any one customer decides to leave the service, it’s not a huge deal. So if you can get a lot of users paying a small amount, that’s a pretty big win.

That’s what we launched with. We didn’t know how well that was going to work but it seemed to us that it was right, that that was the right model to launch with. So that’s what we did and people started paying immediately for it and it was easy for them to ramp up. The cheapest plan was cheap enough that they didn’t care. If they got more repositories then the next plans were not these huge monetary jumps and they could ramp up as they used the product more.

The freemium model doesn’t work that great for everyone but it worked well for us because it is a rich product and you can use the entire thing. Every feature of GitHub that there is, you can use for free if you’re using for open source. Everything. There’s nothing restricted. There is not a single feature that you get when you pay for it that you don’t get when you use it for open source except privacy. That’s it.

So the model’s very simple for people to understand. They come on board, and they can try it out for free. They know that if they pay for it, they’re getting exactly the same thing, it’s just now they have control over privacy. So that’s why we chose it. Because we wanted to be able to make money on it, we wanted to have a business model.

We didn’t want to make it just free for everyone and we wanted it to be free for open source so we had to charge for privacy where it makes sense for that to be the distinguishing factor and it came out of how we wanted to charge for it. We didn’t go into it saying, “We should probably do freemium.” That didn’t matter. I don’t even know if freemium was a thing back then. We just did what we thought would be the best from a business perspective and it ended up being freemium and it ended up working super well for us.

jk: What do you think are the most important responsibilities for the CEO of a startup or business to have?

tp: I think what’s really important is setting the vision for the company and often this lands on a CEO. As CEO of GitHub, I am one man. Decisions at GitHub don’t happen just from me. Everything that we do, we get together and we talk about it. Talking about things and arguing through things helps us make better decisions so it’s rare that I would ever come up with a big change for the company by myself.

So when I say the CEO should be setting the vision of the company, he or she is probably the only one that is going to be called on to communicate the vision of the company and make sure that the vision of the company has been established and is well communicated, and that falls on me right now.

I happily take that on because it’s the best way to run a team without having to tell everyone what to do all the time, which is stupid. That’s not how you should ever run a business. What you want to do is set a compelling vision that people can get behind and then just let them do it.

The way I like to talk about it is I point the direction that we’re going and everyone else figures out how to get there. As long as people understand and can believe in the vision and see that as something that’s valuable in the world and you hire the right people, then they’ll do that and that’s why you hired them. You hired them to help you do that and you have to let them go do that. So that’s what we do. There’s a huge amount of autonomy at GitHub, letting people figure out the best solutions for things, coming up with new products, everything.

But it all is in service to the big idea of the company. So for us, the big idea that we have right now is to make it easier to work together than to work alone. It’s a concrete thing but it has broad application, which is great. It’s not so narrow that you can’t work on a lot of stuff towards that goal. It can be applied to a lot of what you do and it’s big enough and important enough where people can look at it and say, “Yes, I want to do that and that’s going to enrich my life to help do that.”

I think a vision statement should be one sentence and probably not more than about 10 words. That’s when you get a really compelling vision. It has to be simple enough, broad enough to be big, so big enough that it’s hard to do but narrow enough that you know what it means and how you can apply it. That’s a huge role of the CEO. That’s one of the biggest.

jk: What piece of advice that you haven’t already mentioned would you give to someone looking to start a business?

tp: I’d say the biggest hurdle to running a business is just doing it, is just the bravery involved in stopping what you’re doing now and deciding to go do it. That’s the hardest part. We can all come up with great ideas and everyone has a million ideas for mobile apps that are going to change the world. The hardest part is sitting down and saying, “I’m going to do this, and it’s going to be hard but I’m going to keep doing it.”

So that’s the thing, it takes a large amount of mental fortitude to do it. But for those that are inclined to do so, especially people that come from a developer background, I’d say it’s the best thing that you’ll ever do, the best, most rewarding, most important, and the biggest chance to learn and change the world that you can ever embark upon. Even if you fail, even if things don’t work out, you’re a developer. You’re not going to be lacking for work. If you’re a developer who’s starting a company, that makes you even more employable, even if it fails.

That’s the hardest thing, is just deciding... deciding to do it and doing it and being serious about it and not stopping when it gets hard. Because you’re going to run into stuff, and you’re not going to be able to find the right co-founder. You’re not going to get investment when you think you should. People aren’t going to pay attention. Your stories don’t get on the homepage of Hacker News as often as you want. None of that matters. The only thing that matters in running a successful business is just keep doing it. Eventually you’ll figure that out.

Jack Kaufman is a 17-year-old who is passionate about business, entrepreneurship, and technology. He is the author of The Found a Business Book, which contains 33 interviews with successful technology entrepreneurs. Next year Jack will be heading off to Haverford College, and you can follow him on Twitter at @kaufman_jack.

Send the author your feedback or discuss the article in the magazine forum.