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.