Not every open source software project can or should live on forever: priorities change, technologies evolve, and interests shift over time. From a corporate perspective, you don’t want to have neglected or abandoned open source projects with security vulnerabilities owned by your organization. However, responsibly sunsetting an open source project is more than just clicking the archive button on your repository. You should also be thinking about how you communicate the change and give any existing users time to transition.
Your organization’s customers and the users of your open source projects might trust the projects found in your repositories because of their relationship with your organization. This is why it’s particularly important for companies to monitor the open source projects owned by the organization and responsibly sunset them when they will no longer be updated. One of the benefits of having an OSPO is that they can help the rest of the organization with processes and best practices for responsibly sunsetting projects.
When I worked in VMware’s OSPO, we had a process for monitoring and sunsetting projects that we’ve documented in the CHAOSS Practitioner Guide: Getting Started with Sunsetting an Open Source Project. This guide uses change requests, new issues, and forks as metrics that can help you identify abandoned or neglected projects along with people who might still be using those projects. The guide also has communication steps for what to do before you archive the project, and there is even a section with special considerations for sunsetting active projects, which can happen when a company is making a shift in strategy and no longer plans to work on a project.
All of these details can be found in the guide, and you can also listen to the CHAOSScast podcast episode where Stefka Dimitrova and I recently discussed the guide and the process we used at VMware. Here’s a short quote from the guide:
“Many open source projects, even widely used ones, become abandoned for a variety of reasons (e.g., evolving interests, family situations, employment changes), but abandonment can be done in a responsible way by proactively sunsetting the project (Miller et al. 2025). Sunsetting is an important consideration for corporate environments where it can be easy to lose track of projects that were created by employees who later walked away from the project and left if abandoned. You don’t want abandoned open source projects with security vulnerabilities sitting in your organization’s source code repositories where someone might trust that project simply because they trust your organization. Finding inactive projects and responsibly sunsetting them is a good business decision and something that many open source teams / Open Source Program Offices (OSPOs) do on a regular basis.”
Stefka Dimitrova on When and How to Deprecate an Open Source Project (Part 1 and Part 2) along with a video from the Open Source Summit in Europe in 2022 about Simple Steps for a Calm “Sunset”.
I had the pleasure of attending (and helping organize) the very first Digital Resilience Forum in Madrid, Spain this week where industry leaders, policy makers, governments, and others discussed and collaborated on ways to make our digital infrastructure more sustainable and resilient. Daniel Izquierdo, CEO, Bitergia kicked off the day by talking about how software runs everything and we need to improve the resilience of that software. We always talk about the problems, but this event is focused on sharing how we’re learning and solving the problem of digital resiliency across politics, academia, and industry. Open source allows us to collaborate while increasing digital sovereignty to have more control over our software and infrastructure. Resilience and technological independence is possible if we collaborate and work together using open source software.
“Digital resilience is key for the success of our software-driven digital societies”
The first keynote was from Omar Mohsine, OSS Coordinator, United Nations titled “UN Development Goals: Making Digital Public Infrastructure more Resilient” where he started by talking about the UN Sustainable Development Goals (SDGs). Open source offers us transparency, security, cost-efficiency, sustainability, innovation, and community, and we need technology experts from within our open source communities to help us achieve the UN SDGs. The Global Digital Compact sets out a path toward advancing an open, free, secure, and human centered technology. The UN has 8 open source principles, including open by default, contributing back, and more that were designed for the UN, but now many others have also endorsed them. The UN doesn’t have the funding or resources to achieve all of this on their own, so the rest of us within open source communities need to help by working together. The UN Open Source week is one way to bring all of us together. I attended this event last year, and I’m looking forward to the next one on June 22 – 26, 2026.
John Ellis, President and Head of Product, Codethink had the next keynote, “Why do you trust software? I don’t. (And Why That Matters for Digital Resilience)” where he talked about how software can break the world creating real failures across industries (e.g., recent AWS outage, SolarWinds). Security theater gives us an appearance of security without it actually being secure. We have a trust gap – we built our digital world on speed and features, rather than trust and resilience. The Eclipse TSF (Trustable Software Framework) is designed as a structured path to trustable software with reproducibility, SPDX manifests, zero-trust build pipelines, and automated supply chain traceability along with a FICO-style score for software trust to compare, identify, and underwrite the risks associated with software. This crosses over to make the CRA tangible and help people comply with the CRA. He concluded by saying that we don’t need perfect software, we just need trusted software.
Next up, we had Adriana Groh, CEO, Sovereign Tech Agency (STA) talking about “The Engine Room for Digital Sovereignty”. The STA is focused on solutions to secure and strengthen the open source ecosystem. We have an invisible problem – it may be visible to those of us in the tech industry, but it isn’t to governments and policy makers. Software infrastructure is often overlooked until it breaks, and this invisible problem is how they convinced the German government to fund infrastructure maintenance as part of their digital sovereignty efforts. Digital infrastructure is fragile, but open technologies are the foundation of the modern economy. However, until recently there has been a lack of public investment. This led to the creation of the STA, which is one piece of the puzzle to make sure that OSS continues to be sustainable. They have made 87 investments and over 32 million euros in work commissioned along with a bug bounty program with 32 critical technologies strengthened and over 175 vulnerabilities found. They added a fellowship program with 6 fellows in the 2025 pilot cohort of key maintainers working on multiple open source projects. This isn’t charity – it provides a return on investment to prevent this infrastructure from crumbling while also increasing GDP. They are training a new muscle for the government to encourage them to think of open source infrastructure as something that needs support as a public service in the public interest. Innovation and maintenance are 2 sides of the same coin and you need to support both for long term resilience and sovereignty.
Amanda Brock, CEO, OpenUK and Executive Producer State of Open Con was our next keynote with a talk titled “Digital Sovereignty and Other Fables”. OpenUK is focused on developing UK leadership and global collaboration in open technology. The open source community is the submarine under the UK’s digital economy because we do so much in open technologies as part of global collaboration that people don’t really notice. Amanda talked about her background in law and how she realized that the open source community was her tribe when she worked at Canonical. She melded her love of open source with her background in law when she edited Open Source Law, Policy and Practice (available as open access for free). For her, open source is about global collaboration that includes everyone. The UN principles that Omar talked about take the concept that anyone can use it for any purpose and builds on it. A geopolitical shift has been happening with Brexit being one part of it, and OpenUK was created in part because the UK was being excluded from EU efforts. Digital sovereignty refers to the ability to have control over your own destiny across the data, hardware, and software that you rely on. In the UK, sovereignty is discussed as not being isolationist, but as being collaborative. We need to bring together the best innovation, intelligence, and collaboration to serve our own countries, but we can build this through global collaboration. You need open source as part of a sovereignty strategy, but these projects are built via global collaboration, not as isolated projects. She concluded by saying that open source is not local source, it’s a global collaboration.
The final keynote came from Tanu Sahnan, Head of Software Engineering, BBC talking about “The Digital History of the BBC”. England’s world cup opener in Nov 2022 was the moment that tested the BBC, but resilience isn’t about surviving a crisis, it’s about learning and improving. The BBC values include trust, and the BBC has a public service mission, so they build in-house using open source for digital sovereignty with innovation, ethics, and inclusion while scaling to millions of daily users with a global impact. The BBC uses a responsible, trusted and human-centered approach to AI with efficiency, new capabilities, and trust / responsibility, not about chasing AI trends.
We also had a number of very interesting panels and workshops, including the one that Ana Jiménez Santamaría and I led titled “Kick-starting your OSPO: a practical approach”. I’m only covering the keynotes in detail here because there was just too much amazing content to include all of it, but you’re in luck because pictures and videos from the day should be available soon on the Digital Resilience Forum website.
The topic of viability and risk is one that’s near and dear to my heart, and is something that I’ve been talking and speaking about for the past 5 years going back to when I was at VMware where it was an important consideration for our Open Source Program Office.
Open source software is found in almost every codebase, but some open source projects are more viable than others over the long term. Many companies don’t have a rigorous process for selecting the most viable dependencies. Often product teams, or even individual software developers, select open source projects because they fill a particular technical need without any assessment of the viability of the project or the risks they might be taking by using it. Assessing the viability of open source projects, especially ones that have the potential to impact your business, is a good first step toward managing risk and reducing the chances of potential business disruptions.
Here’s a short quote from the guide:
“Most business decisions boil down to an assessment of risk and making tradeoffs. Organizations should be thinking strategically about project risks in light of how they are using the projects. If it’s a critical part of a technology stack, it should be as low of a risk as possible. On the other hand, if an open source project is used as a small part of some non-critical infrastructure, an organization can accept more risk. Assessing viability and thinking about it from the perspective of risk and which risks to accept is an important first step, but it’s also important to think about which risks can be mitigated to improve viability. The best way to mitigate many of these risks is by paying employees to contribute to the projects that are most important to your organization. This provides an opportunity to improve viability and sustainability, but it also provides insight into where the project is heading and how things are going, so that if something changes in the project to further increase risk, it might be easier to anticipate those changes.”
This guide provides advice for assessing viability across four categories: compliance and security, governance, community, and strategy. Depending on your use case, you may find different opportunities to use this viability assessment framework and how you use it will vary based on your organization’s assumption of risk. I hope you enjoy this guide and the others in the CHAOSS Practitioner Guide series!
I’ve been spending quite a bit of time recently thinking and writing about open source project governance, so I was thrilled to be invited to participate in the Turing Way fireside chat about governance along with Clare Dillon and Richard Littauer! The three of us have very different backgrounds and experiences, so we were able to cover a range of different perspectives on open source governance.
We talked about some of the challenges, including how difficult it can be to make governance changes, since changes involve people with feelings and opinions that will be difficult to reconcile. We encouraged people to use existing resources, like templates and examples from other projects, rather than starting from scratch, and to reach out to get advice from experts who have experience with governance, since governance is complex with nuances and best practices that may not be obvious. We discussed the importance of having a way to remove people from your open source projects that is clearly documented, even when you hope to never need it. These are just a few of the topics we covered, so I encourage you to watch the video to learn more.
This fireside chat was the 5th in a series about governance, so you might also enjoy watching the rest of the videos, which can be found in the playlist.
OSPOs and other open source teams often struggle to demonstrate the value of their work in a way that resonates with the people in leadership positions within their organization. This is why we created a CHAOSS Practitioner Guide all about Demonstrating Organizational Value, which I blogged about in July when the guide was launched. Since then, it’s still been something I’ve continued to spend quite a bit of time thinking about!
Bob Killen and I recently joined Harmony Elendu for an episode of CHAOSScast to share our thoughts about how organizations can more effectively demonstrate the value of their open source efforts. We talked about the guide and shared some of our own stories about what we’ve done at past companies to demonstrate the value of our teams’ open source work. It’s only 23 minutes long, so I hope you enjoy listening to our conversation!
I’ll also be at OSPOlogy Lyon on November 5 & 6 where I’ll be giving a 20 minute talk about Demonstrating the Value of Open Source Efforts, which is based partly on the content from the guide along with my own experience working within organizations to demonstrate open source value. It’s in person, but free to attend, so I hope to see some of you in Lyon!
I have several blog posts here about contributor sustainability because there are so many open source projects and not enough contributors to sustain them all over the long term. With many open source projects desperate for contributors, how do we educate the next generation of open source contributors to grow the contributor base for all of us? This was the topic that Ruth Ikegah, Leslie Hawthorne, Stephen Walli, and I tackled as part of a panel at the recent Open Source Summit EU in Amsterdam.
Collectively, we have experience teaching open source to university students, creating and sustaining open source contribution programs for students in secondary school through to university, and building new open source communities in Africa. In this video, we talked about what we’ve learned, what’s worked, and provided tips for growing the next generation of contributors from within your local communities.
I’ve spent quite a bit of time looking at relicensing and rug pulls, but the data isn’t the important part. What really matters are the actions that we take based on what we’ve learned. It’s important for OSPOs and other open source teams within companies to think strategically about what these power dynamics mean and how we can anticipate and mitigate the risks associated with rug pulls from open source projects driven by software vendors. During my talk at OSSEU, most of the discussion during the Q&A was about the indicators and red flags that can help us anticipate these risks along with how we can mitigate the risks through open source project contributions.
Indicators and Red Flags
There are a couple of indicators that can help you anticipate which open source projects might be more or less likely to be subject to a rug pull or relicense in the future.
Contributor License Agreements (CLAs) create a power imbalance within open source communities where the power is tilted toward the company who owns the project and controls the CLA, which gives the company more power than other contributors; for example, the power to relicense a project. This is probably the biggest red flag when assessing whether a project might be at risk of a rug pull in the future.
Neutral Foundations and Governance provide a level playing field where people from many different companies can work together on an open source project as equals to create something that benefits everyone. Projects are much less likely to experience rug pulls if they are under neutral, well-run foundations and have governance structures with leaders and maintainers from a variety of organizations. This is in contrast to projects owned or controlled by a single company, which is a red flag because those projects are more likely to experience rug pulls.
Mitigate through Contribution
The most impactful action that a company can take to mitigate potential issues within an open source project is to have employees actively participating and contributing to the projects that are most strategic for your company. This is an important way to better understand and mitigate the risks associated with future rug pulls, but it also goes beyond just that one concern. Companies have the power and resources to make real improvements within open source projects, and corporate involvement can positively impact the sustainability of our projects. Companies can allocate employee time to contribute to projects or provide funding and other resources to help sustain open source projects.
Having your employees working within a project helps you understand the power dynamics that might be at play and better understand the strengths and weaknesses of that project while also being able to influence the project from within. If your employees are in positions of leadership within a project, you might be able to help prevent future rug pulls, or at the very least, maybe you can anticipate them.
A lot of the work that we do in open source projects is based on the relationships we have with other people. By having key employees attend conferences focused on their open source work, those employees can build deeper lasting relationships with others that will benefit your organization and your employees. These existing relationships make it easier to collaborate with others, and it’s sometimes easier to work through really difficult, big issues when you have a group of people together at a conference. It’s also easier to communicate with someone later online if you’ve met them in person. I have deep and lasting connections with people that I’ve met at events, which often allows me to make introductions to help a colleague learn something new or solve some tricky issue. Conference talks also showcase the work that employees are doing within your organization both for potential customers and when recruiting new employees either now or in the future.
However, getting talks accepted at important conferences doesn’t always just happen organically, and this is where your Open Source Program Office (OSPO) can play a strategic role in getting the right people speaking at the right conferences. I’ve seen too many examples where no employees get talks accepted at conferences that are important for the organization, and other times where you have one individual spending too much time at conferences while other people aren’t getting the same opportunities to attend. By getting organized and taking a strategic approach to conferences, your OSPO can help to get your employees speaking at the conferences with the biggest benefit, both for those individuals and for the organization as a whole.
I ran a process for doing this when I worked at Puppet, and it helped us get more talks accepted at the conferences where we wanted to have a presence. This was accomplished with input from product teams, engineering, marketing, events, and other key stakeholders. Here are the steps you can use to replicate that process:
Select strategic conferences based on which conferences are most important for your organization.
Identify topics and speakers for each conference in areas that are important to the organization and with speakers who would benefit from attending that specific conference. Imposter syndrome can play a role in this step with some people thinking that only the world’s leading expert can give a talk, so it might take some encouragement to help them understand that they just need to know some things that a person new to the topic would need to know. I have an entire video about imposter syndrome for giving conference talks.
Create timelines and reminders to make sure that talk proposals are prepared in time for your review process and then to meet conference deadlines. I’ll admit that this part of the process required a fair bit of following up and reminding people about the deadlines.
Review and provide feedback on proposals to help employees craft talk proposals (along with appropriate bios) that are more likely to be accepted. Writing excellent proposals requires some specialized skills, so you should recruit a few people who have sat on program committees to help with these reviews. This review process should also be open to anyone who wants to submit a talk, not just the people you’ve identified, because there will be additional topics and conferences that are important for some individuals that you didn’t anticipate.
If you don’t feel like you can run this full process right now, at a minimum, encourage submissions to your most important conference and get people to review those proposals. We did this one year when I worked at Pivotal by encouraging people to post their KubeCon talk proposals into a Slack channel where several of us with talk selection experience reviewed those proposals, and we went from having almost no talks at KubeCon to having about a dozen talks across a wide variety of topics. A lot of people are terrible at writing talk proposals, and a little bit of direction from someone with the right expertise can make the difference between acceptance and rejection.
However, there are a few gotchas to watch out for that are likely to get a talk rejected, regardless of the topic:
The person speaking needs to submit the talk proposal. Never submit a talk on behalf of someone else, since for many events, this is an automatic rejection, even when they give you the option to do it.
Do not submit anything that looks even slightly like a product pitch. Audiences don’t like to be pitched to, so conferences decline these for a reason.
The bio is as important as the talk abstract, and it should be written to highlight why the speaker is the right person for this particular talk. It should not be something generic that is thrown together as an afterthought.
I hope this helps your OSPO get the right people giving talks at the conferences that are the most important for your employees and your organization!
People sometimes think of open source project ownership as something a bit nebulous with projects owned by an undefined “community” of people; however, this is rarely the case from a legal standpoint. While there are a few exceptions, open source projects usually have an individual, company, or foundation controlling the trademarks, project infrastructure, and other assets. This overall ownership structure often impacts how the project is governed on a day to day basis and how the project is perceived by others.
For projects owned by individuals, there are often concerns about succession planning and the impact on the project if something happened to that individual (see obligatory xkcd dependency comic about the one maintainer in Nebraska). This can result in concerns about the sustainability and risks associated with using projects owned by single individuals.
For company owned open source projects, if the project is truly open, the governance processes should specify how people can move into leadership positions with the assumption that you’ll eventually have maintainers from outside of your company. On the flip side, if you have no intention of allowing people from outside of your company to move into leadership positions or make decisions, then you should be clear about that and keep the project as owned by your company. While it’s not ideal, I have a lot more respect for companies who are honest about how others can participate than ones that claim to be open while still making all of the big decisions behind the closed doors of their company.
On the other hand, we have foundations for open source projects, which tend to be non-profit organizations that are focused on providing the resources and organizational structures that projects need to get funding and legal support for their work. Neutral foundations provide a level playing field where contributors can contribute as equals regardless of whether they are contributing on behalf of a company or as an individual. This structure allows companies to collaborate together in a neutral environment where no single company is in control of the project.
In many cases, projects end up in foundations because an individual or company decided to move the project into a foundation, so it’s also important to think about when your project might be ready to contribute to a neutral foundation. If your project is very immature, foundations are unlikely to be interested in your project, whereas a project with many users and good traction that just needs help moving to the next level would be much more likely to be accepted and successful under a foundation. For companies contributing projects, you’ll have a stronger case for moving it into a foundation if you have some contributors, and ideally at least one maintainer, from outside of your company. Contributors tend to be suspicious of company owned open source projects, especially ones requiring a Contributor License Agreement, given the recent rug pulls and relicensing behaviors from some companies over the past few years, so contributing a project to a foundation might make it easier to build a community around that project.
The challenge with contributing open source projects to foundations is that as individuals and companies, you also give some of your control to the foundation. Typically, the project’s trademarks, repositories, websites, and other assets would be transferred to the foundation. Existing maintainers and leaders will usually keep their positions. However, neutral foundations (e.g., Apache, Eclipse, CNCF, Linux Foundation) often make sure that the governance is set up in a way that makes it easy for anyone to participate and eventually move into leadership positions, so as the contributing company or individual, you should expect for some leadership positions to transition to other people over the longer term. While this does mean giving up some control over the project, putting a project under a neutral foundation gives others more confidence that they can contribute as equals.
You’ll still need to do the hard work of getting more contributors and building the community – you won’t automatically get this from the foundation. Most foundations have so many projects that putting a new project into a foundation may not get as much attention as you expect, and the foundation’s attention will be spread across all of those projects. The biggest misconception about putting a project under a foundation is that you’ll get immediate traction with more contributors and more adopters, but this still requires hard work from the people already participating in the project, so it’s important to set your expectations appropriately.
One important note is that contributing a project to a foundation is almost always an ongoing commitment, not an exit strategy, so the contributing organization will likely be expected to provide staff and other support over both the short and long term. It’s also a permanent decision, and you aren’t likely to be able to take the project back after you’ve put it into a foundation, so it’s worth taking some extra time and doing some research to decide whether you should continue to own the project or whether it would be better to put it into a foundation.
Defining your governance / decision-making processes along with pathways to leadership are key to creating an intentional culture for your project that encourages participation and contributions from others. Having a scope, vision, and values (sometimes called a charter) for your project can help people understand what is / is not in scope for your project to encourage people to work on contributions that are most likely to be accepted and avoid wasting time on contributions that aren’t aligned with the project. This also helps to avoid issues and misunderstandings later by helping align the expectations of all community members. By setting expectations and clearly documenting them, you set the stage for creating a healthy and sustainable project over time.
However, just documenting your governance process and setting expectations in writing isn’t enough. You should also be role modeling good behavior and helping others understand what behavior is appropriate within your project. It’s important to remember that tolerating bad behavior unwittingly sets the expectation that this behavior is acceptable in your project, which can drive new contributors away, so addressing concerns promptly before they can get out of control or become a crisis helps set an intentional culture and improve sustainability of your project. A code of conduct is a good starting point for these conversations, but it’s also important to think about how you plan to approach code of conduct issues and how things like remediation and education can be a first step to help people meet the expectations of your projects, instead of taking an enforcement first approach.
Unfortunately, some projects eventually run into issues that can’t be resolved via remediation or education, and in these cases, it may be necessary to remove someone from your project. Your governance documents should have a provision for involuntarily removing someone from your project, even if that person is in a top leadership position. I watched a project struggle with bad behavior for months while waiting for a steering committee member’s term to end because they didn’t have a process for removing that person. We always hope that we never need to use the process to remove someone, but you’ll be glad that you put it in place now if you ever need it in the future.
Having your ducks in a row with robust governance documentation that incorporates your code of conduct, charter (or similar statement of mission, scope, and values), and includes clear processes for dealing with conflict can help make your project more sustainable over time.
