 All right, I'm Destiny or DB Babjack and I run the Osfo office for United Health Group, which is the fifth largest company in the United States, which should mean that I have all the money I will ever need to support all open source efforts, but we already have giggles. So, as you probably can guess, this is not where that talk is headed. We are going to have a little bit of an interactive component for those of us in the room as well as those of us online, so I'm going to invite you to take those devices that you're glued to and go to menti.com and enter the code on the screen, which is 2615-5878, and this is actually going to capture responses from you, so just to kick us off with a super easy one, I'm just going to ask you how many open source contributions you made in the past year. We are all home, so we should have made more contributions than any other year. Sure, that's the stats of my office are showing as well, and I'm actually running it from my phone, so you're not actually going to see it pop up on the screen, but you will see it pop up on your phone. Let's just make sure that's a true statement. So as I'm waiting for you all to log in, I'm going to preface our talk. So we're here to talk about open source corporate sustainability. Why are we here? I think I prefaced it a little bit by saying usually in a corporate setting, we face more challenges than nonprofits because you work in a place where you're trying to balance two things, which is bottom line profit against changing the world and making it a better place through code. So I think we've seen a lot of the models that have been tried. We're going to talk about that, see how successful they have been, but the big problem, the reason we're actually here in this room talking about this today is that code is not a great seller of itself. It's not charismatic, it's not sexy to everybody. It's probably sexy to the people in this room and maybe at this conference, but it's not as sexy as in Roads and Bridges, a Kickstarter campaign, or helping for the code. Yes, it is 2615-5878. So it seems almost unfair that the open source code has sparked this revolution, that we're moving in a place where we can work collaboratively together across the world to do big things, but funding it, supporting it, especially at the places where they have the means to do so is still a very difficult thing to do. So that's what we're going to talk about. So why does sustainability matter? I'm still seeing your responses come in, by the way. So so far, 100 contributions. Somebody made 100 contributions I'm hiring, so just email me, none, 10, 7. So why does it matter? Community dependence. The people at this conference, the people who are contributing to the Linux Foundation, open source projects around the world, communities depend on contribution. And contribution is supported through OSPOS, even corporate OSPOS. I understand that's almost a dirty word, right? Second reason it matters. Our corporate organizations now run primarily on open source software. The majority of installs in our organization is open source, and in almost every organization, that shift is well underway. So the failure to contribute, the failure of offices to support our developers, the failure to sustain efforts, results and breaks for our operations. So we do care as OSPOS, as corporate OSPOS. Thirdly, we, most OSPOS job, one job is to create a polished technological eminence in the community, right? To showcase our top developers, our top talent, to get them out there and create this pervasive influence, this halo, if you will. Well when the majority of your efforts through your OSPO are abandoned, or poor quality, then your reputation suffers. And finally, innovation progress. So we all know as working together in an open source community, we can gain more progress than by working siloed within our own four walls or siloed within our area, but by collaborating openly, our innovation progress moves exponentially. The corporate OSPO supports a large portion of the developer community. So without that office, this type of progress will stall and slow. Okay. So moving to question two, there was a good mix here. It ranged from none to 100, I'd say the meaner median is somewhere around 10. And then if we go to question two, here we go. I think if I touch the button here, it'll move. Let's see. Nope. I touched it too many times. Give me one second. Oh, dear. And it stopped working for me. I'd just give me a second to pull it back up while I'm talking and then I will bring it up. This will be the developer's only question. We'll see if we can get that up there and working or it might have technical difficulties. The screen's really small on a phone. One more. One more. I'm afraid to tap it again. Give me one second. Oh, dear. Goodness gracious. Okay. So we'll come back to this. Trust me when I tell you, if I can get this up and running, we can do it and it'll be fun, that when I'm interacting with my developers or my team of developers, there is hesitancy. Anybody in the room ever hesitant to start a new open source endeavor? Okay. Yeah. There's two nods. Three nods. Why are you hesitant? You have masks on, nobody will ever know what you're talking. Yeah. Okay. There you go. So those are two big ones. Two. Right? And that's the failure of your OSPO. I'll take that one. That's my failure as an OSPO leader. I made it hard for you to do your work. It might not succeed. Anybody afraid that it will? Yeah. Okay. So that's where, let's talk about this. I'm new to open source. I took this office in June. This is my first time at the Linux conference. I was really surprised by this thing that I learned. It's a phenomenon I've observed at United Health Group. It's a phenomenon I've talked and discussed with other OSPO leaders about. And I'm going to call it the Oxymoronical Balancing Act. Developers like to do fun hacks, right? My developers at least, they like, they're great developers. They do a lot of open source work. I'm fully dependent on them and I admire each of them. But there is a tendency to want to get in there, do something cool and get out. Right? That's the kind of mindset that comes from our classically trained developers to this point. I would say we're on the verge right now of a new type of developer that I'm going to talk about. But I will say that my developers cringe when I ask them to think about what they're building in terms of those two things that I just put on the screen. I want you to tell me about this repo that you want to open. This community that you want to support. Tell me, because I make corporate OSPO office, how that fits into my, wait for it, product roadmap. How does it fit into the product roadmap of your engineering team or your human resources team or the security team? Is it something we need? Is it something we can sell? Is it something that will sustain itself over time through some type of ROI return? Or is this literally a donation? And we'll talk about what I mean by a donation here in a second. So how do we get developers, offices run for and buy developers to adopt this horrific, in their opinion, business strategic mentality? Right? I often hear, hey, I'm not a business guy, I'm a coder. I'm here to code. I want to hold up in code for 24 hours, go play some video games and rinse and repeat. But I need them to document, talk, become a product owner, circulate, and make sure and get buy in for what they're building. So here's my quick formula. First adjust your own expectations. Understand the beast that you're dealing with, right? You're talking about people who may not want to do what you need as a corporate OSPO. The second you do is adjust the expectations of the people on your team and the people that you're about to hire. And we're going to say no longer is it okay to just be a great developer and a great coder and a great engineer. That may have been true in the last generation, but it isn't now. I need you to now be a unicorn. Most people in most fields are familiar with the concept of a unicorn, right? And I need you to be a good engineer. I would prefer a good engineer who is a great documenter, a great communicator, and a good strategic thinker over a great coder. Because the latter skills are the skills that you need to work in a community. They're the skills that you need to sell a product. They're the skills that, and I sell, I mean, get acceptance of, right? Building a great piece of code isn't great when it's drawered. Sitting in a drawer on the desk. In the desk. It's not great when it's put up in a GitHub repo with the worst read me you've ever seen, right? Because nobody touches it. Go take a look at your Ospo if you run an Ospo, and look at your read me's. Can an average engineer understand what is being built and done with each of your products or projects? Support your developers. So mentioned was it's hard to start up a new project. Your job is to make starting a new project a simple, easy thing. A new developer should have an idea and be able to sit down and start contributing to an open repo or build their own in 30 minutes or less. If that is not where your Ospo is at, your foundational work is still in front of you. Lift with your back. My husband always says knees. But I see him lift with his back all the time, and what I mean by this is go in and do the hard work. Sometimes you can't do it the easy way, which means go in there and actually build your system to work for your developers and still code. Somebody said none. I don't do coding anymore. This creates a divide between those who are actually in the trenches developing in the open source community and those who are making the decisions in the Ospo. Do you have to do 100 contributions in a year? Absolutely not. I never could. That would just mean I would never sleep. And I really believe in healthy sleep for myself. But can I contribute once a quarter? Absolutely. So do it. So now we're going to talk about that evil thing I just mentioned. One of the reasons that projects and products and offices fail, don't make it as long as they would like or never level up, is because we are thinking about code and products is two different things. Code and products need to be one thing. The closer you can align these two things, open source for open source, the more sustainability you would get. If I ask a coder what they want to develop, they will usually open up their laptop, share their screen, throw some code at me, throw a link, throw this, throw that, right? It's a great discussion. If I ask a product owner the same question and say what is this product that you want to build, I get a five-year roadmap with the key features and the key connections across the organization and a reasonable budget and a CBA. Those are two very differently prepared approaches to beginning work. And the latter is what is actually going to help you plan appropriately to make sure that what you're building is what you want it to be. So once upon a time I admitted to a professor of mine, sorry, a mentor and a professor of mine that I didn't study for the test and didn't do well, right? And he looked at me and said, I like you. You're a good person. You don't owe me an apology. You know that you get out what you put in, right? So if you're looking at your Ospo today and you say, look, it's not the quality that I want it to be. The onus is on you. You have to look very systemically at what you're building. Look at each product, product line, project. I'm using the word product on purpose instead of project because I don't think we should have projects, at least in a corporate Ospo. If you want to have a little project, I'm going to do that on my own time, right, on my personal contribution time. In service of my Ospo, I will work on products, healthcare technology products specifically for my company. But look at the quality of the bricks that you're putting in. Assess the strength of every product, the fit of your Ospo vision, the roadmaps as they align to other elements of your organization, the lottery factor, which I think sometimes is referred to as the truck factor. I don't like to put that out there in the world. And then the scope. There is a sweet spot for scope, which we'll talk about when I hit moderating factors. A product is larger than a project, and it's not so large that it's a platform every time, right? It's a, that's the size that you should be hoping for. And thinking about these as equivalently sized bricks is a kind of good way to think about it. If you, let's imagine that you go, once somebody wants to start to build a new project and it's going to be a healthcare data platform. But it's eight times the size of any other product on your portfolio. You can throw that on top of your pillar, but it is going to knock it over. So you have to think about, can I sustain that? Is it too big for me? Do I have to shut something else down in order to take that on? And then the last one which we're gonna touch on for a little bit is the ROI. Does it have one? Is always the big question. So I challenge each of you and anybody running an Ospo to go home tonight and say, I'm gonna design the blueprint for my office. How many pillars do I need to hold up my roof? Do I have four? Do I have 40? How will I build it? Who will be my business partner? Who are my contractors? And then the one that I think is really difficult for us is, who and what will you say yes to? And who and what will you say no to? And I struggle with this because an eager engineer comes and says, I want to contribute to this community and they're really powerful. And I think it's a good bet, but it's just that. It's a good bet on that investment dollar. So I'm going to say that a very unpopular thing. We're gonna skip this because I can't get it to work in a second. But I want you to think of these three as the potential outputs of your office. Just think about it for a second. If you think about all the different things that your office puts together, does it look like a pile of spaghetti? Does it look like a small house gaining some structure? Or does it look like, I think this is a sandcast, but we're gonna call this a palace, right? A very well-designed palace with a great view of the organization and a great view of the open source landscape. Where do you want to work? You might want to work in the pile of spaghetti, because you can do absolutely anything you want. That's an option. But if you want your products to live and have impact, you probably want to go for the castle. Because that office will know how to get that done. Your meatballs can get lost in the spaghetti, right? In a poorly, let's say, designed roadmap portfolio. All right, I'm going to address the elephant in the room. Corporations save tens of millions of dollars in software cost by using open source technology. So why aren't they using that and just giving it back to our open source, our OSPOS, to fund the work one in, one out? Well, every corporation is using open source to support their organization, which means it's a competitive savings. So that actually disappears, because your competitors also switched to open source. So those savings are no longer real, right? It's just a shift in the ecosystem of how you do business. The second, another dilemma that is difficult for us is that open sources, open source offices as they grow have greater demands. Projects get larger, communities get larger. The size of the vision gets larger, it expands. Even products themselves go through the same type of cycle. It's easy to start it up, and in the growth period it takes quite a bit. As you get mature, things eventually start to get on the decline in terms of effort. But your maintainers need to still be there in that decline period, right? For every new product or you go out to build, you have now made a permanent investment in human capital. Those people will always be on those products. Okay, so how do we get it done? I'm gonna talk about a few ways that we can organize strategy around developers and organization contributions, and then we're gonna talk about ROI a little bit. So I think most people are familiar with this first concept. It's called the open 20%, open source Friday is an example of that. Another is incentivized allocation, where the more you contribute, the more time you get. This sometimes looks like a sabbatical. This can look like a rotation in the open source office. This can be six weeks off, right? To do whatever it is that you want to do. Bench strength, if you as an organization can reward your auspice by putting more people on the bench. Typically one to five engineers should be allocated per 1,000 engineers. I have 33,000 engineers, I do not have over 150 employees, right? Adoptions and donation, maybe you can't become an adopter and an official sponsor and contribute to absolutely every open source project that you're engaged in. Maybe you can award the top two that your developers are passionate about. So for us, that's CNCF, right, and retain. You can use your marketing dollars to advertise for external contribution, right? So you can use the power of the community to come back and do the work. I'm gonna speed up because we are running out of time. But you should be familiar with all of these models. They have been tried in open source before, the freemium pyramid. This is an ROI generating model where you offer some elements of your code for free and then charge for additional sometimes seats or licenses or expanded versions. You can give away your code and software for free but offer only support and services. This will bring in some dollars or you can even host the entire application end to end as a service. Or you can do open core where the base code is free, but you do charge for the software wrapper. In your organization, this is the one I really wanna spend some time on, you can consider three things. One is foundation partnership. So this is partnering with places like the Linux Foundation to use the power of the people that are here and making sure your roadmap is aligned with theirs. That's a win-win for everybody. So if I bring my healthcare technology roadmap over to Linux Foundation, a lot of the work will be shared. It's a great way to get things done without necessarily having to volunteer thousands of my own people's man hours. Sponsorship. So usually you can get sponsorship through a few different types of organizations. And I'm gonna explain who those are in a second. And then the last one which is my absolute favorite way to ensure sustainability of your office is to embed yourself into other organizations. It's no surprise that when funding gets tight, auspose can suffer. But the more integrated you are with the following, the easier it is to sustain your own roadmap and agenda. So the Human Resources Office is a great partner for talent. Whether that's talent acquisition, talent retention, or even your talent halo in the community, what people think about you. The security teams, if you have one, are usually concerned with a lot of things that you are as well. And they will take up those open source efforts on your behalf. The Social Responsibility Office is a great partner for doing open source in a way that affects world change. So in our example, we are hosting a maternal health data hackathon, and starting to build free maternal health data sets. And that's something that the Social Responsibility Office is funding, because it meets their agenda. You should align to the inner source community because I would say there's probably about a 60% overlap in roadmaps with your inner source community from a getting the work done perspective. And it can make it easy, like I was talking before, the zero to 30 minute climb to getting work done, that can be achieved through direct collaboration with your inner source office. And then we have invention, product teams, engineering, ML, AI, and comms. I want to stop while we still have a little bit of time. If you want to know more about that, you can hit me up at dbabjack on Twitter. And then my slide decks are available. So all of these are actually moderators of sustainability. So you can have a look at them. But having them in play and solid will usually help sustain your office better. We have one minute for questions. Yes. It's a good question. We have, yeah, we have dedicated attorneys in our Ospo as well as a direct relationship and partnership. So I'm actually giving a talk with our invention team at our open source Friday about how invention and open source are two sides of the same maturity coin for a product. So we like to believe that all products have various elements and all elements are either invention or open source or both. So if you use the Apache two license, for example, you can still go for a patent if it is something that is patentable. Good question. Anything else? I think it's a great talk. In future iterations, you might want to try and work that around that. Yeah. Yeah, I think that's very interesting. And I think it's still spot on. Coming out of the corporate culture, we do want to create products. But the community wants to contribute and can only contribute to projects usually. So finding that middle ground and kind of facilitating the transfer between the two would be a good step in the right direction. And that takes you back to business models. Yep. Thank you. All right. Thanks.