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.
I think not, for a couple reasons: a) they're not even intending for it to be commercial software, b) you probably shouldn't use that in your commercial software given the lack of testing and QA assurance, and c) if you want to use it, you can open an issue and ask for a license. I think the licensing thing isn't a big problem for the jQuerys and the Node.jses of the world. I think it starts when you get into the long tail, where people get a little bit upset that there are all these projects without licenses. But that's how the world works -- there's so much code everywhere without licenses.
If we were to get heavy-handed and force everyone to use these licenses, there would still be code all over the world without licenses on different services. My position is that you can always ask someone to add a license. I think that it's your responsibility when you're using code to look for a license. It's not your responsibility when you're publishing code to always put a license in. I don't think it's fair to tell a 19-year-old kid that you should use this license when they may not even understanding what it means and what rights they're giving away.
I think people should definitely understand what they're doing, what they're agreeing to, and what they're giving up -- which is why we have Choosealicense.com. When you create a GitHub repository now you can pick a license -- and now there's a whole site that we have built with our legal team that explains the legal implications of each license.
For me, it was really difficult creating a project back in the SourceForge days and wondering which of the 55,000 open source licenses to use. It was terrifying. I was a teenager. I was like: Am I going to get sued? What am I doing? GitHub isn't just commercial open source or proprietary software. It's this huge spectrum of homework assignments and little toys all the way up to production-grade, military-quality open source. I think that the licensing issue is gray and not so black-and-white. If you need one, ask. And if you're using open source you should definitely be aware.
InfoWorld: GitHub has a unique culture. From what I understand of your "optimization for happiness" philosophy, there's the idea of hiring only the best and having them decide what they want to work on rather than enforcing more traditional management. How is that evolving? Some enterprise managers would say: Oh, yeah, right. Just let everybody work on what they want to work on, and everybody will pick the fun projects.
Wanstrath: It's never really been about picking anything in the world you want to work on. It's picking the thing that interests you most that has the most impact on GitHub. There are people who say: What interests me the most is uptime and availability. What interests me most is billing code. What interests me most is the customer experience. Then you get people who say: What interests me most is the following social models of GitHub and surfacing repositories that get starred a lot.
The biggest change for us has been that we've started to add rules and processes -- coordination, really. A lot of it has been about communication. Now you can see the things we're planning to do for the next six or seven months. You can send a pull request against it if you think it's wrong. Before, we all had to share the road maps in our head. I might be building something here, not even knowing that Paul is building something over here. That worked out fine until we got more people and decided we needed a lot more coordination, a lot more communication. We used GitHub to do that, so the way that we work right now is way different than before.
The development process hasn't changed that much. We still do branch-based development. We still have this amazing staging environment where we can push out branches and get URLs to send to people to test stuff out. We're shipping much bigger things. Later this year, you'll see. We have some huge projects in the works, things that we couldn't have pulled off before. We're really using the muscle of the company a lot better now.
InfoWorld: What huge projects?
Wanstrath: We can't talk about them yet. What's important to us has always been: It's your first day at GitHub and if you have an idea, you should be able to say it. We want to hear all the ideas from everyone because it's the people using the software -- and we have some of the biggest users of GitHub in our company.
InfoWorld: This is a very competitive neighborhood. How do you attract and retain the best talent?
Wanstrath: That's a great question. I think one of the things we do is we don't really think about it that way. We're trying to build a great environment. We're trying to build a great product. We're trying to build a company that people really want to work for. We're trying to do something awesome together. That's really been the guiding philosophy in many ways.
InfoWorld: There are all kinds of elaborate ways of testing and screening people. But you don't believe in that?
Wanstrath: I mean, if we say we hire the best people, we have to be able to prove that. We know that. We have a system in place.
InfoWorld: How is the GitHub model extending beyond coding? I know you announced last year that your version control was being applied to legal documents.
Wanstrath: Believe it or not, government. Who would think that the government is forward-thinking and progressive and going open source? It's really quite inspiring to see that. But I think government is definitely the No. 1 noncoding group that's taking up GitHub.
InfoWorld: My last question, the thing that still flummoxes me: Why this collaborative model in particular makes it a success? It's not like this capability didn't exist before. It's not as if the technical hurdles are necessarily that high for versioning and code management.
Wanstrath: I know this sounds silly, but I think the thing that makes us different is that we think about people. It's not about the pull requests. It's not about the markdown. Those things can go away. In five years we might not have them. Who knows? But we're still going to be trying to help people work together. What is special about GitHub? It's all the people on it. It's open source. It's all the projects. It's being able to comment on code. It's being able to submit code to someone else and then clicking a button and merging it in so you just collaborated with someone across the planet. That's really magical.
You look at it on paper and it's like -- I don't get it. You could do this with email; you could do that with chat. You could do all these other things before, but there's this community aspect to it, with little things like seeing someone's avatars, seeing someone's face. It's very, very human. GitHub creates an emotional connection with people because that's what we wanted. We care about these people and we want them to enjoy using it. We want them to love it.
This story, "GitHub's new CEO: We're serious about the enterprise" was originally published by InfoWorld.