 This panel is advocating for FOS inside companies, and we had a similar panel on this last year, and it's all about companies that have formal organizations and policies around both inbound open source and outbound open source, and it's really fascinating to see how, you know, when maybe we started this dev room or perhaps a few years before that, this hadn't really become a standard practice, and now companies are really embracing that, both from an organizational, maybe legal, defensive point of view, but also from a proactive, outreach point of view and wanting to connect with and wanting to contribute to communities and wanting to make an impact and wanting to get their name out as a good community citizen. So we're really lucky to have a suite of fabulous panelists to talk about this. I'm going to let each of them introduce themselves for a couple of minutes and talk briefly about the issues that they're facing and things that are important to them, and then we'll be able to dig into these issues in more detail, so I will start off with Charles. Okay. Well, thank you for that intro. My name's Charles Echoll. I work at Cisco. Within Cisco we have something called our DevNet team, our developer network. I'm part of that team. I'm one of the developer advocates in that team. So, you know, my job is really to help developers outside of Cisco understand our products, how they can use APIs that they have, how they can build on top of them, integrate with them. What better way to do that than, you know, by having things open? Open APIs is a good thing. Open source code is even better. A lot of what I try to do is make it easier for people to create an open source and then for people to find what I would call sample code, really. We do a lot with big open source projects, and another thing is if you just want some sample code that shows how to use an API, how to do an integration between component A and component B, if you can open source that and make it available for people to use, for me that's a great way to enable developers, and so a lot of the things that concern me are kind of around that goal. Thanks, Charles. I'm Natia Ruff, and I run the open source program office at Comcast. We're based in Philadelphia, and we are a company that's at the intersection of media and technology, so we do internet services, cable TV services, content creation through NBC Universal, DreamWorks, et cetera. So Comcast, you know, traditionally has been a company that acquired proprietary software and purchased products from vendors, and then around the 2000 timeframe we started consuming more and more open source because open source was so helpful. It helped us create our own solutions, get to market faster, be more innovative, et cetera, and then we realized that it's very important and good hygiene to start contributing back to open source, whether it was upstreaming or creating our own original products like content distribution networks, et cetera. So my job from an open source program office perspective is to make it dead easy for our programmers and developers in the company, of which we have thousands now, to both consume open source software, contribute to open source software, collaborate with others, and really to create a culture of open collaboration within and outside the company. Hey, I'm Jeff McAfher. I work at Microsoft and I run the open source program there. As you probably have noticed, Microsoft has been going through quite a bit of change with respect to our open source engagement, and it's only in the last sort of three or four years that we started a formal programs office. It's been really very exciting, pretty scary at times, and our biggest challenge I think really is culture. We've got a company that's full of really, really bright people who have been spending decades writing code that wasn't open source and in fact was often quite opposite. And so changing that business culture, changing the way we do things, the policies and the processes, when I started, each person who wanted to use some open source, they had to answer 25 skill testing questions, and if they got one of them wrong, they were gone. Now we've gotten down to some really high automation rates and some of the tooling discussion earlier that went on was right dead on point. We really want to do open source, we really want to do it well, and so we've been trying to do that across consumption, releasing, contributing back, and supporting projects, and that's really what my team does, is try to help drive that throughout the company. My name is Dwayne O'Brien. I run the open source program at Indeed.com, the job site, and by the time you got to the end of the list here, I started off thinking I had maybe a unique take, but it's not all that different. What I didn't hear any of us talk about is companies really excited to release their own open source projects. A lot of the talk has been focused on getting employees involved and participating in the communities around the software that we consume and that they're interested in, and that's where I focus a lot of the work that I do there. So how do we get developers both reaching for open source first as an instinctive reaction when they want to implement something, but also making sure that they're participating in the communities around the software that we use, not just contributing code back, but just being involved with the communities in a broader sense. It's pretty much what turns it for me. I do, I'm going to switch to the other mic in just a second, but I have sort of a hidden agenda, so it'll make sense in a second. There you go. Mr. Gueswell. I wanted to follow up with that, Dwayne, because it makes me think of a great question, so that's why I wanted to grab the mic. I wanted to ask everybody to answer this question. All of you mentioned, to some degree, this business of contributing back the acknowledgement of the role that open source is playing in your companies. Let me challenge you. Let me ask you, how do you know when you're successful? What does it mean to be a good citizen? How do you measure it? Okay. Just to let you know, we didn't get a chance to talk about any of these questions beforehand, so we're all going to be thinking off the top of our head here. For me, I think success comes from having, enabling the developers within my company to do their job and to do it well, and what I mean by that is if you go back, I don't know, maybe 10 years ago, it was pretty hard to just release some software, just to put some software in the hands of your potential customer and user base, so everyone went through the processes that Cisco put in place to put software out. There was an ability to open source something, but the ability to just put, to get any kind of software out, a product, whether it's open source or closed source is a pretty difficult process, pretty arduous process. And then with things like GitHub coming around, it's so easy now, even accidentally, to share code. And so what I'm seeing is more and more people are putting code out there on GitHub, whether they're supposed to or not, whether they understand what a license is or not, whether they really think through what they're doing. So a big part of what I'm trying to do is not stop them, but just to try to have a conversation with them to educate them about, do you realize if you don't put a license, you're not really doing someone a favor, you're actually hurting them because now they have no license to use your stuff. And to a lot of people, that just comes as a surprise. So helping people do what they want to do but still do it the right way. To be a good open source kind of contributor and as Dwayne was saying, a member of a community and not just be throwing a bunch of stuff out there. So a lot of what I'm doing is just trying to have that happen. It is difficult to measure, but I think just by looking at the amount of code that's out there and talking to our developer community and see are they able to find what they need, that's how I'm kind of measuring it. That's good. Miss you. Tom, I think it's going to be an ongoing journey. So it's going to be hard to know when we've reached it. One of my, well, things on my table is a simple button, you know, like the kind you get at stores. And essentially we want to empower the developer to make the right choices, as Charlie was saying as well. And not to be, you know, overloading them with policies and processes and, you know, approval bodies and stuff. We want to build it into the build process. We want to build it into the software development processes. And we want the open source developer inside the company to be a first class citizen. So one of the things that happens is many of us, our companies award people monies and leather jackets, et cetera, for patent filings. And we want open source software development to be just as well recognized in their technical path to being a distinguished engineer, fellow, et cetera, and also to get monies associated with that. So for us, I think we're looking to, I mean, to use the buzz phrase, you know, delight our customers. And our customers aren't just the people who pay us. They're also the people who are in our communities and our ecosystems. And so by, you know, to your metric point, I'll say up front, we don't have a suite of metrics that, you know, if it goes above certain things, we're green and we're happy, we're done. It's very much a continuous process. But I look at some of the code, some of the projects we put out there, things like VS Code or TypeScript. I mean, these are widely, widely used. People are thrilled with them, delighted with them, you know, using them all the time. And those folks walk around really feeling really tall and happy and really, really proud of what they're doing. And we want that to happen throughout our company, obviously, our developers, but also the people who are engaging with our products or our open source projects as well. So we look at that as, you know, essentially customer satisfaction, right? How happy are people with the things that we're doing, whether it's our own projects or our contributions back and our actual products? So I think the question, you actually asked two different questions. And one was, what do you measure? And the other one was, how do you know when you're done? If I think about what it is that we measure, I have sort of a, you know, earmarked goal of getting 50% of our engineers involved regularly in free and open source software, which I think is a, as far as I can tell, it seems like a high number. Not a lot of companies publish like how many of their employees are involved in this kind of work. I don't want to set the goal at 100% because for some people who've developed disciplines within certain languages or environments or stacks or communities, encouraging them and trying to force them into those communities might not be good for them or they may just not enjoy it. Like it's not, participating in these communities can't be for everyone. Not everyone enjoys it the same way. So driving participation and trying to get, you know, half of our engineers there, that's really, like that's what I'm sort of looking to measure. But the thing I'm looking for, for how I know when I'm done, is when the predominant instinct is to see a piece of free or open source software that does 95% of what we want it to do and having the developers decide that writing the remaining 5% of that and giving it back to the community is less work than trying to write 100% of a new solution, which is a predominant instinct in a lot of companies. And I think there's some, you know, there's a bit of, oh, I could do this better. It's going to take two weeks, no problem. I can absolutely outwork the 40 or 50 people who've been working on this for five or six years and you'll get 80% of the way there, but we know how long the other 20% takes. That's the first 80% and then there's the second 80%. Right. And then the third. And then the fourth 80%. I think it was muted. That's why. User error. Some people call that error 39. So I have a question as a developer I want to ask you a question about your employees and this is inspired by a podcast that Karen and Bradley did a long time ago on the Free As In Freedom podcast. FIF.us had recommended you look it up and it was about this thing called the, yay, yeah, clap. It's the contract patch project and the idea, if you hadn't heard of it, was that when you join a company as a new employee, that's the moment when you have the opportunity, well, you have the most power in negotiating the terms of your employee contract and if you're an open source software developer, one of the discussions that you have an opportunity to have with your employer is, can I keep copyright in the projects that I'm actively contributing to or that I will contribute to? Obviously, I would license the work, you know, or maybe not obviously, but you could have the employee license the work back to the company as a variation from the default work for hire situation and I think it's tough for all employees when you're excited about a new job to enter into a discussion about terms of an employment contract because frankly it's scary and on the other side of the table are the lawyers or your manager, potential manager. But it's, my question is, how do you welcome new employees that might be coming from a free and open source software contribution role or how could you make that more friendly and or have you ever considered the idea of letting employees keep copyright in their projects? So as, how do I say this? Implementing change in a corporate context is a slow process, especially when you're so much laugh, especially when you're starting in an organization that already has thousands of people in it, right? And so coming into an onboarding process an employee onboarding process that has already been defined by legal entities and culture and everything over time and trying to upend that out of the gate is a hard thing to do. So I see it as, you know, a long game and sometimes it's a game of inches. Like let's get the open source guidance in front of people as part of the onboarding. Let's get a half an hour of the onboarding process so that we can talk about what policies are and how things work and what sort of the guardrails are for the ways that you might run afoul of policy and take things from there. That's how we've been approaching it. One of the interesting things at Microsoft is we actually have a number of employees who are maintainers of popular software packages you'd use whether it's Webpack or Moment or Lowdash if you're in the node world. Some of the key maintainers work at Microsoft but oddly their job is not to work on those things. That's stuff that they do on their own time. Sometimes it's a bit tangential to their work and they do it on work time. So the point here is that we do have a policy in place. We call it the moonlighting policy and it's a negotiation or a discussion with your management. This applies to everybody. The secretaries, everybody has the same policy and it becomes a discussion with your management as to I want to work on this project. I want to do it in my spare time. It might intersect somewhat with my work or something and it becomes a discussion. So there's no one in a company, a big company of thousands of people, there's no one answer that you can have that just says that. But I think we've got a, it's suitably vague which can be frustrating but it's also flexible enough to handle a bunch of different cases. I think it's becoming increasingly important to allow for people to come in and continue to do work on the projects that they had been working on. I am still working on a policy within the company in terms of some of the things Jeff covered and Dwayne covered which is can I moonlight and contribute to projects that I want? Can I do personal contributions to projects that I believe in which have nothing to do with my work? Can I bring my copyrights over and continue to maintain those copyrights, et cetera? I know some folks who are, who've been in open source for a very long time like GitHub have kind of created some very progressive policies but we came into this just very recently so we are still working through how to address this issue and do it fairly. Yeah, so let's see. You know, at Cisco the default policy is anything you do on company time or with company resources gets the company copyright. For most people that's not really a problem. You know, it's still relatively easy to open source something it just has that copyright. You know, I haven't really been involved too much in this but if that was somehow going to be a problem to you contributing to some other open source process then, you know, that can change, right? There's some flexibility in there. You know, this is just the default as far as to have this go copyright. So in terms of coming in and when you first get hired I think the thing to do is just to have a discussion around well these are the things that I already am contributing to or I want to contribute to and putting a Cisco copyright won't fly within that arena for these reasons and then make sure that that's understood coming in but there's no reason that also can't happen after you are in and then start contributing. So far I haven't really seen that be a big problem. Okay, well thank you for those answers and I have a ton more questions but I want to give everybody here an opportunity to ask questions too so I'm going to pass the mic to Karen and let you ask some questions of our panelists. Also, if anybody lost a thing of pencil leads for mechanical pencil they're down here. Maybe it's found object actually I have I think two comments and a question on just this last topic and one is the first comment is that these are all very large companies so it's very hard I agree it's very hard to make these changes I will say that at the scale conference last year we were talking about contract patch and we asked the audience it was maybe 50 people in the room how many of them had been able to negotiate an open source change in their agreement and a good half of the audience at least put their hand up that they had been able to do that. So there's a lot of employers that are much smaller who are willing to deal with that to allow ownership of copyright by employees. A second a second way to slice the cake on that and this is sort of my pushing back on you when you say oh this is so hard this is so hard as corporate culture it's hard to change because what really has to because I don't know that it's necessary that the employee own the copyright why don't you as an employer promise that that work will be released under an open source license instead and come about it the back door that way. I'm going to give it to Dwayne. I actually don't remember I almost want to see the video I can't remember if I said hard or slow I think that both can be true I think it's worth mentioning that if you look at the risk profile of Indeed versus Microsoft versus Comcast versus Cisco the kinds of contributions employees are going to be making at Indeed there aren't a lot of open source projects centered around connecting employers and job applicants and so I struggle to think of an open source contribution that an employee would want to make on their own time that wouldn't just be fine and so we may be a little cavalier with policy but I think it's because our risk profile is fairly low compared to shipping set top boxes or routers with embedded Linux in them or everything possible that you can try to ship good idea or bad and so it's very hard to give a one answer for everyone kind of thing as far as can we commit to the employees that the open source work that they do or modifications to free and open source software that they do they can give back to the community and we'll give back to the community we haven't made a formal promise to that but that's generally been our policy yeah and I think my approach has been kind of to that second alternative where you're saying put the Cisco copyright but just you know make it what I've tried to do is make it as easy as possible to release code as open source and I guess what I saw a good talk about people just following the path of least resistance and whatever that path of least resistance is that's where people are going to go so what I've tried to do is insert some good kind of open source principles I guess into that path of least resistance instead of fighting the whole copyright thing and maybe some of this is my own ignorance of legal issues but it's like I kind of see like I don't need to fight that one I'm fine with the Cisco copyright as long as we have a good well understood easy to find and relatively fast and straight forward to open source something which you know we actually do and that to me seems to be an okay solution I would like to come back to the question how do you measure that as you ask and go a little bit further I'm very curious about as private companies as profit driven models first of all how did you jump in and first of all why what is the spark what is the initial motivation it is business driven does it come from the base and how do you position yourself today are you still in an exploratory phase with dealing with private code and open code and if you are even more mature do you put in place or do you plan to put in place a kind of governance framework to manage what do we do as private old code and what do we do with open code and how do we decide with what rules to have a full blended business model so that that was a lot of questions there so yeah yeah I know for us the reason we felt that it was important to have an open source program office was we felt that this is the way people develop today and this is the way companies should innovate and we wanted to be a technology innovator and so the way you do it is by establishing at least we did establishing a center of excellence so that developers didn't have to do the hard work of figuring out which license and how to what's the process for open sourcing et cetera and they could just come to one place and they could get all that help and get that support they needed to make that happen and I think it's worked quite well it is a business differentiator it helps us get our products to market faster it helps us cut cost it helps us attract talent and it's a real battle for talent today and offering good open source policies and good open source support is a huge differentiator in attracting talent so it's been quite a journey for us and I work I drive the open source program on what I used to call a maturity model now I call an engagement model we started out a few years ago in denial and we progressed to tolerant and hype sort of peers of one another and I'd say right now we're kind of that proficient right and the reason why we instituted the program's office is because we recognize that they are dabbling with the tolerant level of maturity was very focused through a small relatively speaking set of people that all open source in the company went through them and that's just not going to scale right so we decided that we would essentially blow that out distribute everybody in the company could do open source but we still needed some level of management and governance over that process that was what was going to get us to proficient across the company and frankly that's been we've been at three years now trying to get proficient and I would say we're getting there like we're pretty close it's still you know it's we've got some parts of the company that are amazing like their mastery and they're really doing well on the engagement scale but the bulk of the company is getting to proficient and it's really a lot of the things that you mentioned that motivated us to do this but the recognition that the phrase I like to use it came from somebody that I in the company that I don't remember and I won't quote their name but it's basically it's not enough to aspire to be world-class when everybody else starts there right and we used to write software by just starting with okay let's I think we're going to have a database system so you crack open your laptop you know new file write a database system that's that was the Microsoft way of writing code you know previously but that clearly doesn't work when you can go out there and get you know MongoDB Postgres with all these other open source databases that everybody else just starts with and if you make your own then you don't get to engage with all that ecosystem that's around all those those other ones and the last 5% why are we doing you know we need 5% different than what they've already got why are we doing that so the recognition at a core business level that doesn't make sense to be building all of our own stuff when we can engage with people in the community help them help us accelerate the industry as a whole and really deliver the value that our customers want they don't care whether we've got some cool new database under the cover or yet another UI framework they care that they can write their word documents or run Excel or run on Azure or whatever like our products so we can really drive where we differentiate where we provide the value but build on on and with software from others there was a question over here no it's fine do it are you done yeah I work at relatively small company we're about 80-90 people and just started an open source working group that I guess I'm kind of driving and so I love some tips on like what to do what to drive I guess one area is we have a lot of libraries for the Golang that we have and they are central to our business but don't really contain any business logic to them but how do you the community is not going to be like oh wow that's exactly the library I've been looking for is that something that we still push out you know try to hit that 50% of our developers pushing to open source like where do we go there and if you want to touch on helping to choose licensing I think we're going the path of least resistance with the MIT like okay that doesn't matter we'll just throw it out there but any input would be great so I'll take the second one first in the legal room and say I'm not your lawyer and I'm not a lawyer seek legal counsel when it comes to choosing your license or something from someone more informed there's plenty of them in the room here and I believe me you could talk for the rest of the remaining two days to them about only that as far as you've got a bunch of go libraries that crucial to your business no critical business logic and maybe the community doesn't want them my philosophy tends to be that if there's not someone else who wants to be a contributor to the code it's likely that you're just polluting the stream with code that nobody wants right there might be other reasons to push code out there you know it might be academically interesting or or something like that but really if nobody else wants it I would you could put it out but then we already have a discoverability problem when it comes to finding software and so do that judiciously I would say the most important thing is that when someone shows up to your project it's very clear to them what this is what kind of response time they should get from maintenance what kind of level of maintenance and it's in if you want to push libraries out that people might want to use but don't intend to maintain them make sure the person who lands there knows that immediately and how to get a hold of you if they have questions is what I would say and they're all I would go down roughly what you were saying but I'd also think look internally and see if you can make an open source inner source culture inside the company so you don't have to actually open source it you can you're a small company but still you can have people who are working in different parts of the company collaborating on those libraries and working together and sharing ideas I differ a little bit on what Duane said in that yeah you can pollute the stream but don't presume that you're not special I'm sorry you're not right and so don't presume that there isn't somebody else out there who might want to be doing they might just take your stuff and run with it you know that's fine because you might find somebody else's stuff and you'll be able to use it or they might come and contribute so making the clarity that's one of the discoverability problem we have right now is horrible and you show up to a project you don't know whether it's dead, whether it's alive what's going on and that's a really big problem so definitely go down that path but I try to default to open but clarity you need to be clear about what it is you're doing but I would go for open first so I'm addressing a different one which is congratulations on starting an open source working group I think in a small company that's the way to go with lots of volunteers and lots of little time and as you scale you'll probably create more of a dedicated one and if you're looking for more resources on how to create an open source program office there's a group called the to-do group to-do-group dot com dot com, right? or dot org, sorry which has a lot of case studies and journals and resources on how to start your own program office yeah and the other thing I think there's big open source projects there's small open source projects most of what I'm dealing with are lots and lots of very small open source projects just some sample code around how to use an API or something like that so then in having that discussion of well should we open source it or not I mean yeah we don't want to throw a bunch of junk out there that's not being maintained but so I think the thing to do is make sure that the of course the read me has to be good and describe how to use the software but whether it's in the read me or in a contributing file we make sure we put something about what are our goals with this are we trying to start a community around it or is the engineer who built it just like hey I want people to see an example but you know I don't really want bug fixes or extensions just if this helps you copy start using it fine if it doesn't you know so just just put that disclaimer out there too of what are your intentions and often times that will influence your license choice too I think right what depending on what you want the longevity and the kind of give back sort of model for this to be so there's a lot of old mature code out there down in the guts of software infrastructure that doesn't have a lot of maintainers and I'm wondering if your companies have been thinking about how to contribute to the maintenance of some of that really vital code some of the security problems that the internet has run into have been really caused by just not enough maintenance on that stuff can you guys talk a little about that yeah I can talk a little bit I know there have been some community efforts to try to address that like you know within the Linux foundation there's I forget what it is but the core infrastructure thank you so one thing is contributing with money towards that initiative the other way is also by contributing with developers in some cases often times the money at a large company is easier to do so I think start with that but you know if there's a skill set or personal interest or whatever within the company that's also very welcome so both ways and I agree it's something we need to take care of and address I mean Charlie is exactly right it's easier to contribute to an effort a centralized effort like that which then looks at the underfunded or under resourced but critical components like open SSL I think was one of them and then you know make sure that they are well taken care of it's harder though to justify putting developers like Charlie was saying on projects that we may not consume as businesses sometimes we tend to be very focused on working with communities that we actually use or somehow you know help us and so it's harder to justify communities which we don't use except through a core infrastructure initiative maybe sorry sustainability and survivability durability of projects is actually a really big problem and we've been looking at you know we do a lot of the same things core infrastructure and that sort of thing that's been discussed previously but we're trying to look at models for you know how would we actually do this on a more widespread basis you know waiting until there's Heartbleed and then everybody jumping in and trying to you know get the two steves to fix everything that's okay but that's a retroactive and trying to look more proactive is how can we manage to avoid these problems but it turns out to be a really hard topic and if you have any ideas like you know come down and find me later because I'm really trying to figure this out throwing money at the problem is not always workable it turns out that not everybody just wants money to fix bugs or something right they want to do their thing and so it is a challenge I don't know how to solve it I would love your help in figuring out how to solve it because we actually really do want to solve it I was going to say I have ideas and come to my talk and then you said but money is sometimes not the solution I said well I still have ideas but maybe come to my talk and at the risk of being plug-ish I have a talk tomorrow I'd like you to come to or I can talk to you about it afterwards the drive for wider contribution that we've been taking on has largely been focused the next place to focus is making sure that we're contributing into the things that we depend on as a company the problem is when you do everything you depend on everything and if we look at the inventory of libraries and software that is deployed across this stack there's a lot of everything in there my hope is that as our tooling continues to evolve I can get some insights into where we have contribution activity where our larger dependencies are and make sure that if there's a mismatch between those two we are working to highlight the projects where it makes sense for us to be contributing more and drive programs internally to encourage contribution we haven't done a lot of that focused on project need externally we have done a lot of driving for if you want to get involved for the first time if you've never made an open source contribution and you want to get started here are some things we know that we use that are welcoming to newcomers and here are some other projects that are just generally welcoming to newcomers to get people onboarded into the process so something that I observe usually about large companies is that they start to engage in free and open source software for their own products either because they want the community or the ecosystem that they are building to thrive like more developers use it or they want actually the code contributions back from the developers so there are two perfectly fine reasons but also like to the benefit of the company what is missing that I observe is are the people who don't have the expertise or simply time to contribute back to the software project or they are simply not developers but they would benefit if the source code for example for that internet router in their home is available so that if there is a glitch that is very specific to their use of the software can be fixed by having the source code and fixing it but unfortunately the feedback loop that the company gets from the developers is very short but from these people the very end users who are not developers the feedback loop the benefit that the company gets by fixing the source code for their products is quite large or quite long what can be done to somehow so I am speaking purely from a very end user freedom perspective what can companies do to shorten this feedback loop so that it is also practical or beneficial for the companies to release source code even if it does not help thrive their platform that they are building or does not add anything to the source code that they are developing I know it is a very difficult question we are all going to avoid eye contact with each other well it is a tough one and we have routers in people's homes and if it is based on open and free software we do provide the source code for the gpl component the pieces but not for everything and I don't know enough about the request that we get from customers to make that code available I don't know how many of our consumers actually are interested in it or want to modify it or want to play with it so I couldn't answer what the need is and how we would respond to it so yeah unsatisfactory answer but I am not sure I understand your question are you saying there is a product or a service that is 80% of it is open source code and 20% of it is not and how do we get that other 20% to be open source to cover the very end user to fix the problem and by fixing that problem it would not benefit your company but it will solve their problem nevertheless like there is the installation script or whatever is missing from that thing I guess I have a hard time envisioning that because to me customer satisfaction is kind of the number one success of the product so if there is a customer who has an issue let's say the code is open source and it is on GitHub and someone comes and opens an issue saying they are having this problem and fixing it would be in the best interest we would want to fix that so I guess that is why I think I am not quite understanding your question we would definitely even if it didn't make the software perform better you are thinking of a developer it is just fixing their own problem because they don't have the expertise we are going to have to repeat whatever it is being said down there because it is not in the recording I think we are wrapping it up we will move to the next question I actually want to build up on the previous question so to be a little more exact or detailed here assuming I buy a large Cisco device for a reasonable amount of money most stuff is open sourced and it could actually be driven to a point that you could open source all of the software parts of the product so if you purely theoretically would go bankrupt on the next day then I would be standing there and I would have zero support and I would never have the option ever to get any support for that device ever if that stuff is on GitHub I can just hire your ex-employees which are now looking for jobs and they can help me maintain that stuff you could even develop that thought to a point where since the systems live on when a particular business case fails it can be used to build new business cases on so there is a commercial opportunity there as well maybe that helps I agree and there is lots of cases where we do have the source code has been open sourced but a product or something like VPP and FDIO you have a lot of Cisco people contributing to it the entire thing is open sourced that is used in combination with other products as like its core and then there may be other management software or something on top of it that is not open sourced and that whole thing is offered as a product I can't say that I'm ever going to make Cisco open source everything but what I can tell you is higher and higher percentage of code is being open sourced and that is in a good direction people can come on like the GitHub community and submit issues and so I think we are moving in the right direction there but it is not like everything is going to be open sourced I agree that would be fantastic but we are moving closer to it one last thing the person said they are paying money for it we should have that do we have time for one more question if it's really quick I'll ask is just following up on what Nitya said before for all of you are when requests for source code come into your companies is that sort of under your purview do you see that is that part of your workflow I think one of the best practices of open chain for example is that there is an ombudsman I think that's the way to pronounce it for each company so that people can actually request information or source code etc and we do have an email address that they can write to and then we make sure to contact the right team and the company and make sure that they are able to fulfill request for the source code absolutely that's one of the key roles under the model of doing governance and compliance with the licenses certainly when people request we maintain a site thirdpartycode.microsoft.com you can go there find any of our products and try to download it find the copy left code that's involved and download it there if for some reason it's not there there's a link and you can click it and send us an email and my team gets that it's not there did something bad happen did something wrong happen in the build system or whatever we also interestingly please don't do this people interested in sending this email could you please open source microsoft paint or notepad which we are doing or money there's one of the game ones that anyway we try to not just for fun for interest sake we go and ask the teams we try to track down the teams and ask them what do you think because the actual value in open sourcing it it's very challenging to open source it's all embedded in some big build system but yes we are trying to make sure that people who want the source code can get it you really want it Bradley asked if we could open source windows and I asked if we really if you really wanted it fair enough well we've come to the end of our time and I just want to enthusiastically thank Dwayne, Jeff, Nitya and Jeff for coming to talk to us