 Well, hello everyone. Good evening or good morning or good afternoon depending on where you're at. I'm Charles Echoll, really happy to be here today. Although I kind of wish we were in Edinburgh or somewhere else cool like this, I was one summit for this with this T-shirt, but presenting to you here from my home instead. Still very excited about the topic and that's about using GitHub at a large corporations to really work on open source and share open source collaboratively with the community. I currently work in the global technology standards group within Cisco and before that I worked within DevNet. And in both cases I was doing a lot with both open source and with standards. With that light, sometimes we were sharing open source that was really more sample code just trying to help you understand our APIs and how to use them. In other cases, we were actually starting substantial open source projects where we wanted to work with people from other companies and in combination with the standards organization to improve the standards work we were doing and create artifacts that developers could use. There was a variety of use cases there. And then there's also of course, all the great open source projects that are in the, you know, in the Linux Foundation, those tend to be the much larger efforts. So I'm not focusing on those Linux Foundation projects because I think we have great governance and tools and ways of doing things that the Linux Foundation takes care of us. That's why we bring those projects in. But I'm talking more about things you want to open source that you're doing within your company and you want to do it responsibly and work together with the community. That's really the focus of this talk. So I'll start out by just kind of reiterating that goal and then show you what was actually happening within Cisco. The majority of this talk, I'll be talking about GitHub and the way that we've been using GitHub. Not that this is really meant to say, be an endorsement that you have to use GitHub, but the reality is, GitHub is the way that a lot of people are sharing code today. It's a great way to share code. A lot of what I'm saying probably applies equally well with just slight tweaks if you're using some other system there. And I think that's one of the next steps because although I think we've made some improvements that they're still certainly a long way to go. So the idea here was really, as I mentioned to collaborate on code and share code and content with the developer community both inside and outside of Cisco very important that we could engage with none. This wasn't just for Cisco internal use we really want to engage and accept contributions and work collaboratively with people outside of Cisco as well. What I got up with very quickly was really what I've heard is Wild West and with GitHub, it was just so easy and continues to be so easy to create a GitHub board, name it whatever you want. It's free, have public repos, start sharing code right away. It's very empowering. Even if you have good intention and meaning to do the right thing, it can very quickly and it did for us lead to a lot of different GitHub orgs being created that all were related to Cisco run by perhaps Cisco employees or people who had some affiliation with or used Cisco equipment. And it was great that there's a lot of code out there but as you can see from the search results on the right hand side. It was also a little confusing because you get back a lot of results and you're not sure like, is this the official one or are there many official Cisco ones where should I go. And oftentimes it was hard to know what that board was for, or who to contact if you wanted more information. So, that's really what we wanted to address. And I'll walk through a couple ways in which we've done that with a couple of those GitHub orgs. So, first, if you're not familiar with with GitHub and the concept of a GitHub organization or an org. This is really just GitHub definition it's shared accounts for businesses and open source projects can collaborate across many projects. So the idea is you have an org, an organization, and within it one or more projects, which results in one or more repositories or repos as people often call it. And there are a lot of tools a lot of mechanisms there for setting up different rules and restrictions and permissions and ways of collaborating. So, so there's a lot you can do and that's great. And it's completely free, as long as you just use public repos. If you want to have private repos then repositories then that's where you start to have to pay. So you can see where this very quickly led to a large number of GitHub works out there. Now, the first question that really came to mind for us as we have all these GitHub works. And it's confusing that they all exist. But do we really need to get rid of all of them and make just one is that appropriate or do we just need to clarify what each of them is for. And our thought was, you know, we do have different orgs with different things they're trying to share. There really isn't a way a concept of nesting organizations like these are all, you know, within the larger GitHub. Sorry Cisco org, but now all these multiple different orgs within it. So, what we decided was, we'll have many orders. That's just a fact of life. But the key factor is governance and the governance for each org needs to be clear. And, you know, if there's different governance or different goal or a different motivation for each one, then perfectly, you know, perfectly fine to have it. So let's just clean up the orgs that we have, and find a different mechanism for making it easier for people to find the right one. Here's an example of one that I'm an owner of the Cisco DevNet GitHub org. And just a few things just to show you what we've done and it wasn't I think these are this is a good starting point. We have a very clear description of what the GitHub org is for. It's a place for the DevNet community to access sample code and collaborate on open source projects that are used in some way in DevNet. So pretty broad, but yet also descriptive so you know what type of things you'll find within this org. Very important there's an email address. This is so you can contact us if you have questions. And a lot of people don't put anything here so then if you're unclear or just need some help, you're kind of stuck. So you see this is something that's relatively new this verified what this is telling you is that the people who set up this GitHub org actually own developer dot Cisco dot com have control of that domain and of Cisco dot com for this email address. So that gives you at least some assurance that if you go and the code here and if you contact us that it really does come from the DevNet team within Cisco, which if that's what you're looking for it now you have that assurance. So you know I think that that's a good place to start. If you don't have these things clearly done for your GitHub org, you know I suggest you start there. Now here's an example of another GitHub org. This is the Cisco Systems GitHub org and this one tends to have sort of larger projects in it. The description, not as specific but still at least gives you an idea it's open source projects from Cisco Systems, you can see the domain's been verified so you know that you know we're really are authoritative for Cisco dot com domain. Who to contact in this case it's fluffy if you happen to know fluffy, then that's a great assurance to you because you know, you know he's fantastic with open source standards and a great kind of work with. If you don't know one then perhaps having an email address like that is not the best so if you think about a first time user maybe this isn't exactly what you want to do, but at least there is someone you can contact so I say we're in pretty good shape on this one as well. So the next thing is public versus private, and I mentioned this earlier on there's a concept of everything is free as long as you make it public. And when I said that I was speaking in respect to the repositories or repos or projects. So if they are all open source everyone can see him for us when we're working as Cisco working in the open source space. That's really the goal right is to have public repos. And the other thing though is people, you can see we have almost. We have 800 repos 200 people almost. And that's, I see all all the projects I see all the people because I am a member of the org. If I log out though. And I'm no longer met or not a member of the org. That's what happens with the second screen. You can see a lot of the projects went away. But maybe more importantly in some ways, a lot of the people went away. And now you only see 12 people instead of 200 with, and what I've seen with a lot of orgs is this number of people actually drops to zero. So then if you didn't have a contact here, or if you didn't know any of the people are who to contact, you could see where this would be a real problem. So I looked out for that because, by default, people are private, which is nice for, you know, privacy considerations, but it is hard if you're trying to work with a community if you don't tell anyone who you are. So, so think about that. And you can see, even though I've been, you know, recommending this to people, we still only have 12 people who have changed their profile in the public. So, not always an easy thing to do. Because a lot of people have very cryptic user IDs, just do the nature of, you know, a shared namespace, right. So the other thing I recommend is make sure that even though GitHub doesn't require it include the name by which you're known, it may not be your official name but the name by which people actually know you include that in your GitHub profile. So when someone's interacting with you via GitHub, they actually get that assurance that they're talking to the right person rather than maybe making a mistake with a cryptic user ID where they maybe get one, you know, put a one for an eye or something like that. And then all of a sudden they're working with the wrong person. So another really important thing in addition to that kind of one line description that I had at the beginning was to provide some examples of what type of projects what type of code is actually appropriate for the Cisco DevNet work versus what's not appropriate or maybe is more appropriate for another work. So this one was Cisco DevNet. The idea is we're really trying to help developers with things like sample code with here's how to use a Cisco API. It's really focused on Cisco products and platforms, and how to use them, or at least Cisco technology so we do a lot with network programmability. So things related to standards like NetConf and ResConf. Those are great too. But we wouldn't want to see something that was had like no relation to any Cisco product or any Cisco technology. That wouldn't be necessarily a good fit. So similarly, we don't want to put things here that we have no intention of open sourcing. We could put a lot of code out here make it private so that no one we would see it unless we wanted them to see it. That's, that doesn't really make sense right that should be on like an enterprise GitHub or behind some firewall. So this gets back to the governance I would say don't mix and match things that are really meant for public consumption, whether they're, they're a public, you know, and shared an open source right now or not, but only put things there that you think would eventually be useful to the community that you're trying to serve. Now, an example of the Cisco org that we mentioned before there, you tend to see slightly different projects they tend to be larger they tend to be projects that are not as closely tied to Cisco products and APIs, because what we're really trying to do there is we see something an industry need, not yet industry need that we're trying to drive and work collaboratively and in some cases these projects might even graduate to become like a Linux foundation project. But in other cases we're just trying to set up something we're working collaboratively with the community for something that's important to Cisco but important to many other people too. And so we tend to have fewer projects there they tend to be larger the governance and the maintenance of them tends to be a bit tighter. We really keep a closer eye on these projects right, because they're not just sample code and you know quick things to use that they're more established projects with a wider base of contributors. So, just at a very broad level, at least we've established a clear way of when you should put something in the system of DevNet org versus in the Cisco org. So that was a great start for us. Now archives, this is interesting because when you first start, you're kind of anxious to get more and more code the more the better. But over time, some of that code is either no longer relevant no longer useful or just not being maintained anymore. I did a lot of work with open daylight, a number of years ago, and we did some boot camps that were, you know, really really, I think they were fantastic to bring people up to speed on open daylight. However, that was five years ago, we're not actively maintaining that and the information there's very stale. So fortunately GitHub offers this nice mechanism where you can archive free pose. And I recommend you make use of that. It's better I think than deleting it, because some people might actually still find something they're useful. But when you archive it, it marks it as being archived and read only. So that's great. Now if you do have code that's very like useless or empty, you created a repo no one ever did anything. Now those I would probably get rid of right no reason to have noise around so deleting those types of things I think is good. But archive things which are usually useful but just no longer, you know, actively maintained. Okay, going to shift gears now to membership and permissions and GitHub offers a lot of options here and certain things are done by default. So what I'm going to do is point out some of those things and show you where we've deviated from the defaults and why we did that. So members of some roles you have owners, you have members and you have outside collaborators. By default when you add someone in, they are a member. And then you can elevate privileges to owners, or you can also put people in as outside collaborators. And there's a good way to use each of these. So owners, those are like your super users, they have access to everything in the GitHub work, they can change things like the description and the email address that I showed you earlier. And, you know, they have broad range of access and permissions. Now, we currently have 20 owners in the Cisco DevNet GitHub work, and that actually worked well for us in that it was very empowering. Everyone in the team basically became an owner and could create repos and so very self service. But I would say it's actually not a good thing, because that's just a lot of people who could possibly be doing things different. You really want to have, I think, finer grand control and think of other ways of, you know, making it easy for people to get the work done that they want to get done. One thing we did do is we enable two factor authentication, because we did have problems with either through use of API's or other mechanisms people's accounts getting broken into. And so at least with two factor authentication, we've actually never had that happen. So this at least, you know, when people start doing things as owners, at least we have more assurance that they really are owners. What I would propose would be better though would be if we only had three to five owners, and they should be people who are, you know, real stakeholders of the DevNet team. And I think that would be better. But at least two factor authentication, make sure that your name is there. So you get that assurance that you're talking to the person you think you are. And then we require that you associate your Cisco email address with your GitHub account. It doesn't need to be the primary one, but at least it's a mechanism through which we make sure we can communicate with the GitHub owners using their Cisco email address. Because there could be something sensitive if we want to, you know, talk with them about, and that's a good way to do it. So members I mentioned this is kind of the default role, and we have about 150 members right now, most of them are Cisco employees, some are not employees. We basically made everyone members, initially, when we wanted to accept contributions from them or wanted to give them access to rebos. I don't think that was necessarily the best way to go. What ends up happening is your members by default have access to all of the private repos. And so, if you think about that and why you might be having private repos, you know, we probably don't want to have, say, non Cisco people is having access to private repos, even though eventually we want to make those public. If we're making them private, there's probably a short term reason for that. So we've not that we haven't gotten rid of a lot of members, but we, we don't add people as members as often anymore. Two factor authentication, very important there. And the biggest thing is, by default, all members can create new repos, and we didn't want this. We said, hey, only owners can create new repos also only owners can change a repo from private to public or vice versa. This is important to have it read because it's an important default that we, for us, it was very important to override this, especially when we have 150 plus people who are members and some arts is called employees. So, this way we restrict the least the permissions of the members a little bit. If you ever need to be able to do something and you don't have the necessary permissions, you just send an email to they get a bonus alias, right, and there's a set of us that will help you along. So that's important to if you're going to restrict access, you need a mechanism for people to request what they need, as opposed to what we did initially just giving everyone, you know, the access and self service that they wanted. So I'd say it's better to restrict a bit. So outside collaborator. This is one I really I didn't know what it was at first and now I'm a big fan of it. And we have over 500 people who we've added this outside collaborators. A lot of them are actually Cisco employees that many are not. And the way that this works is whenever we give anyone right access to one or more of our repos, if they weren't already an outside collaborator that they out like automatically become one. So it's a way that they can be associated with our organization, they can have right access but they only have permission to work with those repos that they're, they're actually supposed to now they probably have they can have read access to everything right, but they can't. So we don't have commit access necessarily a right access to anything except those where they've been granted. And that makes total sense from an open source perspective right now everyone has right access to every project, usually have an established number of committers who have that so that's essentially what this allows us to do. Here as well though, two factor authentication, include your, your name with your GitHub account. That's just for everyone, I would recommend doing those two things that that helps a lot. Okay, so that was individual permissions and types of roles. Now teams is a way that you can help with some of the say TDM of when you have a lot of say outside collaborators, and you want to associate. A common set of permissions with with them. So perhaps like we have a bunch of learning labs and perhaps we want a set of people that have access to or commit access to all learning labs, but not to anything else. So we can put them in a team that has access to learning labs. So we found that that's very useful. Now, what GitHub says is that this should reflect your org structure. That I don't think is true, or at least it depends on how you look at it. It, I would say your team should not reflect like for us should not reflect Cisco's organizational structure, because that has nothing to do with access rights to our open source code. It should instead be based on the function of the task, as I mentioned, like people who need access to learning labs, having a team for that I think is a good way to go. Another model that we've used very successfully is within the Cisco or what we do is every single repo has a team associated with it. And basically, if someone's supposed to have access to that project, we add them to the team. And so your access is controlled by the team. If you aren't a member of the team, you won't have access to the repo. This results in a lot of teams, but we have very fine grained access and it's really easy to tell exactly who has what access to each repo, and to maintain that over time. So there we needed to be a little bit more careful with who the committers were. And so that was a way we were able to do that. So looking back and not just what I'm saying you should do, but what certainly we've done and works well for us is repos are the main guardrail and source of freedom. What I mean by that is that only owners can create new repos. So to get a repo is kind of a big deal. But then once you get it, if you have, you can be given very broad permissions within that repo, and that's what we do. If someone needs a new repo and I think it's a good idea, we create that repo. I can even make them an admin of the repo. They can do everything with that repo, even though they are have no permissions say with any other repos they have no right access to any other repos. So someone who was not a member of our org I can even assign them as an admin of a repo. And this happens quite a lot. The repo admin has brought control over the repo that they're an admin for, although here is another thing where we overrode the default. It was important for us that in addition to creating repos only owners can change the repos I think I mentioned this before from public to private and vice versa. By default the admin could do that for the repo that they're admin of, but we restrict that. So admins can't do that. The only way for them to have the status of their repo change from private to public or vice versa is to ask one of the owners to do it. Okay, so that's it for permissions. No contributions. I mentioned up front one of the big goals for us is of course we want contributions right we're trying to work with the community. We're trying to put code out there that's helpful but we want contributions back. And these contributions can come in many forms. It could be, you know, starting a repo to let us know it's useful. It could be submitting a bug report. It could be giving us a patch for a fix or, you know, for corrective spelling mistake and a read me, or it could be, you know, adding a really cool new feature. So that there's lots of different ways to interview or could even be starting a whole new project. So one thing that's very important is, you know, we welcome we encourage contributions. It could be a member of our GitHub or to contribute. What's important though is to have make it clear how people can and should contribute. And so the common way to do that is by having a contributing file, and there you list how people can and should interact with you, what types of contributions you're looking for what's a relevant or what's the way to go about doing that or the best way to go about doing that. And you don't necessarily have to have a contributing file. That's the way I would recommend, as long as you make this information available either in the read me or I would recommend creating a contributing file. So we try to do that and make sure that that's always there. Code of conduct. Now, we don't require this but but I think it's really good practice. And having a code of conduct file it's very straightforward easy to add. It really helps foster an open and welcome environment, and it just establishes those basic ground rules that we all probably hopefully consider as common sense, but it's nice to just put them out there. And it just helps make participation, you know, our harassment free experience for everyone. And you know that's really what we want we want to make it easy for people to contribute for them to feel comfortable contributing and for them to have you know their voice heard and all that so Code of conduct, pretty straightforward easy way to go about, you know, making an improvement in that direction. Now, contributing the whole new repo. I mentioned you have to contact us if you want to get a new repo created. But then we also want to help make sure that when you create a repo it's not only useful code, but it meets our guidelines or our conventions. Now, we don't want to frustrate you by hitting you with a bunch of conventions that seem very strange and arbitrary. So we actually write them down and they come available to you. And I think that's important to do. An example here is we have templates. So you don't have to use the template but at least by looking at the template it gives you a good idea of appropriate use of a read me of a license we always require a license that contributing file that I mentioned before. And in this case, the code of conduct is also in there. So we make it very easy for you to copy this clone it do whatever you want. You can use cookie cutter to last you a few questions. And then it kind of automates the production of a start of a repo for you. The goal being we want to make it easy for you to do the right thing. And actually most developers are happy to do that. If they already have that code, then at least they can use this as a reference, so that they know before they bring it to us. Oh, these are the types of things they look for. So that served us really well. Now, in the case that where they did have their own repo if they're bringing it to us the common way we work with that is you can transfer it from where it currently exists into our GitHub work. You just contact us like you would if you wanted to create a new repo. In order for this to work. What I found is, you can't transfer from like your personal GitHub account into our GitHub org, you can only transfer from one org to another. And so the easiest way to do this that we found is, if you don't already have a GitHub org that you can use create one sentence and they're free. In one case where it's very handy, create your own GitHub org, put your project in there. Make one of us who is an admin of that are an owner of the Cisco DevNet GitHub org, make one of us an admin. And then if you're an admin of a of two different orgs, you can transfer repos between them. So we can take your repo and transfer again in its entirety. And that's worked really well for us. So long live forks. As a general rule, we don't want to fork of their open source projects and maintain and work on our own forks of projects within the Cisco DevNet GitHub org, right, better to work upstream work with the community. However, in some cases, we've done this, not because we actually intend to start a different project, but just because it's helpful to have a group of people work on something. And then, once it gets to a certain state then you know upstream or contribute the set of fixes or a larger change. In this case, NC client, that's one place where we have several people within Cisco who are working in collaboration with the NC client community. We actually have a fork of that project. And what we did was we put in the README a note to let you know, hey, this is a long term fork. It's just here to facilitate us working on it and sharing things upstream. So this way we at least let people know our intentions. I don't think it's ideal, but it's the best thing we could come up with. And if you have a better idea, let me know. But this is what we do. And it seems to work, you know, reasonably well. Okay, now I'm not a lawyer. I have been a fair amount with open source licensing and copyright and I'll just start off by stressing that this is super important, because without appropriate licensing or copyright. No one has the right to use your code. You haven't told them what the terms are, and therefore you have not given them, you have not open sourced it, you have not given them any right to use your code. Anything actually isn't a good thing. It's not a automatically open sourced or something like that. So it's important to license things and to work with your legal department to license things correctly. One challenge that we've had is if you think of the use case I mentioned of like sample code, just putting small bits of code out there that are useful to the Cisco community. Maybe you're not appropriate to be open sourced, or what's more typically the case is that they're perfectly fine to open source, but we don't have the time to go through the due diligence of working with legal to really make sure that, you know, get permission to open source something. I think it really lightweight for engineers to create sample code to share that with with with customers with partners just with the community at large. And so, and we were having a problem with doing that, because you couldn't get approval for open source quickly enough and efficiently enough. So it was we came up with the Cisco sample code license. And this is not an open source license, and we try to make it very clear it's not an open source license. However, if you're using it in combination with Cisco products and services, it does give you the right to use it to modify it and that type of thing. It's not restrictions like you can't use it to create a product in competitive with with Cisco. So it's certainly not open source it's proprietary, but by putting this this license on it, it allows us to share the code very quickly and easily without jumping through a lot of hurdles with the Cisco legal team. Now, in our mind, there's no downside to this. It's, we're not abusing open source, we're sharing code that we probably couldn't have shared otherwise or at least not shared so quickly. And we certainly lean toward open source when when possible, or when appropriate. And the other thing is, when we license something using this license. And if we find out that that's problematic for someone, we ask them to come to us and you know let us know that hey, you know this Cisco license I can't get my legal team to approve it or this is giving me grief because of my use case. And we can always open source it then if we see there's a need, then we can spend a little bit more time go through the due diligence of going through the licensing and open source it. So, so far this has actually worked out quite well, and I was a little nervous at first about bringing this out and talking about it and open source conference, but so far the feedback I've gotten has been good, because, again, it's all about just being clear with why you're doing something and, and what its intention is and I think it's worked well for us. So in terms of open source licenses, there's there's a lot out there. Just to simplify our life, we tend to lean toward when there's not a reason to choose a different one, one of two licenses the BST three clause of the Apache to another license. And like, because say we're using a lot of MIT code in our dependencies or something like that. Then we actually tend to go with whatever aligns with the other code that we're using so we might go with MIT or something like that. But, but just in general if you have a choice to make and you don't have a reason to go with something else you want to open source it. We use these two and we use the BST three clause for kind of smaller efforts sample code, and we use the Apache license for kind of those larger efforts, because there's a little bit more in there around community and patent rights and, and we tend to get more due diligence into something. If it's a larger effort and then we release it under the Apache license because it tends to be a little bit easier than for people to come around it and work collaboratively on it together. That's just a very broad brush over simplified thing but fewer licenses we have found is easier than more licenses just for people to wrap their head around, and then choosing between these two. Again, there's no hard set rules that's just a general rule of thumb. Beyond licensing though what's what we found is really important is for the types of things that I'm talking about the sample code in that a CLA or something like that was was wait, you know is overkill. So we don't need that, but definitely having a contributing file having the code of conduct that sets the right framework in place. And we found that that works quite well for us. And so figuring out the licensing is is is important, but we just want to make it easy to, and we want to make make it as easy as possible for people to do the right thing. And that's why we've tried to simplify it as much as we can, even the licensing is a very complicated subject. Okay, I'm going to jump forward to navigation now. For us navigation is is important and it's important for us to think about because, as I mentioned at the beginning we have all those different GitHub orgs, and I focused on the Cisco DevNet one and the Cisco one, but all those other ones still exist and a lot of them have great And they exist for a great reason, and they've, you know, now have good governance behind them too. So we're not trying to eliminate or reduce GitHub orgs although now we do try to steer people toward using one of the existing ones. And we have consolidated in a few cases, but there's still multiple works out there. And, thankfully, there's a lot of great code outside of Cisco outside of Cisco boards that is tremendously useful to the Cisco community and works well with our products too. So, being able to find this code regardless of where it exists is is important. Our early efforts were what you see here we basically said, here's all of the GitHub boards that we know of. Let's just scan them. And if they have a read me that's more than 50 or 100 characters. And if they have a license that is OSI approved. That's, that's good enough, right, let's just add them to this set and let's, let's put them up on this page. So it was basically an auto generated page that just stand repose. And we had multiple different pages with different criteria in mind, some that looked specifically for sample code as an example. And this was partly just seeing what we could do but also trying to provide a useful tool to the community. And it was certainly better than nothing. And an important thing was to it when people did find these and they said, Hey, why, why isn't my code there or why is my code there to make it easy for them to contact us and say, Hey, I want to opt out or I want to opt in. And as we started to think about it more we're like, you know, this probably isn't the best way. We created something called code exchange. And the idea with this is it is really is an opt in mechanism. It's a curated set of repose related to Cisco technology. And, and we provide some search capabilities and some, you know, metadata and intelligence behind giving you back results that are intended to make it easy for you to find code that that you need code that's useful to you to get you started on like your access to Cisco products and solutions. Anyone can contribute repose don't have to be a Cisco employee. And we actually really encourage and do get a lot of contributions from from partners and people in the open source community in general. To submit a repo into code exchange basically to opt in to have your, your repo there. It needs to be related to Cisco technology, because that's what all the repose and Cisco code exchange are. We really look at your read me quite closely to make sure that not just that they exist, but that when we read your read me we understand what your code is what it's for how to use it how to install it, all those good things. And actually how to contribute back to so whether you have a contributing file or you just include that in your read me. It needs to have an open an OSI approved license. So one of the licenses recognized by the OSI, and the law asterisks there is for the that Cisco sample code license, which we do accept as well. For the reasons I stated earlier. It's publicly accessible on GitHub, not not much use and sharing code if it's not a public repo. And this is the hard one evidence of the repo being actively maintained. We can actually see that that is the case when we first accepted, making sure that that remains the case over time I think that's, that's not going to be tough for open source in general, but not with the projects that we bring into. So then you hit submit, we see that you want to, you know, contribute your code, and we'll work with you if there's any changes that we think are needed or in order to accept it. And just to get an idea we're not trying to, you know, force you to like copy and paste or maintain a whole like bunch of separate information. All we do is we really intelligently look at what's in your GitHub repo and as you can see here, the repo is on the left. The, what it looks like in code exchange and the tile of the search results is on the right. And we're basically taking the description or the beginning of the read me from your repo and using that to populate the results. And the other thing you can see here is that this is kind of good to show actually the top three results that just happened to be here at the top of this page. This is telling me what GitHub org gets from. So this is from the Cisco DevNet GitHub org. This is from the Cisco Systems GitHub org, and this is from the Cisco GitHub org. So, just showing you that these results can come from multiple different GitHub orgs. And we're not trying to, I guess all we're trying to do is make it easier for you to find the code that you're looking to use in GitHub. So that's actually worked great for us. Now, next steps before I run out of time and hopefully have some questions, some time for questions. So we've made a lot of progress, both in terms of tying up our tidying up our governance, working with the community more consistently making it easier for you to find code with code exchange, but there's there's definitely a lot of work for us to do. So before you vulnerability for security vulnerability, GitHub has actually added some really nice automated functionality there to let you know when you have vulnerabilities in your dependencies. And that's that's a great thing. I think we need to systematically work to make sure we address those and probably do a bit more than that too. I don't have that in place yet, an audit process. I mentioned it's easy to check the code when it first comes to you, then to make sure it stays fresh that people are, you know, addressing issues that they're with a security vulnerabilities or otherwise. That's important. Perhaps even more important is establishing and tracking metrics, because, I mean, certainly from my perspective, I want to be able to show that all this great work we're doing in the open source community. Has value that people are using it that it's growing that we have traction with it right that way I can justify that we spend more time working on open source and in creating tools that help you find and use it. Now the governance around Cisco DevNet and the Cisco GitHub orgs I shared that with you here and my rationale for it. I would actually like to make that type of governments more pervasive across all of Cisco, and all of our GitHub orgs so that even though we have a lot of orgs, you have a similar governance hopefully behind all of them, even if the type of projects they accept are consistent if the way that you work with us and you know kind of the the mechanisms they are consistent. I think that would be helpful. And then to improve our Cisco corporate open source contribution process. And that Cisco sample code proprietary license that we created was a great work around for this, and it probably even deserves to continue to be used, but we're seeing more and more people wanting to open source things which is great, but we need to streamline the process and make it easier for people to do the right thing and to get the help that they need from legal or from open source experts, so that they open source correctly. And so those are just a few of the things that we need to work on, and that hopefully I'll be able to share progress and talk with you at a future date. So here's a few links that I just wanted to share. The the Cisco GitHub orgs both on Cisco DevNet and the Cisco one to code exchange tool that I showed you are a template repo that has helped us a ton. So take a look at that. Use it as inspiration. If there's things that you question in there that you think like hey these guys kind of missed the bone on something by all means let me know. I'm not operating on it. A lot of people using it. I'd love to make it better. I know it could be better. So, you can contact me via email, Twitter. And with that I have a few minutes, I will open it up for questions. Before I do just want to say thank you to all of you weird being to presenting remotely, but look forward to engaging with you through questions and afterwards so I'm going to go back to this slide. And just so that you can have those links and then again just say thank you and look forward to chatting with you about open source more.