Episode 123: Practitioner Guides: #6 Sunsetting an Open Source Project  ## Metadata - Author: [[CHAOSScast]] - Full Title: Episode 123: Practitioner Guides: #6 Sunsetting an Open Source Project - Category: #podcasts - URL: https://share.snipd.com/episode/ccfbb55f-3f53-410a-9778-fabb7a3dfd66 ## Document Notes > [!note]+ Document Notes > tags: [open-source, project-management, ospo] > author: CHAOSS Community > source: YouTube > reference: https://www.youtube.com/watch?v=k2pscF2VA9o > date created: 2024-12-19 16:30 > > # 🏷️ Title: Episode 123: Practitioner Guides: #6 Sunsetting an Open Source Project > <!-- deep-read:sections start --> ## 🧰 Action Inbox - [H1] Review organization's inactive projects for security risks — OSPO teams #security - [H2] Implement proactive sunset communication plan — project maintainers #communication - [H3] Create unarchiving process documentation — OSPO teams #process ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [CHAOSS Practitioner Guides](https://chaoss.community/practitioner-guides) - [Sunsetting Open Source Projects Guide](https://chaoss.community/) ## 📝 Summary - CHAOSS Community discusses their practitioner guide for responsibly sunsetting open source projects - Why it matters: Abandoned projects create security vulnerabilities and reputational risks for organizations - Key stakeholders: OSPOs, project maintainers, community managers, and organizations managing open source projects - Risks and tradeoffs: Balance between maintaining inactive projects vs. properly archiving them with community impact - Bottom line takeaway: Proactive, communicative sunsetting processes protect both organizations and communities ## 📖 Main Content The CHAOSS Community has developed practitioner guides to help people move beyond overwhelming metric dashboards to actionable project health improvements. This episode focuses on their guide for sunsetting open source projects responsibly. The guide addresses a critical problem: organizations often leave inactive projects unarchived, creating security vulnerabilities and leveraging organizational trust inappropriately. The sunsetting process involves three key metrics for identifying candidates: change requests (pull/merge requests), new issues (indicating usage), and technical forks (showing continued interest). However, the technical identification is just the beginning - responsible sunsetting requires extensive communication, stakeholder outreach, dependency checking, and planning for potential future unarchiving. The guide emerged from real-world experience at VMware, where Stefka Dimitrova led a comprehensive sunsetting program. Their approach treats project sunsetting as a natural lifecycle phase rather than failure, emphasizing proactive decision-making while projects still have active maintainers rather than waiting until abandonment occurs. ## 🗒️ Notes #### ⏱️ [00:02:15](https://www.youtube.com/watch?v=k2pscF2VA9o?t=135) — [H1] Practitioner Guide Series Overview - Key idea: CHAOSS moved from overwhelming metric walls to actionable guidance for practitioners - Evidence: "The goal of these guides is really to help people interpret the data about their open source project. But more than interpreting the data, it's about how they can improve the health of open source projects" #### ⏱️ [00:04:30](https://www.youtube.com/watch?v=k2pscF2VA9o?t=270) — [H2] Security Risk of Abandoned Projects - Key idea: Inactive projects create security vulnerabilities that exploit organizational trust - Evidence: "People will tend to trust the projects that are in organizations like GitHub organizations for big companies even though they may not be updated" #### ⏱️ [00:06:45](https://www.youtube.com/watch?v=k2pscF2VA9o?t=405) — [H3] Stefka's Background and Motivation - Key idea: Financial background brought risk-focused perspective to open source project management - Evidence: "My background before that was in finance and economics. So I was really practical about considering really risks" #### ⏱️ [00:08:20](https://www.youtube.com/watch?v=k2pscF2VA9o?t=500) — [H1] Project Lifecycle Philosophy - Key idea: Sunsetting is natural lifecycle phase, not failure - Evidence: "It's part of a life cycle of a project... as there is the sunrise and the initiation of things there is the sunset and it's not good or bad" #### ⏱️ [00:10:15](https://www.youtube.com/watch?v=k2pscF2VA9o?t=615) — [H2] Three Key Metrics for Identification - Key idea: Change requests, new issues, and technical forks indicate project activity and usage - Evidence: "Change requests... basic idea of developer activity... new issues helps us look at usage... technical forks also gets a usage" #### ⏱️ [00:12:30](https://www.youtube.com/watch?v=k2pscF2VA9o?t=750) — [H3] Release Activity as Additional Indicator - Key idea: Continuing releases, especially with security updates, indicate non-abandoned projects - Evidence: "If they're continuing to make new releases with security updates, for example, then the project might not be abandoned" #### ⏱️ [00:14:45](https://www.youtube.com/watch?v=k2pscF2VA9o?t=885) — [H1] Communication-First Approach - Key idea: Extensive stakeholder communication before archiving prevents community disruption - Evidence: "Communication is really important... any kind of announcements that can be made in the readme and any other related docs to the project to give people or give the community ahead of time to prepare" #### ⏱️ [00:16:20](https://www.youtube.com/watch?v=k2pscF2VA9o?t=980) — [H2] Dependency Analysis Critical - Key idea: Must check and communicate with projects dependent on the sunsetting repository - Evidence: "Check on dependencies that other project has on this repo. It's also crucial so that again be able to reach out communicate properly to people" #### ⏱️ [00:18:10](https://www.youtube.com/watch?v=k2pscF2VA9o?t=1090) — [H3] Active Projects Can Proactively Sunset - Key idea: Better to sunset while project is still active rather than after abandonment - Evidence: "It's much better to decide it when it's still active rather than decide it when it's already gone" #### ⏱️ [00:20:25](https://www.youtube.com/watch?v=k2pscF2VA9o?t=1225) — [H1] Corporate Complexity Considerations - Key idea: Company projects with customers require additional planning and PR involvement - Evidence: "This process gets a little bit more tricky within companies, especially if you have customers that are using this project" #### ⏱️ [00:22:40](https://www.youtube.com/watch?v=k2pscF2VA9o?t=1360) — [H2] Unarchiving Process Reduces Decision Anxiety - Key idea: Having documented unarchiving process helps teams commit to archiving decisions - Evidence: "Stefka also had a really well documented process for unariving projects so people knew that if they decided later that they really wanted to have the project that we had a process for bringing it back" #### ⏱️ [00:24:15](https://www.youtube.com/watch?v=k2pscF2VA9o?t=1455) — [H3] Emotional Support for Maintainers - Key idea: Acknowledging emotional attachment to projects helps maintainers through sunsetting process - Evidence: "It's hard to let something go that you've already worked on it you spent so many hours in it... managing people's emotions as well as their expectations is also super important" #### ⏱️ [00:26:30](https://www.youtube.com/watch?v=k2pscF2VA9o?t=1590) — [H1] Plan for Sunset at Project Creation - Key idea: Teams should consider sunsetting processes when starting projects, not when crisis hits - Evidence: "Be ready for the sunset already when you start the project. Don't think of it when it's about time, but really on creation of a project... keep that in mind" ## 📚 References - [CHAOSS Community](https://chaoss.community/) - [CHAOSS Practitioner Guides](https://chaoss.community/practitioner-guides/) - [Chaos Cast Podcast](https://podcast.chaoss.community/) ## 🗣️ Paraphrase - Organizations need systematic approaches to sunset inactive open source projects because abandoned projects create security vulnerabilities and exploit organizational reputation - The identification process uses three key metrics (change requests, issues, forks) but the real work involves extensive stakeholder communication and dependency analysis before archiving - Proactive sunsetting while projects are still active is preferable to reactive archiving after abandonment, and having unarchiving processes reduces decision anxiety for maintainers ## 📰 Newsletter The CHAOSS Community has released valuable guidance for one of the most challenging aspects of open source project management: responsibly sunsetting projects. Their practitioner guide addresses the security and reputational risks that abandoned projects pose to organizations. Key insights include using change requests, new issues, and forks as activity indicators, but the real value lies in their communication-first approach. The guide emphasizes stakeholder outreach, dependency analysis, and even planning for potential unarchiving to support teams through the emotional process of letting go of their work. For OSPOs and project maintainers, this represents a shift from reactive abandonment to proactive lifecycle management. Consider implementing these processes before you need them - your future self will thank you. Resources: [CHAOSS Practitioner Guides](https://chaoss.community/practitioner-guides/), [Chaos Cast Podcast](https://podcast.chaoss.community/), [CHAOSS Community](https://chaoss.community/) ## ✅ Action Items #### OSPO - Policy & Governance: Develop organizational sunsetting policies and approval workflows - Security Management: Regular audits of inactive projects for vulnerability assessments - Software Inventory: Maintain SBOM tracking for sunset candidates and dependencies - Developer Support: Training on responsible archiving processes and emotional support - Community Engagement: Stakeholder communication templates and escalation procedures #### Community - Maintainers: Implement proactive sunset planning in project governance documentation - Contributors: Create pathways for adoption of sunsetting projects by interested parties - Sponsors: Establish funding mechanisms for responsible project transitions #### WordPress - Meta: Develop sunset processes for WordPress.org hosted projects and plugins - Plugins: Create review processes for identifying and handling abandoned plugins - Themes: Implement sunset communication for theme directory projects - CLI: Consider sunset pathways for deprecated WP-CLI commands and packages ## 🧪 Hypotheses - Organizations with formal sunsetting processes experience fewer security incidents from abandoned projects - Projects that undergo proactive sunsetting have higher rates of successful adoption by new maintainers - Companies that communicate project sunsets transparently maintain stronger developer community trust - OSPO teams with documented unarchiving processes make faster archiving decisions ### 📊 Methodology - Longitudinal study comparing security incident rates between organizations with and without formal sunsetting processes - Survey analysis of maintainer emotional well-being and decision-making speed when unarchiving options are available - Case study analysis of successful project adoptions following responsible sunset processes ### ❓ Questions - How do different communication channels affect community response to project sunset announcements? - What metrics best predict successful project adoption during sunset processes? - How can OSPOs balance automation with human judgment in identifying sunset candidates? ### 🔮 Future Research - Development of automated dependency impact analysis for sunset candidates - Study of legal and compliance considerations in corporate project sunsetting - Investigation of cross-ecosystem project adoption patterns during sunsets ### 💡 Implications - Practice: OSPOs need dedicated resources for project lifecycle management beyond creation - Policy: Organizations require formal policies balancing innovation encouragement with responsible archiving - Security: Proactive sunsetting becomes critical component of organizational security posture - Education: Maintainer training should include project lifecycle management and emotional preparation - Funding: Budget allocation needed for responsible sunset processes, not just project initiation ### 🧠 Learning Styles Assessment Reading level estimate: 12th Grade #### 👀 Visual learners - Present: Process flow descriptions, metric identification frameworks - Improve: Decision trees for sunset candidates, communication timeline visuals, stakeholder mapping diagrams #### 🔊 Aural learners - Present: Podcast format with expert discussion and real-world examples - Improve: Audio summaries of key process steps, recorded stakeholder conversation templates #### 🗣️ Verbal learners - Present: Clear definitions of terms, analogies to natural lifecycles, examples from VMware experience - Improve: Glossary of sunset terminology, comparison tables of different sunset approaches #### 🧩 Kinesthetic learners - Present: Step-by-step process descriptions, actionable checklists implied - Improve: Interactive sunset assessment tools, hands-on workshops, template repositories #### 🧠 Logical learners - Present: Risk-based decision framework, metrics-driven identification process - Improve: Decision matrices, cost-benefit analysis templates, ROI calculations for sunset processes #### 🧑‍🤝‍🧑 Social learners - Present: Community discussion format, stakeholder communication emphasis - Improve: Peer review processes for sunset decisions, community feedback mechanisms, collaborative assessment tools #### 🧘‍♀️ Solitary learners - Present: Self-contained guide format, individual reflection opportunities - Improve: Self-assessment questionnaires, private decision-making frameworks, individual planning templates #### 🌿 Naturalistic learners - Present: Lifecycle analogies, sunset/sunrise metaphors, natural process comparisons - Improve: Seasonal planning approaches, ecosystem impact assessments, environmental sustainability considerations ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure in guide format, descriptive content organization - Improve: Enhanced alt text for process diagrams, ARIA labels for interactive elements #### Keyboard navigation - Present: Standard web navigation for guide access - Improve: Keyboard shortcuts for guide sections, skip links for long process descriptions #### Contrast and readability - Present: Standard text presentation meets basic contrast requirements - Improve: High contrast mode support, adjustable text sizing for technical documentation #### Text resizing and reflow - Present: Responsive guide layout supports basic resizing - Improve: Enhanced reflow for complex process descriptions, mobile-optimized technical content #### Media and captions - Present: Podcast includes transcript, audio content accessible - Improve: Chapter markers for podcast sections, downloadable transcript with timestamps #### Forms and interactions - Present: Basic guide interaction patterns - Improve: Accessible sunset assessment forms, screen reader-compatible checklists ### 🌍 DEIB Assessment #### Cultural breadth - Present: Global open source perspective, international community examples from Spain - Improve: Multi-regional case studies, localized communication templates, cultural considerations in sunsetting #### Inclusive language - Present: Professional, neutral terminology, avoids technical jargon appropriately - Improve: Plain language summaries, multilingual guide versions, cultural communication guidance #### Neurodiversity support - Present: Structured process approach, clear step-by-step guidance - Improve: Multiple information processing formats, flexible timeline accommodations, stress-reduction strategies #### Representation - Present: Diverse panel with varied professional backgrounds, female technical leadership - Improve: Broader representation across organizational sizes, geographic diversity, role diversity #### Psychological safety - Present: Acknowledgment of emotional aspects of sunsetting, supportive framing - Improve: Mental health resources for maintainers, community support networks, grief counseling considerations ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Strong logical progression from security risk identification to systematic mitigation - Inductive strength: Well-supported generalizations from VMware case study to broader applicability - Causal reasoning: Clear causal links between abandoned projects and security vulnerabilities - Analogical strength: Effective use of natural lifecycle analogies to normalize sunsetting process #### Fallacies - Appeal to emotion: Use of natural lifecycle metaphors could oversim <!-- deep-read:sections end --> ## Highlights - **Use Practitioner Guides To Act** - Use practitioner guides to interpret metrics and take concrete actions to improve project health. - Focus on practical how-tos and steps, not just dashboards of metrics. Transcript: Dawn Foster Absolutely. So one of the things that we've realized in the Chaos Project over the years is that we have historically given people big lists of metrics. We've given them software that displays a wall of visualizations for just about any metric you can possibly think of. What we found was that that was a bit overwhelming for a lot of people. So the practitioner guides are designed to be used by people who are more on the practitioner side. So not necessarily experts in open source, maybe not even experts in metrics. But the goal of these guides is really to help people interpret the data about their open source project. But more than interpreting the data, it's about how they can improve the health of open source projects and how they can make their engagements in open source even better. What I think is the magic in these practitioner guides is that they go so far beyond the metrics and really focus on actions that people can take and how to's and what people can do to make Their open source projects even better. ([Time 0:02:37](https://share.snipd.com/snip/df1457a4-abf0-4048-a9cd-51c14a047b49)) - **Inactive Projects Create Real Risk** - Unarchived inactive projects create real security and reputational risks for organizations. - Treat sunsetting as a responsible lifecycle step, not just deletion or neglect. Transcript: Dawn Foster So one of the things that in particular a lot of OSFOs spend time on is thinking about projects that are inactive within their organizations. So the problem with just leaving projects unarchived or not going through a sunsetting process is that projects get old. They have security vulnerabilities. And especially if you're a part of a company, people will tend to trust the projects that are in your organization based on really kind of the brand reputation that you have as an organization. So leaving these inactive projects unarchived creates security vulnerabilities for your customers, for the people who trust you as an organization. So it's something that I see as problematic for open source program offices. And so it's something that we talk about a lot in the Chaos OSPO working group as well, about security and unarchived projects. So this got me thinking about the work that Stefka and I had done when we were at VMware, mostly Stefka, because she ran the project to do this. ([Time 0:04:59](https://share.snipd.com/snip/40813706-b007-4aa3-99e6-de3daf061661)) - **VMware Experience Sparked Sunsetting Work** - Stefka built VMware's sunsetting program after noticing projects with unreachable original contributors and risk exposure. - She framed sunsetting as a natural lifecycle phase and designed processes to address it responsibly. Transcript: Stefka Dimitrova And as Don mentioned, some of the main reasons and importance of having it related to risk. I'll just start with a little bit of my background because I've been working in IT companies for more than 10 years, but my background before that was in finance and economics. So I was really practical about that, practical and considering really risks as we all do. Starting with or thinking about getting to know the open source projects within VMware at that point, I get to observe that it's hardly to reach to some of the initial contributors or People who originated the project. And it got me into thinking of all the risks that are related to that some project might have been abundant or might not have the resources anymore to maintain that project. And this is, in a way, I started thinking about that program together, which, you know, consulted many of my colleagues as well. But in a way got into the direction of, okay, how we could be aware of that in the meantime. Search for names or search for reasons for some projects to not be active anymore, but really be able to proactively discuss with people and with maintainers and to see is this phase Approaching? Because that's also the reason to decide to call it this program, because I called the program Sunsetting Project and also Kit in order because it's part of a cycle. I'm really related to nature. Some of my hobbies are related to mountaineering. So I see it part of a life cycle of a project life cycle of many things that we do. ([Time 0:07:42](https://share.snipd.com/snip/6643880e-a34f-4618-9b43-133d4ba04651)) - **Three Metrics To Spot Abandonment** - Measure change requests, new issues, and technical forks to judge project activity and usage. - Reach out to active forkers or issue authors before deciding to sunset. Transcript: Harmony Elendu Why did you decide to focus on these three metrics? Dawn Foster Yeah, absolutely. So change requests, that includes pull requests on GitHub, merge requests on GitLab. And that's sort of a basic idea of developer activity. So whether there are any new changes coming about within the code base. So that can help us determine whether people are still making updates to the software itself. New issues helps us look at usage because if people are still using this project, the code in this repository, you'll probably see users posting new issues where maybe they found a bug Or they want a new feature or make some kind of request of the project. So new issues gets kind of at usage. And technical forks also gets that usage because it shows people that have forked the repository, which usually means that if they forked a repository and they're continuing to use It and update it, that probably means that they're continuing to use the project or intending to contribute to it. ([Time 0:10:40](https://share.snipd.com/snip/2c4a0993-912c-409a-9793-039483b27788)) - **Communicate And Offer Handoffs** - Communicate early and widely before archiving: update README, announce on project channels, and contact dependents. - Offer transfer options or maintenance handoff opportunities to users who still rely on the project. Transcript: Stefka Dimitrova Hopefully not just click archive. Yeah, we talked about what can help us take this decision. And again, I would focus that it's not easy to take the decision and who takes the decision. So this is a longer step. So it takes time. Many people need to be involved, whether it's within a company, within a community, for sure as well. But yeah, given that, okay, everyone agreed that this is the logical phase that we are in. And now it's about to sunset the project to archive the project. There are necessary steps to be taken before to clicking the archive button so communication is really important. Like for example any kind of announcements that can be made during the readme and any other related docs to the project to give people, give the community ahead of time to prepare for That. Or in this case, also offer someone who is really using or dependent on this project to maybe decide to start maintaining and owning the project. So this communication ahead of time will help people be prepared for the next step. So it, as I said, it could be any channels, communication channels as a project is on, besides the readme documentation as well. And also to check on dependencies that other projects have on this repo. It's also crucial so that again, be able to reach out, communicate properly to people that what's going on. And then the archive itself, it's not the ending point because you may be ready to archive. If I said there is a willingness or opportunity by someone else to become a project and to continue working in it, that might be a possibility as well. But in order to allow this possibility, there needs to be a proper communication and contact about that. So that any documentation is updated as well. ([Time 0:13:20](https://share.snipd.com/snip/aafe53b2-ca42-42a0-a7e4-8ef06f944cbb)) - **Sunset Proactively While Active** - Sunsetting is easier and more responsible when done while a project is still active. - Active winding down allows time to plan replacements, communicate, and support customers. Transcript: Stefka Dimitrova Can start and maybe Don, you can add it as well. Maybe this is the thing that I mentioned about taking the decision and making the decision. So here, when the project is still active, I think that's the proper time to decide, to weigh down. It's much better to decide it when it's still active rather than decide it when it's already gone. So it means the time to really consider priorities, consider where you're going with this project because it might have been a great idea some years ago, but not the best way to spend Your time and energy right now. It's just that because the project is still active, you have enough time and hopefully bandwidth to prepare for that, to communicate it properly, to find a replacing project maybe. So, yeah, it's going through this process, but then you go through the process more proactively. Yeah, absolutely. Dawn Foster And just to add to this, I think this process gets a little bit more tricky within companies, especially if you have customers that are using this project. You really need to have a good plan where, as Stefka mentioned, you know, maybe there are some substitutes that people can use, some replacement technologies or other options. Maybe someone else wants to continue the project. And you really have to look at that, I think, in a more detailed way if you're working within a company and probably getting things like your public relations team involved if you think That there might be some backlash. But it's really, I think, all about timing and having a responsible plan that you can communicate to all of the people who are using the software. ([Time 0:16:25](https://share.snipd.com/snip/419bb9df-a58d-452b-851c-9aabd6914d6d)) - **Give Teams Clear Next Steps** - Use sunsetting guidelines as decision aids so teams can see concrete next steps and timelines. - Help teams decide sooner or defer appropriately based on clear actions required. Transcript: Alice Sowerby And so maybe work with their OSPO, or if they don't have an OSPO, work with their community. Or work with their OSPO and their community, preferably. Stefka Dimitrova So maybe I can add an example. Yeah, go ahead. Because I've worked on such cases and it was really helpful for the teams to have these steps and these guidelines because they were considering that they weren't sure yet where the Project was going. And they wanted some help. So they were like, if we decide to sunset our project, what should be our next step so that we know when is best to take this decision based on the timeline that we have and based to customers, Et cetera. So it was really useful for me as a person in the hospital to be able to help other teams to take this decision. So part of taking this decision was that they see clearly what are the next steps and what they need to do. ([Time 0:18:38](https://share.snipd.com/snip/ba25ed22-7890-4d80-a524-6824c2aa61af)) - **Offer A Clear Unarchive Path** - Provide a clear unarchiving process so teams feel safe to archive proactively. - Use that safety net to help maintainers accept sunsetting when it's time. Transcript: Dawn Foster I'll just add one thing. One of the things that I think really helped the process was that Stefka also had a really well-documented process for unarchiving projects. So people knew that if they decided later that they really wanted to have the project, that we had a process for bringing it back if they needed it. So I think that helped a lot of teams get over the, oh, but I don't want to archive my project because maybe I'm going to want it in the future. And this gave them an opportunity to bring it back in the future if we needed it. Although I'm not sure that anyone ever did. Stefka Dimitrova I'm not sure also, but it really helped because it was so hard to take the decision to archive team. But as soon as I offered them this opportunity, a possibility and said, okay, you have the clear steps, you need just to follow this and that, we need to be sure that you can follow this And that, and then you archive them. Then it was much, much easier. ([Time 0:19:52](https://share.snipd.com/snip/694d2561-d71f-4454-95bd-ffd185d23025))