What's in the SOSS? An OpenSSF Podcast

Turning AI into the Ultimate Open Source Maintainer Power Tool with Michael Winser

OpenSSF Season 3 Episode 18

Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.

0:00 | 33:05

In this episode of What’s in the SOSS?, host CRob welcomes back open source security champion Michael Winser to reflect on Alpha-Omega’s spectacular milestone of surpassing $20 million in security grants. Michael breaks down how their mission has evolved from simply chasing bugs to acting as a catalyst for sustainable, long-term security culture across critical projects. The two dive deep into the unsustainable economics of package repositories—the "app stores" of software development —and address how a massive partnership with frontier AI model providers is aiming to flip the script on AI. Instead of fueling endless, low-context vulnerability "slop," Alpha-Omega is working to put AI assists directly into the hands of maintainers as their ultimate defensive power tool. 


Chapters:

  • 00:24 - Welcome Back, Michael Winser!
  • 01:10 - The Origin Story of a $20 Million Milestone
  • 04:54 - Evolving Beyond Audits to "Sustainable Security"
  • 11:18 - The Messy Economics of Package Registries
  • 20:28 - Turning AI into the Maintainer’s Power Tool
  • 29:01 - Vision for 2026: The Security Trust Graph


Episode links:

Intro Music / Promo Clip - Michael Winser (00:00)

My goal moving forward is to to help maintainers with AI assists that they control that are on their terms. If you have your own tooling, applying AI, to find and fix all those vulnerabilities on your terms that you can keep iterating on, we all end up better. But hopefully it'll make them feel like they are more in charge of their projects and their destiny and can focus on things that matter.


CRob (00:24)

Welcome, welcome, welcome to What's in the Sauce, the OpenSSF podcast, where I get to talk to developers, program managers, architects, and engineers, all of who are contributing actively to this amazing ecosystem we lovingly refer to as the open source. Today we have a repeat offender, a friend of the show. Mr. Michael Windsor is back from his latest wind sailing adventure.


to talk to us, kind of give us an update on what's going on in the amazing world of Alpha and Omega. Welcome back, Michael. It's wonderful to see ya.


Michael Winser (01:02)

As always, it's great to be here. looking forward to chatting and you know, lots of things to say, so it'll be good.


CRob (01:10)

So I a little birdie told me that AO kind of surpassed milestone, where you hit a pretty high level of grants and money shared out. Can you wanna share a little more about that?


Michael Winser (01:24)

Yeah. So at by this point in time approximately, and you know, we we sort of count numbers in in big chunky ways, you know, we've we've had over twenty million dollars in funding over the since we started. Yeah. you know, it it little origin story, right, before I get on the other numbers, right? Is that Alpha Omega was started without realizing it was started at the same time as the OpenSSF was created.


When both Microsoft and Google realized, wow, this problem is big. It's gonna take some money. We don't know what money is gonna need, but never let a good crisis go to waste. And OPEX is best spent when you have it. Yep. And so they put money into an LF account each one and said, we'll figure this out later. And then if you recall, there was this pandemic or some sort of global phenomenon of something. And so everyone's kind of, you know, was doing other stuff. And then I joined the ghost team at Google on open source security, and I started talking to Michael Scovetta. And


CRob (02:09)

Think I remember that.


Michael Winser (02:21)

We started working with Brian Bellendorf and various other people and started thinking about well, what can we do? And Michael had written this paper called Alpha Omega that was sort of a a theory about how to go off and address the risk around there. And we said, Well, let's let's go try some things. And rather than having the money sitting there and not do anything, we started let's try doing things. And it was, you know, it was five million dollars to start. and from there I would say one of the most important lessons along the way, which is when, you when


When people give you money, make them want to do it again. Right. And that actually turned into philosophy for Alpha Omega, too. When we give grants to various organizations, we're not hands-on. We like to hold hands and help people, but we're not hands-on in the project management or what's going on like that. Yeah. Simple rule is make us want to do this again. help us help you, help us tell the stories. And it's it's been a pretty good philosophy. So yeah, $20 million. dozens of projects, and ecosystems and


