 Making it open. Google has provided not just one Dan, but two Dan's to help us navigate that space. So I'll hand over to Dan Nadasi. I'm Bentley. Bentley. Hey, I'm Dan Bentley. That's Dan Nadasi who should come up because we're both going to be talking. So we're talking about open sourcing existing successful closed source projects. And this is a really different challenge than just making an open source project. Because the code's already written, which is a lot of the work. But there's also successful projects. They mainly have three contributors. But those three contributors, because they work 40 or 50 or 60 hours a week on it, are really doing great work. And so it's a very different challenge, which we'd like to talk about. And I think the big point here is that we want feedback. We've done this a lot at Google. And we'd love to know how it is at other places. And if you have stories, or war stories, or anything to share, please just shout out your comment, or raise a hand, or throw a shoe, or whatever, because we would like to get your perspective. So just a bit about us, I guess. So Dan works full time in the open source programs office. And this is sort of what he does, is helping Google to release code, and make open source better, and various other cool things. And I do it in my 20% time. So roughly one day a week, or one week every month, or something like that, I'll spend a bit of time helping doing open source stuff. And I got into this in 2008, mid-2008. Someone started a little open source group in Sydney, and said, let's try to help local open source communities, open source stuff from the Sydney office, and so on. And I found out that a lot of stuff was blocked on one particular product, which is what it's now known as closure, or closure tools, to be precise. So internally, so closure tools, for those who don't know, is comprised of a JavaScript library, which provides a large supply of various different forms of functionality, sort of similar things to the sort of stuff you'd found in jQuery, except a bit more sort of heavyweight and intense. But jQuery is if you want to add functionality to a website, closure libraries if you want to build a web app. Yeah, I think that's a really good way of putting it. And it has a large supply of functionality for all of the sorts of stuff we build at Google. So it's got the wrappers around AJAXE communication stuff for building various sorts of widgets, or all of this sort of stuff. There's the compiler. I'm trying not to spend too much time on this because it's sort of getting away from the point, which is very, very good for those who haven't tried it. It's essentially if you want to minify your JavaScript in an effective way, and also do various cool things, like strongly type checking your JavaScript, and so on and so forth. And a few other things in the closure tools suite. And so back in 2008, I had sort of gotten into this open source thing, found out that this was blocking it, and I wanted to release this project. And sort of the process that I went through, I think, is a bit instructive for sort of how this has worked in the past, and what we've tried to do to fix it, which is why I want to sort of tell the story. So I started out, and I happened to know the two guys who were maintaining closure, the closure library specifically, and there were two guys who were maintaining it in their 20% time. So they already had their hands full doing lots and lots of stuff already, and they were maintaining this huge thing, which already had 400 different contributors from across Google. And so I emailed them and said, hey, look, has anyone tried to open source this? And they said, no. Well, I mean, we've thought about it, but we have no time if you want to go ahead. And so I said, OK, how hard can it be? And so I sent an email out asking for help, and one other engineer, Nathan Nays, decided to help me out. And a tech writer, very kindly, decided to lend his time on the documentation stuff. That was David Westbrook. And so we continued on. And we came across the whole gamut of challenges. So fortunately, getting buy-in was not too hard. People were generally pretty keen on open sourcing this thing, which was a nice first step. Particularly, Google has this sort of thing where we want to make the web better, for some sense, better. And so obviously, releasing tools for people to build web apps that are effective is part of this sort of border goal. And so not too hard to get buy-in from management, a little hard to convince my manager to spend a lot of time over a sort of a decent few months working on actually putting the pieces in place to do this. And at the time, Closure Library hadn't actually, sorry, Closure Compiler wasn't actually being open sourced. So I'll get to that a bit later. Then we went through the process of sort of preparing it to put it in the public domain with the initial sort of minimum bar of getting the code out there. We're like, we can get the code out there and then let's try and actually get some contributions later once we've proved that we can actually sort of get this thing out without any major problems. So we built stuff to strip out comments that mentioned Google internal products and all of that sort of stuff. We built things to strip out all of the Google copyright headers and attribute it with the right license and the right authors and so on and so forth. And all of these little, niggling engineering tasks. In 20% time, this takes a couple of months, even though the total sum of work is not that huge. And we get to a point where we're pretty much ready to open source. And someone up there comes down and says, OK, well, we've also got this awesome compiler that we want to release. And we've also got these awesome templates that we want to release and this awesome debugger that Firefox plug-in that we want to release. And so that delays us by about a month and a half. Of course, in the process of tying everything together, getting some PR out there and all of this crazy stuff, making sure with legal that everything's OK, which was generally pretty quick. Although the naming for something like Clojure, of course, provides its extra challenges. And there it was. So about three or four months after I sent the initial email, we had code out there open source under the Apache 2 license. And I guess it got some good initial press because we didn't really have too much trouble finding contributors. So at this point, sort of a couple of months after open sourcing, we have maybe 10 people who are contributing occasionally. We don't have a community per se, but this is a very mature project. And so we were mainly looking to provide this as something that people could use rather than something people would actively contribute to and build up and so on. And that's essentially it. And it sort of stayed in maintenance mode. And there's been a small sort of continuing burden on engineers to maintain that little extra sort of maintenance that's due to the fact that we're out in the open source. And the engineers have continued developing internally, the ones who actually want to contribute to it. And the ones who develop out in the open, we have a system which we're going to describe later for bringing their patches in and actually sort of unifying the two projects. So that's sort of a rough picture of how it's all worked so far. Major discussions take place on the open mailing list. And it's sort of what you'd expect. Although because it's, again, a mature project, it mostly is discussions about how to use the libraries and the compiler rather than how to improve them. And so that's it. And I think this is a good starting point for sort of highlighting the issues around open sourcing. So what are the things that we've identified? Not only through this, but also through open sourcing. I call Java libraries. Python, we've done a similar thing, called Python libraries, and various other things. As you can tell, we sort of focus on the very low level stuff, because it's easier to separate that out from the Google infrastructure. If we can't open source something, B, that depends on A without first open sourcing A. So this is the first problem, is that basically it's very easy to get people to buy into the concept of open source and say, oh, well, if you open source something, it'll all be magical, and every step you take towards open source will make your project better. What it actually looks like is more like this. So you've got a closed source project. And then you've got to open source it. And at some point, you have to sort of make this leap where you transport all of your code to the outside through some system. There are various ways of doing this. You can either just pick up all of your code and step to the outside, but then your engineers have to all learn the new source control if you've changed your source control system, which is often the case. They have to at least deal with a new repository, often a new workflow, because they're having to deal with the outside and so on. So there's in between this totally open space, which is magical, and you're getting contributions from the outside, and everyone's using your product, and you're getting good publicity, and it's wonderful. Contributions from unicorns. Yes. And the closed source world where you're just doing your normal internal software development thing. We're moving really quickly, and you are being really productive for having a three-person team. Yeah. In the middle, there's this thing where you're sort of trying to do both, and it's really hard. And I think that's really what the sort of trough in the middle is. It's nothing more than trying to do two things at once and doing both badly as a result. So what we try to do, and specifically what Dan spends all of his time doing, is basically trying to raise this barrier so that you can actually sort of transition a project from the inside to the outside without having to sort of deal with this pain point in the middle. And you can get the benefits of open sourcing without sort of struggling. So step one. And this is the part where we really like sort of input, because I mean, again, we've dealt with the Google cases, but it's sort of specific to us. So if anyone has input or experiences with this, we'd love to hear them. So the first one is sort of the big one. What's the business case for all of this? If you go up to your manager and say, I'd love to open source this project, it's kind of tricky. Well, I think it's more that managers are often fine with a project being open source. Their problem is, what's open source going to take away? Because we have a successful project that's being really useful for, in our case, Google. If it's open source, are you going to spend all of your time and the whole team going to spend all of its time fixing bugs on Windows that don't matter to Google? And if that's so, I think it's just to be clear, it's not, are you all right with it being open source? It's more often, are you all right with engineers having to maintain open source? A lot of engineers have heard, oh, you're fine with it being open source, therefore you must be fine with me spending all of my time on it being open source, which is rarely the case and something to keep in mind. So this is what happened with Nathan in my closure story is after we open sourced, Nathan had to spend basically his 20% time continuing to sort of make blog posts to have a little down to conferences and give some talks, maintain the community just by maintaining the mailing list, answering bug reports and all of that sort of stuff, which was not part of his core job. And so he needed to find time to do that and of course, his time cost money for the company. So you need to be able to evidence this with things like you might get open source contributions, that's a big one. So obviously, for every contribution you get, that's a contribution that an engineer doesn't have to make in your company. The other one that I particularly like is by doing something open source, you contribute back to the community and as with Google's case, if you have some sort of overarching principle where you can say, by releasing this it'll make the sort of environment better for engineers and that's a good thing for our company, that's also a very compelling argument I've found. And it makes acquisitions and hiring easier if people already know what you use internally and the underlying reason for making the web better by making it faster is that people will use it more and we happen to think that we're a company that can monetize people using the internet more. So our incentives are really aligned with a better internet, which is a convenient place to be. This is an unfortunate one and I'm sure it's probably something other people have heard. You want to start open sourcing something but the engineers who work on the project or if you're working on the same project then the other engineers will say, well, I'd love to open source it except I don't really feel comfortable with the outside world seeing this code. And it's code that's perfectly fine for internal purposes, it may be well tested, it may be perfectly reliable but it's not quite good enough. There's hacks in there and you don't really want to expose those hacks to the world and things like that. And to me, this has always just been rubbish. I mean, Dan's had a recent experience with this. Yeah, utility trumps beauty. If the code does what you want it to, it's better to the outside world having code that does it messily than the alternative not having code that does it. So we are trying to quash this and I'm sorry about your pretty little egos but code that's not pretty but is useful needs to get out there. So I've started giving people a month to fix up whatever hygienic issues they think it has. So I now have an appointment on my calendar on February 13th. I get to open source a new library with whatever updates the maintainer has done before then. How did you get into that position where you were able to put that deadline on it? By telling him that I was in that position, right? It turns out that an awful lot of authority comes from words. Yeah, so I mean, I don't know how particularly, well, this carries over to various things but if you can get authority from somewhere either by claiming authority or by actually getting buy-in from someone with the power to do it, it helps a lot to just get over these humps that don't really exist. And the other thing is that open source code is not that pretty either. Like it will be comparable to your internal code. I'm not a kernel hacker but during a talk yesterday it was mentioned about the testing situation in the Lake's kernel and at the very least, within Google we have very strong testing practices about how each module is supposed to be tested, what testing framework we're using and all of that, which seems a lot more consistent and well structured. So the not pretty enough argument doesn't seem to hold up under those conditions. Yes, there's also a formal code review process. Yeah, no code gets checked in without another engineer saying yes, I agree, this is tolerable code. So you'll slow down the project and this is particularly, this is related to the trough of productivity we talked about earlier. So basically during that trough you're going to spend time and effort on the project itself which is something we'll deal with in a bit. The other side of this though is actually sort of the myth that once you get into a stable open source state people have to continue to invest a lot of effort in maintaining the project. Much more so than they spend when they're just working on the project. And it's true that there is a little, a small amount of effort that people have to put in in order to sort of stimulate the community, make sure the community is particularly aware of what's happening internally, just as with any corporate investment in a open source project. But the point is that the burden is nowhere near as high as people make it out to see at least in my experience. But I think this is a really relevant objection that like it's not a silly objection to have, right? Like a manager or a VP of engineering should be having this kind of objection because that's exactly the kind of thing they're paid to prevent. So you shouldn't go, oh you idiot and like punch them. You should like engage them and go like are these costs going to be too high and can we talk about them? Handy tip. Yeah. You can, feel free. It may not work out well for you. If you're looking for another job, I hear Google's hiring. Okay, I'll have to make changes in two places. So this is, say you have a big code base and you want to open source part of your code base. So this is exactly what we did with closure tools. Then all of a sudden you have something like Gmail which is built on top of closure tools. And if someone wants to make a fundamental change to Gmail not only do they have to make the relevant, where they could have just made the change to closure tools and Gmail at the same time. Now they have to make the change to closure tools wait until the patch gets downstream into the project and then sink it in and then make the change in Gmail. Which is definitely a valid concern. One thing that we looked at when we were open sourcing closure tools that really helped in this case is looking at actually how many changes are there that affect two places at once. And we found that they weren't too many because generally what people do with a fundamental library is a piece of infrastructure is they make the change in the infrastructure first and then they'll make the change in the project anyway. So that's not too bad. And the additional burden is just the sort of time taken to sink up, yeah. I work on Open SSH and it has two streams of development, the core protocol stuffs done in OpenBSD and we periodically pull changes into the portable branch. So there are open source projects that are already in this state. Great example, thanks. Yeah. And one of the other things is that in terms of things like the release time and so on, because you are actually open sourcing this yourself you do have a great degree of control over it. So you can set sort of the release expectations and the versioning expectations such that it's fast enough for your needs. In the case of closure for example we're just pulling in every change and we're fine with that and that works for us. And obviously that turns out to be fast enough. Okay, step two, actually doing this. We're going to get in a little bit to the thing that Dan's been working on which is sort of what makes this easiest. But just to give you a rough idea of the steps involved that we've had to go through it's all of this sort of crafty work. And it tends to be just writing a bunch of scripts to go over the entire code base and do this sort of stuff but it tends to be fairly risky work because you're doing bulk changes to a lot of places. For example, one of the changes I had to make for Closure Library was 1500 files and 12,000 lines of automatically generated changes to the code base. And that's not something you want to mess around with because it can break a lot of stuff. So yeah, be careful with it. Other than that, things like removing usernames, removing dependencies you don't want to stick out, removing internal versions of libraries that are no longer, that are deprecated which we have to keep around because we're using them but we don't want anyone to use even internally. So removing all of that stuff is fairly easy to automate with a set of scopes. It just takes- It's still non-trivial, like for a decent-sized library, if you're going to take it and you want to take how you have it internally that is integrated with a lot of stuff, you just want to chop it whether you do it manually or automatically, like just figuring out all the things you need to chop is non-trivial. Has anyone tried to do this? Yeah, it's frustrating. Yeah, it's an unpleasant process and it requires a number of tries to get it right. And the new build system for us was a particularly big one because we use our own build system. So getting it to gel with the outside worlds it took a bit of effort. Not only does no one at Google remember how to write a make file, no one at Google knows- I'm pretty sure Steve Feldman knows how to write a make file. He knows what the trendy replacement for make files are nowadays. So it's really hard trying to get it ready. Yeah. All right, so now we've gone through the sort of steps of getting buy-in, which is the tough one, doing the sort of crappy engineering work in order to actually make this project releasable and we've released it. But as we've sort of all know, this isn't an open source project yet. It's sort of code that's sitting outside. And for some purposes, this is okay. If it's just a util library that you want people to up and use, then maybe you don't really want to build a community particularly if it's a small thing that you aren't maintaining anyway, even internally. And your engineers are still working on the project like they've always worked on the project. Like you've got the ability at this point to release your code, but not really to interact with the outside world to take patches in a meaningful way. These are processes that you have to set up in some form. The ability to like take a piece of code and actually put it in when the contributor is not part of your core code base. You've got to sort out where code reviews happen. You've got to figure out like do we commit and then do a code review or do we take a patch committed internally and then push it outwards? All of these options and to have various degrees of friendliness to your internal engineers and also friendliness to the people who are trying desperately to contribute but might not be able to actually communicate. And I think that's one of the most important lessons we learned from closure is like the amount of communication is critical, which might sound sort of dumb or obvious, but definitely having that communication line so that users outside who do want to contribute and don't know how or are trying to contribute and unable to get through have a channel by which to actually sort of ask what's going on. Can I introduce this new module? Things like that. What can we talk about in the open? You've got internal products. You've especially when you're doing the sort of bottom up approach of releasing the fundamental libraries before the outside, before the sort of things that depend on them. You've probably got things depending on them that you don't that are sort of core business logic for your business that you might not want to get open even though you can get sort of underlying things into the open. And so there's a question about, do we maintain two mailing lists? One internal for internal discussions and one external for the bulk of the discussions. Stylistic clashes. So this hasn't actually come up too much in my experience, I don't know if. So my take on it is that there's a lot of rules and idioms that make a lot of sense at Google where we have this huge code base and so we have to make one decision and stick with it. And we make that decision on the basis of all this code, which is basically an iceberg. Then we take this tippy top of the iceberg and we publish it and people see that and they go, why are you using these crazy rules that make no sense? And the answer is yes, they may make no sense for that little bit of the iceberg but they make an awful lot of sense overall and it can sometimes be really hard to say, well no, we aren't going to, like thank you for that patch that completely changes the formatting but we're not really going to take it. Everyone knows this by now in the room, which is a lot of problems in this, in this process of open sourcing something internal are going to be social problems and they're going to be social problems that you encounter in every open source project, largely and you will have to solve them in the same way that you solve them for every other open source project and it's as simple as that. So a number of these problems in terms of the things that are caused by having two interacting code bases particularly can be facilitated with engineering solutions and this is what Dan's going to go on and talk about is basically that you can make engineering solutions that at least help you along the way to sort of gel the two worlds. Hey, so I'm going to be talking about make open easy which is this tool I've been working on. Basically at this point you reach the point where you have the code internal, you have the code public and the choice is where will the developers work? Well a lot of people are going to say well we should keep working internal as we always have and it's pros. It's what you're used to and you have all these tools that are internal. You might go, oh well why can't you open source those too? And that just turns into an effort in yak shaving where you have all these tools that are built assuming they can run one way and you can't just open source them all at once. So it is easier for developers to work internally and if you still don't believe me you should catch me afterwards and we can talk about it until one of our ears falls off. But there's a con where the public only sees code dumps. So if you're picking a library one thing I do is I go and I look at the library's changes and I go like how often has this been updated in the last month or two months? And if the answer is it has quarterly code dumps I'm a lot less likely to use it than if I can actually see oh there's a developer who has been checking in four things in the past day that means I can probably get a decent response and a decent help. Also the code dumps often stop happening because it's really hard to keep up with doing something once a quarter because you don't do it for a quarter then you go back and oh you forget how to and so you just stop. So it's kind of. Look at the first few contributions to the open source closure project. It's there's a month and then something happens and another month and something happens and in each change there's a bunch of changes but you don't actually know what they are because there's sort of the code is being thrown over the wall in that fashion. So the response is all right so we're just gonna take this project we're gonna move it and we're gonna make it a public project and this has pros right the rest of the world is included and actually feels like they can become a member of the community but the columns right it's hard for new internal contributors and so you know I've heard a lot at Google well you know like Googlers are smart you know like if we move from working in say Perforce to working in say Subversion they can pick it up because Googlers are smart right and they are and so it's fine for 80% contributors and it's even fine for 20% contributors but it's a real turn off to your 1% contributors who are people who just want to make one change and those 1% contributors are where you get your 20% contributors and it can be where you get your 80% contributors and so and I think this is an important point at the moment that you open source a project the contributions from internal developers are so much larger than the contributions from public developers because public developers have had no chance to work with the system that under sort of any reasonable rational waiting you're going to pick to keep internal and I think that's bad because it's hurting public contributions it's not fostering it so the solution is to live in both places which is why I've been developing make open easy or mode so basically the concept is that one project leads different lives in different repositories so I've put on the left here code as it might appear inside Google and on the right yes the right my left but code as it would appear publicly and you can see there are some differences here right and it's not that like the code that we want to strip out is like the be evil code there's just various stuff that happens right like I put in here a second constructor that takes a buffer size maybe it turns out that like this class didn't need buffering at all so we deprecated it and it's not harmful but we don't want to support it with Moe you can just throw the at internal annotation on and then when the code gets sent out to the public that gets stripped entirely away and so you don't have to worry about supporting deprecated code at Google we run a very homogenous environment and so we write code that takes advantage of this to only look at things one way so you know at Google we would just handle Google formats and everything is Elphin 64-bit or whatever the actual knob turn settings are whereas you can so you can tell Moe hey when it gets out you know like strip that part and then insert this code handle all so when it gets sent outside to the public it really just says handle all the formats and these are toy examples but I hope they sort of show the motivation because I'm dumb oh yeah yeah yeah yeah that was great great great so strip works in any language and you can strip sort of any amount of code or text right it's just like looking at code as text but at internal we actually integrated with the Java compiler so it's a Java specific feature we can annotate anything that's annotatable so a member method or class and then you don't have to say end strip it's just so if you need to like delete part of a method you can use the second syntax and if you just want to lead a whole class it also like knows to remove the imports of the code that's no longer used and it's all very and sometimes too clever so if you once you have Moe set up with your project what can you do well the first thing is just make a code dump you can take whatever the latest version internally is and send it out right and that's sort of the minimum required to be at all useful you can do the other way and so if there's a library outside that you depend on but we have to tweak it to get it to work with Google system it used to be that you could do that once and then if you ever wanted to update that library you were up some sort of creek because you know I made modifications I had to change these lines to get to compile and I'm never going to do it again so with Moe you can also take the head publicly and bring it inside to Google you can migrate each change in one repository as one change and I'm going to show you this and why don't I do that now so this is closure compiler which Daniel mentioned it's a really great JavaScript compiler if you have a web app written in JavaScript and you aren't using closure compilers because you hate your users and you can see here in the last year and a quarter there've been 736 changes in subversion and I can go and I can look at these and they're from today eight hours ago and these are changes as you would expect them to appear as they were done so if you're a user and you're wondering hey what does it take to contribute you can see you don't have to make a month's worth of 1800 line patches you can just make an edit and maybe they're yeah right like hey I just need to well that's a silly change but this is the idea is that development often happens by way of silliness and so we want to make people feel included and so if you weren't at this talk and you saw this you'd think wow this is a real project that's being developed in the open I should use it because I have a chance of contributing I have a chance of getting a response from an author so this is a demo by which I actually had to do nothing at the moment which is great the best kind of demo for me as a presenter other things you can do and I've started them because they're still experimental you can take a patch against the public version of a code base which as we've discussed may not be the same as the internal code base and you can turn it into a patch against the internal code base so what this does is by way of magic undoes all the scrubbing and the modification of the code and so you take a patch in a format that's easy for the patch author and you turn it into a patch in a format that's easy for the code maintainer and so obviously there are all sorts of complicated merge issues but the idea is you automate what's automatable and then you leave what's difficult for a human because we still need jobs we shouldn't let computers do everything and you can visualize the history of what's happened with the project and where changes happened and when they got pushed between internal and public how much, what time is it? How much time do I have? Seven minutes Seven minutes, great MoWorks, we'll talk about it never unless you wanna catch me later so I've shown you the closure compiler we also have Google App Utils Python which is just a set of libraries for writing Python applications easily and well and what I'm going to do here is I'm going to come and I'm going to run Mo with the, I'm going to run the auto command of Mo with this project piglib which is an internal name and it's going to tell me that I need to tell it who I am so I'm going to do that yes I am essentially what Dan's going to show you is syncing the two code bases so by the end of this what you'll see is that Mo basically enables you to have two parallel running code bases a perfectly functional open source code base and an internal code base that is sort of the original code base where your developers can continue developing happily it can be part of a much bigger code base as in Google's case and so you end up with a situation where the internal engineers are happy and you are able to have a functioning open source project and so we're going to let this run for a bit and come back to it there's also a bad visualization so for instance our JS compiler closure compiler that we mentioned is hopefully going to show me something oh it's not there should be lines here and there aren't oh well but basically yeah that's pretty much it the code is now open source so you can go get it from Google code if you have one project that wants to live in two repositories and you need any differences between them or you need to have in any way heterogeneous source control systems we have that a lot where some people really want to use Git some people really want to use Mercurial etc etc Mo is the tool for you and it can be it probably won't work straight out of the box that's honesty but we can get it to do what you want so come talk to us and now we're going to oh yeah and we'd like to acknowledge people who've worked to get closure tools open source Nathan Nays, Nick Santos and David Westbrook and the 400 plus people who actually wrote the code at some point at Google without in any way having to bother about it being open source and continue to develop it without worrying that it's open source the only people who really work on it are Nick Santos Dan Nadosi, Nathan Nays, these people who work as the bridge and then for Mo, David Borowitz did a huge amount of work to get it actually publishable and open and so that that gives us a little bit of time for questions or comments or doubts, dilemmas yeah so at this point Mo figured out that there haven't been any changes but here's a command that you can just run every day, every week and any changes that you've done internally can get pushed externally so you know you just run it in the morning and you have a live public project questions, yeah so you said that works with heterogeneous SCM so say if you've got git internally and you want to publish via subversion or vice versa it can handle that so you can see the changes you made over the last two days and push them out to your public repository which is a different type to what you're using internally yes, now obviously there's going to be some information lost you know like it can't turn a version into a distributed version control system and at the moment if you're doing crazy things with branches it just ignores it and just publishes it as a sequence which can look very odd but yes just a quick follow up you had your syntax there for pulling stuff out of files is there something similar for whole files like if you've got proprietary library x which you can't use externally but you've got a replacement of a different library that you're publishing internally it knows how to pull out the proprietary say jar or other yeah, so you can specify that this file just gets deleted on the way out right now it integrates really well with our internal build system which is obviously something that you know if you have any kind of build system you'd want to integrate with two we don't know your build system, patches are very welcome it's probably going to be easier to patch it than to write your own thing to do this yeah so one thing that comes up at a lot of companies often legal concerns around what's going on what's coming in and often there's review processes or steps in place between you know effectively in the middle of what your most stuff all the stuff that goes either way would often be reviewed in some sense to do you have that sort of structure or the lawyer is happy to let the engineers work out so when we take patches we need people to sign a copyright license assignment so that we know that we have the right to use it yeah but it doesn't matter if they sign it and they've ripped it off and it doesn't actually really protect you no but there's no such thing as protection right as soon as you leave the house you're going to fall down and skin your knee and so it's a question of like how do you optimize it and the thing about Mo is that a lot of lawyers are actually reasonable people so if you tell them many the majority are people I'm struggling I'm struggling a lot of times if you have a process that takes you know two days and legal is one day of that and the engineering work is one day legal goes well we don't need to optimize this process because like we're only half the time so if you set up something like Mo and you get it down so the engineering work is ten minutes then you can go to legal and you can go to the VP and you can say look there's something that would take me ten minutes that's taking me two days because of legal like that's often a better incentive for the lawyers to go oh wow we really are interfering um... yeah anything else comments questions dot dilemmas yeah we've got a lot of projects that we have talked about opening opening up to the public and the usual while the main objection is um... it's going to take a lot of effort and it's going to take a lot of and it's also too there's too much local knowledge there uh... I guess that uh... it would be quite a daunting prospect to um... make a lot of the changes because I know there won't be a budget allocated for it it would be a uh... spare time kind of an activity you've got any I mean I suppose using Mo as one thing um... does Mo um... how do you actually make Mo aware of which part which changes you need to make you there's a configuration for the scrubber and you tell it do this don't do that scrub these user names publish these user names but for me what I like to do now is I've gotten it to the point where when there's a library I can send out a draft of what a public version of that library would look like with about thirty minutes to an hour on my time and I find that that inspires people are they going oh we should open source it oh we do hard if I just send them a patch and I show them like hey these hundred lines make a library like this instead of going that's dumb they'll go you know that's rubbish it doesn't do this you know you need to add these lines I'm like well like great thank you you know it's kind of like stone soup if you just give people a base that they can add on rather than talking about it endlessly it makes a lot more likely for something to get open yet another story from closure it's so something I didn't mention explicitly is a few months after uh... we had originally open source closure we migrated to Mo because Mo had existed suddenly and so uh... that while we spent several months actually going through the original process to open source closure uh... in order to set up the Mo config which was sort of equivalent to the work we had done took a couple of days uh... so it's vastly simplified the process of actually doing all of that legwork would you accept a broader Google open source question and uh... yes but I reserve the right to table it uh... from the outside it appears that the uh... open source program office mostly operates as a marketing organization internally doesn't provide consulting and enforcement uh... to uh... projects particularly the high-profile uh... projects were open source is of strategic interest like android which is yeah well um... we have we have turned out at this point android doesn't need much help from us because they have people who know how to do this stuff right like uh... jbq and dan moral you know and we can talk about the quibbles you have uh... but uh... i mean i'd love to talk about offline but the answer is you're probably wrong in that there is consulting it and this consulting and i think there's a high degree of confidence but we should take this offline all right would you join with me and thank you for that