Hello everyone. Jonathan will be unable to make the meeting today, so I have stepped in. We'll give everyone a few more minutes. Okay. So for those of you that are just joining us, Jonathan will be unable to make today's meeting, so I am going to step in and assist. So bear with me. We've been making really good progress on the content for the paper. I would like to point out a couple of things worth noting and I'll drop them in the channel later. For items that are specific recommendations, they should be captured under a recommendation header with an assurance category and a risk category. It looks like we've started to settle on a format for what that looks like, so I'll make sure that's included. So we've got a lot of really good content in here. There's a couple of areas that do still need to be cleaned up, but overall we're on the right track. So according to our schedule, by next Friday, we should be finessing the content and we should have most if not all of the commentary cleared out. So any active discussions need to be resolved associated with comments, any suggestions that were placed in the document need to be reviewed and accepted. So over the course of the next week, we'd like to focus on kind of finalizing the organization, making sure that we have all the content in the right spot, clearing up any potential confusion in the content as it's written, and providing any further clarifications if a discussion were to highlight, for instance, that something isn't exactly clear or we're focusing too heavy on web applications, for instance. Which is actually the area that I've been checking out this morning. So I will type all of that up and drop it in the channel, so everybody has notes for it. Does anybody have any items for open discussion? Emily, are you asking which controversies do we want to bring up first? Yes, that is what I am asking. Which controversies can we knock out on the call? Yeah, maybe I will jump in. I think I was going back and forth with Faisal. Maybe there is some misunderstanding from my side. Why Pat is better than the SSH case, right? Like, so from my understanding, there is both pros and cons for both authentication mechanisms. And I don't really get why the assurance is a bit more over for the SSH. That's why I mentioned that some threats related to personal access token, right? So, yeah, so there is a, we mentioned about implementation or rotation policy for SSH key. But why, you know, I don't understand why we don't need some kind of rotation policy for Pat, right? So Pat is, from my, from my understanding, it's a shared secret and then it can have more security risk compared to the SSH key. So if he won't rotate it. So that's why, you know, there was a going back and forth with that particular one. So if Faisal can help me to understand that. Yeah, Vinod, thank you for your question. I tried to clarify this thing on the comments as well. So, so when we are talking about Pat, right, we have to understand that it is a token, but it, the automated agents do not maintain that token. This is just a one-time token that is used to basically use OAuth mechanism to get, get other tokens. And then those tokens are basically used to kind of communicate back and forth with the Git repositories. What I am, when we say in this section, let me show you just a second. Sorry to jump in Faisal there, but from my understanding, the GitHub or Bitpocket personal access token is not an OAuth token. No, it is used to get an OAuth token. It itself is used. It is not maintained by the agent. So agent will not keep it, right? It is just used to get an OAuth token and then OAuth token is used to basically get, get any request, right? Or any, any kind of operation, get, get related operation is then performed by that OAuth token. The personal access token itself is not maintained by the, by the agent or the runner, okay? But again, the point that I'm trying to emphasize is that we are recommending policies, right? So if you have any policy, right, you are saying, okay, this is the comment, right? If you have any policy that will allow us to address shared secret concern, then we should include it. I am, I am with you totally, right? That we should have a policy if you know of any policy, any example, let's include it, right? But we cannot include that shared secret, right? We are not identifying concerns. The focus of the paper is around best practices, so we are recommending policies. And then those policies help us to address something. So what I'm asking you here in these comments is, what is the policy that you want me to include that will address shared secret? Yeah, okay, so I'm, I'm with you. Yeah, I completely get your point. I said, I only have that particular issue when we recommend one or another life. So I was commenting where it was a, for a personal access token should be preferred or as I said, when we make such a statement, right? So I think we should have that level of assurance why we are doing that. Yes. One of the challenge I see with the personal access token is the rotation part, whether how you can programmatically or automatically rotate a secret that that can break a built pipeline or CICD things. When you change it, if the board side is not saying, you can break the thing. Yeah. So OAuth works this way. OAuth has two tokens. Okay. Once you have received the OAuth token, you also get a refresh token. Okay. So there are two tokens. Okay. Normally for every communication, you will use your OAuth token. Okay. But before the OAuth token expires, you will use the refresh token to get a new token. You never again use the patch to get it. If you have a continuously running CICD pipeline, of course, now can there be out of band processes that you do not use refresh token? Yes, there can be. Right. But you have to understand that's why I'm, I'm sorry, my understanding or the personal access token is similar to OAuth in GitHub or BitPocket. For OAuth, there is a client identity. There is a client authentication in order to get a refresh token, right? Like there is an initial authentication when you get an access token and refresh token. Thanod and Fusall. Okay. Before this turns into one of those terrible like city council meetings that happened on Zoom, can we move this to like a thread inside a slack? And I think it needs to be a thread inside a slack because these, I will say these Google dot comments are not. They're not easy to follow. If you can just do a thread inside of Slack, if you write this down, we don't have to keep thinking or remembering what was said on the call. Nobody has to watch a recording either. I think I actually do think we need these for each controversial item. And I and there is a strategy element here for something that we're going to recommend. Are we going to like vote on it? What is this a democracy white paper or? So the way that I would consider it being done is when we have a case when there are nuances associated with one and another that are typically conditional with their implementation, that we discuss those conditions about when it could potentially be used. So this is I don't want this to turn into who's got the best idea argument because a lot of that gets gets very heated. So we it is our responsibility to ensure that we are presenting both cases and allow the reader to make an informed decision. So realistically, if that means adjusting the recommendation to be you need to use something and here's two options. And here are the conditions under which you might use this. And here's the conditions when you might use a different one. But I would also state that just for the record, personal access tokens in this context need to be explicitly clear as to how we're intending them to be used. Because pets can be used in other applications in different environments and different cloud service providers. So it's one of those items that we need to be very clear in what we're talking about. But I agree, it should be moved to a thread in Slack. I think that's if you could, Vinod, at Fizal, like, let's let's let's hash it out there. Everybody weigh in. So so just to end this discussion, right? So if you look at the recommendations right now, we have recommended both SSH keys and also personal access token. It's not like we have completely disregarded SSH keys. We are just saying that for developers, this will be make more sense right now. And for CI CD pipelines or agents, access token make more sense. And then in this paragraph, if you read it, we have given our arguments, right? And you have to read those arguments that why we are preferring it over SSH, right? Shared concern is not the only thing. There is expiration attached to personal access token and they are randomly generated. OK, so there are these things which basically gives Pat more ability to operate more in our least privileged model. OK, and this is why this recommendation is being both of them are being given. So I have not taken any side, right? But I just not can randomly say, well, there's shared secret there. I think I understand it. I think the key thing getting back to to Emily's idea of Fizal is that it's more it's more about making a clear recommendation. If we put everything out there, it's not recommend we're not taking a side. We're not recommending anything. We are taking a side. CSED by plan agents. OK, I was rewriting it differently. Just make a copy, make the edits, and we can wait one of the other and how we do it reframing. Yeah, I mean, OK, yeah, I mean, I think I think ultimately one of the things we got to get to is like getting the gist. So Mike is on the call. Mike Enzer is on the call. You were you were involved with the software supply paper from Google. I'm massively curious how you figured out what what made it into the paper in terms of recommendations versus what fell on the floor of the editing room. Sure, I think a lot of it was passing around. So I wrote the paper pretty much the entire thing. So what I ended up doing is like I had a lot of things additionally that didn't make it. What I did is I originally just put everything together and sort of passing it around to the rest of colleagues and even some outside of the company and had them kind of vet it. Like, do you also believe in these things too? And so whenever I had a lot of the controversy, those are the things I ended up pulling out because even in this scenario here, like, I don't believe that or at least I'm not entirely sure that like access tokens are always the same between all the source repositories. What happens when you don't use the get repository and stuff like that? You're going to have differences. So I tend to like, I tend to pull those things out and I didn't use them as as a or I didn't put those in as a hard recommendation many types.  But if it was a very obscure, I generally either deemphasizer or pulled out because I don't because you don't have to make a recommendation. I'm like, that's the thing. You only put in if it's really strong, right? Yeah. And it's like, you can pull it back out. Right. I mean, from my perspective, the entire point of this paper is that I want to know very succinctly what I should be doing. That's it. And so if I see six equivalent options, that's not helping me. That's just making me more confused. I think we're doing here, right? We're taking a secret and we're tying it to an identity. So that is what we need to talk about rather than the specific method and how we do it, right? We can say, hey, these are the implementation methods of doing that, but this is what we're doing. We're identifying that workload to pull that get repository, right? Or we're saying, hey, this person has the ability to do that, right? So we're giving them a secret to do. So we're tying secret to identity. There's a lot of different ways to do that depending on where your risk level is. Yes. So Rich, I agree with your point. I definitely will continue discussing the slide even though I'm not that active in slide. So yeah, so in my opinion, there won't be always one thing for all the problems, right? Like there won't be a silver bullet for all the things. So maybe there can be a situation we have to leave it out one or two or three. But definitely we shouldn't give six, seven, 10 options that make people confused. But at least there might be pros and cons for each and everything. I don't think we should go in details. I agree with Faisal that we shouldn't mention all the key management, all the problems and all the threats and all the countermeasures. I think this paper will go too much. But instead of that, maybe we can give them two or three options depending upon organization, risk appetite, whatever options they can use, right? Like there is a risk elements to everything. Sounds good. So that'll be moved over. I kind of heard there as well that, you know, you basically, I'm sorry, I didn't see who was speaking. I'm still a little bit new to you, but I like what you said there where it's like, you know, we're tying a profile to a secret or an identity to a secret, something like that. So like having that explanation before you try to say, here's the recommendations. It's more like you're setting up the principle and the interface for what you're trying to describe. And then the implementations, you can't have multiple of them after that because you've described what that problem was and then here are some ways you can solve it. I like that approach as well. So rather than just straight into recommendations, sorry. No, actually, that was something that we discussed previously is the formatting of the different sections, which I'll repost that in the Zoom or in the Slack channel that way everybody is aware of what we're looking for. So the discussion on Pat and SSH, please move that to the Slack channel, thread it that way it doesn't blow up the feed. We need to get that resolved before March 12th. So if that means providing dual recommendations or moving the recommendation to a higher level and discussing those conditional options, let's go ahead and make that happen. Any other markets of debate? Emily, to take further what Richard had said, and I think this is going to apply to any debate, ultimately, whatever recommendations we make need to be able to stand on their own in front of a security review team, that none of us are going to be there to defend the argument. Correct. And it will be the justification of like, hey, this council of people who have cut their teeth and this stuff, we cannot do the service to people who are trying to put software into places and saying, we're going to do it this way. And on even take the identity thing, sure, like map identities, identities to secrets call right on in that. But even the order of like, well, which one do you do first? Because if you're just distributed in tokens to anything that's been identified, you're back in square zero. So how do you test for identity in first place? If you put secrets first, you're going about it wrong. So we should be arriving to that level of detail and we can even like, write down like the thought process of getting a bet. So I think ultimately reason will stand up or pop up from the document if we capture like with that fidelity. And don't be afraid to add footnotes and refer to blog posts where others have waged war on the internet about those particular topic areas. Can I can I ask that for the controversies? If I think we should thread all the controversies and I think we should label them, I'll find some sort of cute emoji to make that happen. And I think all of us should weigh in one of the things I think we really should do it. And, Andres, you had a good point about this. It should pass our sniff test first and then the the real sense of satisfaction should come if outside security folks read our recommendations and don't go what they're talking about. Because that's that's I think ultimately the goal is to be concise. Am I wrong on that? Should we I kind of crowdsource some of I have a and a big DevOps slack that I'm part of and I go to some of my my close counterparts and like, you guys do this as anybody use Pats for for developers, you know, Pats for CSED tools, fine, but developers know. So just is that is that sound like something we should do? First, all of us should kind of agree that this is a sensible recommendation. And then eventually we we expose it to the greater that way when when it when it does get released, people aren't caught off guard. So so just to add to this point, Richard, so we have 200. So this is my point of view, right? We as a community are gathered here. OK, and we all have different backgrounds, right? You might be a developer in the open source community, right? And you act as a developer, right? I am more on the enterprise side, right? And the idea is that we take recommendations from each other and then incorporate in this document when we say that, well, I go to someplace or I have not seen this thing, right? For example, I have not seen in total deployment anywhere in enterprises. So I cannot go into that section and basically say, well, I have not seen it. Let's remove it. OK. If people have not used it, let's take the opportunity to combine feedback from all in this forum and give recommendations. So if people do not know about something, they know about it. If somebody has been using things wrong for 10 years, we cannot say, OK, great job, continue 11, 12th and 13th year on this one as well. So we have to combine opinion from both enterprise side and also from the development side and then give these recommendations. So I think in many of your comments, the comment is like, I have not seen it, right? Yeah.  So I mean, similarly, that's where we can provide evidence that people are doing this and people consider it best practice. Yes. And then, since that allow list, no, I can't find anywhere where somebody recommends that. No. So this is where I will tell you, right? This is where you will take my recommendation, right? Because I come from enterprise. People do set up project templates, build packs, and they do define using post pre hooks and post hooks in Git repositories. What what developers can come in? This is what I do and I'm telling you if this thing is not out there, I am telling you based on my experience in a similar way as a developer, you will tell me in development, I use SSH keys more and that's why we have given the recommendation for SSH keys for developers, right? But you when you say that I have not seen it or my community has not seen it, right? Then I have no argument against it, right? Because I'm like, well, I have not seen in total, for example. So does that mean it does not exist? Right, right. And those of us who work in the enterprise know that there's a whole variety of maturity levels. The question is, who do we want to offend more? You know, like, do we want people to be looking at it and saying, this doesn't this is just an added process that makes sense in the enterprise, but maybe not for my small open source project? And how do we parlay that? So I would make a recommendation that for instances of discussion or recommendation and justification within the paper where there is a particular enterprise viewpoint where the impact is significant for software producing shops. And that is our goal and objective that we need to make sure that we are clear in couching that and associating the assurance and the risk level. And if that means that we need to break the recommendation into two corresponding areas, we can certainly do that. While it is still in draft and then revisit upon a final community review, because ultimately we can have the best, most brilliant ideas documented within this paper and we can get it to a semifinal state. But if it does not hold up to a community review and we cannot objectively adjudicate those comments and suggestions from the community, we will have to revisit the topic area in question. So for the purposes of continuing to move forward both today and with the paper, if there is a viewpoint that is specific to enterprise or global level security for supply chain versus open source specific development or I'm just a lonely developer working on a fun project, we need to be clear and the recommendation, the justification and the associated assurance and risk levels. That's why we have that level of assurance and those risk categories so we can separate those line items. Yeah, I agree. Excellent. What's next? So I have to drop everyone. Yeah, so please just last thing, do check this assurance level and risk categories with Pat's as well. So yeah, and we'll follow the discussion up in Slack channel. Yeah, thank you. I have to drop. Yeah, sorry about that. Thank you. Thanks for all. Okay. Does anybody have any other highly contested areas? I think that can be potentially another one, but I haven't received anything so far yet, right? It's with the software bill of material. I'm not sure. It is also something, you know, may not be actively used in all the enterprises. So for now, we, I mean, at least in the document, I have put both SPDX and Cyclone DX, right? But I'm not really recommending one or another. So it's interesting that you bring that up. So I had a lovely conversation with Alan Freeman from NTIA who is heading up the SBOM effort concerning some of the topic areas and the content. So I have engaged with him and requested that he provide some insight and feedback. There are some organization-specific endorsements associated with one format over the other that we're going to dig into, and probably offline to figure out what's the best and most appropriate recommendation there. Because ultimately, whatever we identify in this paper is likely going to be what the industry is going to start looking towards and settling on. And we want to make sure that they're set up for success. Definitely, sure. So is Alan going to join Slack or Meetings or anything or just the Google Docs feedback? I'm working on that. Okay, that's fine, just thank you. Emily feels like the biggest controversy is, well, we want to push cloud-native security practices everywhere. But now we're talking about, well, here's where enterprises are at and we need to account for traditional ways of doing things. I think we need to call that out in scope. I'm not inclined to do the latter, honestly, because we're just perpetuating status quo and just reconfiguring existing pieces versus like, hey, guys, see the light. And I don't think anyone here is like a lowly developer working on a fun project.  So we should make a determination on that. Well, I would defer that to the group's side as well. Yeah, and the community review will actually help resolve a lot of those items, especially if they're reading through it and something seems out of place. In some cases or in previous documents I've worked on, we've provided a disclaimer around a few line items where there might be considerable differences for an enterprise that's doing software production versus a shop that is fully cloud-native. So just something to consider. Yeah, and like, let's have the debate on paper, make a copy of the doc as if you're making a fork, make the edits you wanna see, and then share that back. It's often easier to come with someone like, hey, here's how we think we can frame this better rather than trying to get someone to rewrite what they already wrote that may be personally attached to. Okay, so moving back to the schedule. So a quick reminder, and again, I'll put this in the Slack channel that we should be working towards clearing out the commentary on the document as well as finalizing any last-minute content that needs to go in and smoothing it out or dishing it to make sure that it reads correctly that it's not an incomplete thought. Are there one or two individuals that would be interested in kind of going and doing that initial first pass and making sure that the recommendations are formatted correctly, that we actually have assurance and risk levels associated with them that the justification is fully formed. Don't everybody jump at once. What's the date on that, Emily, that you want that done by? March 12th, just that initial first pass. Not looking for you to spend two hours writing a justification on an area that's controversial to you, more just to make sure that we've got everything buttoned up and that we're not missing an assurance or a risk level or that we're missing a format error somewhere. Just a good first effort. March 12th. All right, I'm blocking off time now to do that, Emily. Thank you, Cole. Can I get one other person to help him out? Please, please, please. And if you could, Emily, just kind of slack me what those individual tests are so I can make sure I stay on track and I don't get distracted. Yep, I will. Awesome. You can jump in and help make a pass as well. Is there a style guideline out there to make sure that? Because I'm just new to this. I don't want to try to make recommendations that I'm not sure about either. Yep, it will be in the Slack channel so you all have something to go with. I'll help out with that. Awesome. Okay, is that everything for today's meeting? I want to try to give folks back 30 minutes if we can, but if not, we still have another 30 for more discussion. You know, I've been thinking about this and I think there's some themes that we need to pull out of this and kind of start thinking about the executive summary to start tying everything together. And I think the theme of verification is really important, right? How does everything tie back to verification? Verification that the software that the code came from where we know where we think it came from, the things were built away. We think that's all the guidance that we're kind of seeing coming from MITRE and some of these other places that are printed out reports. I think we should continue to follow that and really tie that all together. So each one of these points, right? If there's a way that we can tie that back into verification, let's work on doing that. I'd like to get some feedback on that, that terrain of thought. I'm not positive I'm correct, but I think I might be going along the right route. Yeah, I actually had a somewhat related thought when looking at the distribution sections yesterday, where we have this like separate call-out section for how to verify metadata. But it seems like that would almost make more sense when you're describing what the metadata is to kind of tie that whole end-to-end. You create it here, you verify it here process, or at the very least just like calling out, no matter what you generate or sign or whatever, make sure you verify all of those pieces. Like right now we verify left, right? We verify like with the CI CD process. I think we want to move that to the right as much as possible and verify as close to the execution of that workload as possible. And that's just kind of some of my thinking that I have going to that. So that could be like a theme of this paper and how do we do that? How do we have these tools in these recommendations? How does that help support that effort? So I'll tell you one of the things that I did. So I heavily leveraged our binary authorization concept, the idea that you have like these signed attestations. And so when you create any of your, so you do the verification in the pipeline and you run through some sort of rigor and then you create an attestation for that. As long as that artifact doesn't change, you can only, you know that you got the immutability and then your trust can stay in there. So then the verification is kind of a, the attestations or groupings of those are kind of the proxy for that at the execution time. And so I did the same thing. I just didn't do a whole series of them in the environment. I relied on the attestations and the buildup of that to transfer that trust. So then you're not trusting the signature, right? You're trusting the attestations. Correct. It's a zero trust principle. You wanna use the buzzwords. Correct. And then I essentially use, so that way you can have many of them. So it's both the signature of the software, it's a guarantee that it's the person who wrote it, it's all of your tests and automation, all that kind of stuff is bundled into these attestations. And then you can have a policy that allows you to, allows you to do a couple of extra things too. Like if you do need that break glass scenario, like like I just gotta get something out right now, you can create a quick policy in placement to replace that. Rather than going in and hitting every single tool to say, normally re-check the validation software, you can, it gives you a little bit easier of a point to make changes for. So. Right. And I think that's what we wanna do in a cloud native CI CD environment, right? Traditionally, right, we just rely that the pipelines configured the way that we configure it for best security practice, right? We don't do any validation, out-of-band validation of that pipeline in the artifacts and metadata from that to make sure that's correct, right? We're replacing trust in some administrator that configured a pipeline, which we all know, right? As good as we are doing this stuff, we always make mistakes. So I really wanna emphasize that in this white paper and it sounds like either some agreement is consensus on that. So if we can push for that, I think it would really bring the whole thing together and make it more cohesive. So yeah, I like it. In fact, that's actually one of the areas that I didn't get to address in my paper because I don't have a good answer for, and now that there's a really cool community, I can ask it at some point here, but it's the, I can easily get around things in the CI CD pipeline if I have access to it. I can literally just redefine something and override it and just bypass all the security things if I want. So we can't always rely that the CI CD pipeline is completely controlled by an administrator and all of that, you have to build in these checks as you go along the way. And that's where that verification is important and then just be able to capture it. Anything else? This is your time, folks. So I just want to review the schedule. Do we feel that between now and March 12th is enough time to start cleaning this up? It's not the final review for this group. It's more to get the content in an area and a layout that we can actually do a cohesive group review. If not, we can bump it out another week, that's fine. And I think we should maybe do a poll, see how many hours we have next week to work on it. And you know, people on this call and then kind of make a decision from there. So right now I'll start, I have six hours blocked out on Wednesday for that and zero the rest of the week. So that's what I can commit. Emily, I just want to add, right? There are some areas which are not still missing main items like distribution of S-Bomb. I don't know who took ownership of that like a couple of weeks before, but there are a few items like that. I think we need more content. And I don't know if someone else is interested to jump in and help with that content, maybe, you know. I plan on reaching out to Alan and company to get their engagement on those particular areas. I did reach out to some other people as well in the background, but you know, everybody's busy, right? So that's the problem. I also ask some other people, but I think there were a few other individuals joined the call like two, three weeks ago from your own channel or, you know, they told that they can help, but seems like they may be busy or they're not available at the moment. But, you know, if someone else is still interested in those areas, maybe if he can have some content that have things ready. So we're going to target for March 12th. And then during the March 12th call, if we feel like we need more time, we'll push everything out one week. Does that work? Yeah, yeah. All right, let's try to get that done. If there are areas during your reviews and commentary cleanup that are grossly lacking in content, go ahead and highlight them yellow. And I will make sure that I add that into the notes from today and drop that in the Slack channel. That way we can get that taken care of, right? Thank you. Speak now or forever hold your peace. Anything else? No? All right, everybody gets 23 minutes back. Congratulations. Make good use of that time working on the paper. Thank you all. Thank you. Thank you.


