 Okay. Great. Hello, everyone. Thanks for being here. It's a real pleasure to be here, be here in person. My name is Charles Echoll. I work at Cisco. I'm in our Global Technology Standards Group. Sorry, I obviously work a lot with standards. But also, partly because I'm passionate about open source, but also because as many of you probably see, there's a lot of ties between standards and open source, and we've heard some talks about that. Here this week, and so I deal a lot with open source, and there's a lot of passionate people doing quite a lot of good things with open source inside of Cisco. This talk is a little bit about how GitHub really empowered and enabled this community of sometimes different siloed groups, not siloed intentionally, they just had different things they were working on and ways about going and open sourcing things. I think in that excitement, and using GitHub as a great tool for sharing code, the way that happened organically within Cisco, and some lessons that I learned and that others learned from that, and some improvements we've made. So just wanted to share some of that with you, and hopefully get some help with ideas for good improvements that are still easy for us to make on top of what we've done. So I'll start by talking a little bit about our goal and then the reality of what happened as we started using GitHub, and then I'll dive into a bit more detail of our usage of GitHub, the various functionality in it, and how we made use of it, and things we learned along the way that maybe we hadn't anticipated or where we thought, wow, we could do a little better here. Then I'll just close with some next steps because we've certainly made some improvements, but there's a lot left to do. So just very simply, what we really wanted was a way to collaborate on code with the entire developer community that was involved with Cisco products, with our APIs. Primarily we were thinking of open source, but as you'll see it didn't even necessarily need to be open source. But this collaboration with developers was really the goal, and many different teams had that in mind. What ended up happening partly because of the ease of use and availability of GitHub was many groups went often just started doing this on their own, which in some ways was fantastic. But it also resulted in literally dozens of Cisco GitHub orgs, different variations, different groups of Cisco. They're all legitimate meaning that at least there were dozens that were legitimate, maybe there are some that weren't. But quite often there wasn't a description of why did this GitHub org even exist. Some of these had a lot of very, very good projects in them. Others started and stopped, someone had an idea and then lost interest, and they were just dormant. Many of the repos that were out there didn't have a license, and I think maybe the worst thing was, it often was not clear at all who to contact if you had a question or wanted to find out more. Even for me, working within Cisco, I often didn't know who to talk to, who set up this GitHub org, I don't know. So now I'm going to start by just looking at orgs and repos. First thing, a GitHub organization. I'm sure you're all familiar with this. We see it with open source projects a lot. A GitHub organization just provides a really convenient way for a group of people to collaborate on a set of projects on a set of repos. You have some owners who can set things up in a certain way, there's a lot of flexibility there. I think the key thing here was that it's free. For an unlimited number of collaborators working on an unlimited number of public repos, and that in itself was just very empowering, and that's why so many people went off and did this. Because they could, it was free, it was easy, and they were often running. So the problem though was we had this organic kind of mismatch of things. So we started to look at it and it was confusing to us. We figured it's certainly confusing to our developer community. So we started thinking about what are we going to do to make this better and one thought was, well, we have a dozen of orgs, but should there really just be one GitHub org for all of Cisco? We thought, well, first of all, we'll probably never be able to achieve that. But second of all, there's sometimes really good reason to divide things up into different GitHub orgs. So we thought we're not going to try to reduce them necessarily. What we're going to do is focus on governance and have clear governance behind each one, behind each GitHub repo and make sure that all of the repos, all the repositories that are in a particular GitHub org follow that governance. That way, we weren't going to even try to unify on the governance. We just said have a governance and then follow that for your GitHub org and for your repos. I was in the DevNet team at Cisco at the time. That was really our developer outreach team. So I was one of the owners of the DevNet org, and I had some close colleagues who were owners of the Cisco org, and we thought, well, let's at least start with those two. So with the DevNet org, we put up a very simple description of what it was we were trying to do. It's a place for us to collaborate with the community on sample code and various projects that are used in some way with DevNet. So it's very broad, but yet told you a bit about what we wanted to do. We have an email alias where you can easily contact us, and then we just verified that we actually own the authoritative for the domain developer.sysco.com. So you knew this was legitimate. So when you see like all of these many Cisco GitHub orgs, at least this one you knew, okay, we know what it's about and we know it's legit. So the other one I mentioned, the Cisco GitHub org, this one was a bit more general purpose just as it says here, open source projects from Cisco systems. At least you have some idea what it's there for. You have a person you can contact. If you know Fluffy, he's very responsive, he's passionate about open source, you get a good answer from him. Again, verified that we own the Cisco.com domain. Just so again, you get at least a little bit of assurance of who you're talking to. So this just solved our initial problem of not knowing who to contact if you had a question about what this GitHub org was about, and hopefully the description even helped you have at least a good clue of what it was about. So a step in the right direction. The next thing we thought we needed to figure out and make clear was what's appropriate for one versus the other. This is both for our internal users who will be contributing to it for external audiences as well. We said, well, the Cisco DevNet one, we will use that primarily for small projects. It's a sample code where we're trying to illustrate, here's an example of how to use one of the APIs of one of our products as an example. Or an integration between some of our products and someone else's product. Whereas the Cisco GitHub org, this would be for larger projects that actually have value outside of Cisco. We're starting them, we're running them, we're maintaining them, but we feel in many cases know that there's people outside of Cisco who outside of using any Cisco product find them very valuable as well. We really expect and want people outside of Cisco to contribute. Because of the significance of these projects and the contribution model, we also keep, and the fact there's fewer of them, we keep closer tabs on them. We really think a bit more proactively about community of each of these individual projects or repos. The next thing is public versus private. I'm going to talk about this in relation to repos, but also in terms of people, because I think there's an interesting phenomenon. What you have to keep in mind is that when you're looking at a GitHub org, if you're not a member of that org, you see a different version of it, and a different number of things than people who are a member of it. So when you are a member, you may have the false sense that everyone sees what you see. As an example here, what I'm showing now is what a member sees, is when I was logged in, but then if a non-member comes, they see something a bit different. One of the governance aspects that we put in place is, well, for the Cisco DevNet org and for the Cisco org too, all of the repos we have there should eventually be public. So we don't really plan on having any private repos. If they're meant to be private, they don't really belong in these GitHub orgs. We have other things. We have enterprise GitHub. We have other ways of keeping code internal. Don't mess with a private repo on GitHub, if that was what your intention is. So yes, it might be private for a little while, but it should become public. If you look at the two versions here, you'll see that we have 681 repos total and 673 are public. So a non-member sees almost as many. So we actually are doing a good job. I can tell you a few years ago, we were not doing as good a job. I'd say close to half of our repos were actually private. So we've cleaned that up a lot. One thing that's still a bit odd here is you see we have 210 people in our org. But if you're not a member, you only see 12 people. That's despite me trying to ask people, hey, the default is when you join an org, you're private and you have to choose to make yourself public, which is probably good from a privacy point of view. But it can really make complicated things when people want to contact you and reach out to you. In fact, what you'll see sometimes is a GitHub org that has a lot of members, but all of them are private. So for you a non-member, you'll see zero people. If they didn't provide an e-mail alias or some other way for you to contact them, you also can't see any of the people who were involved. So you're stuck in terms of trying to figure out, why does this thing exist and how can you learn more? Okay. Next, just a brief discussion of membership and permissions. So GitHub, you probably know this, has different roles. You have owners, members, and outside collaborators. I'm just going to talk a little bit about how we've used them and kind of evolved our use of them. Now, as an owner of a GitHub org, you're basically a super user. It's like root privilege. You can do everything and anything within that GitHub org. So when we first started out, whenever anyone wanted to add a new repo or change anything, it's like, okay, I'll make you an owner. So we ended up just having, almost everyone was an owner. We had people who weren't even at Cisco who were owners or who were owners and then ended up leaving Cisco and going doing something else. Nothing awful came as a result of this to be honest, but we realized that that isn't really right. It's just lazy and while it's empowering to let everyone do everything, that's probably not a good practice, especially as things start to grow. So we have reduced it. We still have a little over 20 owners, which I would say is arguably too many and we should really try to reduce it more to just a few like three or five. But at least they're all Cisco employees who have good ties to the DevNet group. Also, we made two-factor authentication mandatory, if you're going to be an owner. This gives us a little bit better sense that someone's account isn't going to get hacked in there, and bad things happen to our GitHub org. So we're not great here, but we're better than we were. Now remember, this is the default role in GitHub. By default, all members have access to all of your private repos. They're able to see all of those. But now remember, we don't really want to have private repos to begin with. Initially, everyone who wasn't an owner actually was a member and had accessed all those private repos, and we weren't very diligent about, well, should they really see our private repos? Are they a Cisco employee or are they not? Did they just contributed something so we made them one? Maybe they shouldn't see these private repos. So now what we're trying to do is make you a member only if you have a need to see these private repos. If you think about it, there should be very few private repos, so there should be very few people that really need to see that. So we're using members less and less. We still have about 150, but again, we've reduced that. I think it would also be good if we forced all of the members to have two-factor authentication, but so far, we've just asked for that. We haven't enforced it. Then the third role is an outside collaborator, and I didn't even understand what this was at first, but now I'm a big fan of it, and basically anyone who wants to contribute something doesn't even need to be an outside collaborator, but where it is really handy is, I can create a new repo for someone. I don't even need to make them a member of our org, yet I can make them an admin of that repo and really empower them to do everything and anything with that repo, and they just become an outside collaborator. So they don't see any of the private repos. This is a great way for me to work with people who are not Cisco employees who have no need to see our private repos, and yet let them have vast rights with the repo that they are the admin for. So we started making use of this a lot, and so we have more than 500, and that's great. The one thing is I wish we could get them all to have two-factor authentication too. So in summary with permissions, for us the level of a repo, that's our main guardrail. We've actually turned off the GitHub default that says members can create new repos, and we said only owners, those 20 odd people can create new repos. Now once we create a repo, then we give very broad, in some cases very broad rights to it to someone who may not even be a Cisco employee by making them an admin, and this has worked out great for us. So I think it's a practice that at least for now, we plan to continue. Okay. Now shifting gears to contribution, we're here at an open source conference. Obviously, we want people to contribute. So it's very important to welcome and encourage contribution, and as I mentioned before, you don't need to be a member, you don't even need to be an outside collaborator to contribute, and because contribution can take many forms, and it could be as little as starring a repo, submitting a clarification for a read me, sending in a pull request. All of these are ways of contributing, and what we try to stress is for your repo, make sure that you let people know how you want them to contribute. Most people are willing to contribute the way you want them to, but you have to tell them how you want them to contribute. So we really emphasize having a contributing file in your repo or putting the equivalent information in your read me, and before you contribute to someone's repo, make sure you've read their contributing file and contribute accordingly. That will just reduce a lot of that initial friction that may happen, and lead to you contributing in a way that's rewarding for you, but also expected by the project. The other thing is a code of conduct, and this is a very simple ask of people, but it's also very important. So we stress that you should state your code of conduct in your repo, because we really want to foster a welcome and open environment in which everyone's able to participate in a hassle-free, very positive way. So we provide a sample code of conduct, which we think works pretty well. You don't have to adopt that, but we say you should have that or something like it, just to create that good atmosphere. Then what we did was we put these files, the contributing file, the code of conduct, and then a read me that illustrates what we think a good read me looks like, all the points you should try to cover in your read me, an example of a license so people are aware of how that works and how to add that to a repo. We put all of that in this template repo, and we put this up as an example for people to be able to use. They can clone it, they can run a script where they answer a few questions, and then they get an automatically creates a customized version of it, and sets up their repo with these things in place, a good read me where they can just fill in the blank essentially, the code of conduct and whatnot. So we're just really trying to make it easy for people to do the right thing, which you'll find out most people actually want to do the right thing if you can help them, and especially if you can make it easy. Okay. Now moving to licensing and copyright. I'm not a lawyer, I know just enough to get myself into trouble sometimes. So I'm not going to go into any depth here. But just to let you know, very broad level, we tried to use two different licenses the majority of the time. Either like a BSD, three clause license or really an MIT license to those two we use. Kind of similarly for these small projects, most of the ones that I mentioned we have in the Cisco DevNet GitHub work tends to be that a very simple, clear, concise license that gives you sufficient permissions to use it and do with it what you want is sufficient. So of course we may alter that based on the dependencies you use and other licenses that are involved with those dependencies. But by and large for these smaller projects we use BSD or sometimes MIT. Then for the larger projects, the projects that I was mentioning are more typical of the Cisco GitHub org. There we usually do Apache and we go with the Apache license just because it provides a bit more structure and some of the things that make it easier for collaborators outside of Cisco to feel comfortable with collaborating that that's a safe environment and for us to accept their contributions to. So we usually don't go with that for some of the really small projects because we just don't feel it's worth the added complexity. But we do that for the larger projects and this is just as a general rule. Now the one thing that I do want to stress and this is actually a simple thing but it happens all the time is people mess up on the copyright and as much as I love the functionality in GitHub to create a template license files, I think that's great. It leads to a lot more people putting licenses on their file, on their repo. But you can just see here, for example, I was creating a default one for which license, the BSD3 clause. And now by default the copyright owner is going to be my name. And in the event I didn't put my name with my GitHub account, it would just be my cryptic user ID. This isn't the end of the world but it's certainly not ideal. What we'd like this to be is Cisco Systems, Inc., and its affiliates. So just a very simple change but we have to let people know, don't take the default, put this in instead. And then people have tended to do the right thing but until we made it obvious to them, this got messed up a lot. Now the point that I do want to spend a little bit time though on is this corporate license challenge. And if any of you who work at large companies, you probably run into this. Not all the code that we want to share really can be open sourced either because it conflicts with our business strategy to open source it. Or I guess we could open source it but it's not really appropriate because it's only useful to paying customers because you can't use it unless you're paying us for access to the web service that has the API that supports the APIs or something like that. So it doesn't really feel right to open source that and then say, but you have to pay us. So we wanted a way to share this code and make it easy to do that but without discouraging people from open sourcing code when possible and when it is the right thing and without confusing the community. So we came up with this Cisco sample code license and it is not an open source license. There are restrictions, it can only be used with Cisco products. It's not meant to replace open source in any way but what this did was it empowered our community to share code very quickly and easily with the community, right? And code that they wouldn't have been able to share otherwise or that would have required negotiating a license that would have slowed things down. So now we can put it out quickly. And what I'm actually finding is in a lot of cases, people will put stuff out quickly using this license. And then if there's interest, we can actually go back and re-license it with an appropriate open source license. So it's kind of a speed thing for us too. The gotcha there being, we need to watch out for people just being lazy and open sourcing with this, or sorry, putting code out with this license and never getting back to do the open source when they could. We still want open source to be the default whenever it's appropriate. Okay, I'm gonna kind of skip the navigation stuff in the interest of time. But basically when we have all of these GitHub repos, you can think that we wanted to make it easy for people to find code regardless of whether they were in one of the GitHub repos that I've mentioned or one of those other dozens. So we had kind of a quick and dirty way of doing it using automated tools and APIs, and then we switched to this opt-in method called code exchange. And I've given entire talks on it. If you can just read a little bit about that, but in the interest of time, I'm gonna just gloss over this, because I don't think it's as important for this talk. And I just want to make sure I have time for next steps. So a few things, you've seen security stressed at this talk. It's an area where we know we could improve, especially with those 600 and something odd small projects that don't get a lot of scrutiny in many cases. There's security vulnerabilities all over the place in those. Having a way of identifying them and dealing with them more systematically would be great. Establishing and tracking some metrics, we don't really do that. I'm gonna look for topics and I'll be going to the chaos con. And hopefully understanding a little bit better how to do that. An audit process, that would help us a lot because we're really good about making sure a repo only gets created and added into our GitHub org if it's appropriate, but then you need to make sure it's still appropriate over time and figure out when it's maybe you should archive it. Then I want to take this governance that I mentioned that we've applied to a couple of our GitHub orgs and see if we can apply it more broadly across all of Cisco, because I think we've learned a lot from it. And I think, in general, those other GitHub orgs could be improved. And we probably learned more from talking with them too. And then lastly, we want to make it easier to contribute to open source within Cisco. We've done a lot of improvements in this area already. One area we have not tackled yet is recognition. And so there's a lot of people doing great things with open source in Cisco. And I feel like they're not getting recognized or rewarded for that enough. We reward people for patents and things like that. We don't really reward them for open source. So it'd be really good to make some improvements there. With that, I think I used most of all my time, but we may, there may not be a session after me if you have any questions. And I'm certainly happy to stick around. But any quick questions? Any suggestions of things that you're like, wow, he was saying was a good thing. We need to know something even better we should do. I'm looking for other suggestions for improvement to help add to my next steps. Okay, yeah. I need to create a repo and just open a pull request. Instead of like, hey, I need to talk to- Instead of sending us an email, they can do it with a pull request. Nice. It feels a little more developer friendly too, so fantastic. Well, thanks, I'll look into that. All right, well, thank you all very much. And I look forward to the rest of the conference. Hope you enjoy it too.