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 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 understand 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.