We got 40 minutes, which usually means that we'll go short or longer on time I say that always means that we're short longer on time so I'm not going to wait for everyone else to come in and I Really did want to go get a coffee, but I'm not so who's really tired right now Awesome me too Okay, so what we're talking about today is contributing back as an operator So operator integrator manufacturer What I want to have just a Q&A discussion day, so we have two microphones up here I kept it really light on slides because there's stuff that I've done inside my company to build a strong business around mixing in open-source contributions into what we do And and balancing that out a lot of what I do when I talked to new companies as an open-stack ambassador Or just want to talk to the company as another operator I talked to individuals and companies manufacturers other operators whoever is Sometimes I look at the beard and they want to talk about the development of things Sometimes they want to talk about cloud platforms SDN Most time I talk about process and talk about process and business strategies and and a very simple realization that developers cost a Lot of money and giving away code is giving away money And so what can you do to actually do it successfully? So that's what I want to talk about now So I want to talk about how by giving code back to the community how that can help you grow So again the microphones are there to be used We have a nice small thing so why don't we get all cozy and come on in we're all friendly Yes, I'm looking at you in the back of the room No, it's alright if you don't feel like coming up you don't have to so Again, this is as much about businesses as a tech. So who here is like a technologist in their business? Here in who here is a developer? Okay, who here is a manager a director a vice president a chief Okay Who here has to or wants wants to get your business contributing code back or being a tighter member of this community? Okay, so that's a really good goal. I'm going to talk to me in two segments here So I'm going to talk in a business segment first in a technical segment second What I find is a lot of people go direct to the direct technical How do you contribute back as an operator of the technical items of it? But then they miss the business at the business items and they end up getting squashed general counsel board of directors whatever end up having a problem so The gender we have I'm going to talk about why we do this and we being the community I don't talk a lot about the business. I work for Steph that's pretty accurate. I don't really talk about actually at what company do I work for? Exactly and I've known you for two years So I'm actually going to talk about the company. I work for It's not a sale thing. We actually don't have to sell we just got bought a week ago. So or two weeks ago. So sweet Yeah, had some meetings went to Hawaii for a week had my guys coding without me interrupting them It was awesome. So I'm going to talk about what the effect it has been on us and the effect of getting acquired building a half billion dollar company getting acquired was really good and then Talking I'm going to talk about the business topics of how we do this and stay profitable We all have we all have a responsibility to create healthy thriving organizations no matter if we upstream or not And we need you need to stay profitable to do great things for the community I'm going to talk about the technical top tech some little tricks that we do that allow me to As as leader in the business maintain control of intellectual property avoid violating non-disclosure agreements and and leakage of also partner property and License code and then things that we do to go ahead and there's some technical things that we do and we're actually growing faster and Faster every day in this to be able to model the effect of open-source contributions on the rest of our business Does that sound like good topics that we'd like to talk about today? Does anyone think this is crap? Okay, cool.  You did a lot of time you need or there's not that much time this week So this was me this morning. Yeah, this was me doing a workshop. All right. This is me I had submitted I think three presentations to opens tech design summit I had a list of things that I feel are important to talk about in 2014 And I think all of them got accepted. I was like, damn it It's actually a lot of work presenting and it's kind of this is a work week for me as part of the community Luckily, I was so hungover after probably I will be honest I have been partying and drinking and celebrating every day since we announced and so I Didn't realize that we actually had a workshop this morning and I had a presentation and And I was really lucky that I have an amazing team So these are these are this is actually one of my one of my developers mark Mcglanna That does some QA test some QA work for Tempest Is actually a really awesome dude and he led a workshop on developing for multi-node publicizing multi-node multi-node dev stack deployments Those things allowed me to have a good morning, but I am under caffeinated I have these teams so these these team members are key in their open-source contributions their partnership with the community They're ability to upstream code These team members define a competitive advantage in my business Not only competitive advantage when I'm out when we're out doing stuff for customers But when we write our own software and platforms and we operate our own Operator own code having developers and engineers and architects in your company on your team that are engaged with an open-source community Is a farce multiplier we get just this week. I had a friend of mine from an open daylight side Who's he started mentoring me on SDN three years ago? I think he's like dude And you got to check out this professor shanker. He thinks software should be networking And open my eyes and so the ability to have an organization that extends past your your core capabilities And to be able to leverage Architectural support troubleshooting guidance the support putting in a new feature Partnership in the community especially say if you're like us and like we use open stack We use Amazon we use v-claw director now the company acquiring company has like a billion clouds I am it's a goal of mine to make sure the open stack sitting right next to it. Hopefully they're not listening I think they'll like it honestly But it and the company's died in mention days. It's owned by NTT which has a big open-stack cloud So not you know them. I'm really happy to be able to work with them. I have the so I have these teams I have this ability to do great things for the community for the corporation for for the individuals in it and Specifically that little dart in the center Because I wear a suit a lot I am a business leader. I manage a P&L. I share the I share successes and failures with my teams financially I am responsible for my was Strategy and vision to set the technical directions for 600 person a half billion dollar company in the decisions. I made good or bad You know make it so their spouses can eat or not and their kids are successful So it's very important when you're looking into open sort participating open-source software To put your business hat on as tightly as your as your technical hat so For the background for people don't know me I ran a hundred I built and ran a hundred million dollar line of business in Texas At the same time, I'm kind of an undercover hippie at work. Although with the beard. It's the less and less undercover every day So you yeah, I am a serial instigator in the open-stack community I really love connecting with people who are passionate about the same thing that want to make this world better The code better share the burden of creating great things Open-stack is a cloud platform and running wraps on top of it. It is it says something's pouring me I'm an open-stack ambassador and the goals of our ambassador program is to Lower the barriers to contributing consuming participating in the community also active technical contributor and a co-founder of open-stack manual or core and open-stack manuals and co-founder of insect training But on the business side, I am on the leadership team of a old stodgy business or we got acquired So now I'm kind of figure out what I'm gonna do but So why is open good for biz? And by the way, if anyone has any questions about this that we can do this in the Q&A And we can do Q&A at the end whatever I'm gonna talk about a lot of topics and it's okay to stand up and ask the question fundamentally By identifying your unfair advantage in the market and clearly understanding why your company makes money So if you want to participate if you want to upstream coding your business That's the first thing that anyone has to do So you have to go ahead and graph out a very simple thing Why my company is special what is our unfair advantage in the market if you don't know this you can talk to your executives You can talk to your product managers to talk to your salespeople There's something that's special in there and there's a whole bunch of other stuff that supports it Just because someone is in the same business segment as you does not mean they're your competitor They mean that means that they are similar to you Usually, you know if your business engages in a company in a competitive situation for a customer There's ones where you'll always win and your customer and your competitors will always lose anyone seen that in your own business Yeah, yeah If you want to successfully can be part of an open-source community You have to know that you have to document that you have to prove that to your executive team Because there's a lot of old gold watch guys Especially if they if software is key to your company that intellectual property is so freaking sacred is key to the valuation and giving it Away will get you fired Right so executive sponsorship we do this however by by going through that exercise to actually understand why we are successful in our business Then we understand where we can partner in development and share the burden with our competitors Yeah, I've competitors every day that I that I partner an upstream development here. I think it's amazing We can do it with our customers. We can do it with our new employees future employees, maybe But it's very important the goal here is to make it so you are operating your business in a forced multiplayer So that you can rapidly expand your development team based on your credibility in the market based on the work that you've done So I won't go too much into it. Um open source helped us grow Participating the open-source community helped us grow. Um three years ago. I came to nexus is a hundred sixty five million dollars We closed the books last year to half billion dollars got acquired for a Undisclosed some I will say By a five point eight billion dollars international integrator that's owned by NTT We are contributors to open stack open daylight corporate sponsors of the foundation We're half engineering and we integrate Amazon. Yeah, I said the evil word here open stack and open daylight into our product offerings We we contribute back to open stack open daylight puppet as well as some of our own repositories on github.com slash nexus is participating in this community Accelerated the growth of our business and accelerated our hiring In a way that I could never have I could never have understood So we're gonna do a couple of business topics here and I want Q&A by the way, it's important So I didn't put all much of slides so I'm preaching so the business topics I want to cover here first things first we're gonna talk about is talking to your executive team So has anyone walked up? So do you have a mahogany row? Yeah, you want a question. Can you talk a little bit about how involved your legal team has been and Determining your IP and making sure that You just don't trip up. Yeah general counsel, right? So I'll answer that question directly. Let's start right now. So My legal is really permissive I ended up basically saying Demonstrating how some of these technologies were important to the business my headquarters are in California in California There are some specific laws that if you do not so you as an individual have rights and they vary by state I am not a lawyer Right in California in another law at other states There are similar laws that you are so you are you are hired by your employers You're not a slave of your employer, but you are employed during 9 to 5 to accomplish work The term is work for hire under the contracts of work for hire the intellectual property that you create under on and when You're under work for hire our property of your employer now In California, which I now have to actually there's 32 companies around the world So I'm going to spend a lot more time with lawyers And not and I'm not sure where my role will be but I think I'm kind of talented at making open source integrated with a company and 32 dimension data companies around the world and have to answer this question. So I'm thinking that's a question I want to help answer So but in California, this is actually how we started so I talked to some really smart people Anisa Google was at IBM research talked to him about patent law There's I'm learning a bit about that, but very specific in California law If your company does not make the similar product that you're working on If you don't do it during your work hours And you disclose it to your manager Your direct manager, and you don't even have to disclose it. There's some gray or in there But I'd recommend it. Hey, I'm working on some of those projects. It doesn't compete with anything We have at work. I'm doing on my nights and weekends I just want to make you aware because I'm excited about it that right there fits illegal requirements, by the way That you're free to work on open source project. You're free to commit you can do it under your personal email address For the first year and a half or two years of open source A year and a half of open source company known two years of open source participation in nexus I required the engineers submit it under the personal email address I gave them authorization as a director in the business saying I authorize you to work on this I gave them encouragement. I sent them to Vegas when they'd submit patches I couldn't I couldn't adjust their MBOs at the time because I hadn't set the business case for doing this But did that answer your question? Okay, so that's a really really good way to start and because we had to actually define the value I was in the process the market three years ago. The market is absolutely transforming everyone thought that I was crazy for all this hippy stuff And I'm crazy But I think now seeing everyone coming in there's validation open sacks important to business, right? Some other projects that you open daylight if you're not in it get in it But being able to map out that graph and go through your market test and validation and really clearly understand of why you make money What differentiates you? It's really easy by the way. Don't say because I'm first to market. That's not unfair advantage That's an advantage other people come to the market steal that advantage So talking to the executive team means talking in business sense It means going through and graphing that out creating the tables Clearly understanding and actually estimating the monetary value and there's a there's a who has anyone read the lean started by Eric rise If you're going to do this for your executive team, please go through and read the lean started by Eric rise The build measure learn pattern Build something measure its effect in the market document your learnings and pivot or persist out of it is something that's very very effective And as a way of communicating I'm going to try open source contributions I'm going to measure it some fact I'm going to learn from it and you can actually use that to fill out a thing called a lean canvas Which defines what you believe your business and you can do this with your business leader It actually goes allows you to define your monetization vehicles how your business makes money and a lot of times if you haven't taken a look at it You'll be surprised how you actually make money your unfair advantages in the market things the metrics that you'll use to measure it All these things are things that you have to do and that we did I did start with and presented to the executive team Luckily I reported to him so it worked out a little bit easier if you are lower in the organization That doesn't mean you're an important. It just means you're closer to the you're closer than these your customers You need to get an executive mentor. I would suggest Executives execute we say yes or no Try going one level before below like that VP director. They're generally looking for an initiative that will give them juice They're looking for the initiative that will allow them to say I did it I identified a challenge in the company and I pushed it forward. They will support you so The that is identifying that unfair advantage and you do need to find the mentor if you are that person in your company Look downwards look for the people there that are trying to make this change help them out So the legal challenges when you talk about talking to counsel the big challenge with counsel is knows default Right if you come up as an individual from the contributor for the company without legal precedent For contributing and they're going to say no by default The best thing that you could do to start this is to get people in your company Contributing under their personal email addresses at night Right now. There's some companies like we work at Cisco Because of the massive protection intellectual properties Then what you have to do is if you're at a large enough company has multi-billion dollars You probably already have someone in the company that's kind of leading this charge in front of you if you were at systems Look, I saw Jay sitting down when Lou Tucker. Did he want to lose Lou standing up around here? He was one of the first guys Kind of didn't like a lot of Java was CTO at son came to Cisco He's a guy.  I'm not sure Created he basically created air cover and for open stack. There's a thing called a corporate licensing agreement So a CLA so if you're going to contribute to open stack There is a individuals contributor licensing agreement I CLA and then there's a CCLA if your corporation has decided that they want to That they want to control what your commits are once they've decided that You really can't violate it. Honestly It breaks a lot of the governance for the for the project put things in the in a scary legal areas So don't mess with the you know if you see it look for the CCLA if you have an ICLA you're gonna have to basically Full some commitments into this and say that I am authorized to give this and you have to be truthful about it If you're not authorized to commit the code don't commit it okay, so Next thing is is one thing that's actually really interesting to me once you've gone ahead and talk to your executive team Now you buy in and again business centric Everyone forgets the business and you have buying from your executive team where they at least have given you authorization and allow you to explore the financial impacts of Sharing the burden of updating your of developing the cloud platforms that you run on You've gone ahead and cleared with legal and you said hey I'm going to go ahead and do this and this is why by the way your general counsel will listen to present your company It's why you have to have us an executive sponsor if you legal will say no, right? At that point you can demonstrate and we'll get in the technical side of it There's some intellectual property protections in the in this in the second half of some processes that we use internally because I've access to Let me see and the NDA portions of all of Cisco's STN controllers I also have access to the NDA portions of all the VMware's NDA STN controllers and they hate each other they want each other destroyed And I refuse to leak anything out. I'm like I'm an integrator.  Who at least has them in your contract and you it's like something extra But you don't get your coaching sessions. You don't actually manage people with them Okay, so I'm actually a big fan of setting objectives mutually with your associates and your employees Having them set their goals and figuring out what you can do to achieve them once you've identified the business impact of Contributing back to open source when you've once you've identified the benefits and you can start to estimate the finance Financial gains from it. You now have a business reason for taking someone that might be yourself, by the way Who wants to get a bonus for submitting upstream code?  I can't say no That and that is to your discretion Right, I can make sure the intellectual property in the lake But that's very very important because a lot of times you get stuck committing on nights and weekends Like who doesn't feel that commit that who feels that they have to work on open source projects on their nights and their weekends Who wants to do it during the day? Well, guess what? You can either leave your company which actually isn't the best thing to do because the person behind you is gonna be in that same trap Or you can set and help your manager be a better manager and you can say hey I'd like to understand the objectives of why I think I can be successful I want to go ahead and share those with you ahead of time so we can mutually agree to them I want to go ahead and define the performance indicators in the metrics to understand how we're mutually successful and I'm gonna both I'm gonna manage myself and you're gonna manage me to this and we're gonna mutually achieve those goals When I mutually see those goals, there's gonna be a financial benefit for me and you right by the way That's the right way of doing an MBO open source contributions can be in there I would suggest talking your manager in this fashion You have to tie it back to the business case if you say I feel safe I feel at home when I'm with my hippies with beers and tattoos and I want to do this nine to five and you can't tell me If you can't tell me the business reason why I'm setting your MBO and that could be personal growth That could be I you know increased retention if we all whatever but if you can't tell me it's not going your MBO You can't do me why it's important to you. You need to tell that to your manager Next thing is and by the way, do you have any questions on the MBO side of that? Yes, no, maybe so okay Who's comfortable talking to their manager about changing your pay structure It's a way you can get more by the way you don't have to quit But you should get it sir Yeah It's achieving what they committed to so it's so When you start forming a as you make the transition from engineering to development You're gonna move from like ticketing systems and everyone calling you To someone else committing or estimating your time Which isn't really accurate anyways and you having a billion priorities by the way There's only such a thing as one priority everything else is subservient to that and you know what? Prioritizing is creating a list. We don't have five top priorities That's stupid, right? So what you'll end up doing is switching over probably to us Konban board you probably use scrum, right? So we scrum hybrid scrum Konban. You probably do start doing waiting to your tasks To finding out epics and stories instead of projects once you start doing this If you do it right and if you build a proper software team Which by the way is part of this transition is you have to actually be a mature software Modern software development organization is now the work that you do is roughly you're normalized by the team So it's not the hours that's in the waiting It's the effort and so I can actually look per person and I can see the percentage of their time focused on certain things And if you do upstream work in our Konban we use Trello By the way, if any of you use Trello, I love it. It's not open source. I wish story I screw wishing I need to put Devote resources are making storyboard a little bit more mature, but there's a project Rosetta inside of the It's in preview release right now. So don't use it until we get our tests up there McLaughlin is what our QA engineer that wrote it is being put on the Improving the tempest suite for some app policy stuff and neutron for the for the next month So that's more important at the time. But so what we do is we actually pull from the Trello APIs We normalize those because Trello is actually not it's optimized for security and speed not accuracy And then we normalize all of those and we establish we pull all of our metrics are you know the time something stuck in impeded the percentage of Cards that came in the backlog and we also have an upstream tag And so I have the username associated with it or I don't my team's do I have stream to by the way I have upstream tag and then what project and that ties in right now It's a manual process for observing what goes through our CI system So if you upstream if you want to get paid for it it goes through our CI system right now It's there is a lot of other upstream like the rest that's under my team The rest of the company is still under contribute on your own time on your own email And so it's I'm in the process. It's been to your process I'm moving from and I hate the word centers of excellence But early R&D to organizational execution like having scrum of scrums having our ops teams now development managers that type of stuff So it's about 250 of them on the upside so in the in that process normalizing You got to be careful doing organizational transformations too slow as bad too fast is worse, right? But so check out project Rosetta on github.com slash nexus is that's a tool for pulling those KPIs And so we can I we have a very simple report and get pulled I have a business product a business analyst who's also a scrub master five years of Deloitte ITSM I till expert I haven't run the reports for me trying to We'll probably in about I know probably 60 90 days We'll have time to put that put some more improvements back in our backlog and just make it so that's our Automatically done the CI system Did answer your question about KPIs?  You're not doing a manager.  If you were at the HP party, probably someone rocking it, but So it also helps deal with special kids syndrome One thing that you're going to find is that open source Attracts a certain type of person who has a Many types of people and In any engineering organization when you have a constrained skill When you feel that you are better when you feel that you're awesome It's all right to feel awesome It's all right to know that you're awesome Like I am an amazing freaking person and a great business leader and a horrible developer But I try right I also know that when I sit in the community I'm surrounded via people who are smarter than me who are more successful than me Who are more engaged with the community and are the most humble people you'll ever talk to right and by the way Prima donna's kill your open source contributions.  So dealing with those special kids The biggest thing you can do is visibility Biggest thing you can do and it's also the same through any software team Whether it's your internal software, which by the way is your infrastructure or external The visibility and accountability managing your scrums. So open source contributions need to be talked about in your daily stand-ups Open source contributions need to be shown in your showcases Open source contributions need to you as a manager as a director as a chief or a vp Need to go ahead and participate in that community and validate And what you may find is some of the quietest people in your organization are the most impactful And the loudest people in your organization might be dragging you down Um, so there's there's things they can do uh Marion Jim Poppendike They have they have some really great books about managing agile software development teams They'll also start to cover the psychology of these things Um, and if you look if you listen to a lot of people in the dev ops movement are talking about calm and whatnot Um, you look like john al spa, um, botchic loupes floating around here today John Wallace has talked about this too Um, let's get to patents. I got 10 minutes. I want to get to the technical stuff Patents are really really complicated. Um, really really complicated In open source, uh, there you choose to give away your right You choose to dictate who has the right to copy the software that you own Um, you have the right to make a copy You dictate that you always own the copyright unless You grant it you legally give it away And that's that's a very important distinction Because a lot of people forget this. Uh, there's a lot there's been some email discussions on the email list about putting copyrights in code And I think uh text in a folder it's important to understand and communicate this that you own copyright until you choose to license it And if someone violates that copyright and I've had personally uh, pure uh, pure companies, um, who've, uh, violated copyright and sold something back to me I own the copyright My company owns the copyright And we can dictate whether to litigate against them And I chose to just call the cto and tell him that wasn't really happy with it You're on an awesome company that does amazing things in open source But I will not stand for this behavior not because it it screws me because there's someone out there who's working nights and weekends, right? Um, and we have to we have to control that so Understanding copyrights and intellectual property is really important One of the things that I do internally to they end with my teams Is I don't mix code I don't mix code. Um, I would make a very vulgar reference of protecting yourself, but um What we do is we clearly identify the open the projects that we want to upstream And so we have a rule in our code and I'll use our code our puppet code for example So we have this uh project called denica where We're refactoring it right now to basically train to separate all the commercial code from the upstream code or the open source code It's a ci toolchain that allows you to do stn modeling So if you want to model like a an open play application open flow switching applications stn controller positive negative test together That goes and spins it up automatically plays a cloud platform dude. It's pretty neat. Um, there's some commercial code mixed in there and so for us We and I'm actually gonna jump ahead to the technical stuff. Actually, I want uh, there's it So we use get here jankin. So is who uses garret every day? Okay, first things first You have to become comfortable with using software tool chains to be able to protect your intellectual property Your software tool chains and specifically your governance modules Um, so get is this is uh, is a distributed version control system. It's what we use inside open stack Jenkins is a ci. It's like a manufacturing line for software It's like an automation toolchain for for building everything together testing and providing reports garret Is also a tool that we use in the in the open stack and it's a governance tool You can say this person is authorized to do this to this code I can only do this if four people review it and an authorized person approves it This person is the only one who could release it out By the way, this tool for the for the the lawyer question for legal one of the things that you can do Is you can allow your lawyers to do code review You can give them access to garret You can allow them You can you can delegate to them the ability to release to github Think about that they are worried about release of intellectual someone is It's their choice. It's not yours delegate it to them here press a button and then measure How long your projects are stuck and impeded because they didn't press a button Pass that metric right back up to the executive sponsor And so once you've aligned how open source supports your business Now you can show how your lawyers are wasting your money by not allowing that patch to get back up And then you can also assign the 22 cost metric for sustainment engineering of any piece of code you write Say, oh if I write a piece of code, I'm going to have 22 percent of my time maintaining it That's a cost Here's our profits Here's here's legal Where's the gap and you communicate about it and you still give them the right It's actually really really powerful. I'm very lucky that nexus that nexus legal Literally, they were just happy that I reviewed contracts before I passed it up to him because I'm kind of anal about that stuff Um dimension data legal. I'm getting to know them. Um, they already have uh opens upstream Some upstream development It has a lot of upstream development if look like what nachi's being able to do an isl stuff is isl or isis Uh, the the nachi's not who nachi works with Not you know neutron No, okay Yeah, I'm still learning. I'm like, hey, you're my coworkers now. Um Okay, anyways, um, so Secondly, uh market benefits a marketing benefits of contributing Right there open stack foundation sponsor. I will tell you right now There's all sorts of integrators and and operators in the world.  The foundation are people that have to actually get paid salaries the ci systems cost money Making it so all all all of us can come together You notice how those tickets were really cheap? It's because it's not a for-profit enterprise. I pay $25,000 a year to support the foundation and guess what? It's huge marketing benefits. It differentiates my company from others Same thing by going and I don't have the slide a big slide that I normally give when I'm talking to another cto or something like that Or I'm not cto. I'm a person now associate. I like it. Um, but um When I when I'm talking I talk I have like this. Here's our resume of open source project. So like Oh, well, that's interesting. There's great marketing benefits. So who does things for other people here? No one Okay, so you're like integrators just consultants, right? Yes, is anyone a consultant integrators of var? An operator who sells services to customers that consume it? Yeah, exactly. Well, guess what? So the denica stn Modeling platform. I have a weight inside of there. So we have a bidding module They'll go and like bracket bracket bid amazon And if you have a pricing amp it'll try bracket bid that and then pass up to an abstraction layer in that abstraction layer I have a waiting I call it our stake weight Right and that that waiting is a preference And that preference is adjusted to who we've partnered with Who maybe have taken us out for steak and beer? But but those are the things that it's actually important I choose based on mutual participation in the company who I work one of my workloads on So there's a huge benefit Huge huge benefit Also, if you in your partnerships if your partnerships are important to your business being able to advertise those is very important so Getting through the the marketing benefits that I've had it's been really really good and since Nexus is and dimension data are their systems integrators or cloud operators is a bunch of stuff. They do business process consulting Agile consulting and cloud nesting development That the the marketing benefits of this for for me have been part of my unfair advantage in the market That it's really hard for my competitors to actually participate in a community Because a lot of them are gold watch use car salesmen types, right? And that it's really that if you don't have a certain amount of engineers and developers in your company You cannot participate in this if you don't have people like you sitting in this room who care It is impossible to go ahead and participate and win That's one of my unfair advantages and I believe is an unfair advantage of the of the acquiring company So let's get into technical topics so Who I mentioned I saw A really small lack of hands of who Uses or knows about get Garrett and Jenkins. So can we just get another who knows and has and uses get Garrett and Jenkins Okay, about a half so um, I Let me see for those that don't I want you to open up your notepad your laptop write something down go on to youtube Um puppet comp 2011 jazz humble continuous delivery Right, it was a key. It was jazz's keynote talk Um in at public comp 2011 and it's just a overview of software manufacturing lines It's not technical. It's conceptual Talks about business value Get Garrett and Jenkins are the three tools that are core to the workflow that we use to develop open stack It's also very very common To implement those yourself now These tool chains are how you will maintain control of your intellectual property These tool chains are how you will maintain core review or peer review This is how you will allow someone to control of our ability as a support should I say and control and support there kind of can be Properly supporting someone allows them stops him from getting out of control, right? um That it allows you to go in and implement like peer review So for example, you're saying you're going to have properly formatted code that goes up in the github Your I will enforce a certain lights in the patchy 2.0. Actually don't I delegate it and do it everyone I prefer if it's patchy 2o. I like him have that choice um The you can say uh, if I don't have a dock attached if my test coverage is too long I'm not going to release You can do the right thing. So these ci systems. So get it's version control It's where you check things into You know, you don't just put a put a file in a folder the intellectual property is something as value And you need to you need to maintain and track Get garret ties into it garret when you submit a patch you submit. It's a garret and kind of it's technically Integrated get very tightly But it goes ahead and has rules like I need to test this I need to make sure that Someone looked at and reviewed it before it moves forward. I need to build it completely make sure it works I can you I need to have someone that's responsible for the business approval. It's released in the next step Right, it's very very powerful It also allows you to start to delegate that responsibility to people who understand or closest to the code Who know better than you and you can sit and review it if you're on the if you're on the leadership or executive site It also allows you if you're an individual contributor Or or or technical leader to be able to go ahead and push that up So you get the responsibility delegated down to you, but it allows you to establish the metrics It's time my time up. So I'm going to finish right through this Um, it allows you to authorize authorize those things programmatically Um, so we talked about mapping commits to mbo's earlier. So that's really really important You need to have consistent tagging. Um, one of the things that I'm that I'm doing right now Or is teed up in our backlog is to map the the hashtags of the upstream hashtag to project Pull data out of uh, tail to leo. Um, no Track star, which is our mbo tool Normalize that together and then implement tracking in and get in in the garret message So like if you commit to open stack say implements bb slash whatever that's the bug You need to have implements, you know upstream slash whatever is employing that full cycle. I'm not there yet We do have the raw data that we manually do it to be able to support it Um, second things is pulling data out programmatically. So that when I talked about the unfair advantages in the market One of our unfair advantages is when we partner with a customer Or a manufacturing partner or another Operator's just good and all but for money making money We partner with a a manufacturing partner or or a customer Sometimes the customer's moving some of his customers are operators. Um, we see a rise in revenue in that customer We see an increase in margins. They don't squeeze us as much because we're not elites. We're just providing value We see other products that we sell we sell how much of bs like phones and stuff Extra product categories that get sold and we see the time to sell shortened It's basically a sign that hey, I realize and value your partner with me and here's some stuff to fund it And then I'll do is I'll shave off some margin out of that and fund some software development team Like put some stuff that's important to them higher. Um, it's that's totally valid by the way It's okay to upstream software. That's that's important to your business It's not okay to undercut your partners in upstream software development. It's not okay to compete in that way It's okay to succeed Right, but one of the things is that we're pulling pulling the data manually out of salesforce.com Which is where of all of our stuff is and we just got acquired. So we got to do SAP integration Um, that is tying those two together as your kpi's your program your programmatic management and control of intellectual property Delegating it to the appropriate resources and putting that in your management methodologies Communicating to your executive team getting that buying and support understanding the impact of your business That is what I believe has led us to be very successful so far in in integrating open source into our business model It's about 5% actually 5.8 billion now. It's it's like infinitesimal percent, but um That's allowed us to be successful. I hope that you're able to take some of the things we talked about and implement these in your own In your own pro in your own on your own businesses I am co-authoring a book enterprise dev ops With some people are way smarter than me. I'm going to cover this in depth in in uh in one of my chapters there It's uh, there's no profit in the book. We're giving all the profits away to charity So hopefully I'm not trying to withhold information. I'm just kind of recommitted right now with that acquisition As I put it on the deck, uh, I can I think we had we're at the end of time But I am going to come down here and we can talk we can just hang out until he kicks out. All right Yeah, apparently cool. So that concludes my talk on uh successfully open sourcing as an operator