partnering with a variety of organizations, audits, lots and lots of audits.


CRob (03:25)

That's really important because that's not a skill most projects have.


Michael Winser (03:29)

you know, you could generalize that, right? One of the things I think another lesson to talk about is, you know, when as an industry we started worrying about open source security and supply chain security, there was a lot of like, you all should fix this. Right? And A, we were as an industry trying to write checks on other people's time. That doesn't work out well, especially when they're nights and weekends. You can't even pay for more time when it's nights and weekends. Right. And B, you know


People are good at doing what they're doing, and they weren't doing these other things because they weren't good at them, right? And expecting everybody to become a security expert overnight at the same time as being an expert in file compression formats or user interface frameworks, or to take a trite example, inserting white space at the beginning of a string, right? Those are all things that actually have complex, nuanced expertise associated with them and do not allow attention and


Capacity and expertise to be in locking down your CI system or managing your dependency graph in a really spectacularly complicated way that is still not a well-solved problem, right? So it I think that's sort of been a key part of like, you know, our journey is it takes a different class of expertise. We need to figure out how to help people be helped and be helpful. There's a lot there.


CRob (04:54)

Uh-huh. So historically you've said a lot of stuff. Yeah. but I want to kind of focus in on you you mentioned that Alpha and Omega isn't just about throwing money at a problem, but you wanted to be a catalyst. So kind of reflecting on that 20 million dollars, which is not a small amount of money that you've been deploying since 2022. How has you how has the strategy evolved from just like finding bugs and vulnerabilities into like


You've talked about sustainable security. How's that evolved?


Michael Winser (05:28)

this is actually probably the most important question. It really is, it's awesome. And I'm glad you really glad you asked it. I'm glad that the the catalyst word has sort of stuck in your brain too, because it's it's key to how we think about things. So early on, when we first started working on this, we're like, well, the scale of the problem was, I mean, that five million dollars we had at the beginning, which looked like a lot of money, we're like, well, how many engineers does that pay for? Right? What's the size of the problem?


As my good friend Paul X to say, if you have a, you know, very big numbers multiplied by even relatively small costs, you still end up with very big numbers. And we were like, how do we how do we see this playing out? Like will Alpha Omega become this ginormous fund that is essentially paying for all the security work that needs to happen? Because every other project, every project has sort of reached a a status, a a a a stasis, like a a balance of


what its energy is going into, whether the energy is paid for or volunteer time or whatever. So the largest project you can imagine or the smallest single maintainer thing has achieved a a an equilibrium of what they work on and what happens and so forth. And now there's this, hey, you forgot about security. You need to know about it. And by the way, that we don't really know how to solve the problems yet, but here you should figure that out. Right? No, that balance was not easy to maintain. And we're thinking, do we just


Become like this giant global fund that funds all the security work everywhere and nobody else has to worry about the economics of that or never and obviously the answer is no. Right. For lots of reasons. One of which is what we do doesn't scale easily, right? What makes us work well at at one scale, if you turn that into we'll just go hyperbolic, a billion dollars, right? you know, guess how many people full time staff Alpha Omega has? Zero. I'm part time.


I'm this is my retirement gig, right? So if you had a billion dollars, which still wouldn't cover all of the work that needs to be done, right, you would have so much overhead and complexity that wouldn't work out well anyway, and you get into a whole bunch of complicated problems. And so a long way of saying that is like we like, look, we need to be about helping communities, organizations, maintainers, projects, individuals get over the hump of.


Michael Winser (07:52)

Being on a journey towards security. And it is a journey. It's there's no like flip the switch and you're done. It is a it's a journey, it's a discipline, it's a practice that becomes a norm in your culture. And we wanted to normalize and make achievable a different category of security, different level of security across projects. And the theory was it would start to spread too. Like we can solve it here, and then that's made it easier for somebody else to do so. And so that


