 My name is Ruth Sealy. I am the relatively new director of open source at SAS. If you think, wait, I know Ruth, and she works for Red Hat, you were right. I did work there for 15 years until last fall. Started out as the editor of Red Hat Magazine, which, if you have been around for a very long time, you may remember. But it has been gone for a very long time. I worked a lot on opensource.com, but spent the last 10 years building the open source program office there. And then joined SAS back last fall about eight months ago to start working on the OSPO there. Does anybody have any idea what SAS is who doesn't work there? Yeah, so normally when I say those people, like, well, which one? Like, no. But it's only 1A. It's not software as a service. It is not the airline. It is not the purveyor of comfortable shoes. It is a nearly 50-year-old proprietary AI and analytics software company. So if you did statistics in college in the last couple of decades, that may be where you heard of SAS at some point. It is also the SAS language as a part of the deal. So it's a $3 billion company. I often see it referred to as the largest privately held software company in the world. 90% of the Fortune 100 and or their affiliates are SAS customers. So it seems to be going pretty well for them, right? And when I heard about this job, one of the things that was really interesting to me is that the SAS values, like your company is probably also have something that looks a lot like this, your corporate values. But these really aligned with open source values to me, despite the fact that it was very much not an open source company. But this is how open source software comes into being. Someone is curious about a problem. They get really passionate about solving it. Authenticity is transparency. That's the basis of open source communities. And we all held each other accountable for what we do in them. So I thought that was a really fascinating thing about this very not open source company. So how did SAS come to this decision to make this change? Because open source ate the world, like that's why we're all here, right? That's why I've been coming to open source summit since it was LinuxCon since, I think, almost the first one. It's been a very long time. Depending on whose survey you read, basically all software is now built with open source components at some point. There's one survey that says, 98% of companies use open source software, and I really want to talk to the other 2%, who I'm pretty sure sent somebody who knew nothing to fill out the survey because it's really just not even possible at this point. Are you using Chrome? OK, cool. You're using some open source software. Most companies, however, do not have an OSPO. So there's nobody sitting around thinking about this question all day. It looks a bit different for everyone. And I think of this, particularly in software companies, as a bit of a spectrum. And so I will probably repeatedly compare these two because I think of Red Hat as one end of the spectrum and SAS really starting down at the other end. So what it really comes down to for an open source program office is if any task or topic is important enough to you as a company or even as a manager, you pay somebody to think about it all day. And that's what an OSPO is. The point is to have someone in your company thoughtfully paying attention to how you consume and contribute to open source, given that it is likely that some percentage of your software or your product or process depends on it. This is a page from the to-do groups survey last year. It's a little bit different in results from the 2023 state of open source survey. So it kind of depends on who's answering your survey as to what they say. The state of open source survey actually says that only about 10% to 15% of companies have an OSPO now, depending on how you slice by size. If we say large companies, it's about 15%. But whatever the numbers are, the use of open source software and integration of it into proprietary software is effectively ubiquitous, like I said. So depending, again, on whose numbers you slice, maybe 75% of proprietary software may be way, way more, maybe more like 90%. So how many of you have a formal OSPO at your company? Somebody doing this? Probably more than average, given that you're in the OSPO contract. My SaaS colleague is like you, we have you. And the to-do group, how many of those of you with OSPOs have a to-do group member? Oh, so you should know about this. So the to-do group is the Linux Foundation organization for OSPO practitioners. And participation is open to anyone, really. You can join the to-do group as an LF member. It's free, which is a magical word, right? Oh, no, a free organization. How are we gonna do that? But to be a general member, and this is the set of logos of the general members, that means that they have an OSPO that they are not primarily in the business of working with OSPOs. And the organization, as almost as certain if they have an OSPO, is contributing to open source. What's interesting to me is that this is a wide variety of companies. So I mentioned that spectrum from a Red Hat sort of place to a SaaS sort of place. There are a lot of places along the way that these companies fall into. And a lot of these aren't even software companies because how many times have you heard at this point every company is a software company now, right? And if you look at the membership list of something like OIN or the Lot Network, there are lots and lots of not making software as a business company. I started to block out the ones, in fact, that are not software companies. And then I realized that's actually kind of a fuzzy and challenging line and gave up on that task. So if you're gonna start doing this in a company that is not a Red Hat, that has not been foundationally open source since day one, that is a sea of culture change. Culture change is hard. And I know that's also a bit of a controversial term now that it's really now about culture add and what that means. But when I say culture change, what I mean is that it's about whether your values match your actions and intent. And if your intent is to work collaboratively and openly, but that's not what you're actually doing. If you are, we'll talk about forking projects and maintaining them internally, that is not matching your values to your actions and your intent. How many times have you heard culture eat strategy for breakfast? That's what we're talking about here, right? Mighty ice cream for breakfast, too, if you're my children. These are my kids at the Ben and Jerry's number of years ago. And I use that picture because sharing is actually innate to children. There are multiple studies now that show we think we teach kids to share in kindergarten. And in fact, one of the earliest things that I wrote in Red Hat was, your mother was right, it's better to share. But it turns out we actually unteach them. Because children natively want to share, it's how they come. Very small children instinctively share with one another. And then actually it turns out by rewarding that behavior, we tell them that there's another choice. And then they get into school and we tell them not to look at your neighbor's paper and we unteach that sharing that is so fundamental to us as human beings. But then all of you come to open source software and you decide that sharing is great and you start over again. So that's what we want to instill in companies with an OSPO is to rebuild that sense that we have from the time we were born that sharing is the right way to do things. So you have to start with what your motivation for this is. Why have you decided that you wanna do open source? Why have you decided that that is a value that's important to your company? What is your motivation for engaging in open source? And that may feel more important to you as an employee what you value, but you have to think about why it's valuable to your company. Are you in Oracle? Are you Larry Ellison saying that the reason we're in this is to exploit open source? Or are you Microsoft that has come along this path from Linux as a cancer to Microsoft loves Linux and admitting out loud we were wrong about open source. Where are you starting from? Are you starting from Steve Ballmer in 2001? Are you somewhere further down the road? Where do you have to go from here? Figure out that path. What I expected when I joined SAS was to be much further back at the beginning of the road. I actually, I'll be very honest. I had a lot of doubts in the interview process. I was like, I don't know. I don't know if I wanna do this. That sounds like I might be going to work and having a fight every day. That doesn't actually sound that appealing. But I obviously did decide to do it. And when I got there, what I found was actually we already had, this is the SAS software GitHub page. There were already SAS open source projects. There are already people working on Kubernetes. And Apache Arrow and an assortment of other projects. And so as soon as I walked in the door, I posted on, we used the Microsoft suite. I posted on Yammer and I was like, hey, you have an open source channel with like 200 people in it. I'm here, what's up, whatcha doing? Instantly, I had a flood of meeting invitations. I have talked to so many people. I have forgotten quite a handful of them and I'm very sorry to all of them. So I found that we were actually further down that road than I thought we were gonna be when I got there. So then the next question is, if there is contribution happening and there is, why, why is it happening? Did they already take that first step of figuring out the values, figuring out why they're going to do it? And a good way to tell is whether those contributions are valued and rewarded. Are they showing up on people's development plans? Or are people contributing to open source projects because it helps them get their job done? Are they using open source because it helps them get their job done? But they're doing it quietly and not telling their managers about it. Because that is the thing that happens a lot too. So once you get that far, it's time to find all your friends and define your strategy. All those stakeholders who are going to be involved, get them together and figure out where you're headed collectively, collaboratively. One might say, as we do all things in open source, figure out together what open source means to your company, why you're doing it, where you're going to go. And one sign for me, a huge sign for me of what a company values is where it sits, where they put the Osmo. Is it in legal? Is it in marketing? Is it in engineering under the CTO? Something like that. Because I feel like that gives you a good idea of at least when that organization was founded, what somebody thought was valuable, what the purpose was. If it's in legal, it's because they thought that this was all about license compliance. That's all they cared about. If it's in marketing, it's about perception and wanting to maybe build a reputation with engineers. That's the kind of people they want to hire. If it's in engineering, it's because they care about the code. That's cool. Ours actually, I think it's an interesting place. I sit in R&D within strategy. And I think that's a really good place to be able to connect to all of those other folks because you can't Osmo alone. Unless you are going to go hire some lawyers into your Osmo, you're going to need your legal friends. Unless you're going to hire basically a mini company within your Osmo, you're going to have a marketing team and an events team. And actually to an extent, Red Hat's Osmo does operate that way. There is a designer and writers and community managers and whatnot. They're not lawyers in the Osmo. But ideally I think you would go make friends with all of these people around the company and bring them in to work with you. Part two of that is who's in charge of the team? What is their experience? Is the person who is leading the Osmo coming from community experience? Do they have any open source experience? Or is it a marketing manager? Is it, you know, what is their starting point? What are they interested in it for? Obviously I'm coming from a very open source kind of place and I like me. So I think that's the right choice. And then ideally you build up that team of whomever is going to help you meet those goals, that strategy you've defined. Or you find that it's 2023 and you don't actually get the opportunity to hire right now. So what do you do then? You go find your supporters. You find the team without a team wherever they are in the company. You make those connections, particularly if you're working on license, compliance and legal. You go make your friends in the events team so you can get some sponsorships. You figure out where you can go show up, what you can do and find the developers who are working on the projects and how you can support them. Whatever is going to meet those goals that you've defined, go find your team. For us that means there's the Yammer I mentioned, there's Teams chats, there's occasionally a mailing list for a lot of companies that might mean there's a Slack channel. It might mean you have to go create it. It might mean you have to create the communications channel probably within whatever culture the company has defined as their communications method. And then the next step is probably a degree of education. So it's been probably the biggest shock for me. The biggest change is coming from 15 years at Red Hat where everybody kind of has at least a reasonable baseline understanding of the whole open source idea to a place where I think that everybody in the room understands what I say and then I realize they absolutely did not. And the reason I use the cookies on this slide is first of all, cookies are an excellent way to make friends in a meeting. And the second because Red Hat used to teach this program called Colab where we would go teach middle school girls collaboration. It wasn't a coding camp or anything like that. We would use hardware but it was really to teach them collaboration. And so the way we would describe to them how open source works, what it is because your average sixth grader does not know what open source software is with cookies. And so one kid says I like chocolate chip cookies and another kid says I like chocolate chocolate chip with walnuts and I'm like great. So my chocolate chip cookie friend has the best chocolate chip cookie recipe in the whole world. If she will share it with my friend who wants chocolate chocolate chip with walnuts, all she has to do is figure out how much cocoa and walnuts to add. She doesn't have to figure out how many eggs and how much flour and what temperature to bake it at and all of those things. And Jeff brought cookies. Did you bring enough to share with the class, Jeff? Ah, come on man. Okay, so I kind of did. If you scan the QR code, this is the double chocolate chip cookie recipe that made me a lot of friends last week. So I am sharing my cookie recipe with you. But you're gonna need to do some education possibly not about cookies, possibly with cookies, I find it always helps. Because there are everything for misconceptions that lead to bad open source practices to just absolute complete lack of understanding about what's going on. These are not all necessarily fast problems but they are things that I've heard a lot of people mention. So first of all, the open source is inferior. What we're building is better. It's no good unless it came for me. Obviously not true. If that project goes away, if we incorporate that and then somebody stops maintaining it, we're in trouble. What are we gonna do? Better just not use it. Or you could step in and maintain that project if that were to happen, that would be great. Or there is the perspective that open source is great because it's free. Like that was Larry Ellison back in the beginning, right? It's free software, great, just grab that and then we don't have to do the work. Nope, that is not how this works. You contribute back. Contribute, no wait, open something, wait. No, we can't do that. What about our secret? Something's gonna get out, we can't do that. We can't participate. We're just gonna take it. Not cool. Oh no, wait, that thing, we can open source that. We can throw that on GitHub. It's crusty and nobody uses that anymore. That's cool. Also not how open source works. So there's a lot of education to do. And one way to go about that is intersourcing. So intersourcing is basically applying the concepts of open source practices to the insider company. Perhaps your proprietary code, how your engineers are working with one another. It can really help establish that open source working method with people who are not accustomed to it. It's a good tool to build education with. And education can also be important in a company more like Red Hat, where I watched it grow from 2,000 people when everyone that Red Hat hired already knew open source probably came from the community, already knew what Red Hat was. And at this point, it's 20,000 people and that is not true anymore. It hasn't been true in a very long time. So education can be necessary regardless of what kind of company it is. So then we're up to the two directions of open source that an OSPO is probably concerned with. And the first is consuming it, or we call it inbound open source. So the bar is probably different for something that you're shipping with your software and something that is a tool you're using, something like that, that's not also getting packaged up and shipped out the door. So we have a third-party software process. It's Jira Ticket-Based. There's SCA Tool Review, all of that. There's a good chance that most of your companies have established some version of this, even if it's not within an OSPO. What's important though is that this isn't the end of the road for your open source practice. Because I said there's two pieces to it and the second half is contributing. It's that outbound open source part. Because if you're not contributing back, you're just taking, you're just being a leech on the community. That's not cool, don't do that. And the reason I have baking stuff on this slide is A, because again, you make friends with cookies, but B, because it's a spoon and that is not a fork. And forking it is the wrong way to do it. So I have run into several instances where somebody said, we're just gonna fork this and maintain it ourselves. No, that is so much more work. That is a terrible idea. But it feels like the obvious answer to people who are new to open source. Just fork it. Also a piece of the education campaign because I learned through a lengthy conversation that many people who aren't familiar with open source and how it functions don't understand that forking a project is not the same as forking and git. And I had a multi-email exchange with someone before we realized, oh wait, we're not using the word fork in the same way. I kept saying, don't do that. And he's like, well, how am I supposed to do it if I don't? So then you need an open source contributions process if you have things. So that was all about contributing to things that exist. But perhaps your company is also going to originate projects, or perhaps it already is. You need a process for that. Where are you going to release it? We chose GitHub. What approvals do you have to go through to be allowed to do that? Does somebody have to do a code review? Is that a strategy review? Is it both of those things? And how are those requirements different between something that is a full project that is hosted by you and something that you are contributing to? And then we'll talk a little bit in a minute about success metrics. But one thing to think about when you're looking at projects that you're originating as a company is are you going to take outside contributors and how who's going to be responsible for that? And are you going to actively seek those people? Because that actually is a good bit of work and somebody needs to be responsible for that. So to put all of this together, I would recommend creating some sort of policy guideline document. So we had one at Red Hat, we called it the open source participation guidelines at SAS right now. Still kind of working on it. There's an older version, but I'm working on refreshing it. I've been calling it policies and recommendations because there's a little bit of both in there. There's some education topics in there. And I think that's really the first place that these documents are good to start with is, okay, let's assume you have wandered into this and you want to do some stuff but you're not sure what you're going to do. Here's what open source is. Let's start from zero. I would always rather tell a stranger who has wandered into my document too much than have them read it and go, I do not know any of these words. I know some of those words, but not in that order. Let them scroll down and skip the stuff if they already know it. But if they don't, make sure that they know where to get the information. Then you want to cover how to contribute internal versus external things, what approvals are required. And as far as approvals, my opinion is lower the bar as much as possible. And I've heard folks at a lot of companies where maybe you need manager approval and you need to go through an education class and maybe get some kind of certificate and bend over backwards and sing a song and it's just an ordeal. And engineers run up against that and they either say, I am not doing that. I'm doing something else with my time or they go, policy, what policy? I didn't see that. And go ahead and do it anyway. And then you've achieved nothing in either case. So lower the bar as much as you possibly can get away with in your company. Have a process for launching new projects, what the approvals are there, what licenses you recommend. And again, explain everything as much as you can in small words for people who are not lawyers about the license choices, what your company is okay with. Are there licenses that are automatically approved? Are there ones that we're like, that's maybe okay, but let's have a conversation about why you're making that choice. And then you may have some related policies that might even be separate from this document but you link to your data security policy, your export control policy, what you need to do if you're asked to sign a CLA or a DCO, all of those things. And what's great about creating a document like this is there are a lot of them on the internet. So RedHats is definitely out there publicly. I think the to-do group in their GitHub actually has a repository of these. Googles is out there. I think Salesforce is out there. It's pretty easy to start Googling company name here, open source guidelines, and you have a lot to start from. And I could have used bullet points to tell you all of those things, but I didn't. I did mention license compliance and that's both for the inbound and the outbound. How to be sure as a company that you're complying with the terms of the licenses of the software that you're using and then in the other direction, how to protect your own product and services and how you're differentiated. Your lawyers are definitely going to have opinions about this, so make those friends over on the legal team. Different companies have different comfort levels with this. You need to know what yours is. So we got to this point, you've got a pretty good thing going. You've got a whole Ospo happening now. You found your friends. You've got participation guidelines. Might as well spend some money, right? There's lots of things you could spend money on. You could spend a lot of money on events. Events are very expensive at varying levels. So actually, what you're interested in is encouraging contributors to your projects, meeting developers, maybe recruiting them. Community events, super cheap. You can sponsor those for as little as like $1,000, $2,000 show up, do a table, tablecloth, good to go. The bigger events, we're talking more like five or six figures. That one's gonna be expensive and that's just the sponsorship. We haven't actually shown up yet. You can do funding maintainer programs, which are an increasing thing that I love to see. So we've seen an increasing number of people, and sorry, this is a whole tangent we could have another talk on, but you've seen news stories over the last couple of years of people who said I am tired of doing this for free and every company on the planet is using it and I'm gonna pack up my ball and go home. We need to, as a community, figure out how to support all of those folks so that that stops happening. But the biggest expense I think that is probably the first one for a lot of OSPOs is joining foundations. Build a process for this from the beginning. Don't just, people all over the company joined a thing and we just keep paying for it every year because they sent an invoice. That is not a process and it's going to get very expensive for you. So create business cases. Have them stored somewhere so that if you win the lottery and you decide to move to a beautiful island somewhere that someone five years from now can figure out why the heck you joined that thing that cost $100,000 a year instead of having to start from scratch. Check in on that business case when it comes up for renewal every year. Is it still worth it? Talk to the stakeholders. Find out why we're still doing this. Track the benefits and value of those memberships. And I put together a little pretend scenario because I think a lot of people don't realize exactly how much these cost and this is a short list. I don't know what this company does. I made up this hypothetical company. Some memberships depend on your revenue and number of employees. So this is my pretend company with 5,000 employees and about 50 million in revenue. And they've got some pretty basic memberships here and it is already at $200,000 and that is just a short list of memberships. I will call out. So most of these come with some degree of benefits, a board seat, something like that. The Apache Software Foundation is a little bit different. It is important and I say that not only as the executive vice president but also as a part of the open source ecosystem. The ASF supports about 300 really important projects that keep the world running. But sponsoring the ASF doesn't give you a board seat. It doesn't give you a whole lot of very specific benefits like these other memberships do. It is just because you believe that that stuff should continue to exist. So it can be a little harder to justify within your company and as the executive vice president if you'd like to have that conversation, please let me know. I just wanted to call it out because it is a little different because then I decided what if, all right, we've been doing this for a while. We want some more benefits. So I bumped this up so that we definitely get an AI and data board seat. We bumped that up to Premier. We got an Eclipse board seat now as a strategic member. We might have an open end for a seat because that one, we're gonna be one of the gold members running for it. Potential LFC with gold membership. We just went from 200 to 545 real fast. It gets expensive. Yeah. Well, I would say I partly agree. So I think there are two ways that companies do foundation membership. I think it's either get involved or pay more money so that you slap your logo on the page and look like you're involved. That is definitely two things that happen. Now, some of these memberships, I think some of the Eclipse groups have different tiers of fees depending on whether you have engineers on them, right? So that is also another consideration is how much are you paying based on whether or not you're paying somebody to actually do the work. Now, regardless of that situation, the right answer is to put engineers on the work also when you join, not to simply join to slap your logo on the page. So yeah. All right, it's time to measure success. We have done a lot of work. Somebody is gonna wanna know where all that money went and what good it was for. Why are we paying you? Exactly what do you do here, sir? How many of you have open source in your OKRs, KPIs, whatever you choose to call your thing? Oh, one, two. Wow. Three. Three and a half. Might be something to think about. So just like deciding what do you want to do, what do you want to measure? And those are really closely related. So are you in this for the ROI? That is really hard to measure. And that's why I have s'mores here. So I decided, I'm gonna say this is like 10-ish years ago, I wanted to make s'mores from scratch all the way down. I wanted to make the graham crackers, make the marshmallows, make the chocolate and end up theoretically with a superior s'more. The actual outcome of this is graham crackers are really hard to make. The graham flour is very hard to find and it is not worth it. Marshmallows, worth it. Marshmallows are absolutely worth making from scratch. And all of this, measuring the ROI on your investments, some of that is the same deal. Sometimes it is worth the project. Sometimes it is worth doing it from scratch yourself. And that's what you have to figure out how to measure and it's not as easy as measuring whether or not the marshmallows are more delicious as they are. Software is free as in puppies. So there's free as in beer and free as in puppies. Software is free as in puppies. Here is your free puppy, it is not super free. So that is your starting point for measuring exactly what you're getting out of this. Events, easy to measure lead gen until you decide to go to a developer or community focused event and they do not want you to see their badge. And that's not what you're there for anyway. You're not there to make sales. And that's a hard thing to explain to people who are going to give you budget. We're not showing up at this to make sales. You're going to get zero revenue generation out of this. That's not the point of this event. So then you have to find ways to measure that instead. You can measure your contribution activity, PRs, issues, commits, things like that. What are you measuring them in general? Are you measuring them on only the things that you've declared strategic projects? You can massage all of this data to show exactly what you want, which is true of most data, right? So I think that there is value in a degree of experience and having an understanding of this is working for us. There is a degree of community work, which is by feel. I feel that very strongly, despite the fact that I now work for a data company. Early on, maybe your internal goals are much simpler. Whether folks are aware that things have changed, that you're encouraging open source contribution, that is a thing that you can measure reasonably easy within your company. You can measure whether you're getting those outside contributors. If you're deciding that that's something that is important to you, that's relatively easy to measure. But this whole concrete measurement of your success of an OSPO is very hard and you have to decide exactly what's important to you and how you're going to figure out a valuable, meaningful metric for that. So that was a very long journey that I took you on through cookies and s'mores and we can talk about food all afternoon. I'd love to eat. But there is one more thing I want you to remember, which is that in open source, we often run fast and break things, but culture change takes a long time. Scientifically speaking, it takes three to seven years to change a corporate culture. This isn't gonna happen overnight. This isn't drop it on GitHub and you're done. So depending on where you're starting from, what circumstances, the world and the economy and whatever's going on in your company throw in your way, it's gonna take a while. So you just have to be patient. And for the Ted Lasso fans, believe. If you're not a Ted Lasso fan, this is not actually a show about soccer, it turns out. It's a show about leadership and teaching collaboration. Kind of ultimately a show about open source, I think. We could have, that should be somebody's talk. There you go, free talk idea. Ted Lasso as open source analogy. Somebody make that happen. To wrap it up though, it is a little out of character for me to make multiple sports references and a day, much less one talk, but I wanna borrow something brilliant that I heard at the beginning of the week. So I came here from SAS Innovate, our conference. It was in Orlando. And one of the keynotes was Coach K. If you're unfamiliar with Coach K because you're not from North Carolina and don't care about college basketball, he is arguably one of, if not the greatest basketball coaches of all time, few gold medals. His story's all involved, Kobe Bryant. And he shows up and he says, I noticed that your tagline for this event is outpaced tomorrow. That sounds pretty good. That's nice. But I'd like to add, let's run together. Which I thought was a really amazing analogy for the entire open source ecosystem and the reason that we've decided this is a better way, that by running together, we all achieve a better result together. And in the case of Ospo, there's a lot of help out there now. You don't have to run alone. There's the to-do group. There is Ospo plus plus, depending on what your industry is. There are folks on the internet waiting to help you. So let's run together and make better Ospo's. Thanks for coming. Any questions? Yeah. So that's a really interesting approach if you are on the open source model of, here's the free project that you can download and use if you're willing to pay somebody to do all the work or you can pay us for essentially the same thing but we're doing the hard work for you. The red hat model. Let's call that the red hat model. SAS is a little different. We don't exactly have that going on, but it does get a little hairy in that your sales folks are going to feel like they're competing with the free product. So that is a really challenging thing to discuss and try to measure. So what you're talking about is conversion from free to fee, as they say. So one thing, since all of you are presumably involved in something with the Linux Foundation, you have dashboards and LFX insights that show you the participation of everybody in your company, assuming they have tagged themselves with your company in, oh, you know what? I didn't mention this with GitHub either. So on the list of education things, telling people in your company how to make contributions so that you get credit, so to speak, and that is one of them to go into their Linux Foundation profiles and associate themselves with your company so it shows up in your dashboards. And so it'll show you, if you haven't looked in there, all the things you remember of, what your benefits are, but then it also shows you how many people have contributed this year and fairly granular data. It's pretty cool. LFX.linuxfoundation.org, is that right? Anybody? Insights.linuxfoundation.org? LFX, sweet. You wanna add anything? LFX, no? Cool. There is, the Chaos Project is also useful for metrics. A lot of it is about community health, if that is important to you. Oh, and then as far as associating GitHub so that you get credit, a lot of people think that they need a separate GitHub account with their corporate email address, and they don't. You have two email addresses in GitHub, and when you make a commit, you just pick which one you want, if you want your personal email address or corporate email address or whatever, you don't actually need separate accounts. And then you can make all sorts of dashboards about everything that your folks are contributing to that are on GitHub, and then you get credit for those. I did not previously think that. I'd like to hear more. Give me an example. They're usually recruiting if you need a job. I think there used to be a lot of, well, so for a long time they were called Linux Fest, and then they started being about more than just Linux, but you had the Florida one and Indiana and Northwest, and there was sort of a collapse in those, and then the pandemic did even worse. But then I think it's a cycle, and they're starting to come back around again, and if you really just want to talk to developers that those are the more interesting places to go. The biggest one in the U.S. at this point is Scale Southern California Linux Expo, which is a fantastic event. In Europe, if you want to talk to developers, you go to Faustum in Australia, you go to LCA. So those places still exist. I think they're just fewer than there were. Do you have thought stuff? I think there are a lot more niche events like around specific technologies, whereas there used to be more big, broad events. And then there's things like All Things Open, which I think hasn't decided yet if it's a business conference or developer conference. Yeah. Oh, I love your news. Yeah, will you tell us what your foundation budget is? Bigger than that number? I'll tell you the whole way. Okay. I have a pretty good idea. I don't think that depends on revenue. I think it depends on goals and value. So Red Hat's Ospo is 25-ish people. I'm not sure the exact number today, but there's a pretty large group that is community managers who have one-on-one relationships with projects that are foundational to the Red Hat products. And then there's a team that, I call everything but code. So that's where the designer and the writers and data science and all of that are that are doing audits of community health and supporting the projects. And then there's a team that's sort of vertical focused. So 20 or 25 seems to be right for Red Hat. I don't know of many companies that are quite that big in their Ospo's. I think it's much more common to have that network of people who are working together to make whatever the core Ospo is successful. So again, like you're probably not gonna hire the lawyers into your Ospo. You're probably not going to hire the events team into your Ospo, but all of those people are Ospo-adjacent. So if you start counting those, like you probably have a pretty big one. And then in a place like IBM or AWS, I think has at least four. I don't know. Like there's no core Ospo. There are different ones that handle different tasks. So that's another model. I'm not sure there is, I don't think we could make a specific chart of at this revenue, at this number of products. This is how many people, I think it depends on what you want to achieve. Like I'm never gonna have a team of community managers at SAS, I don't think. Like that doesn't seem like it's on my to-do list. But maybe I end up with that many people but doing something very different. Yeah. It also helps to know if you're the kind of company where a person can only get things done if they have a certain title and whether you need someone with at least that level of title to be able to get those influenced things done. Where's somebody back here who had a question? Okay. I have almost no time left. So I'll do that in reverse and do the best I can in a short time. So the second question is literally what all of these foundations are about. So my favorite example, because there are a ton of them is that the film industry feels like software is the secret sauce. They do not have any interest in sharing their software because that's what's making them awesome money on cool movies. But about, I don't know, six or eight years ago, they came together. The industry came together on these two pieces that were not making anybody's movies magical. They just all needed to do it. So they collaborate. And that's the basis of the Academy Software Foundation is these two pieces of software that all the film industry companies needed weren't anybody's secret sauce but that was what they could collaborate on. And now that's a, they've got, I don't know, six or eight projects. Anybody know in the Academy Foundation? And that's happening again with O3DE, which was the gaming foundation that started about two years ago now. That happened in the banking industry on the order of about 15 years ago. They needed to collaborate on a messaging product because banks similarly needed to, they felt like their software often was the thing that was their secret. But they came together on a messaging product because they all needed fast messaging. Project, sorry. I kept saying product there. It did turn into a product as AMQP. That is the basis of all of these open source foundations. It's pre-competitive collaboration is one way to think of it. In the more granular sense, strip out your internal links before you post stuff on GitHub. That's step one. You would be amazed how much stuff gets posted with internal links. Like have somebody review that stuff. You have to have some degree of trust in your engineers or someone. However many layers of review and requirements you're putting into it, at some point you have to trust someone. That's what it comes down to. The first question was about the cost of open source. Oh, pros and cons. That's a very challenging question for somebody who spent 15 years in pure open source and now works at a proprietary company. So a lot of folks have asked me over the last eight months at SAS, what is important enough an open source project to contribute to? And my answer is yes. Contributions to the open source ecosystem are all valuable. Now the likely answer, if you ask anybody else in the company and probably a lot of other companies, is it needs to be of some degree of strategic value to your product. And so that could be the con is that maybe you've got engineers spending time on something that isn't necessarily as valuable as something they could be spending time on. But I could give you a whole another hour long talk on the benefits of stability and security and cost savings and all of that. And I'm going to come up with a very short list of cons for you, which is why I have my job. Yeah, if you're gonna start contributing to a project, they almost all these days of any projects of any size have a getting started guide, something for new contributors. Here's how we want you to behave. Here's where our communications channels are. Have your people read those to begin with. Because, so historically speaking, SAS products you programmed in the SAS programming language. And if you studied statistics in college 30 years ago, you learned SAS at college, but now they learn Python. I mean, that is the very short, short answer. People want to write in Python now. And beyond that, like I said back in the beginning, there's almost no proprietary software now that is written without some open source packages somewhere. Why are you reinventing the wheel? Don't write stuff over from the beginning. It already exists, go use that. So there were enough people in engineering and R&D who recognize that this is how the world works now, that it's no longer 1980. And that's just how it is. And like I said, so if you're, oh, Joe probably has a better answer. And like I said in the beginning, if you care about something, you pay somebody to care about it for you. So, yay, I have a job. They get cookies, win-win. Any other questions? I think we're super duper over time, but I'll be happy to stand around on the hallway and chat. Thanks.