 Hi, I'm Jason Hibbitts with Opensource.com. I'm here with Chris DiBona, director of Opensource at Google. He oversees licensed compliance and also helps with their internal Opensource developer community. So you basically built the Opensource initiative at Google from the ground up starting in about 2004. Kinda. Yeah. What was that like? It felt that doesn't sound like it was an easy task to do. No, no, it actually wasn't hard. You know, Google already had a number of Opensource developers internally when I got there and they what they wanted by hiring me was to formalize it, make it easy, and as they grew, to make it persist, you know, so that Google could still feel like they can contribute and and release Opensource projects. And more importantly that we could also use Opensource software inside the company. And they knew that that would need a bit of care. Right. And they were growing enough at that point that they needed somebody whose job it was to care about that. So it was more a matter of coming in, formalizing what was informal processes. Okay. And then you know, looking after compliance in a scalable way for the then and still now very fast-growing company. Okay. Any changes recently? Or is that music? Imagine... Well, you know Larry you know, reasserted as CEO because he was our original CEO back in the dusty past and then Eric came in and then Eric became chairman of the Board of Emeritus CEO type guy and Larry became CEO. Again, Larry changed how the company was organized internally which changed some aspects of the work, but not for the worse or better just different. So but you know the thing about I've been in large companies before and large organizations before and you know it's just a matter of saying okay, here's how we're different now. If I were starting today what would I do differently? And so I do this thing at work about every two or three years I bring together sort of the major stakeholders and say okay, what are we doing right? What if we were going to start it today? How would we do it differently and and and just try to adapt? Right. And and I sort of take that as a measure of how I'm doing, you know because if they say to me, Chris, we're really screwing up this this mess. I know what it would concentrate on. This is why we did a renewed focus on get infrastructure for Chrome and Android which we've deployed externally as our kernel mirrors and the rest but all the Android folks are now running, for instance, on a version of Git that sits on top of our very scalable backends. That's a great approach to kind of check in every year. Yeah, no, well it's not every year. I really don't want to waste their time but it's interesting. So yeah, so a lot of people hear about all the perks at the Google campus. Can you give us a little bit of insight as to the culture at Google and kind of my main question here is that you know is there a default to open mentality there? Well, you know, I would love to tell you that that's the truth but I mean most people, you know, at a company like Google, there's a default to coding. Okay. And and some of those projects are open. Some of those are closed. But then we also have people who are very passionate about open source and what we try to do in their case is is get to know them and say, okay, you're going to be patching, you know, which projects matter to you and and just make sure they're putting, you know, both our best face forward but also meeting the right people and source because it's very rare but there are some projects that are very difficult to deal with as a larger company and as an employee of a larger company. And so we make sure that they get the right kind of attention. Similarly, you know, contributor license agreements have become way more popular over the last couple of years and some are completely signable and in fact are often based on the Apache contributor license agreement which is the same one we use at Google. And so that's usually very easy and so we make a make a point of making those very efficient when a Google goes to sign those. Other CLA's are not as easy to sign because they carry type right assignment and often patent assignment clauses that are too, you know, grabby. Sure. You know, and so in those cases we usually end up pushing back on the project that wants that kind of thing and they often change because they still want our patches, you know. And then in some cases we'll release patches wholly separate from our project, you know, and independent of their desire to have grabby clauses in their CLA's. So, you know, we exist in those conversations to basically protect Google and to protect Googlers and to protect open source people from Googlers who are not always so savvy. You know, so. Well, one of the other important parts about about contributing open sources or open source general security. So recently Google announced a new program to reward large security improvements to open source projects. Tell us a bit about that. Well, I'd love to take credit for it, but this came out of our security group and they're just brilliant. And they're like, hey, you know, we want to expand our bounties programs to these very popular libraries. And we had focused funding on some of these libraries in the past to ensure that they persisted. But this was a very smart approach where basically, you know, what it is is if you take a commonly used and popular library and you find a security bug in it, you know, we're happy to basically award you for finding the bug and for fixing the bug. And then we also have a program on the side where we approach those projects and said, you know, if this creates a lot more traffic for you that's hard to deal with in terms of, you know, patch traffic, let us know we're here to help, you know, and because the reality is if you look at like a library like Zlib or the OpenBSD drive open as cells and the rest, they're incredibly important, right? They're important to Google, they're important to the web of large and we can make a better web, a more secure web, if we just make sure that, you know, these patches are found quickly and dealt with. And that's the power of the open source model, right? Well, that's very, very true. And so we just want to, you know, make it very, very clear how important these projects are to the internet, frankly. Thanks to Google for putting together that program. Well, sure. I mean, you should be thanking these library authors, you know, they're the ones. They're the ones that do their day to day work. Great. So last question here, and before the conference here, all things open, we did an interview with you on Obasource.com and you talked about Obasource being brutal, got a lot of attention. Yeah, I think that was a great quote for people really like, ooh, brutal, that's a great thing to say. But so, I mean, it sort of is, right? So what's the, you know, it's brutal. Why is it brutal? Well, I mean, it's very much the survival of the fittest applied to software, right? And the thing that people forget about evolution and survival of the fittest is that there's a lot of, you know, stalled forks out there and it represents broken hearts and broken dreams, right? And sometimes those people come back to open source and come back to the main line project and sometimes they don't, you know? And that's how it's brutal, you know? Because it's because people are always like, you know, they do blog posts like, you know, you are not your software, you are not your work, you are not this, but the reality is if you're going to spend 8, 10, 14 hours of your day working on software, it is personal. If you're going to spend 10 hours of your day at your work, it is personal. I mean, it's funny because people have this mentality that like, well, you know, a man is not his work, a woman is not her work. It kind of are. I mean, I hate to say it, if you put your heart into something that much, it is. And because of that, you know, when your work is rejected for whatever reason, you know, it's heartbreaking and brutal and all these things. And at the same time, you know, it's also how we get really good software because sometimes you have to say, this piece of software is unsuitable to the task. And that can be hard to hear, but it doesn't change the fact that people want software unsuitable to the task or insecure or broken or worthless. There's no, you know, there's no gentle way to do that. And the thing is, there are some people who over-correct the other way and make it extremely brutal. And that's too bad. And you see communities that are harsher than others. But in many of them, it's just simply hearing your software, your patch is unsuitable. And it takes us too long to teach you how to make it suitable. That's very hard to hear. It's awful, right? But at the same time, you know, I've seen it over and over and over again, both inside and outside of a corporate context. And it's like, you know, I would love to take your patch. I'd love to tell you what's wrong with your patch. But to do so would take too much time. You know, and so that's why you have better software, right? Well, that's how open source. Because it's funny, because within a corporate context, you actually, it's very hard to say that, right? So for a Googler to say that to another Googler is very difficult, right? I don't have time to help another Googler out. I mean, it happens. And this sort of goes to the nature of why some software developers are valued more than others. And it's a very hard conversation. But inside a corporation, you have the conversation outside in the open source world, people are just like, I'm not going to reply to this crap. You know, I'm just going to be a black hole this person's email address, look how much easier my life is. It is, you know. But great. Well, Chris, we'll take you off the hot seat. Thanks so much for your time today. Sure. Happy to.