That the word catalyst started really sinking into our our framing and our thinking, and it has, you know, continues to influence how we think about a project and we evaluate a potential effort. Is how will this cause change, transformation, learnings to happen in a community that then grow on without us? Right. And we're very happy if people go off and do things and nobody tells it and nobody even mentions it and that we don't get credit. We love it. That's awesome. Right? We don't, we're not here for the


The laws or the credits. Yep. And when we can look back personally and as a group, we can look and see something and saying, wow, that that might have been us, might not have been us, but that's what we wanted. That's really good. Right. Or that's not what we thought it would be, but that's really good. We're very happy, right? That's the outcome of


CRob (09:04)

I I was just reading your last year's report and kind of looking at the twenty twenty five numbers and it's just mind boggling. Last year alone, you all invested just shy of six million dollars across fourteen projects and you had sixty audits. So like these are these are big, big numbers. Yeah. When you when you look at that data, kind of what's it telling you about the current state of critical infrastructure? Are are we kind of to use another Windsorism?


Are you effectively turning that money into security?


Michael Winser (09:38)

one of the questions I get asked a lot is how do you measure the impact of your work? And again, if we were at a billion dollar range, people would have strong opinions about us measuring the impact of that work. to be very honest, we measure our work anecdotally right now. It's still something where we can and do observe it and talk about it and reason about it, and that is good enough for now. it's not ideal, but it's also like anybody who tries to measure developer productivity is walking down a very dangerous road.


Right. So but anecdotally, well, one of the things about, you know, our encouragement is make us want to do this again is tell us your stories and tell those stories. And one of my favorite things is like, we started out with a, you know what, we'd like you to produce just a monthly report back to us so that we have a clue about what's happening. Sure. And one way of phrasing that is like, tell us about the inputs, the w effort that was put into your world. And then at the end of the year, or maybe even quarterly, tell us about the outcome.


It's the outputs that happened, right? And all kinds of strange and interesting things happen. First of all, those reports are public. They're in our public repo. You can go look at them, and they are evidence of energy that's going into security work that was not happening before. And you can look at those projects over time and see that there is much more security work happening in those projects. And then what happens, of course, is other work follows that.


not our work. It becomes a normal thing. Or somebody invests in a some tests that validate various security expectations and then sudden suddenly everybody else's commits have to meet those tests and pass those tests and do the right thing. Right. So good things happen that.


CRob (11:18)

That's awesome. Yeah. So you you and I get to collaborate on several opportunities upstream. well, let's shift gears and talk about the package repos and kind of the software supply chain a little bit. I can't recall who it was. It might have been sonotype, but there was over 845,000 malicious packages have been identified within these repositories since 2019. Yep. The removal times


while are pretty good at thirty-nine hours, aren't amazing and that the that you are gonna have something where consumer's gonna grab some bad packages just because of the timing. Yeah. and these package repositories have kind of become the center of the open source software supply chain. Yet, you know, oftentimes we're not seeing a ton of people standing up saying, I wanna support these, I want to invest and make these little microcosms.


more secure and help them, you know, the the the security lags behind. I I remember that you had spoken at FOSDAM this year. So let's talk about your thoughts about the package repos and kind of how do we kind of crack this nut. It's not a s it's not another small you don't work on small problems, do


Michael Winser (12:32)

No, I I I I get to work on all the fun stuff, right? So a couple of years ago, you know, first of all, we've consistently funded. Like our if I may take a small aside, our funding strategy has historically looked at four buckets of investment. and I'll I'll go briefly, but the category A, which really should be audits, is 'cause audits are the start of every journey. But that's actually category C for historically weird reasons, right?


