The Changelog: Software Development, Open Source - Open Source at Google (Interview)

Episode Date: March 28, 2017

Will Norris (Engineering Manager at Google's Open Source office) joined the show to talk about their new release of the Google Open Source website as well as the release of Google's internal documentation on how they do open source. Nearly 70 pages of documentation have been made public under creative commons license for the world to use. We talked about the backstory of Google's Open Source office, their philosophy on OSS, their involvement in the TODO group, and much more.

Bandwidth for Changelog is provided by Fastly. Learn more at Fastly.com. Welcome back, everyone. This is The Change Log, and I'm your host, Adam Stachowiak. This is episode 245, and today we're releasing a special episode in collaboration with Google. We talk with Will Norris, the engineering manager at the Google Open Source office, about their brand new release of the open source website for Google, as well as their newly released internal documentation on how they do open source.

Nearly 70 pages of documentation have been made public under the Creative Commons license for the world to use. We talked about the backstory of open source at Google, their philosophy on open source, their involvement in the to-do group, and much more. We talked about the backstory of open source at Google, their philosophy on open source, their involvement in the to-do group, and much more. We got three sponsors today, Hired, Rollbar, and GoCD. I want to tell you about our friends at Hired. We've been hearing lots of great things about them

and their process to help developers find great jobs. So we reached out to them, and guess what? They were excited to work with us. And we partnered with Hired because they're different. They're an intelligent talent matching platform for full-time and contract jobs in engineering, development, design, product management, and even data science. Here's how it works. Instead of endlessly applying to companies, hoping for the best, Hired puts you in full control of when and how you connect with interesting opportunities. After you complete one simple application, top employers apply to hire you.

Over a four-week time frame, you'll receive personalized interview requests, upfront salary information, and all of this will help you to make better, more informed decisions about your next steps towards the opportunities you'd like to pursue. And the best part is Hired is free. It won't cost you anything. Even better, they pay you to get hired. Head to Hired.com slash changelog. Don't Google it.

This URL is the only way to double that hiring bonus. Once again, Hired.com slash changelog. And now on to the show. All right, we're back. We got a fun show today. Jared, this one is in collaboration with Google announcing the new docs they're releasing, the new open source website for Google. And how awesome is it to have this conversation, Jared? Very awesome. And we have Will Norris here with us, who is an engineering manager at Google, as well as involved with the Google open source office, which will I'm assuming that office is, I don't know, somewhere out in the middle of the ocean or something. I don't know. How do you put an open

source office? Thanks for having me on the show, guys. Yeah. So our open source office is part of the larger engineering organization. We sit, I mean, organizationally, we're very close to the developer relations team at Google because we kind of work on very similar kinds of problems, reaching out to external developers. But yeah, we're primarily based in Mountain View. Geographically, we've got a handful of folks up in San Francisco and then a couple of remote folks. And Will, you reached out to us, I guess, kind of through a connection, Nadia Ekbal of GitHub, also of Request for Commits, one of our podcasts, was talking to you about some cool stuff.

And you mentioned wanting to get in touch. And y'all have this cool thing happening around internal docs and Google being shared. Lots of stuff taking place. So this is kind of revolving around that that big deal you want to kind of maybe intro yourself a little bit and then kind of tee off what is exactly happening here yeah absolutely so uh by way of intro i've been at google for about seven years i actually started in our developer relations groups and so i i've been uh working with other developers is very near and dear to my heart i moved over to to the open source team about four years ago.

And I mean, my background in technology is in open source. Just all the way back to the very beginning, I was working on a project called Shibboleth, which is an open source authentication package. And so I've been involved in open source for a really long time. And then this last year, I've now taken over and now manage all the day-to-day operations of our open source for a really long time. And then this last year, I've now taken over and now manage all the day-to-day operations of our open source office. And one of the things I wanted to do in doing that was to try to tell a better story of all the different open source things

that Google's involved with. There were a couple of really specific problems that we were trying to address with this new website that we're launching. One is that Google does a lot of open source, and it's spread out amongst a lot of different places. So just on GitHub alone, we've got over 100 organizations on GitHub. And so we've got code spread out all over the place there. And then we've got things that are not on GitHub. We have our own internal Git service. So things like Android and Chrome and Go Go for those kinds of projects, the canonical repo for those are on our internal Git service. And so prior to this website, there was no one place to really see the full breadth of all of the open source that Google does. And so that was

something I wanted to try to provide a place to see all the different things that we're doing and how those projects relate and all of that kind of thing. And so the current open source programs office website just wasn't cutting it. You got obviously the cool things you're doing there. Google Summer Code, we know about that. CodeIn, the release project you have, but just nothing that pulled these several hundred organizations together to say, this is the massive impact we're having. These are all the docs we have that show enterprises and small businesses how to better do open source. Yeah, yeah, that's right. So and this kind of actually touches on your earlier question of like, where does this

open source fit or sit within the company? And at Google, the open source office is relatively small compared to the overall size of Google. So most of the open source projects that you think compared to the overall size of Google. So most of the open source projects that you think about being connected with Google, like there are product teams spread around the company that are actually managing those projects and running those communities and things like that. Whereas our open source office, we're relatively small and we focus on things like compliance. So making sure that we advise the company on legal matters relating to open source to make sure that when we're using other people's code

that we're compliant with those licenses. And then like you mentioned, we run the student programs. So Google Center of Code and CodeIn, we have a peer bonus program where we recognize open source contributors a couple of times a year. Yeah, there's just a lot of open source

going on at Google. And so we're just trying to tell that story a little bit better than we've done in the past. Let's talk about the whys behind open source. But you mentioned personally that you've been involved for a very long time in open source, going way back. What about organizationally? We know Google has axioms around open and not evil and things like this, oftentimes equating the two.

But organizationally, a lot of the open source initiatives inside companies, especially companies on Google's side, tend to happen organically because engineers want to do it or people just do it and don't ask for permission. But with how much open source Google has, projects, there's more than just a grassroots kind of engineer by engineer effort. So if you can speak on Google's behalf, why is it so important for Google as an organization to not just have all these open source projects, but then to also bundle them up in an attractive website and do all the things that you're trying to do to help spread the message? Sure. So we have had a formal Google open source office for about 12 or 13

years. It was started by Chris DeBona. He was hired to start the office. And just within the first actually few weeks of his joining Google was when he started putting together the plans for Summer of Code. So this summer will be, I believe, the 13th year that we've done Summer of Code. So every year that Chris has been at Google. But what's really interesting about it is while we've had a formal open source office for 13 years, we've been doing open source for far longer than that. We've been doing it since the beginning of the company. And that open source is really in,

both open source in the code and the model is very much a part of Google. So if you think back to the founding of the company, you know, this Larry and Sergey running, building the foundations of Google on commodity hardware, using Linux, using all the standard open source tooling of that day. So it's been present from the very beginning. operates in kind of an open source fashion in that, for the most part, every engineer at the company has access to all of the source code for everything. And anyone can contribute to any

project at the company. So I can, you know, go and inspect the code for Gmail. And if there's some weird bug that just, you know, is really bugging me that I know the team's not gonna be able to get to, I can go and send them a patch. Wow. Just like a normal open source project. And so and that's the way that Google has always operated. There's actually there's a term for this called inner source, which is actually really funny. When I first heard the term, I was really confused. It was a year or two ago. And I was I was kind of confused because it's like, what do you mean? Like, why do you need a name for this? Because I just took for granted the fact that Google is so open about that. That's the way we've always operated. And it just never occurred to me

that, and I've worked at some other companies where that's not always true, but at a large scale, thinking about not having that openness is painful to think about. And so I just greatly value the structure that we have. Yeah, I mean, that name is relatively new. And anytime you have an old thing that gets a new name, the answer to why is usually marketing. And it has helped. I mean, it's done pretty well, actually, for a bit of a movement of this inner source thing

and other corporations who don't operate that way natively. Trying to move more in that direction, I think, is valuable. But let's go back to your everything's open source inside of Google. So even the crown jewels like the PageRank algorithm, you tell me that you come in as an engineer on day one and you can go at all that stuff, or something's got to be hidden, right? There's a few hidden things, yeah. I mean, there's certain pieces of code. And more recently, as we've started getting into some more experimental stuff, certain teams have put access controls in place and stuff. But it's relatively rare.

Certainly, the most sensitive things tend to be a little bit locked down. But it's pretty rare. Google is more structured to trust our employees and to design systems such that we're very fault-tolerant. And that comes from a technical perspective, but then also at a human level. We know people are going to screw up every now and then. And so we design systems to to deal with that. I'm surprised and impressed that you've had an open source office for 12 or 13 years. I was kind of, you know, it was tongue in cheek a little bit asking where it is, because it seems like many companies open source office was probably some sort of, again, marketing checkbox that you say, yeah, we got one of those.

And that's why I said, where is it off in the middle of the ocean somewhere because it's like something that wouldn't be like core like it's like yeah we just added an open source office because people ask us if we have one and now we do so that's pretty impressive i think that it's been such a long-standing effort and um especially that summer of code's been going that long is just surprising how many years has it been now for summer code i think this will be year 13. wow this summer will be and then code in with so summer of code uh is our program for university students to spend the summer working on on open source projects and then google code in is a newer program i think we just completed year number seven uh which is targeted at high school students. And that's a contest for high school students to do smaller tasks that are related to open source during that since the fall during the winter months.

Winter months in North America. So, yeah. Yeah. CodeIn is one aspect of what you guys are up to that I actually had never heard of until you gave me access to the pre-release of this website. So it's doing a good job, at least in terms of bringing some visibility to that, because I had never heard of it until today. Great. So you have open source in your roots from way back. You have countless open source projects.

Actually, maybe you've counted them recently as you've been bringing everything together. How many open source projects would you say Google has as a corporation? It's, it's a hard question to answer. And it was, it was a question that we, we grappled with a little bit in putting this directory together, because how do you actually define an open source project? So on GitHub alone,

I'll actually, I can give you a live number. Today on GitHub, we have 4,300 repositories, public repositories across all of our GitHub organizations. So 4,300 repositories, some of those, if you think of projects like Android, where the Android open source project has, the last time I looked, it was some time ago, it had like 500 repos related to open source. And like Polymer is, because of the build system that they use, they tend to have lots of small repos rather than a few larger repos. So we think a pretty conservative estimate is 2,000 plus what could be considered a standalone project. And that's ranging from all the way from the really big things like Android and Chromium and the really notable stuff down to just maybe a Googler's 20% project or something that they did over the weekend, purely as an experiment or just for fun. We've,

it's actually something that's maybe unique about Google. Maybe not that our philosophy toward open source has always been about if at all possible, we want to help engineers releasing the release, the thing that they want to release. And we're always looking for how to say yes to, to an engineer that's wanting to release. We're always looking for how to say yes to an engineer that's wanting to open source something. And so that sometimes is going to mean that it's one person working on it in their free time. It's maybe not as robust or doesn't have a whole team behind it

that's going to be able to address pull requests really quickly. But we're okay with that. We actually think that getting all of that source code out there is a net positive or can be a net positive for whoever finds it. So what's the process inside of Google? I know you're formalizing things now, and again, I feel like a lot of these things, especially when you're native open source or it goes way back, is that things tend to grow organically. But as corporations get larger and larger, even as you said, you're starting to have more and more access controls

and things like these that must come into place. What's the process of being an engineer with some source code here on a local Git repo, and I want to take that out and open it up to the world? How do I go about it? Is there a license forced upon me? What's your guys' process for going about open source right so uh you hinted at this earlier one of the things that we're uh launching with this new site is publishing all of our internal

documentation for exactly this kind of a question um all of our documentation around how we release projects how we use projects how we uh send patches. And so for releasing in particular, we treat open source launches like any other product launch at Google. And so we have a calendar or a tool for managing these launches where you'll have a handful of approvals that you need to get. So for an open source launch, you have an end reviewer. We look at it for licenses to make sure that you have a license in place. And much of this is actually automated. So we have a tool that will scan your repo and make sure there's

a license and you have a contributing file. And if you're bundling any third-party code, that that's separated in a way that we require. And this whole process normally takes place within a couple of days. We've got it down in a way that we require. And then this whole process normally takes place within a couple of days.

We've got it down pretty quick. And then we've got a tool that you go to, and once it's all approved, you go and it'll automatically create the GitHub repo for you and you go and launch. As far as licenses, we tend to prefer the Apache 2 license. That's our default license, if there's not a good reason for doing something different. That's probably because it's just a really well-worded license. That's our default license if there's not a good reason for doing something different.

That's probably because it's just a really well-worded license. It has a patent grant in it that we really like. And so it's just a good standard license to use. But we're totally fine. We tend to be very pragmatic about certain communities prefer certain licenses. So the JavaScript community tends to be more MIT. Go itself is a BSD license. And so a lot of Go projects tend to also use the BSD license. And we're totally fine with that when it makes sense to. You know, if you're going to release something in Perl, then you use the artistic license because that's what that community expects.

So we definitely were very cognizant of the communities that we're engaging with and what the kind of the cultural norms within those communities are. What I'm kind of curious, you said that there's a process to do this. So how often does someone in their well-known Google 20 percent time or just anyone else that has a project come to this scenario and want to release something open source and get turned away from it? What are the obvious things that say, oh, this, we can't release that or this, this doesn't work or, you know, how often do people get turned away from open sourcing something? Almost never. It's very, very rare that we would find a project that we say, look, we just simply cannot open source this.

Sometimes it's, okay, this is maybe you're wanting to release some code that's actually owned by this other team, and so you just need to make sure that they're okay with you releasing this. Or actually what happens there really often is maybe you have a dependency that is owned by another team. And so in order to release your project, you actually need that dependency to be open source as well, or else people outside the company aren't going to be able to use it. And so there tends to be more about coordination, things that, you know, we're certainly not going to release any projects that is.

So actually, let me give you an example of a project we would not release. So the spam filters that we'd use for Gmail, it would not be in the best interest of Gmail users if the filtering algorithms were open source, because then the spammers would be able to look at those algorithms and say, oh, well, I know exactly how to get around these. So it's one of those things where it's not even so much about they're the crown jewels, as you were saying earlier.

It's more about it would actually damage the product and it would damage the users of the product. So it's not actually valuable to open source those things. It's the same. I mean, speaking of crown jewels, it's the same concept with PageRank, which would be which is already a cat and mouse game. Sure. People trying to game the system and getting their content to the top of search results um and and google trying to make that as i don't know merit-based and relevant as possible well if they all knew exactly what the algorithm was well you're just giving the mouse some cheese or i don't know what the how that metaphor works but you're you're, you're helping them out. Yeah. Yeah.

So what about stuff that's not quite ready yet? Because surely you guys have, um, standards of quality. And I don't want to imply that any of your engineers ever write any code. That's not good, but do you ever see something that's not quite ready? Like it's half baked,

not, it's not ready to be open source. And so it needs more strategy. I mean, let's wait six months or is that ever happen? well i mean i would push that back and say well what do you think is ready to be open sourced because we have projects that and so the part of this comes from having such um a big portfolio of projects that are just really all over the spectrum in terms of size and complexity and quality

that some in different development models too where we have some projects where it is mostly developed internally and then then released as a whole to the community so maybe tensorflow is a good example of this we released a year and a half ago that that was internally uh had been developed for many many years and we'd been using it for a long time and really perfected a lot of it and then released this, you know, kind of complete package. And now the future of TensorFlow is as an open source project and collaboratively. But then we have other projects that are developed in the open from much, much earlier in their development process. So, you know, maybe something as simple as a design doc, and they actually want to develop it in the open from the very beginning.

So it's really hard to say that there is like a particular bar of quality or of whatever, you know, metric you want to use, because I think that they're all okay. And again, that kind of speaks to our philosophy that we're okay with all of these variances in these things. The one thing that I've been wanting that I hope that we can do with this new website, and this is something I'm trying to do with the project directory that we're launching, is to do a better job of setting an expectation. So I think all of these are okay to do as long as we're upfront about what user

should expect from a given project. Because on the surface, it's difficult to tell the difference between the big fully staffed projects and the, you know, experimental stuff. And it's not to say that anyone's, either one is better or worse. It's just that to be fair to the user, we should try to be more transparent about that. So one of the things that we are including in this project directory is for a handful of projects, and we're hoping to increase this, is we're talking about where we actually use that project inside Google. So if this is something that we use to power, you know, whatever at Google, we're trying to talk about that and say, you know, this is actually something that we use ourselves. Um, and you can kind of take that as a signal, um, for, for what to expect. And we want to do more of that. I mean, that's just the, just the kind of

the first thing that we're starting with. Yeah. I mean, I think you hit the nail on the head there, messaging and signaling and these things. Communication really is the, the absolute key on open source success. Let's take a break here. We come back. Will, I know you have some other ideas around how people can create these messages around what kind of a project is this. Recently, we saw GitHub add topics, which we were very much excited about because it kind of allows you to add labels or tags to projects and give some of that messaging of what this thing is all about. And so perhaps we can talk about that as well.

So let's take a break and we'll take up a conversation around how you message your project, how you explain things on the other side of this break. Hey, everyone. Adams Dukowiak here, Editor-in-Chief of ChangeLog. And I'm talking to a Rollbar customer. Rollbar puts errors in their place. Rollbar.com slash Changelog. Check them out. Get 90 days of the bootstrap plan totally for free. I had a conversation with Paul Bigger, the founder of CircleCI, and he talked deeply

about how they use Rollbar and how important that tool is to their developers. Take a listen. CircleCI is a continuous integration and continuous delivery platform. Our customers are the developers in an organization. Developers rely on us heavily as part of their deployment workflow. So let's assume anyone listening to this is someone who needs to use Rollbar. Someone needs to know about this tool Someone needs to know about this tool, needs to know about this product, needs to know how it's changed how you do business because of it.

I'd like them to know how important this tool is to you. And a better question might even be, could you have done what you're doing with CircleCI without rollbar's help? We operate at serious scale. And literally the first thing we do when we've created a new service is we install Rollbar in it. We need to have that visibility. And without that visibility, it would be impossible to run at the scale we do. And certainly with the number of people that we have.

We're a relatively small team operating a major service. And without the visibility that Rollbar gives us into our exceptions, it just wouldn't be possible. If there's people out there who ship code without Rollbar, I can only imagine the pain that they're going through. Oh, that's awesome. Thanks, Paul. I appreciate your time. So listeners, we have a special offer for you. Go to rollbar.com slash changelog, sign up up get the bootstrap plan for free for 90 days that's 300 000 errors tracked totally for free give roll bar trying today head over to roll bar dot com slash changelog all right we are back with will norris of google talking about google open source and the brand new shiny website,

opensource.google.com that has a few purposes, Will. And one of the purposes we teed up before the break was helping you guys really explain and communicate what kind of projects you have. This is something that everybody struggles with. In fact, a few episodes back, Adam and I were discussing with Chris Lamb about some throwaway code and whether or not it should be open sourced. And some of the conversation there is like, how do I actually communicate that this is a throwaway?

Or like you said before the break, some things are experimental. Some things are flagship products that you're developing internally, internally but open sourcing for other reasons other things uh you want the community to design it so let's talk about that problem in general and then why you think this website is a specific solution for it for google at least yeah absolutely uh it's certainly a problem that uh that anyone that's doing any amount of open source is dealing with. I don't even I wouldn't even go so far as to say that this website is yet solving that problem. I think this is us beginning down that path that there's so much to that of how do you set appropriate expectations? You were talking before the break a little bit about GitHub's new tag feature, which, you know, or I figure what they call it, labels or topics. They call it topics.

Topics, yeah. I mean, even something as simple as that gives you at least something to pivot on to start to set that expectation. There's actually a number of really interesting projects around this, around like status badges. You know, like most GitHub repos have these badges at the top of their readme file, sort of from like shields.io or wherever,

that talk about, you know, whether their tests are passing or, you know, various things. Lots of people are having these things. And there's a couple of efforts that I've seen to try and define some set of values for indicating the status of the project. And that can be something as simple as this is like completely experimental and might, you know, kill your cat.

Or this is, you know, we run this in production. It's kind of interesting that, and I've sort of hit into this earlier, that so Facebook, by comparison, they've been very upfront about everything that they put in github.com slash Facebook is something that they run inside Facebook in production. And so, and that's great.

And so that sends a really strong signal for those repos. We haven't taken that stance because I don't, personally, I don't think that like the GitHub organization is necessarily the right place to try and divide. The problem is GitHub organizations only provide like one access on which to divide projects. And I think when you're dealing with a portfolio of 4000 repos, you need more than just one access on which to try and slice and dice your projects. And so that's what we're trying to do with this project directory. So like we don't have, we don't yet have something like a status value that just is one of three or four different values that, that say, is this experimental? Is this stable? Is this, you know,

whatever. But that's absolutely the direction we're trying to go. And we're, we're talking very much with, with Facebook and Microsoft and other companies that are struggling with the same type of thing. And we're actually collaborating, trying to come up with a more common way of expressing that kind of stuff. This is interesting because I often go to orgs on GitHub and feel the pain of basically of not being able to know what teams they have, who owns what, how the teams are formed. It's sort of just like, here's all of our code. Here's a list of it. It's ordered by most recently contributed to or most active, basically. On the right-hand side, there's some people,

and good luck finding out what they actually contribute in there unless you go to their personal profiles. It's very antiquated on how you can actually dive in. So you're hoping to solve that problem through this kind of site for Google? Yeah, I think so. I don't know you're hoping to solve that problem through this kind of site for Google. Yeah, I think so. Like, I don't know if that will necessarily solve the problem of identifying

exactly which people commit to which projects, although maybe absolutely that's something we could explore down the road. Well, for example, they, Jared and I reach out to people all the time to bring them on the show. And it's very hard to say, well,

here's something cool. You know, it starts with a project, for example, right. And then we're like, who in the world do we reach out to? So that we end up basically just spamming them with an issue and with a humble sorry about that but we don't know who to reach out to so i feel like

one it's recognition two it's just who is involved so it kind of onboards contributors it just better informing you know which projects do you have and then who's involved in those projects? Yeah, it's really common. Like internally at Google, we'll have each product team or project team will have an internal site that identifies who's the PM, who's the tech lead, and may or may not list all of the engineers, but it's at least like, who is the primary point of contact for this? If I just wanted to get more information, who would I reach out to? And that's something that's often really difficult for open source projects. You're absolutely right.

I mean, you can go to github.com slash Google and go to the people tab. You've got 1,262 people on your org, and it's easy to go and find out who they are and follow them, but it's very hard to find out who they are and what they contribute to. Yeah, sure. And we found this with a lot of things on GitHub that, you know, it's actually, I mean, GitHub has been great over the last couple of years and adding more features and new things. But my philosophy around a lot of things has been that I never want to fully rely on GitHub to solve this problem for us. Right. For a couple of things has been that I never want to fully rely on GitHub to solve this problem for us. Right. For a couple of different reasons. One is, you know, our needs are the things that we care about are going to be a little bit different. You know, you care a lot about being able to reach out to the primary point of contact so that you can interview them. You know, we care about

whatever other things and GitHub may or may not care about those things enough to build them into the product. Right. But the other reason is that, you know, not all open source in the world is on GitHub, that it's great and we love GitHub and we use it extensively, but we don't use it for everything. And so any product or any kind of solution to these things that we're looking at, we also need to keep in mind that, you know, that we have code off GitHub and, you know, GitHub is only whatever, eight years old. Another eight years from now, it may be something else entirely. And so I'm much more interested in finding ways of so. So, for example, when we were talking about how to represent the status of a project, I would love to get some of this data down into the project itself.

So when we were building this project directory, we do pull a good bit of the data from GitHub's API. But again, not all of our projects are on GitHub. And so I don't want to rely on GitHub's API for any of this stuff because not everything's there and not everything's going to be there forever. But I would rather see this data actually live in the repo. So you have a readme file. All major projects have a readme file that is for human consumption. It would be great if there was some file in there that had all this metadata for machine consumption to power something like the project directory that we launched.

And you see this in a lot of different language communities. You know, NPM has, I think it is package.json, and PHP's composer has their thing, and our packages have a description file, and you've got all these different language-specific ways of doing it, but I would love to come up with some kind of cross-language, cross-organization, whatever standard way of expressing this data

that GitHub could then use to power their UI or any other system could use to power their UI and keep that stuff in the repo itself so that it's portable. Because Git's great in that it's a distributed source control system, but when you think about something like GitHub, there's a lot of information around the project that's not actually stored in git you've got issues you've got pull requests you've got you know various other things and so i'm really interested in projects that are trying to make all of that data more portable well it's

similar to like the contributing file license i mean there's a handful or changelog although there's no uh nobody uses that the same way the problem is that as you're identifying is everybody's using these things in different ways and so there needs to be a more formalized specification and you know maybe that has to start with github implementing it because oops siri just talked to me sorry about that she just said perhaps not i was like well maybe she disagrees yeah well she's like the magic eight ball quite possibly wrong but it seems like it has to start with github or sure because they're the biggest player in the hosting space right now if they would come up at least

supporting us back and saying okay if you put this file in your root or please don't put it in the root put it somewhere else we got enough files in the root of our projects. Um, make it, make it a dot file or something. Um, if you put this file in, you know,

we'll, we'll pull it out. And then from there, other people will, will perhaps follow suit. But do you think that's the best strategy of getting something like that actually implemented? I don't know.

I think it's, it's something I'd like to explore. And so we actually have been talking with GitHub about exactly this. And I think they are open to the idea. So in this actually kind of segues, we've been talking with a lot of companies about these things that through a group

that we're a part of called the to-do group, which we can kind of talk a little bit about that. It's kind of a collection of companies, open source offices. So the people that do open source at all these companies, we started this group about two and a half years ago to share best practices, to kind of just collaborate and talk to each other and say, you know, what are you dealing with? And so this is actually one of the topics that we've been talking about over the last few months, is we're all dealing with these same kinds of problems of needing to express some more metadata. So Netflix actually has exactly such a file.

They call it OSS metadata, that they have a lifecycle field that expresses where in the life cycle is this project. So I think it's possibly a solution. I don't know if it's the solution. I actually care less about what the solution actually is and more about finding something that we can agree on. Yeah. Yeah, exactly. That's interesting that you, you know, with to do group that, you know, you've got a membership

there. Netflix is in there. eBay's in there. Capital One's in there. Huge contributor to open source've got a membership there. Netflix is in there. eBay's in there. Capital one's in there. Huge contributor to open source. You are in there. GitHub's in there. So lots of,

lots of larger organizations, enterprise organizations, so to speak, that have been down the road, been developing their own software, been doing inner source, potentially even, even if it hasn't been named that for very long,

they've been doing this. They may have things like this. They're like, well, we feel the pain. We don't know how to describe the maturity of the project or the SLA or if it has an SLA or whatever. Yeah, absolutely. So we're finding that the conversations we're having, we're absolutely all solving very similar issues

and we're all just at different points along the path of trying to sort this out and figure it out it's been actually really interesting seeing companies like capital one or autodesk or companies that you don't traditionally think of as open source but companies that have been around for a really long time and seeing their approach to it, because they actually bring so much more cultural baggage when they're trying to embrace open source, particularly if they're coming from a company that's not used to that kind of startup that grew up in this open source world where it's just taken for granted. And so while they're younger, in many ways, it's a lot easier for them to sell this to their management.

Before we go too much further, can you give the listeners kind of a brief, quick rundown of the to-do group and what it is? Sure. So the group started in, I want to say it was like September 2014. It started with James Pierce, who at Facebook, who's a good friend and colleague from David Recorden and was sending out feelers to friends and colleagues around the Bay Area or around Silicon Valley saying, hey, you know, I'm doing this open source thing now. And like, I assume you guys have some kind of group or you talk or you meet or something. And it was like, no, not really. Like we, we have one-off conversations and,

and like Chris DeBona knows everybody and everybody knows him because he's been doing this since the nineties. Um, but for like some of these newer companies or people that have recently taken over, uh, open source at these companies, they just didn't have those connections. And so the group started by just bringing those folks together and saying, look, you know, we're all trying to do open source from a corporate perspective. And realizing that the types of challenges that companies face in trying to do open source tend to be a little bit different than, you know, your typical individual open source developer. And so this was really an attempt to try and get people that are doing open source from a corporate perspective together and allow us to share best practices

and just share tooling if possible and things like that. Have you seen a lot of fruit coming out of that? Yeah, absolutely. So we're now actually part of the Linux Foundation. The group started very ad hoc and eventually we moved into the Linux Foundation. What's sort of ironic about the group is to do, there's a acronym for it, which is talk openly, develop openly. And it was because it's all about within this group being open and sharing our practices. But a large part of that discussion actually happens on a private mailing list, which is, you know, sort of ironic. We're doing it openly in private.

But there's actually, I mean, there's good reason for that, because we're often talking about some really sensitive things. And I was talking with Adam about this, right? Like a little bit ago of sometimes even when you're, you're generally very open about things, there is value in being able to have a conversation about the people that are actually affected by it in a more controlled setting so that it's not being scrutinized all the time. Because as soon as you,

you know that everyone's watching you and everyone's going to, you know, take every word that you say and try to twist it or use it or whatever, then you're much more reserved and you're just, you're not going to open up in the same way. It goes against the open part of it, which is, you know,

right. It actually has the, the complete opposite effect because it causes people to close up and not be willing to share. Absolutely. So, yeah, there's actually been a lot of grapefruit. We meet about quarterly and we have been accepting new members at a pretty regular clip. But with a lot of the things I'm trying to push, you know, efforts that I'm involved with to the more, and there actually is a public mailing list as well.

It doesn't have near as much traffic. But so for example, we were talking about the project metadata file. And that's actually one of those things that there's really no reason for that to be in a private setting. And so I've been trying to push that conversation into the public discussion forum.

And so we have a public repo where I'm trying to track down some of the prior art around this on the to-do group GitHub org. And so as much as possible, we're trying to push things more into the open sphere where we can. Yeah, I think when it comes to those types of things,

the more people involved, the better in terms of, like, this is going to be a thing that the whole open source community hopefully adopts as a way of adding this metadata to their repos. And so, you know, you say you don't care too much about the details of it, but trust me, there are people who do. Oh, yes. Oh, no, absolutely. Yeah, you're absolutely right. This is a perfect example this is this is a perfect tell them how you feel no i don't have i only my only opinion i've already stated it which is like less files in

the root of our projects please that's that's my only opinion it's definitely getting crowded it's like a super long list and they're all they all end in you know something file i've i've gone off on this before but you know docker file gem file blah blah blah well the reality is most of these like i'm not even sure that we need a new file and that's the thing is i just want to make sure that the data comes from the repo that i don't want to be beholden to any one host right i don't want it to just live inside some GitHub database that I can only access through the GitHub API. I actually want it to live in the source files. And maybe that means using existing files. Absolutely. So from that perspective, yeah, I'm totally open to whatever the implementation looks like. Yeah, if we don't have to add another

file, by all means, let's not. Yeah, yeah i agree so one of the things that you mentioned during the break which uh seems like it's a good time to talk about now with regard to the to-do group and some of the the uh the original inspiration or the desire behind the documentation side of the website that you're launching we talked about the project side and helping message those and really kind of bring them all into a place where people can see them. But it sounds like to me, the exciting part of what you're launching this week is this documentation of how we do open source. Did that come out of these to do group conversations as you've been having? Directly. Yeah, absolutely. It came out. So we've been having these kinds of conversations for two years now of, hey, how do you all deal with, you know, employees doing things on their own time?

Yeah. Right. You know, GitHub just published their their new policy on how they deal with employees doing things on their own time and all of their IP policy for that. Questions of how do you deal with, how do you actually manage your GitHub organization? Like how do you deal with when people leave the company and what are the tools that you use for that and all of those kinds of things. And so we've been having these kind of one-off conversations for a long time.

Actually the more recent one was dealing with CLAs, contributor license agreements, which on and off tend to be a hot button issue. You know, it was widely discussed a couple of years ago when Node publicly said that they weren't going to use CLAs or when Joyent said that they weren't going to use CLAs for Node. And we have our rationale. What's a CLA? Just so there's no acronym behind that.

Yeah, so a contributor license agreement is what you'll see with some open source projects is when you contribute to the project, the project maintainer may want you to sign a contributor license agreement. And so this is an explicit license of what you're contributing to the code base. There's a similar type of agreement called a copyright assignment agreement where you actually assign your copyright to the project maintainer. That's not what Google does, and that's not what most companies do. All CLAs are different, though. They're not all the same.

There's some sort of agreement, though. You're contributing, and this is a license you agree to, to say what we want to do or what this agreement says we do with your code is what we do with your code. So like not everybody is trying to assign IP. It's is that right? So most CLAs are not copyright assignments. That's correct. But also most CLAs are actually modeled after the original Apache contributor license agreement. So the Apache

Software Foundation, most people know the standard like Apache 2.0 license, but they also have a contributor license agreement, which years ago, Google took the Apache license, sorry, the Apache CLA and modified it very, you know, put our name in place of Apache and just modeled ours after theirs. And since then, Facebook has modeled theirs after ours, and I think Yahoo might use a similar one. I don't remember what Microsoft uses, but most of these companies do have some form of CLA, and most of them are very similar in language based on the Apache CLA. And that makes it a whole lot easier for,

for lawyers that are reviewing these to look at it and say, Oh yeah, this is a standard Apache CLA. I know what this is. I understand it. Yeah, we can, we can sign this. Right. You mentioned, we're going to take a break here in a second or two, but you mentioned James Pierce a couple of times and for the listeners, long time listeners know that we had James on the show back on episode 211 and that show was titled Open Source at Facebook. And one of the reasons, and what we talked in the pre-call kind of preparing for the

show about this, one of the things that Jared and I were very excited to do that show with James about was because having a model, you know, which is what you're doing with the documentation here, having a model for other enterprises or other, you know, sure, not everybody's the Google size of the Facebook size, but there's a lots of companies out there that are looking to find better ways to embrace open source, to lead open source, to allow open source, to be part of their business. And, you know, I couldn't be more excited about you all doing this so with that said we're coming up on our second break here when we come back we're going to dive a little deeper into some of the docs that you all are sharing and some of the hopes and

dreams behind them and potentially how those who can can appreciate them can check them out so we'll break right now we'll be right back head to go cd.io slash changelog to learn more about this open source continuous delivery server go cd lets you model complex workflows promote trusted artifacts see how your workflow really works deploy any version anytime run and grok your tests compare builds take advantage of plugins and more once again head to gocd.io slash changelog to learn more. And now back to the show. All right, we're back with Will Norris talking about Google's open source documentation. Now you've already had this open source office website

out there. This is a new and improved version of it. opensource.google.com um i believe slash docs is the url we've got some early access to this so our url is a little different than maybe the ending version of it but um you know i mentioned the call will with james at facebook james pierce at facebook and uh jared you can back me up on this like i was so excited to have that conversation with them because we obviously we've been doing this show since 2009 so it's been forever like we we love open source we think it's the lifeblood of the future of software and what we're doing so to see organizations like Google like Facebook leading the way but in particular not just leading the way in terms of like sustaining and funding and employing people to maintain software, but also very much so documentation. Like people underestimate how important documentation is.

And to see you do this is a cool thing because you're helping so many organizations lead the way. I couldn't say it any better. But let's talk about this. So this wasn't in place before you championed this. How hard was this to sell to anybody else? Was this a big ordeal to get in place? What was what's the behind the scenes of this? So it was it was a little set the stage for this, that these docs are quite literally our internal documentation for how we do open source.

So this is, I said this a little bit earlier, how we release code, how we patch, how we bring it in. But this is, we've done very, very minimal cleanup to these docs, and it's mainly to remove references to internal things that aren't really relevant or to remove email addresses or some basic things like that. But for the most part, these are just identical copies to what we've had as our internal documentation for doing open source for many, many years. And so what's kind of interesting about that is we actually did leave in, we didn't try to cater it to an external audience. And so we're very upfront about this is the way that we do open source. We're not trying to be prescriptive.

The way that we do open source is not going to be right for every other company. And so you should definitely not view this as a how-to guide. But, and we said this in the blog post, we announced the site, that in the same way that viewing another engineer's source code and seeing how they solved a particular problem in their code is useful. We hope that seeing how we address certain open source problems is useful, even if you choose to go about it a different way. I think that there's value in just seeing how others solve those problems. And so that's what we're really hoping to achieve here is just by being transparent

about our docs aren't perfect. Our processes aren't perfect. Some of the things that you read might not make sense for someone outside the company. And so there may be a few things in there that just, you know, don't don't stick quite as well, because it all of these docs were originally written for an internal audience. But rather than trying to write a different set of documentation for an external audience, we thought that it would be really valuable to just put it out there and say, look, this is what we have. Very nice to see it also licensed liberally as well, Creative Commons attribution license. So in the spirit of open, it's out there for others to use with attribution.

Yeah, absolutely. So Adam had actually asked me that earlier about whether we were open sourcing this site, which is another thing that comes up often in the to do group that a lot of the tools that we have built, us and other companies, are not open source for various reasons. And so the site itself is not being open source. But as you said, the documentation we are putting under a CC BY license because we want people to be able to take this and use it. We're not actually putting it in a public GitHub repo because we're not really trying to collaborate on these docs. It's not really the goal of what we're trying to do here, but we do want people to be able to take it and apply it and use it in a way that makes sense for them. They're more of an artifact of the way that you're doing things as opposed to a working document of the way you want to do things.

And so there's no reason to have community involvement around the creation of these because they are a reflection of what Google's doing internally. Yeah. Yeah, absolutely. The contribution and conversation can blend on GitHub quite easily. Like so sometimes open sourcing something might simply just to be having a conversation around it rather than contributing to it. So for those listening that dig into this, these docs, if they have questions, conversation they want to have around something, what's the best way to go about like reaching out to somebody to say,

hey, I've checked out your policy on GitHub and Google. I've got some questions. Yeah, absolutely. That's a great question. I'm glad you asked it. So like on the site, we do have a feedback mechanism, which is like a standard way

to leave feedback in Google Sites. And so that does come to us and you can leave that. That's more really for like reporting bugs and things like that. But for really having a conversation, what we're hoping to do is to push those conversations toward the to do group to the. So it's to do group all in word at Google Groups dot com. You'd have to go and join the group. But that's a public group that anyone can join because it's I think the more interesting conversation is not just around. Hey, Google, I saw that you did this thing and I want to talk about it.

You activated Siri a few minutes ago and I actually just activated Google now by saying, I think I said, okay, Google. We've created our own prison, haven't we? We have. So I think the interesting conversation is not just looking at how Google does things, but to have, and not having that in a private context, but to have a public discussion around, okay, so Google says that this is how they do things, you know, and then, and bring in other companies and say, how does your process compare? And can we, and these are the kinds of conversations we've had, um, in, in the smaller context within the two group, but I really would like to have these in a more public setting, um, which is one of the reasons why we're putting

these docs out there is we would love to invite that conversation. And I hope that the two, the two group becomes a good forum to invite that conversation. And I hope that the to-do group becomes a good forum for having that conversation. Let me just give a little, I guess, constructive feedback on the to-do group website, because the way it looks is it doesn't look very much like you are invited to come join this group. It looks very much like, hey, check out what GitHub and Facebook and Adobe and Microsoft and Netflix are doing. But, you know, maybe you run a five person, you know, development agency. It doesn't say every corporation that wants to do open source should be a part of this.

And so you're saying that's what you want. You want more people to come join. I think that message is lacking a little bit. Yeah, I think the site has not actually been updated since we launched in 2014 okay i i don't know if that's actually true but i think it is uh and it's we actually like i said the the origins of the group were very humble and it was just a few of us getting together say hey we should talk right and it was it was really put together in about four days um um, right before, um, uh, whatever the, there was a big Facebook event, uh, right before it.

Uh, and so we actually didn't know how we were going to deal with accepting new members. And so we were trying to figure that out. Um, but separate from like the formally joining the group. And that involves like, I think being a member of the Linux foundation and things like that, there is a public mailing list that anyone can join. You don't even have to like be a member of the to-do group. You don't have to join the Linux Foundation, anything like that. There's just a public mailing list.

And I'm not actually sure that it's even linked to from the website. So I will make sure that that gets fixed. Because I think there is a good opportunity for companies of any individuals, um, anyone that's interested to, to be able to be a part of that conversation. Yeah. Yeah. I think we should definitely get that, uh,

address and put it in the show notes for people interested. I'd be interested even just to lurk on there and just be a fly on the wall because, uh, I'm not, you know, running a corporation that is interested in open source. I guess you could consider it unless you consider the changelog or

a small business that cares about open source. Honestly, I mean, because our site is open source. We clearly care about it. Right. And I would even say that, you know, I would love to be involved in those conversations and even just, you know, hear some of the trials and tribulations that everyone's going through

because, you know, being people who are involved in open source, I think we probably have insights to share. Sure. Yeah. And maybe the to-do group is not necessarily the right venue for that because, you know, it was created to serve a very kind of specific need that we didn't feel was being addressed at the time. And so by just publishing our docs in the way that we are, anyone can, you know, reference those docs in whatever community they're part of. Um, and, and we're happy to, to go to where the audience is and to have those conversations in the venues that make sense. So, yeah, I mean, there's no, no reason why it has to be within that one mailing list or anything

like that. Sure. Well, one thing you said to me in the prep call for this was around the to-do group. You said this is for companies who have or have the need for a dedicated open source office and or open source resources. Right. Yeah, that was kind of our general very rough litmus test when we started the group was, um, it was kind of targeting companies that are of sufficient size that they have need for dedicated open source resources, um, where sufficient size is intentionally undefined because it's going to be different for different companies.

Um, and that's totally okay. Um, but, but yeah, I mean, that's, that's kind of the idea. It was that it just we felt like the kinds of problems that a company faces is different when you're a, you know, a two person startup like changelog or whatever versus a hundred person company or a thousand person or a ten thousand person. Yeah, let's let's focus a little bit on the docs. I think we've covered that to a large degree. We have two big angles, creating and using. And inside of the creating side, you have releasing a project, which drills down. You have GitHub at Google, so how Google approaches GitHub. Open source patching, personal projects. Any of these stand out as something that you'd like to maybe hatch open and just discuss a little bit? Anything that is unique to Google or interesting to our audience?

Sure. I mean, like, so I know, Adam, you were kind of interested in the GitHub at Google. And so I'm happy to talk about that too. So this particular page is talking about how the way that we have sort of embraced GitHub. So kind of an interesting tidbit, I joined the open source team originally,

whatever it is, four years ago, originally as a 20% project that I was working on Google+. I was an engineer working on the API. And there were a number of teams that at the time, we didn't release things on GitHub, we still release things on Google Code, which was our hosting platform at the time. And a number of teams were saying, look, the developers we're trying to reach, they're on

GitHub, we need to be there. And so we're like, okay, let's do it. And so I spent a 20% project for about a year of managing our GitHub organization. Originally, it was just github.com slash Google. And so that was kind of my introduction to the open source group at Google. And I managed that for about a year and then eventually came on full time. And so now it has become a very major part of the way that we publish open source and the way that we engage with that community. And so we have some policies around how, and part of it is just practical things of how we deal with security on GitHub. We require everyone to have two-factor auth enabled.

We generally encourage Google employees to use existing GitHub accounts if they have them. Some people really like having work and personal stuff separated. And for those that really want that, we're totally fine accommodating that. But we found that, number one, that that can be challenging from a technical perspective. But I actually think it is in the employee's best interest to use the same account because you're not going to be at Google forever. And when you go, like Google, GitHub has done a really good job of building up the reputation of an engineer or of a user on GitHub. So, you know, you have your contribution timeline and you have all of these things. And you were saying yourself, like you want to go to a person's profile and see what do they work on or what have they worked on in the past? You know, some people use GitHub as their resume for better

or worse. Um, and so we actually think that there's a lot of value in just using that account for, for work stuff as well so that it's, it stays with you. And so, and then we deal with things like what happens when someone leaves the company and stuff like that. And we've got policies around all of that. Yeah, it gets really hairy. Interested to hear your policy around personal projects, which is part of this documentation. GitHub just made waves this week with their new employee IP policy, which is very much allowing the employees to maintain copyright over things that are personal projects, um, historically. And it looks like Google has been this way where anything you work on, on Google time is Google's, even if previously it was yours in terms of the property. Um, can you talk about that a little bit in terms of what's out there and, and, and correct me? Cause I'm probably miss misapplying it. Yeah. I was gonna say, let me correct you on that. Thank you. So yeah, what our policy is, it's not that we're claiming any rights to things that you did prior to employment at Google.

It's that any work that you do, any additional work that you do on those projects, of course, anything that you did prior to employment at Google, that's yours. That's fine. But if you can, when you continue to contribute, then Google potentially owns the IP for that. The IP for the improvements. So let's say I have a Jared widget 1.0 that I created on my own time. And then I come into Google and I was like, oh, you guys, you know, what you guys need is Jared widget 2.0. I'm going to improve this on company time. And so now Jared widget 2.0 is completely owned by Google or just the parts that I worked on or it's really hairy, I'm sure.

It does get really hairy. And that's actually kind of the thing that I think maybe got missed with GitHub's announcement is that GitHub does a really great job of taking complex things and making them look simple. They've done that with Git. They've done that with many things. But this is one of those areas where you can try to make it look simple, but a lot of them it's just not. That employment, all of these legal things are relatively complicated. And so our policy and what you see on the site is that we realize we can't come up with a simple blanket rule. And the thing that really gets you that makes it super complicated in employment law and in most areas talk about whether the work is within, you know, the research areas of the company or a product that the company is working on or might be working on. And that gets really complicated at Google because we're involved in so many things.

And so our approach to this has been that we have a committee called the Invention Assignment Review Committee, which is what's talked about on this page. And if you have a project where you want to own the IP, you can bring it to this committee and they will review it and say, okay, yeah, this is outside of the scope of what Google works on and really outline the conditions under which you could continue to work on that and own it. So we very much have a process where employees can do side projects and they can own the IP and all of that. But it's not the kind of thing where we can just draw a bright line in the sand and say, OK, if you're on this side of the line, you're good to

go because it always has to be dealt with on a case by case basis. Yeah. One thing, okay, if you're on this side of the line, you're good to go because it always has to be dealt with on a case-by-case basis. Yeah. One thing, too, that blurs the lines there, Jerry, with GitHub's announcement, and this is quote-unquote, so I'm not sure how accurate it is. It's a journalist. It could be not spoken correctly, but it says, as long as the work isn't related to GitHub's own, in quotes, existing or prospective products and services.

Now, if that were a Google announcement saying the same thing, you all have self-driving cars, you have search algorithms, page rank. So it's what could not be a Google product. You know, so it'd be kind of hard. So that committee, you know, I don't know how accessible they are or how, dare I say human, I just mean more like, do you talk to an email address or do you actually talk to people? That's kind of good to have, though, because then you can actually have some formal way to say, hey, I made this thing.

I want to keep it mine. Is that possible? Yeah, and that's exactly what it is. It's real humans that you can talk to. And like the phrase there that you quoted, like, I'm not a lawyer, especially an unemployment lawyer. I don't know exactly how that should be applied in all cases. Uh, and, and there's sometimes different jurisdictions and there's all these different things. Um, so that's why exactly why we have this committee, um, to provide some clarity, uh, to, to employees that they just want a clear answer.

Yeah. Just reminds me of that Silicon Valley episode where they had to figure out if he wrote a single line of code while he was with his girlfriend. Right. So, yeah. So, well, Chris DeBona, the guy that founded our open source office, was a technical advisor on Silicon Valley. And so they actually advised them on exactly that scene. Wow. It's actually pretty accurate. That's funny.

Well, uh, let's, we've got about four ish minutes left in our estimated time for the show. Um, and I don't want to go without talking about one thing, which is growing. We're all trying to better support,

better grow open source. And one blog or one, one doc you have here is on funding and we have a show called request for commits as you mentioned nadia before nadia ekbal by the way uh her and michael rogers produced that show rfc.fm or changelog.com slash request for commits it's actually not request from it's rfc slash rfc my bad you know we're big on sustaining maintaining the human side of code uh what is your stance on funding and sustaining open source and how do you go about doing that at google not you personally at google yeah yeah i personally give you know whatever you actually

i do i do fund uh like i'm personally a member of the software freedom conservancy because it's you know something i believe in a lot uh but as a company, we take that really seriously of the need for sustainability in open source. And so we have an outreach team within our open source office that one of the main focuses that they have is ensuring sustainability of open source in a lot of different areas. And sometimes that is simply you need some money. A few years ago, in the wake of Heartbleed, the OpenSSL bug that affected so many people, the Core Infrastructure Initiative was created within the Linux Foundation. And that's a group to provide funding for so many of these projects that make up really the basic infrastructure of the Internet a group to provide funding for so many of these projects

that make up really the basic infrastructure of the internet, but are not being cared for in the way that they need to be. They're not being funded in the way that they need to be, pursuant to how critical that they really are to the internet being a safe place to actually operate. So we contribute to CII. We contribute to a number of different things. But then also, even outside of the monetary,

really the core reason why we do things like Google Summer of Code and Google Code-In, which is where we expend a lot of our energy, is ensuring the sustainability of contributors, of making sure that the next generation of developers are aware of open source and that they're getting involved and that all of these projects have this fresh lifeblood, I guess, if you will, of contributors to take on those projects. So, I mean, everything that we do within our outreach team is focused on sustainability of open source in the many forms that that takes. That's awesome. Well, obviously, I mean, we really care about the future of open source and money doesn't always solve things.

And sustaining can be broken down into funding, supporting, nurturing, guiding. Google Summer of Code is obviously a good thing for that. Just giving guidance to those folks out there who are making new software and new open source projects. Giving them mentors to follow. Giving them resources like this to follow potentially. So certainly appreciate that. But well, what else can you share about what's going on here with the docs that you are sharing? These are internal, obviously, as you mentioned before. So this funding will be mentioned, get out of Google, maybe even your licensing or how

you handle personal projects. What else can we highlight before we close out? Sure. I mean, and then the other piece of all of this that we hadn't really touched on is how we use open source code. And I think this would be something that it's something that someone's going to have to go through and really look through carefully to see how it applies. But a huge part of any company, even if you're not releasing open source code, you're not releasing your own projects. Most every company is almost certainly using open source code in some form or another. And depending on the licenses of the packages that they're using, depending on what they're

doing with them, if they're shipping them to customers, there are different obligations that you take on. And so that's the other half of our open source team. We have our outreach team, we have compliance of how do we make sure that we are respectful of those licenses? Not just because, I mean, yeah, we're legally obligated to do so because it's in the terms of the license, but it's the right thing to do. Like this person put this project out there for free and we're able, we're deriving a huge amount of value from it that we want to acknowledge them.

If that's all they ask, give me acknowledgement, which is what many open source licenses require, we're more than happy to do that, and we want to. So we actually spend a lot of energy in keeping track of all of the open source code that we use inside Google. And it's a lot of code. It's literally hundreds of millions of lines of open source code that we use inside Google. And it's a lot of code. It's literally hundreds of millions of lines of open source code

that we use inside Google. So keeping track of that is a lot of work, but it's something that we feel is really important to do. And so for those out there following along with this show to take the next step, obviously you got opensource.google.com, which is a new url the the old site was developers.google.com slash open hyphen source which i'm assuming will not redirect is that correct yeah that's correct

and then you've also got to do group.org which you can check out and i believe uh you'd mentioned a mailing list that people can email for feedback which which is to do group at Google groups.com. Is that right? That's right. All right. We'll put all those in the show notes. Well, thank you so much for taking the time and more importantly,

thank you for reaching out to us and planning the show with us. It's, it's always fun to coordinate announcements like this. It's a big deal for us to have this conversation. It's a big deal for the community to, to, to have this conversation, to kind of human deal for the community to have this conversation, to kind of humanistically dig into this announcement. You know, you're going to put

a blog post out there. It'll have one version, and then they can actually hear directly from you all the backstory, all the behind the scenes of this fun stuff. So thank you so much for coming on the show. Yeah, I had a lot of fun. Appreciate being on it. All right. That wraps up this episode of The Change Log. Join the community and Slack with us in real time

at the changelog.com slash community. Follow us on Twitter. We're at changelog. Special thanks to our sponsors. Also, thanks to Fastly, our bandwidth partner. Hit the fastly.com to learn more. Huge thanks also to

Breakmaster Cylinder for the awesome beats for our shows. We'll see you again next week. Thanks for listening. Bye.