GitHub is more than a cloud service based on Git, Linus Torvalds' popular revision control system. It's a cultural phenomenon that marks the ascent of a new generation of developers that, although closely associated with open source, displays equally intense allegiance to social coding and the agile development movement.
Arguably the center of the programming universe, GitHub currently boasts 6.8 million users and 15.2 million code repositories, more than double the respective numbers recorded two years ago, when the company attracted $100 million in venture capital from Andreessen Horowitz. The investment came shortly after GitHub's release of an on-premises version of its software, GitHub Enterprise, for customers who prefer to keep their code inside the firewall.
In November 2012, I interviewed GitHub's co-founder and then-CEO, Tom Preston-Werner, who described GitHub's unusual management philosophy and unique appeal to programmers -- and hinted at expansion into new markets. Preston-Werner was accused of misconduct by a former employee and subsequently resigned in April 2014. He was immediately replaced by co-founder Chris Wanstrath, a former software engineer at CNet, who is the subject of this interview.
The interview took place late last month at GitHub's San Francisco headquarters, already legendary for its full bar and true-size replica of the Oval Office. This is a critical time for the company, as it faces competition from Atlassian's BitBucket and accelerates its push into the enterprise. What follows is an edited version of an hourlong conversation with Wanstrath. I began by asking him about his role in GitHub's founding.
InfoWorld: Let's go back to GitHub's beginnings. Were you there from the start?
Chris Wanstrath: The founding moment was at Zeke's, a bar a block away from here. Tom [Preston-Werner] pitched me on the idea for GitHub; he wanted to make repository hosting a lot easier. I was totally on board, so we started it together in October 2007. We would meet on Saturdays and talk about what we wanted to do. I would be coding the website, while he would be designing new features or working on the infrastructure. We launched the beta in January and the site launched officially in April . It happened really quickly. It was only about six months from founding to the first commit and to us charging people money.
InfoWorld: But all along GitHub was free to open source projects and you would charge money only for private repos, right?
Wanstrath: It actually took us a while to come to that, believe it or not. There was nothing like GitHub before GitHub, so we were thinking this is a real business, we have to make it sustainable, so we'll just charge for projects. It feels weird to charge for public projects, but it also feels weird to give things away for free. It took a lot of iterations until we decided that private repositories would cost money and public repositories would be free. It's simple in retrospect.
InfoWorld: When did you come up with the idea for a locally hosted enterprise version?
Wanstrath: People were asking for it immediately. I remember we went to ZendCon in 2008 where I was overwhelmed by the number of PHP developers who were working on government sites. They came up and said: "We love GitHub, we're just not allowed to use it. Please help us." Almost right from the beginning we were thinking about doing a private install version. Not until 2011, 2012 did we actually make it real. It was a long time coming and it still is something that we work on all the time, and I think it's going to be a lot bigger in the future.
InfoWorld: Did you expect GitHub to take off like it did?
Wanstrath: No, I didn't expect it. I am a developer. We were sort of building GitHub for ourselves, so I knew it was going to be a viable business. For a long time that was the goal. Even after the first year, it felt like it was the biggest thing in the world. At the beginning of 2009, I remember I was looking at how many users were signing up and being like: Who are these people? I don't even know a couple hundred people and yet a couple hundred were joining GitHub every day. That was overwhelming.
InfoWorld: At the same time, it's a pretty simple concept: Put Git in the cloud. You have competition, primarily in the form of BitBucket. Why do you'll think users will stay loyal to you?
Wanstrath: For me, it's about a good product. I don't think our competitors have bad products, but I think we're leading the way. I think we've always prided ourselves on being innovative, pushing out new things quickly, coming up with new ideas. Right now we're working on new ways for people to work together. I don't think any of our competitors are going to come up with that because they're looking at what we're doing and we're looking at how people are working.
As for the open source community, there's momentum. People see an open source project and say: "Where am I going to put mine? I'll put it on GitHub. It's free." Also, there's something to be said for having a dashboard. I'm following a bunch of projects, and I can go to one page to see what's going on with all of them. I think that that's very, very useful.
But for me, it's always been that we wanted to make it really good. We wanted to make it great for developers. I think that accounts for a lot of the success: We built it for the people using it. We didn't go too far into marketing. We let the customers and ourselves drive the product. That's what we're trying to do as we grow and I think that's going to take us a long way.
InfoWorld: Social coding is essential to GitHub. Could you define social coding for an enterprise audience? Also, how do you feel social coding is changing application development?
Wanstrath: Social coding is about people. Before we had a following, before we had any of the social features, all we wanted to do was make it really easy to share code with somebody else. It wasn't about what you were getting out of it; it was about what you were doing with somebody else. It's about the commenting system. It's about being able to look over a code review, get feedback, and sign off on it. It's about forking someone else's project and showing them what you worked on. There's a certain amount of friction in pushing changes to GitHub or changing navigation of the website. We always care about that. But the big picture is -- how do we make it easier for people to work together? What are new ways that we can get different people working together? That's social coding.
InfoWorld: Do you think that also represents a generational shift in coding?
Wanstrath: For me, it's a lot about the Internet. It might be generational, but a lot of people who are programming now grew up with the Internet. It's always been a part of their lives. The default is: I talk to other people really easily. I get feedback. I grab something from someone else. That's the biggest change.
When we were building GitHub we were looking at Twitter. We were looking at Facebook. We grew up on those things. One of the ways I explain GitHub to people is: Think about Facebook. Someone posts a photo; you see it and you comment on it. GitHub is like that. Someone posts code and you see it and you comment on it. It's the move away from email-based collaboration and email workflows for contributing to open source to just the Web. If it is generational, it's a generation that's really comfortable with the Web.
InfoWorld: Do you think that work model translates to enterprise? GitHub has talked a lot about applying the social coding model associated with open source to the enterprise, but that appears to be at an early phase.
Wanstrath: Absolutely. I think that it is early. It's hard to get there. But what I like about the open source model as opposed to some of the traditional, proprietary software development models is that software development in big companies is "designed." It's designed by someone for a reason: Either there are deadlines, they're trying to coordinate a bunch of people, or there are audit restrictions ... there are going to be gatekeepers. It doesn't mean it's bad, but often it's a top-down decision with business reasons behind it. Salespeople and whatnot are helping design the process and what they say is important to how it works. Open source has none of that.
A lot of open source workflows work because people like them and they are useful and they get things done. What if you could take this workflow that has evolved -- because it's productive and because it builds great software -- and you apply it somewhere internally? You can still have oversight, you can still have sign-off, you can still have control, but you can take a huge cue from the way people in the open source world have developed it. It evolved organically. And it's good -- it works.
Open source is a success. Why not apply that to building closed-source stuff? The promise of GitHub Enterprise is that you have the GitHub community, but you wrap it behind your firewall, so the GitHub community becomes the template for the way your company runs. You still have projects that are totally secret. You still have projects that are read-only, that someone needs permission to access, but you can open it up, so people can create new projects, they can share it with coworkers, they can do experiments and publish their experiments.
These are the workflows of open source that a lot of closed-source companies don't have because they don't know about them. No one has ever pitched it to them; there's been no entity behind it commercially trying to pitch them on it. We don't care whether you work for the government or you work for open source, you work for a small company or a huge company -- we're trying to help people build software better. It doesn't matter if you live in Ukraine or you live in Hawaii. We want to help you build software. If we can help someone in Ukraine work with someone in Hawaii, that's really interesting, too.
InfoWorld: What you've given me is the upside of openness. There's a whole flip side to development management that's all about metrics and how many commits people have made and so on. That runs counter to the culture that you're talking about, doesn't it?
Wanstrath: I'm not sure about that. The contribution graphs on GitHub profiles show how many commits you've made. That's a metric. I look at people's contribution graphs here; people look at mine. I don't know that metrics and productivity have to be a bad thing. I mean you can use it as a hammer or you can use it as a competition. You can use it as a way to show off. You can use it as a way to be proud of what you've done. That's a lot of what GitHub does.
I think it's applicable to businesses too. You can use the information any way you want. In a company, if I say I have to sign off on your code before you commit it, you think: OK, gatekeeper. In open source, if I say I have to sign off on your code before you commit it, you think: OK, quality control. Right? It's just how you look at it. Metrics are really interesting. For example, someone might see that after introducing GitHub, programmers are talking more and writing less code. I think the assumption that more code is better is something that you can actually fight with good metrics.
InfoWorld: I'd like to get back to the open source community and specifically open source licensing issues in relation to GitHub. There's still a lot of code on GitHub that has no license at all. I think part of the generational shift is not caring so much about all the variations of in open source licensing. It's about sharing code -- and that sharing code should be as free as possible. But at a certain point you run into legal issues. Somebody may come back years from now and say: You used a chunk of code and that wasn't really yours, because by default, individuals who put code on your site without a license retain the copyright. How are you navigating those issues and what's your philosophy?
Wanstrath: There are a lot of projects on GitHub without licenses and a lot of code on the Internet without licenses. I see the two as very, very similar. This is actually quite topical. I have a project on GitHub that doesn't have a license. Three days ago somebody opened an issue and said: Please add a license. I added a license and that was it.