category A is staffing roles like security engineers and residents in ecosystems, highly leveraged places where those people effectively now become the agent of catalysm, catalysm, catalysis. They do things, they change the world for us, right? And simply by making it someone's job to worry about security in an ecosystem started with Node, we did Python, we've done Ruby, we've done a bunch of these other ecosystems, Rust and Eclipse, and now, you know.


Making it someone's job to worry about big security problems in entire ecosystem culture has a transformative effect. And you know, it's it's one of the most expensive engagements we do because humans are deservedly well paid for their work. And it's hard to find the right people to do the job, but man, the results are spectacular. category B is about these points of leverage that package repositories represent, right? The the registries. they are the app stores of software development. Yes.


Category C is audits because really every good journey starts with an audit. And one of our best litmus tests for are you ready for your journey of security is we ask, have you done an audit recently? And no, we don't need an audit. We just need this money to go off and build this cool new security feature. Right. And we're like, No, but really, have you done an audit lately? And how the team and project responds to the audit over it immediately and time tells us everything about that project's readiness, that community's readiness to begin that journey.


And then category D is about experiments and innovation because we humbly admit that this problem is hard, it's new, it's like Y2K without the same clarity of problem, solution, or date. and so we experiment. Back to the registries, right? These are the app stores of software developers. People do npm install foo and expect magically great things to come down from the sky and show up in their project. Yes. And


Michael Winser (14:54)

There is some amazing work being done in the OpenSSF in the securing software repositories working group that has to find guidelines for just securing these repositories and registries to making them more secure, to making them trustworthy as stewards of the packages that are coming from the maintainers, and to allow them to start helping the consumers make informed, accurate decisions about the provenance, the real safety of something they're consuming.


By analogy, right, if you were an app publisher of a rental car company and you decided to call yourselves Nudget, and you made an app that just looked like Budget and typo wise B and N are very close on my keyboard, right? The app store providers today would say, Hmm, I don't think you should go quite that way. Can you think about how to reposition yourself, not as a typosquatting attack on budget? Right. Well, that problem happens every day in package registries today. Yes, it does.


And so there's a lot of interesting hard work to be done there. And like everything else in all this open source stuff, right? there's a lot of technical debt. And a lot of these package registries grew very fast as sort of exponential behaviors reached a certain point. Like the exponential is fine as long as the constants are pretty small. And once things get big, they get really big and really fast, right? And as we were funding engineers and work in these projects.


I started thinking about the economics of these systems. Yeah. And I'll summarize it thus. Open source software, the cost of each unit of consumption of open source. Like if you if if you were to create a project and it gets used by one person, right, the cost is your time divided by one. Right. If it gets used by a million people, then the cost of each usage is your time divided by a million, right? Package registries, so it essentially


As usage grows on open source software, the cost per unit trends towards zero. Right? Package registries go the other direction. As usage grows, right? First of all, more packages coming in, which means more malware checks, which need more storage, which means more arbitrary consumption, right? More abuse, right? And as consumers pull more and more of these packages down and perhaps more indiscriminately do so, right, the usage starts to go up and it trends towards infinity.


Michael Winser (17:19)

How are these, how is this? So open source infrastructure has very different economics to open source software, but we all call it open source and it's there and it's historically been there. And when it was small, it didn't cost anything to run. It was a GitHub repo that happened to have a database hidden as a text file, right? shout out to Andrew Nesbitt at Ecosystems, who has written and learned and forgotten more about package ecosystems than I will ever know. And so looking at that math, I'm like, how are they funded? they're funded with flat donations to open source foundations.


So costs are going up and to the right and donations are going slowly downwards. Hmm. And so this began a long effort of conversations, including with folks at Sonotype, because guess what? The commercial entities have similar economic problems. Correct. There is no norm for who should pay and how we should pay for these things and how like you know, but there's also no sustainability right now. and Alpha Omega is funding a significant amount of engineering work into the registries.


