CHAOSS OSPO WG, Feb 19 2026 ![rw-book-cover](https://img.youtube.com/vi/isE_p-eDzhM/maxresdefault.jpg) 🔗 **Source:** [CHAOSS OSPO WG, Feb 19 2026](https://www.youtube.com/watch?v=isE_p-eDzhM) Okay. So, welcome everyone to the Chaos OSPO working group meeting for Thursday, February 19th. Um, as always, this meeting falls under the chaos code of conduct. So, uh, please be kind to each other. Um, as you can see, we are recording this one. So, we've that's the first item on the agenda. So, we've decided to record it. We can stop the recording at any point if somebody wants to have a more more frank discussion off the off the record, so to speak. Um before I turn it over to um Natalyia, we have we have a couple of people that I don't know that I've seen before in this meeting. Um I don't know if you want if you want to introduce yourself. It is totally optional. You don't have to. Um but we'd be happy to have you do some introductions if you'd like. >> Sure. I can can go first. I just joined. So my name is Diego Mastraani. I uh work as the uh OSPO head of Ospo for Cloudera. Uh I was um we actually met last year in Napa. Don I was the OSPO for Moody's at the time so I changed in between and um it's my first time attending the meeting. So yes um >> yeah very good. >> Happy to be here. >> Welcome welcome. Uh anybody else? Okay. Uh so we'll we'll go ahead and get started. I will stop sharing so that I can uh turn it over to uh Natalia to get started with our agenda item. >> Yes, thank you. And I will be taking over the screen share. Okay. Actually before that um I'm Natalia Luzeryaga. I'm a software engineer as part of the open source program office at the Centers for Medicare and Medicaid Services. And today we'll be talking about um our organization's practices with archiving repositories. This has been one of my main projects um starting the beginning of this year. Um so lately um our OSO has been kind of focused on the repository life cycle where um first our major focus was establishing our baseline tools which started out with um creating repository templates for our organizations and uh thus forward assisting those development teams with maintaining those repositories. And then um we've been thinking of uh the rest of the life cycle one path which we call the path of growth. So as a open source project matures further in their journey how best can we assist them as an ospo and the other side of it the path of archival. So how do we assist repositories that have reached the end of life? So today I'll be focusing specifically on the path of archival um and how exactly we go about sunsetting repositories in our organization. Okay. And then I will share screen. So um to kind of start off with um brainstorming and trying to figure out what are the best practices to go along with this um we actually turned towards Chaos's uh practitioner guide on suns setting which was written by Dawn and here this is a very um comprehensive and wonderful guide about how exactly you go about um archiving repositories. So first she talks about identifying trends using um metrics that um using chaos metrics and then from there based on um those trends and metrics that's when you can diagnose a repository as ready to be archived or or identify its candidacy for archived. And there's also some other recommended metrics and data that you can use along with your consideration. And then finally is actually making um the actual change of archiving the repository. And so here um we have some action items that are listed out such as updating the readme, updating communication channels and documentation accordingly and notifying users. And then um you can also do an additional step of adding your code to software heritage to ensure that it is preserved over time. and some cautions and considerations. So after reading this guide, we decided to um focus on this step over here. What exactly does our organization need to do in order to um what we should do when we archive a repository? And so based on this guide, we came up with our own checklist based on this of how we want to prepare a repository for archive. So for instance, first we want to review the metadata of the project. We have a file called code.json which includes all metadata about a repository. So we want to be able to mark the status of the repository as archival in that metadata so it reflects its new um status. And then from there we go through a um thorough repository review where we update the documentation such as the readme. We look through the repositories issues, close what has been fixed, comment on what has been unresolved, label the issues accordingly, and for those that won't be fixed, label that too. Then we assess um who has access to the repository. Then we perform a lightweight security review, review for secrets, keys, PII, and then we do some minor housekeeping like deleting some branches. And then for repositories that are a bit more mature in their journey um such as they accept contributions from the external community that's when we review the pull requests make sure that um we merge those that are ready to be merged merge any dependabot PR so that our dependencies can be up to date um comment on open PRs and close won't fix PRs and for those repositories that um have a wiki or slack channel or just more means of communications outside a regular GitHub repository. We also note to review that and to notify um parties in uh in those spaces. And then finally, we have a little more thorough um security review where we review the code quality, the commit history, um run some code scanning and security alert tools. We check out the change log and then re-review the release and tags. So just doing a thorough review of the repository to make sure that all of our bases are covered before we mark the repository as read me as uh archived. Okay, cool. And then so based on um all this information I just shared with you um our team we created a tool to kind of automate some of that work called repo sunsetter. And this is essentially a GitHub action that um prepares a repository for archival by um creating an issue that posts all these action items from this checklist I shared. and it automates some of that work such as adding a adding some text to the readme to inform users about the repository being archived and updating the project metadata accordingly. Okay, cool. And then I'm going to do a little demo. So I'm going to I have this test repository over here and then I'm going to um run this GitHub action on this repository by first creating a new workflow file. Cool. Okay, this is the workflow file over here. You want to make sure that the GitHub action has permissions to write pull requests and to write issues and to also write uh contents within the files of the repository. And then here we just have uh this one step over here where we actually run the repo sunsetter tool. Okay, I'm going to switch this over to another branch that I have that's that has a little bit more features than what's currently on main right now. I'm just going to do this over here. Okay, cool. Okay. And then I'm going to name the file archive repo.ml. Okay, cool. So now that we have the workflow file, we can easily run this action in the UI. This is it over here. And then we run the workflow. Cool. Okay. And then we're going to wait a minute or two um to let this finish. Okay. Cool. In the meantime, I wanted to ask the audience um does your organization have uh their own archival practices? Um just curious to see like how exactly you guys go about it. >> No, no. Okay, cool. >> Yeah, it's it's actually very timely because we are talking about archiving one project right now. So I was I was kind of doing this checklist. I mean I never been it's serendipity. So thank you so much. >> Okay cool. That's really good to hear. Yes. I hope this uh we decided to make this a GitHub action because we know this is a shared challenge that ospos go through. So we hope that you can also make use of it too. Yes. >> Okay. >> Very thoughtful. Thanks for sharing all this. >> Yes. Of course. Of course. Okay. Um let's see. while she's building let's see I think I can talk a little bit more about diagnosing repositories um let's see feel free to step in Don too but um another my team and I were also creating another tool to to assist with diagnosing repositories as um being candidates for archival um and some of the interesting metrics that uh we've been looking at mostly in this guide is the number of open and closed change requests that a repository has since that indicates whether a project is still maintained or if um other people have been making pull requests to it. It just indicates activity. We also have new issues. So that indicates whether the external community is uh still looking at the repository since users can um post bugs um ask questions or request for new features through through new issues. Um and then technical forks. This is a big one. So people that fork your project, um we want to kind of assess usage within that fork to actually see if people are uh to see if people are building a uh on top of the upstream stuff that you did. Yeah. So um we've been looking at these metrics and kind of just been experimenting with um using these metrics to identify repost for archival and I hope to share that work in a next uh chaos ospo working group. Okay cool and then we're going to look to the actions over here. Okay cool. It looks like our GitHub action repossitter has run successfully. And so as a result it should have done three things. Let's see. It should have created a new issue with the archival checklist that I went over. So, the idea is we post this as an issue so that the repository um the development team can um go through this checklist now that they know how exactly they should prepare their repository for archival. Yeah. Cool. And then notice that we have two items that have already been checked over here. And that's because we actually automated that work. So we should have two pull requests up in this repository. Okay, cool. One is updating the project metadata. And for our organization, our repository metadata lives in a code.json file. So we indicate its archival status. And I think we add it as a tag. Yep. And then the last thing is we add a archive notice to the readme. So this is how that PR looks like and this is the text that we provided. Cool. And this is how it looks like. We use the warning banner as part of uh GitHub's uh markdown rendering. Yeah. Okay. Cool. And that's pretty much it for our repo sunsetter tool. Yeah. I think that's all I have to demo for today. Yes. Uh but any um Yeah. any thoughts, any questions, and I'll share some links in chat. >> And just to add to this, I think the team is actually planning on contributing some of this back to the sunsetting guide. Um, which I'm super excited about because if you're So, Diego, if you're looking at this right now, I would have a look at their checklist because uh the the practitioner guide is missing a few things that um we just didn't think of. So, I'm really looking forward to getting some some contributions to the sunsetting guide uh from the the CMS team. I think that's really exciting. >> Cool. And then um we have Remy DSMaker who's on the call. Um he's the open source lead uh at our OSO. Yes. >> Yeah. And we just got word yesterday that uh our talk at the GWU OSCON conference uh has been approved. So, we were accepted to present and our agency has approved that. So, we're going to be presenting about Repo Sunsetter and the Chaos Practitioner Guide uh on March 23rd or 24th at George Washington University here in DC. And I believe they're going to record it. So, um should be uh a good moment. Uh you folks are the first to hear about it though. Uh the working group here uh as you fellow practitioners uh Nat shipped this yesterday I think. Uh, so this is fresh, brand new, off the press. Uh, we wanted to make sure to engage with the OSO community. We definitely appreciate the feedback here. We couldn't have put this together without the chaos practitioner guide. We leaned on it heavily. So, we really look forward to contributing back up. And that's going to be one of the key elements of the presentation is, you know, making sure that these upstream contributions are made back and that we can share those out with the GW OSCOM. >> That's great. Great. Congrats on getting that talk accepted. That's awesome. Um, other other questions for Natalyia or thoughts that people have on sunsetting and archiving repositories. Natalya, I'm not all that familiar with GitHub actions, so I'm just trying I'm looking at it on your repo. I'm just trying to figure out how would I I saw how you would use it. How would I graph that into a flow that I might try to do? >> Yeah, for sure. Um, let's see. So to actually use the action, okay, I'm going to steal the screen share again, you can simply copy and paste this text over here >> and add it to a okay. So first you identify the repository that you'd like to prepare for archival and um from there we will run the GitHub action on. And so to run GitHub actions, you have to go to the workflows directory in the git within the GitHub directory. And here is where your GitHub action files live. And then from there you can create a file with those contents within that folder and then name it accordingly. Archive repo 2.l. Oh, and GitHub action files are written as YAML files. Yeah. Okay. Cool. And then um you have this actions tab over here where you can run the GitHub actions that live in this file over here. And then so here are the actions that you can run on the side. And so I'm going to click on archive repository. Cool. And then from there there's a button that says run workflow. And then you can run the workflow. >> Yeah. >> Nice. Thank you. >> Yeah. It's super easy. >> I saw another one that you had in that list stale repo identifier. >> Oh, that one's a cool one actually. Um, so that um GitHub action was created by the GitHub Ospo and it basically identifies repositories that have been inactive within 6 months. So um you give it your GitHub organization name and then uh you run it as a GitHub action and then it identifies all the repositories in your organization that have been inactive for that period of time. Yeah. So we were kind of doing some experimenting with what's currently in the landscape and we thought that was a super helpful one that will assist us with diagnosing repositories to be archived. So, >> so prioritize which ones to put at the top of the list. >> Oh, for sure. Yes. Okay, cool. And then it's this one over here. Okay, I'm dropping it in chat. Cool. >> Thank you. That's really helpful. >> And David, you have a question. >> Yeah. When when you saw the banner, like when the action create a banners on the top, is that what does it say? the banner says this has been archived or there's a kind of a way of I don't know adding some kind of reasoning of why this archive or showing like alternatives of what to use if like is there is does the action provides more things to do or does one of the checklist to say oh by the way add more information of what you expect the users to use now >> I see okay I'm going to share screen. Okay, cool. So, um the GitHub action, it does these three things, but um actually I have a PR up where we kind of want to generalize the action so that it's more configurable. So, speaking to um let me bring up the archive text. Okay. So, speaking to your point about um this archad text over here. So, um let's see. Yeah. So, I added a feature where you can add your own custom archive text text um which will be appended right over here. Um, so this is personally the um archival text that our organization decided to use, but there's also some best practices where you point other people to other repositories that users can um use that instead of the one that is about to be archived. Um, but here you can essentially just provide guidance on um to users on how you want to uh approach things. Go ahead, Remy. And one of the patterns that we've used in the past too, David, is that PRs are editable. So even if we have an automated tool that will generate the PR, the OSBO can go back in and then add custom text to it on a case- by case basis. Um along with that same like questions of like where you want to go, I don't know if Nat covered this, but um there's sort of two parts to repo sunset, right? This is the part that says we know we want to archive this repository. This is called what we refer to as the path of archive. We also have this concept of the path of growth which during the archival process like maybe we can say like hey it looks like your project is a little bit stale and coming up with like if you'd like it to not be stale here's a checklist of things you can do like adding pull requests templates or adding better contributor documentation or adding new issues that are labeled in a certain way to draw people towards your project or you know coming up with uh a little bit of like a you know a fork in the road to say like if you want to try and not go to the path of archival here's how you can get your project back on track and then we want to use that also as a as a leading indicator as well. So like maybe the the sun seting process starts by running the identification script identification script says here are the stale repos. So we file our first issue on our repository that says, "Hey, looks like you're stale. If you want to go down the path of growth, here's some things we suggest you do." And then if that issue sits idle for a quarter and we run it again, we can say, "Okay, we told them about the path of growth. They didn't go down the path of growth. Let's now change courses and and suggest that they go down the path of archive." And then if that one sits unattended, the OSPO can come in and we can burn down through the tickets and we want to keep track of all the tickets that we have filed so that we can show progress and demonstrate value to the organization and say like we've identified this many inactive repos, we've converted this many to active repos, or we've archived this many. And that's part of our source code stewardship task force strategy to go through with our inventory work and make more sense of what's going on uh across our footprint in the ecosystem. Uh we are still early on in this journey. You know, we just shipped this tool, so we're not running it regularly. I saw a question in the chat from Travis says, "How often uh do you run this?" Uh ideally, I think we're going to be running it probably on a quarterly basis. uh maybe a monthly basis if we wanted to, but quarterly is probably the right cadence. Um so this is something that's kind of new. Uh I think we'll like as soon as we're happy with it, we'll start rolling it out across our own GitHub organization and then testing it in other GitHub organizations. There's probably about at least half a dozen GitHub orgs that are part of our footprint, plus a bunch of others that we don't know about yet, too. So, I think it's it's going to be a little bit of a patchwork uh process because each org will have different uh cycles that we go through. So, a lot of this, you know, we're still early on in the in the inventory process, but we're we're feeling better as we're starting to put some concrete code that actually runs and actions that we can enable. >> Yeah. And one of one of the things we did at at VMware, so we did we did that audit about quarterly. So we had a Python script that looked for inactive repos. Um, and we ran it on a whole bunch of GitHub orgs because I think VMware had over a hundred GitHub orgs that had come in through acquisitions and various various things. It was it was a lot. Um, and so we ran it on a whole bunch of a bunch of different orgs. But the other thing um the other thing we did and this wasn't my idea. This was Stefka who worked on my team. this she ran the whole sunsetting process. Um she put together a really detailed process for unariving. So um she put together a process for this is what happens if you say that you want it archived and then you change your mind later. This is what we'll do. And it's it's fairly easy. We'll just bring it back. It's not a big deal. And that really that was a real turning point in convincing people to archive their repositories because I think a lot of people when you say they're going to archive it, they're like, "Oh, it's forever. I can never get it back. You know what? What if I change my mind? Um, here's the funny thing. No one ever changed their mind, but um but knowing that they could made all the difference. >> Don, it seems like you were ahead of the curve at VMware just even addressing this issue. And compliments Remy and Natalyia to your team because this is really thoughtful and well thought well well worked out. But I'm curious if there's maybe urgency is the wrong word, but some push to get on with focusing on this either because of the EUR and not wanting to have stewardship assigned to these things or just because people file pull requests and you just don't want to deal with it. >> Yeah. >> Or something. >> Uh, no, great question. I think that um there's definitely value like so we we think about the layers of stakeholders in our hospital right so the immediate stakeholders of the people within our community they just developers need more support uh you might have noticed you know across tech and in the public sector there have been a lot of reductions in force over the last year u maybe four years so teams are getting smaller uh contracts are being uh renegotiated or canceled. So, a lot of that brings a a more urgency to this type of an issue. And so, uh that is an immediate concern. Um with the the CRA, which I just I went to FOSD them in a personal capacity over the past uh month and got to hear a lot more about the CRA. Um in the world of the United States federal government, I think that that's less of a concern um because, you know, we're in the United States. Not to say that we're not a member of the global open source community, but um I don't I think that um we're the first federal OSO, right? So I don't think that that's as much on the radar of um there's no specific open source program offices thinking about that at other agencies. Uh that being said, I know there's cyber security concerns being upheld. That is the place where the federal government is actually really on top of the ball. So maybe there are other source code uh analysis uh and like cyber security functions for supply chain security that are that's more on their radar. Um, but I think that, you know, generally as like a steward of the code, like we just want to reduce our footprint and we want to be more intentional about saying like these are the active projects and these are the inactive projects so that we can, you know, direct the limited resources that we do have towards the projects that are in the best place to receive them and also to provide like another layer of nuance. Um it's been really helpful back at um Nadia's book working in public uh where she talks about the the project uh classifications of like toy federation club stadium where you talk about like your composition of upstream uh developers and your users and using that to describe more uh more clearly or more like you know more specifically like what your open source project is. It's not it's not just an open source project. It's a open source project of a certain size with a certain user base and a certain downstream and an upstream. So taking that same kind of classification and bringing it into the archival space where we can say like it's not just a if it's a inactive project, it's a stable project or it has an inactive downstream or a dormant upstream or a dormant downstream. you can say, you know, this project is being used by lots of places inside the federal government, but the upstream community is dormant now. Like that is a different thing versus we have an active upstream community, but there's not a lot of down, you know, not a lot of downstream users of it. And I think that helps us to figure out like in a more clear way how to prioritize those kinds of projects. Then we are helping to advise some other projects inside and outside the agency that have been impacted by reductions in force and open source is a succession strategy. Uh it really is important when you look at um inner source style models that are totally driven by internal teams and salaried people when those communities lose their core contributors. Uh how do you then provide succession? And an open- source strategy is one of the ways to help with that. It doesn't come without resource load or a lot of upfront work potentially, but uh it is a strategy to help to to secure succession when there's a big change in the composition of the contributor community in a project. >> Yeah. And to just to add to that a little bit, you know, one of the reasons that we started doing this so early at VMware was um was frankly the pivotal acquisition. So I came into VMware through the Pivotal acquisition and Pivotal didn't have an OSPO but we did have an open- source everything by default strategy um which meant that this is partly how ended how GitHub or how VMware ended up with over 100 GitHub orgs. Um and so we just had we had so much open source and nobody looking after it. And so so much of it was was in need of being being sunset and being archived because VMware's big concern was, you know, hey, we we've acquired this this smaller company and people tend to trust big companies like VMware. They're like, oh well, you know, it's a VMware open source project, so it's probably, you know, secure. Um, and and these these abandoned repositories aren't right. They've got all kinds of security vulnerabilities that have not been looked after. And so our concern was leaving these sit around is uh you know potentially creating security problems for the people who trust the the brand of the organization. So that was that was kind of why we started doing it. So we we started this it might have started a little bit before um Pivotal was acquired. I can't remember exactly but so this was around 2000 or so that we we really started uh sorry not 2000 uh 2020. It was right before the um you know people started being locked down. So it was about 2020 that we really started doing a lot of this stuff. >> You'd be really ahead of the curve if you were doing this in 2000. >> Yeah, exactly. This is that was back in the days where all of the Yeah. All the stuff was hosted hosted um in other places there, you know, Git didn't even exist. >> Yeah. Any other comments, questions, thoughts on this topic? We also don't have any other agenda items, so we're free to keep talking about this if it's if it's interesting to people. Um, if you have something else you want to talk about, we have a few more minutes, so we could always talk about something else. Um, that >> I have a sideline and but if other people want to talk about this, I I'll hold on it because it's changing the subject a little bit. I just have a question on uh when we were talking about tagging and giving the opportunity to grow. So this is kind of for the contributors reminding them you have opened this repo here. You were maintaining it and now it's kind of inactive. Do you want to bring it back? So or or this to let's say the for the internal contributors or or open source in general like if somebody else picks it up you would remain keep it open what because yeah if if you I saw you nodding >> you want to take a stab at that and I'll follow up >> you can do like me. >> Yeah. So, um, one of the key pieces of guidance that our ospo is like there are many layers to the the repository life cycle and the key one is our maturity models. So, one of the things we're coming up with right now is, you know, getting people from we don't know what our maturity model is to, okay, we think you're a one-time release or we think you're an inner source project or we think you're working a public project. >> And then knowing what maturity model you're in, then we can say, okay, what are the actions that can take you from base tier two to like advanced tier two? from advanced tier two to base tier three. So mapping the different pieces of guidance and now if you want to grab a link to the maturity model the table with all the like the documentation guidance. So it's a little bit rigid but structure is good. Uh we found that our users really like to have more structure. So we can tell them things like hey you're a tier 2 project. Tier 2 project is an inner source style project. we notice that you don't have your agency mission. You don't have a code owners file. You don't have like pull request templates. You don't have issue templates. If you wanted to go through the checklist and add those kinds of things, then it would make it easier for people to make contributions. And we also have this sense of um we gave a talk recently internally about like is your project really open source if you don't accept poll requests from the outside world? And that's a really interesting question. Uh in the OSBO, our guidance is sort of like open source is a journey, right? So it starts with making your repository public, right? So if you have a public repo and you're working in the open, then yes, you are open source. Then you should start to accept issues and take feedback from the community. And then once you start accepting feedback from the community, then you can start accept contributions from the community. And then once you start accepting contributions from the community, you can start to accept maintainers from the community. And then once you start accepting maintainers, eventually you can accept people into your governance process. So we see that as sort of a a longitudinal journey at each layer of maturity. And we think we can help people depending on what their goal is to get to each of those hubs along the contributor's path. And we have made it more clear with the maturity model framework like what parts of what docs need to be where. Um it has been relatively straightforward to do the the tier zero through tier 2 because it's like that is a lot less specialized. It's like hey you should have issue templates, you should have pull request templates. You should have a contributor process. Like it's easy to say like and here are some that we recommend. But when you get into the higher tiers of like shared community governance or working in public, that's where the like one-sizefits-all uh guidance doesn't necessarily work as well. And you need the communities to opt in with their own things. So some communities are very like inner source style driven where they have timed releases and they go through like specific kinds of backlog grooming and like all that stuff is very particular to their project and should be reflected in their path of growth versus like something that's more of like a classic open source project that goes off of feature releases or doesn't have a very formal dev team or is very widely distributed would look very different. So, we don't have as much tier 4 guidance as we do for like tier one or tier 2. So, we're filling in some of those gaps now, too. Um but all of this stuff is um you know NAT has been incredible and driving so much of it and putting together so much of the tools and they all build on the layers of documentation from the maturity models and the the repository scaffolder work and it's sort of putting it into place and we're starting to consider you know getting that back up into the Cass community because we've been leaning on so much of the metrics work here. >> Awesome. Thank you. >> That's great. Thank you. There was a side topic. I know we're getting close to the end, but >> yeah, Ria, what's your side topic? >> So, you had mentioned that part of your motivation, Don, for doing this was all of the GitHub repos that you were managing as part of VMware back in the day that there's a hundred GitHub repos from various acquisitions and projects and spin-offs and everything else. And I have a similar situation now. I've been just trying to figure out how to corral all of those. and I have index files and traffic cop files that you know so I can just have a one-stop shop to know where everything is. But I'm wondering if this group has experience or suggestions about doing that type of coraling to give a better face to the public so they know where to find stuff. Is that a yes, you do have advice or yes, you resemble that comment that you would like advice, Remy? >> I've been doing a lot of talking, so I was going to give somebody else a chance before I started again, but I definitely have answered for this. >> Um, so >> in government land, we have code.json, JSON, which is the metadata file that gathers up a lot of the information about what a project is and and what it does and what its purpose is and where it is in its development life cycle. And then that is supposed to go to an inventory on code.gov where people can search through and find pre-existing repositories while they're doing their market analysis before they build or buy something. >> That was the intention. Oh, >> it's still uneven amounts of adoption is uh how I would describe it. >> But um that's how it is in the federal landscape. >> In the international landscape, in the national landscape, um you have like code inventories from Germany and the Netherlands and France where they are using a similar metadata file to code.json, but it's probably like public code.yamel or code meta.json. So if you can go through, >> add a metadata file for each repository and then get it uploaded into an inventory. That's how the national governments are doing it and that's how uh the international project for software heritage foundation where they're cataloging all of Earth's source code >> as a UNESCO cultural heritage project. Uh they use code meta JSON to do that and they have forms for generating it and they have some other tools around it too. So, you know, we're hoping that part of our archival process on our road map is to create a converter that will take our federal standard metadata, convert it to the international standard, and ideally deposit it into the software heritage. But that's perspective future work. Shouldn't talk too much about that until we've shipped it. But those are some of the ways that we're thinking about uh that to your question like how do we keep track of all this stuff? If you add metadata to every repository at least then you can compare apples to apples and you can use that to update your inventory and then provide an inventory >> even if it's just like >> you know a simple web page that just puts everything together which is you know what we've done with our fork of >> it sounds like that could also be really helpful from an inner source perspective for the stuff that you're not necessarily putting out in the public but just to help your own organization find all the Oh, 100%. And like even just simple keyword and labeling stuff is great if you're like this is a data science thing or this is a Python thing or this is a Java thing. Like >> that alone really helps out especially in like the government space where we have different programs like Medicare or Medicaid. People will ask like hey does anyone have a Python project that will crunch this stat for this state? And being able to say, "Yeah, I think there's a repo over here that does that can really helps to save a lot of time." Uh, and ideally, if you have like example scripts or, you know, libraries inside the the firewall is just as important because, you know, we have all these tools that are common, the the R and the CCW and, you know, random acronym, but they're just like data sources where you can run scripts that are shared. And I know that those folks are looking to say, "Hey, I want to provide an inventory to other people so that they can run their scripts." It's not even necessarily like a whole projects. It's just like playbooks and and um run books and stuff like that. That is super helpful in the inner source context. >> Yeah. And the other thing the other thing we had within within VMware was we had some internal tooling that we would onboard at least the most important organizations to so that we could better manage things like access so people could request access to things. And so there was there was a bunch of internal tooling that did various bits of maintenance around some of the um GitHub or so. So I don't I don't know that's necessarily the best solution, but it is it is a another another way to do it. All right, we are we have one more minute. So, I'm just going to mention a couple of things. So, the next meeting which is on the 5th. Um, so there's that uh working group within the to-do group that's focused on basically business of open source. Um, and they're going to come in and talk to us a little bit about what they've been doing and some of the uh metrics that they've been talking about and maybe get some suggestions from us about uh metrics as well from a kind of a business value standpoint. Um, and Cornelius Schumacher is going to give that presentation. So, that'll be on the 5th. We will also schedule a what do I supposas need to be thinking about for AI? So, I've talked to Emma, she's happy to do that. We just need to get it to get it scheduled. And then the other things I wanted to mention, we have two conferences that have just opened their CFPs. One is uh the ASF's community over code. Um all things open also opened their CFP. They've got kind of a different format this year. So I would encourage you to have a look at that. And then there's also I think you talked about it uh at the last meeting that I missed, but there's an OSPO virtual conference that uh folks at Punch Tape are organizing. So that might also be interesting for folks. And with that, I think we are I think we're out of time. So, thank you everybody so much for coming. Uh, I really appreciate it. This was a really really interesting discussion. So, thanks to folks at the the CMS group, Natalyia and Remy, for for coming along and showing us some cool stuff. >> Thank you. >> Thanks everybody. Bye. >> Bye. >> Bye. >> Bye., CHAOSS OSPO WG, Feb 19 2026, YouTube, 01kp8hayp00ttvzb62zx8sbp55.