 Welcome everybody good morning. Good afternoon. Good evening depending on where in the world you are Appreciate you taking the time to come and talk to us a little bit about open-source program offices and Some of the things that we found have been helpful to us to be successful few quick notes about our talk before we get going Initially before we the move to a virtual format. We were planning on about twice the amount of time So we'll move through some of the initial background slides a little faster So hopefully I won't make you dizzy flipping slides, but I want to get to the more interesting stuff in the chat and Also, as you think of questions, please go ahead and use the the Q&A speaker chat box function To record your questions and we'll pay attention to those and then we'll try to save some time at the end To address them where we can So real quick some some introductions. My name is Kevin Nelson. I run the open-source program office at United Health Group or Noptum I've been doing this a while. I am an attorney, which usually Helps me but not always my partner here is Ben Woodring Yeah, I'm Ben Woodring the leading engineering open-source program office 25 years of multiple stacks of Technologies and in the healthcare and financial industries and I look forward to working more and more with open source With the half fast change is happening now All right, thanks Ben So real quick just a quick disclaimer. I am an attorney, but I'm not your attorney So please don't take anything I say as legal advice and always consult your own in-house counsel. They will certainly appreciate it Real quick just about us and again, I'll fly through some of these slides. We're a pretty big company We've got over 28,000 engineers worldwide We invest a lot in technology We've got over 8,000 applications with it, which isn't necessarily a good thing and we invest quite a bit over 3.6 billion last year in In technology, but for all those 8,000 apps they almost all use open-source So our open-source program office is is really important to our organization Just in case you're not familiar with us from a healthcare standpoint UnitedHealthcare is the brand you're probably the most familiar with that's our health benefit side Optum is our health services side. It's also where most of our technology functions reside As far as where we fit within our organization, I just wanted to give you a quick picture I'm assuming this is similar for most open-source program organizations around the world But just real quickly, you know, we kind of sit in the middle. We formulate policy and process We take legal and security requirements into context And then we try to do a bunch of stuff with the information that we that we get and we try to serve our constituent groups and that's primarily what we're going to talk about today is is the forming constituent groups that we Consider our customers to try to make sure they can get done what they need to get done when it comes to open source But you can see there on the right, you know, some of the functions that we take on everything from the governance functions that are pretty traditional from an open-source program office Cultural education issues. We're having our first open-source Friday this fall, which we're really excited about And things like that trying to beef up our upstream engineering and our contribution processes What we care about I did a talk last year on the open-source virtual virtuous cycle and I think people understood where I was going with that But primarily as a group as a very small group We we try to educate with with every interaction. We're constantly changing every time we come up with a process We understand that that we're going to learn something about it and we're going to have to evolve it and change it to make it better A good example is our our open-source contribution governance process. We're on at least our third iteration of that So one of the things we have to keep in mind is that That we always need to improve and to get better so that those four groups of people we're going to talk about Get what they need from open-source and from our open-source program office We always want our folks to be able to ask for help and get help. We are a service organization You know, we really try to get things done for them. We're not just sitting around coming up with policies And then we measure the value we add back to the organization by To what extent we can achieve our open-source strategy speaking of strategy We try to keep ours really simple Reducing costs and reducing the friction for those groups that need to interact with us is is really important Increasing velocity, you know, it it doesn't do any good if we Um Give our engineers a way to achieve a goal or to execute a process for less money if we slow them down So we've got to make sure that the processes we put in place Actually enable them to move faster not slower Um, obviously we want to promote our own brands wherever we can And as we learn to give back to open-source communities In the form of code and financial support and those kinds of things we want to Learn how best to influence these strategic open-source projects because we certainly need them to be successful And we need to learn how to get involved in the right way within the open-source communities I've highlighted a few groups over there That are our customers are in-house legal counsel They're obviously important customers of ours to make sure that we work hand in hand with them Our development community certainly is a is our primary customer our leadership groups We need to make sure they understand what we're doing so they continue to fund our efforts And our supportive and they are which is great. And then one that's not on there Is our procurement group which has become a bigger customer of ours in the last few years and we try really hard to make sure that When they're dealing with vendors and so forth because the vendors use open-source That we're getting them what they need in the way of information and in terms of negotiating Contracts and those kinds of things So here's the first of those four groups and since ben's the engineer I'm going to let him talk about what from our experience we have found that they need from us Thanks, Kevin So from the from an engineer standpoint not only as a member of the open-source project office as well as being an engineer It's always important to understand why we're doing that That's what that one the first one the why is this important? So as an office we need to be very clear about what is involved in Using open-source software and what kind of governance we have in place to make sure that we're using it properly There's so many situations that the average engineer does not understand That is a simple of I can use this like I can use this for one situation But not the other and our job is to make sure that they understand that that why they're doing the things You're doing and make it easier So one of the things we've we've done we've done a lot more automation So we'll make it as easy and like Kevin said before frictionless It's possible So they don't have to do a whole lot So we generate some some applications to make it easier for them to figure out What can they do what applications can they use what open-source products can they use without running into licensing issues? And so that that's one of the things we do We we recommend to them what they what is the best So we we say okay here here's some we have other things to say here's the best as far as For from a licensing standpoint you can use these but these are these are better and there's we also provide provide feedback So that's where we do quite well. We have we use flow doc we use teams that allows them to say Okay, I've got this this product. I want to use So what do I need to do to get that done? So we give them a lot of feedback on how we can they can use that That that open source product or or not use that product in the in the use cases they that they're doing So that that and then it also relates into the rules are associated with that as well So that's what we do from a standpoint of an engineer to try to to make it as less Friction as possible as much automation we can so that the the engineer doesn't have one more thing That the box he has to check on his checklist to get things done is a small box not a big box So back to you Kevin I can't hear you Kevin They're very concerned about is that we have Any review processes that we've set up as automated as possible We can't be bringing our attorneys to the table every time we've got A question about a particular use case and whether or not we're building a mobile app or we're building an api That we're going to expose to our customers or those kinds of things So they want to know about automation They want to know about how we're getting training out to our organization. That's one thing Ben and I spend A fair amount of time on We we build training classes. We record the classes when we deliver them We go back and edit out all the The extraneous comments and hopefully we come up with a video that can then be shared across the organization So we try to reuse them wherever we can Our our attorneys are always interested especially as we've gotten into Releasing our own projects as open source They want to know are we using contribution license agreements and what does that mean and is there a Do we have any problem enforcing those so we have processes and we show them how those work And get them comfortable with the wording and all those kinds of things Um, I also spend a reasonable amount of time looking at due diligence responses from merger and acquisition targets We're a company that's grown by acquisition We probably do anywhere from You know 30 to 50 a year of different sizes and we're always trying to understand about the intellectual property posture of the company that we're pursuing To understand how they've used open source how they governed their use of open source Um, those kinds of things So I get involved there and then certainly when it comes to responding to our own customers For their request for proposals. I support Our in-house counsel there to make sure that we're given the the best most transparent answers we can about how we provide our own products and services in the healthcare space Procurement I mentioned procurement and I left them off that first diagram, but it's not because they're not important They are really important to any large organization Um, and I get all kinds of interesting questions from procurement Um, and I and I have a good working relationship with them But but this these are just some examples That I'm sure your open source program office probably has to has to handle as well You know things where you're trying to set up a new master services agreement with a with a new vendor And they don't want to take any liability for the open source that they're including in their their product or service or You know, they give us the kind of the sideways answer of you know Hey, we know this is gpl But you just go download it yourself, you know, obviously we want to steer clear of those kind of intellectual property quagmires You know vendor warranty questions making sure that that we've got things covered If we hire a vendor Essentially in a work for hire type situation and they're building a custom system for us You know, we want to make sure that they're using the same rules for open source consumption That our own internal resources would have to use and so usually there's some education there and we have to introduce them to our our tool set And those kind of things and then obviously any sort of downstream obligations Usually there's some education there to make sure that our procurement folks understand What our own obligations are if we're if we're for example White labeling a product and passing it on to our customers. So we get into those sorts of questions too and then finally Executive leadership the fourth of the the groups that we consider our primary constituents You know, obviously they like the cost savings that comes with using open source as opposed to You know vendor vendor products But they but traditionally most of the folks in executive leadership positions are used to having You know a large procurement office that manages Vendors through a combination of master service agreements and work orders and all those kind of things Well, how does that work with open source, right? They need to understand how the processes we put in place Give us visibility into how we build our code You know, do we really understand what's in our software, you know, to what extent are we exposed to vulnerabilities? I think we've finally gotten over the hump With leadership where they understand that in lots of ways open source is more secure than vendor software because the community itself exposes vulnerabilities wherever they can But you know, everyone is still a little sensitive about you know, say the heart bleed incident from What was it now six years ago? And that sort of thing So we have to make sure and pay attention on the vulnerability side And we have to ensure that we have a good working relationship with our enterprise information security folks Um, sometimes our customers do request a software bill of materials Even though we don't ship hardly any software we do, you know, mostly we do hosting But sometimes they want to see what's under the covers and so we have to make sure that we can provide that And again, all of this we have to be able to do it scale in such a large organization So so those are the four big constituents the four big customer groups That we deal with through our open source program office Um, I assume that it's fairly similar across lots of organizations But but I thought you might be interested in knowing the the ones that we deal with So so now let's talk about some approaches we use to try to um To deal with these these different groups and to try to answer these questions And we don't have time to go into a lot of specific Examples that that's some of the things that I wanted to do when we had the longer format But we can at least tell you about some of the higher level approaches that we take Um, the the first thing that we always try to do is see if there's You know existing familiar tool for the group that we're trying to satisfy So that we don't have to have them learn something new or adopt something new into their To their process For example, this is just a screenshot from the front page of github repo and enterprise github enterprise internal repo From our process for community contribution to open source Um engineers are very comfortable with github repo. They understand how the workflow Integrates into their into their process every day They're very comfortable with with documentation being in a github type environment So we use, you know, lots of lots of markdown. We've we've we've done a lot of work with docusaurus and some of the other Um documentation systems, but they're very comfortable with it because they know how to interact with it They know how to make changes or request changes and then in terms of Making a request of us. They're very comfortable with the whole pull request type metaphor So for an engineer at united health group roptom If they want to start contributing to a new open source community It's as simple as them initiating a pull request with the basic information about the community. They want to contribute to And that kicks off the whole process. It's it's something they're very comfortable with I've got some terms over there engineering native. Again, that's how they build software. So they're used to that It scales really well It's self-service and I don't know about Other open source program offices, but our customers expect self-service answers They don't want to put in 15 requests and then wait around for answers. They want to be able to go do things themselves So one thing great about using a familiar tool like github is if we build a process in github They know how to go out and read about it get started on it And and make it work for them and then they can even if they want to Start automating pieces of it on their own if they want to You know write interfaces to the api integrations that are exposed through github enterprise And believe me some of them do so they can get really creative But that's just one example and something I would suggest You certainly consider whenever you're looking to solve a process problem For one of your customer groups is look at familiar tools things that are already in their wheelhouse The next one and it might be kind of you know table stakes for a group like this. We're at an open source conference but You know be sure and check out what's out there because the landscape is changing all the time You know certainly look at at open source tools look at active communities One of the groups that I just recently in the last six months Got hooked up with the with the open open chain project And specifically the open source compliance working group of the open chain project They've done a lot of good work and pulling together a catalog of tools that help you with compliance and so forth So don't you know just run right out and evaluate, you know 10 different vendors That are going to cost you a lot of money go go take a look at what's already out there and there's a lot of sources now That are that are pulling together these catalogs of potential services for you And software for you that that'll help you out and this is just one example I like these folks. I think they've got a great way of Going about their business and it's a it's a good multinational group of people And so again, this fits right within our comfort zone of self-service by looking at open source tools to help solve our process problems Let's see I included this one as a separate topic. It's still open source tools But my point here is don't be afraid to integrate those open source tools into your Into your native Work process or landscape this particular example We based we took the cloud native compute computing foundation interactive landscape project That's out there as open source And we used it to for our a group that does our enterprise architecture within the organization Used it to pull together A catalog of all of the technologies across the company and We use it to designate those technologies as either preferred acceptable discouraged or unacceptable You may have heard of padu ratings. If you spent much time on on enterprise architecture Needs or with with folks and those kinds of discussions But it was a great way for us to take something that was already out there Do some some custom work on it on our own We intersourced a lot of the effort inside the company to to To get it to where we wanted and then We because we have processes for for giving back to the community Um, they can then take some of those those enhancements and new features and things that they've built And they can offer them back to the cloud native computing foundation project Um, if the project thinks it might be useful to them So don't be afraid to to take something you find and if it doesn't meet your needs right out of the box You know, don't be afraid to take it and work with it on on your own. Um, okay, let's see Don't have a lot of time left here Um, and then finally don't be afraid to build your own if you have to you know I would consider it a last resort But don't be afraid to build your own and there's an example of one that we did And we've had a lot of success with it. So questions. Um, we only got a few minutes left been Are there some here that we need to talk about? Yeah, we can we can answer either we got two questions out there We can we can answer those. Uh, I'll read the first one developer time is a big concern for companies Just getting into this. How do you address that challenge? What documentation is key part of the project contributions? It's part of your policies as well I'll let you take that one Kevin All right, um, yeah, so so developer time, um, specifically the way we deal with that is we we point out that um When it comes to open source you you you pretty much can't do modern software development without open source anymore Um, there's a ton of time being saved every time one of your communities when every time one of your programmers Um is able to include an open source component as opposed to writing something for them for themselves And and so, you know, we take that time savings and then we turn around and and explain We need those communities to thrive and to be successful and so therefore we put programs together like open source friday so that the um Leadership understands important to give back to those communities. Um, it's still it's a it's a work in progress We're not all the way there yet, but we've we have found very favorable responses to going about it that way And yes our documentation Um for our project contribution It's the documentation itself is in the process the policy is separate as a any large corporation We've got a separate policy system that the board of directors has to approve But the documentation is part of the process And this is the other thing from a developer time the barista tool what you see on on your screen We we developed that application to make developer time as small as possible So it it goes out and scans your your project to find out what open source projects it uses and and finds its Vulnerabilities and those types of things. So you don't have to do a manual. Can I use this? Well, you can add your your open source Product to your product and then scan it with a barista and then it will find the license that according to the use case You use it for so from a developer's standpoint. That's a huge benefit to the developer so Next next question does your OS office select? Uh open source software for customers or you let them evaluate. I'll go ahead and answer that sort of the same section before Uh, we actually allowed the the the developers to evaluate their own software and then run it through the barista tool Determine whether or not it works if they can't really understand how that some of the licensing works That's where we play the factor in being helpful to the to the user I guess and one more another question. How do you identify and fix vulnerabilities in your Your open source software you use Sort of the same force I'm answering more than one question at the same time here That's where the breach of tool actually when it only determines our the license that it actually determines the the vulnerabilities as well It matches against the vulnerability database and determines what the the vulnerabilities based on open source software So that's one way we do it as far as the fix goes We we do have our engineers consult with our security engineers in in our enterprise security group, you know, once they've determined that it's not a false positive And it really is a problem for their use case That's something where we refer that out to our Enterprise security folks. So it's not something we do specifically within the open source program office We just help them find that there might be a problem Yeah And our last question how many people are using the tools? Uh Not as many as we like them to but it as as the information gets more disseminated within our organization I think the engineers take it upon themselves to understand why that they as long as we understand give them the reason Why they should be paying attention to licenses and vulnerabilities They're much more vocal about getting those things done and with it as we mature our tool It makes it easier for them and anytime they can do automation to make things easy they do So It's getting more and more people for sure I think that's all I think that's all we got time for. Um, I will be hanging out on the The uh the slack channel um out in the open source program office section if anybody has any questions But we certainly appreciate everybody hanging out with us and I hope you have a great rest of your day Thank you