to improve their security, but they also have non-trivial operational costs. Tremendous infrastructure donations from Fastly and AWS and others help defray their operational costs, but they also mask or confuse people in terms of like where the real costs are. Right. And I I don't joke about this is like don't break into bandwidth jail. The cost of running these things is not simply bandwidth or downloads, caching


Yes, you should be caching. You should be caching for security and control reasons, not to worry about the bandwidth. Yeah. But you can't charge for bandwidth, you can't charge for downloads in the same way. It's a complicated usage metric. And also we have a situation where you know people have been using these things for free since the beginning of time. So we're not incrementing a business model that's in place. We're trying to understand what an accurate or useful business model would be. I will I will say this one thought. If


If every company that had over a billion dollars in revenue that had any meaningful use of package registries in their business paid just ten thousand dollars a year of usage fees towards those registries, on average that would work out to a hundred million dollars a year, which would be about average ten million dollars per registry, which is about how much they need to run and to grow according to our sort of security goals and aspirations. So


Michael Winser (19:45)

The money is not outrageous, but the chasm to get there from where we are today is a big deal.


CRob (19:50)

Yeah, absolutely. It it's been fascinating. I've really enjoyed kind of being involved in this process over the last few years, kind of talking with the repositories. And it's a whole world I had never considered. So again, I we had we all have kind of our work cut out for us, marketing this to get people to want to pay attention.


Michael Winser (20:10)

It is a hard problem for everybody involved. It is emotionally complex as well as, you know, business and legally complex. I'm just glad that the conversation is happening and it may even take off without Alpha Omega in the conversation and we'd be okay with that. As long as the conversation is moving in the right direction, we're very happy. So


CRob (20:28)

Well, let's talk about another very small problem we get to collaborate on. Yeah. this little thing called AI. I don't know if you've heard about it, but people think it's gonna be hot.


Michael Winser (20:39)

Feels like a feels like a it must be a fad, right? Yeah, internet and and you know, like and fax machines. Internet and fax machines, those are the things, right?


CRob (20:42)

I heard like the internet, it's gonna go away next.


CRob (20:49)

So you know, we are involved, you, Alpha and Omega are involved in kind of this really exciting partnership with the frontier model providers. So Anthropic, Amazon, Google, GitHub, Microsoft, and I believe OpenAI. And this is like a really massive show of force. So let's talk about how this specific funding is in we how what we hope to change the day-to-day life of maintainers who


currently don't want to hear the word AI and they're exponentially underwater with the volume of reports that are getting thrown their way.


Michael Winser (21:32)

y this is first of all, I I'll start by saying if I knew all the right answers to this problem, I would have already written them down, right? I and I think that I was observing an earlier conversation today, right? We're sort of experiencing Moore's Law at dog life speed like you're the human and the dog is living faster, right? Like, you know, the the rate of change is like on models is six months. The rate of change


Like Moore's Law was every 18 months, which became a target, not an actual law of physics. But the rate of change on just sort of the the coding agent tooling and the prompt definitions that drive them like that is now on an 18-day cycle. Right? So y months to days of of how quickly things get better and change and improve. and so


Just like every other form of technology we've ever had before, it's exceeding our human capacity to process change and to internalize it. Right. But it's happening even faster than before. And so we're all a little bit like that old Max L commercial with the guy leaning back and the hair blowing in the wind, like that. Love that one. So I'll I'll start with saying that like the new capabilities that are emerging and continue to emerge are making


It's possible for anybody and everybody to do incredibly new and interesting things, right? And the problem with is everything fails at scale. And so now anybody who wants to try their hand at being a security researcher, the barrier to entry, the friction is pretty low, right? And unfortunately, the amount of random vulnerabilities lying around in code, especially not that important vulnerabilities or hard-to-qualify vulnerabilities, is very high.