We've all seen them. Small acreage properties that are overgrazed to the point of causing soil erosion and weed problems. On this property, where rocks and manure piles are the tallest thing on the soil surface, there's a problem with the grazing management. UW Extension and other natural resource advisors provide information and education to small acreage landowners and give them the tools they need to manage their property to protect and sustain our natural resources. Each county has an extension office as well as a conservation district office that can provide you this information. The Barnyards and Backyards Quarterly Magazine is the centerpiece of the educational effort for small acreage landowners, packed with information on gardening, weed management, establishing grass, grazing management, and many other topics. The effort is supported by the website BarnyardsandBackyards.com, a Facebook page, and workshops hosted around the state. These efforts have helped over 100 communities to date improve their impact on Wyoming's natural resources. This site has much more productive grass cover, protecting the soil from wind erosion and weed invasions. Whether you own 50,000 acres or five acres, your collective land management decisions have broad implications on this great state of Wyoming. From the University of Wyoming Extension, I'm Dallas Mount, exploring the nature of Wyoming.


This paper proposes a novel artificial intelligence, AI, based traffic incident detection and alert system. It uses three different models, vehicle detection and tracking, traffic accident and severity classification, and fire detection, to detect and alert authorities about any potential incidents. The vehicle detection and tracking model uses the YOLOV-5 object detector and deep sort tracker to identify and track vehicles. The traffic accident and severity classification model uses the YOLOV-5 algorithm to accurately detect and classify an accident severity level. Lastly, the fire detection model uses the ResNet-152 algorithm to detect the ignition of a fire following an accident. All three models were tested using a data set collected from a highway in Saudi Arabia. The results showed that the vehicle detection and tracking model had a mean average precision, map, of 99.2%, the traffic accident and severity classification model had a map of 83.3%, and the fire detection model had an accuracy rate of 98.9%. Additionally, the authors used an innovative parallel computing technique to reduce the overall complexity and inference time of the AI-based system. This article was authored by Mohamed Imran Bashir Ahmed, Rims Aigdoud, Mohamed Saleh Ahmed, and others.