Right. And so it's not hard to spin up some tooling and go find some bones. And the what used to be involving using a fair what I would call like more esoteric tools. You had to be an expert in that tooling to go up and use this, right? Has now become something where you can just type a prompt and say, Go find all the vulnerabilities in the classic case right now of curl dealing with that, right? Poor Daniel. And


CRob (23:44)

poor Daniel.


Michael Winser (23:48)

Usually these things also are operating in a world where there's no published threat model to help them rationalize about that. And that's a a peeve of mine. and even when the folks involved are courteous enough to produce a PR, right? that PR is typically lacking all context. It's just narrowed it on the thing like that. And so it ends up still being more work for the maintainer. Right. And I I've had an example of the past couple of weeks where.


A well-meaning security researcher found some things, curated them a little bit to make sure it wasn't just pure AI slop. They had actually some experience, and that's great, right? And then they submitted them to a project, and that project was like, well, sure, yep, these are actual vulnerabilities. And no, I wouldn't want to just throw them away. But there's no escalation path or privilege escalation that's real there. It's more like, don't do that, and you could stack 20 of them together and might get to something that could stack another 20 to get to somewhere. But okay. But now all of a sudden he's got more work to do.


And that's that's a case of one of the better ones, right? If you have at scale potentially hundreds and thousands of people submitting vulnerability reports to you, right, all kinds of interesting problems start to emerge. And I've heard people suggest, well, you could use AI to triage these things. I'm like, well, prompt injection has entered the chat here now, right? So we're we're in a space right now where once again people are either trying to seek their fame or


Some validation or or just do something cool and then shoving work or externalizing problems to maintainers, right? And it sort of goes back to the beginnings, honestly, of the OpenSSF era, where we were all as an industry very worried about things and learned that we were not always expressing that worry in terms of how maintainers could benefit from this. We were expressing this in terms of like, we need this to be better. Both statements can be true, but how you come at it really matters, right?


CRob (25:45)

It's interesting in my journeys around the ecosystem, I I've had developers share that it bug reports can take anywhere between two and eight hours to if if they're doing real due diligence and you know rigorously looking at it, between two and eight hours for each bug for the project to validate and or refute. That's a not an inconsequential amount of unplanned work. And then you shove it into the robot and it's barfing out hundreds or thousands of these.


Michael Winser (26:15)

Yeah, and and so look, we can then have a a a a proddy difficult to resolve conversation about how does AI affect us all as software builders, creators, makers and so forth. and I can only share my perspective here, which is when I first started programming, I was on a Timex Sinclair ZX eighty one and the basic interpreter was so slow that I learned how to write assembler and I was literally typing hex codes into a chiclet keyboard.


In order to make pixels fly around on the screen. Those were amazing days, and I was incredibly lucky to be doing that and learned a lot and was it was very like that. I don't miss having a compiler. Right. And and as someone who worked on early versions of tools and back like that, right? Early compilers, they were sucky. They were terrible, right? And so when a compiler actually tells me what the error was as opposed to syntax error, fail. Good luck. Right. or even suggests what I should have done differently, or says, Would you like me just to compile that anyway, which JavaScript's approaches, I'll make this run somehow.


Right. I don't look back on those times with with regret either. Like the tooling gets better every step along the way. What we're seeing with AI now is the ability for people who have experience and knowledge in making software to be even more valuable than ever before. But again, the pace is just it's it's processing us. It's making it hard for us to process. Right. And so my goal moving forward.


is to to help maintainers with AI assists that they control that are on their terms that can work it because the best defense is an offense, right? A good offense. If you have a thousand people submitting randomly discovered vulnerabilities on your project, right? It's a lot of work. If you have your own tooling applying AI to find and fix all those vulnerabilities on your terms that you can keep iterating on and perhaps you can get


Guidance and prompts from people who are experts in security to help you shape that conversation you're having, right? And then you have no vulnerabilities in your project anymore, all those script kiddies filing vulnerabilities are not going to find anything, and we all end up better. That's not zero work. There's there's still work for people to do here. I can't pretend otherwise. But hopefully it'll make them feel like they are more in charge of their projects and their destiny and can focus on the things that matter as opposed to having to fend off a bunch of really noisy people angry about things.


CRob (28:43)

I I think you were referring to this as kind of turning AI into the maintainer's power tool.


Michael Winser (28:48)

Right? I I think that is a great way of putting it, yes. Excellent.


CRob (28:52)

So, you know, we we got a lot of these problems on our plates, a lot of active work and a lot of pending work. So by the end of the year, the end of 2026, we're in the future now. What's your vision for open source maintainers to be aware of, to be able to adopt both like these AI practices, kind of incorporating like the best practices from the registries? You know, how how do we kind of what are we gonna talk about at the end of the year?


Michael Winser (29:21)

I could articulate it this way, and and please accept that this is very much like early thinking on this stage as we are now feeling empowered to empower them. I think that having trusted and trustworthy sources of agentic definitions and skills and tools that as a consumer who is not an expert in this bus, I can say, I trust those people to have thought about this problem. And I think


In general, I I I feel like in all of open source now, trust and attention are the two most important currencies. And so being able to say, I, as a maintainer, can trust that Crobe and Michael and their band of merry band of crazies have actually put together something that is worthy of my attention and they're putting their attention and expertise into this thing, and I can consume it is a necessary step.


Right. Otherwise it's gonna be a very messy space with everybody's vying for supremacy or coolness or whatever, and there's gonna be thousand different approaches. I still want diversity, absolutely. But I I I'm hoping that we can also build some trust roots here that people can start to lean in on.


CRob (30:28)

I I think that is a very wonderful goal to work towards.


Michael Winser (30:31)

I would also like to see


you know, 10,000 projects in a trust graph of we know them and they know us, able to take advantage of early access to AI capabilities so that they can essentially bat down the hatches or or fix the the the newest problems before general availability of these things that become zero day attacks. Right. And then I would love to see a hundred thousand maintainers


Starting to reason about this, starting to think about this, starting to like seeing workshops, being able to learn about it and to go at their pace to integrate it into their worlds so that they can feel like, Okay, I'm in control of my project here. I'm not being told what to do, right? But I am learning about this next space and don't feel threatened by it. Right. These are big hand wavy goals, but that's how I think about this.


CRob (31:25)

I love it. Well, I I look forward to sitting down with you at the end of the year with a nice beverage and kind of reflecting back on what we and the community have been able to achieve.


Michael Winser (31:34)

It would be a i if we can hit even twenty percent of that, I'll be pretty happy as it is. It's really, you know, these are big goals, but that's why we're here.


CRob (31:43)

Michael Winds from Alpha and Omega. It is always a pleasure. I enjoy our conversations. I learn a little something and and I get to kind of soak in a little positivity in in the midst of all this giant pile of work we have collectively to I work on.


Michael Winser (31:58)

I always appreciate our conversations and your questions actually always like make me want to go and think more and have you ask me more questions as well. So I really appreciate that. and if we can't have fun doing this and saving the world from itself, what else are we doing things? Right.


CRob (32:13)

I I agree. Well, and with that, we're gonna call it a wrap. I wanna wish everybody a great day, happy open sourcing, and stay cyber safe and sound. Cheers.


CRob (32:27)

Like what you're hearing? Be sure to subscribe to What's in the Sauce on Spotify, Apple Podcasts, Antennapod, Pocketcast, or wherever you get your podcasts. There's a lot going on with the OpenSSF and many ways to stay on top of it all. Check out the newsletter for open source news, open.


Outro

Upcoming events and other happenings. Go to opensf.org slash newsletter to subscribe. Connect with us on LinkedIn for the most up-to-date OpenSSF news and insight. And be a part of the OpenSSF community at opensf.org slash get involved. Thanks for listening. And we'll talk to you next time on what's in the sauce.