Tag Archives: ospo

General

Responsibly Sunsetting OSS Projects: A Guide for OSPOs

Pink, yellow, purple, and blue sunset in the background with palm trees and thatched roof palapas over sun beds on the beach in Aruba.

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.”

– The CHAOSS Practitioner Guide: Getting Started with Sunsetting an Open Source Project

Additional Reading:

General

Assessing the Viability of Open Source Projects

Various types of purple dice with white letters, including a traditional D6 die, a D20, and others. Sitting on a white piece of paper with blurred writing.

I’m thrilled to announce that we just launched the Practitioner Guide: Assessing Viability, which is the latest in the CHAOSS Practitioner Guide series! A huge thank you to Gary White Jr. who wrote quite a bit of this guide along with the viability metrics models that it’s based on.

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.”

– The CHAOSS Practitioner Guide: Assessing Viability

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!

Additional Reading:

Photo by Ian Gonzalez on Unsplash

General

More about Demonstrating Organizational Value

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!

OSPOlogy hosted by LF Energy and Réseau de Transport d’Electricité (RTE) on 5-6 November 2025 in Lyon, France on a purple-blue background. Profile picture of Dawn Foster with text underneath reading, Speaker Dawn Foster with the CHAOSS logo.

Related blog posts:

General

How OSPOs Can Take a More Strategic Approach to Conference Talks

Dawn giving a keynote at KubeCon EU wearing all black with a VMware t-shirt and purple hair in front of colorful background.

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:

  1. Select strategic conferences based on which conferences are most important for your organization.
  2. 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.
  3. 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.
  4. 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!

Additional Resources:

General

United Nations: OSPOs for Good Day

United Nations: Welcome to Open Source Week #UNOpenSourceWeek

I was thrilled to be invited to attend the United Nations Open Source Week in New York joining a few hundred people from over 40 countries to talk about open source. 

The OSPOs for Good day on June 18, kicked off with a keynote by Amandeep Singh Gill, Under-Secretary-General and Special Envoy for Digital and Emerging Technologies, UN-ODET, who talked about how the UN sees open source as a foundation for digital transformation, but one that requires the UN to move beyond its historical focus on governments to engage multiple stakeholders. Looking around the room, you could see this reflected in the event attendees who represented governments, companies, universities, not for profit organizations, individuals, and more. Later in the day, Dmitry Mariyasin, Deputy Executive Secretary, UNECE, talked about how he sees open source as an inspiration for how the UN can operate more broadly in their role to create public goods using digital solutions to improve sustainability and increase transparency and trust. 

You can watch the livestream of the event, but here are a few highlights or common themes from the OSPOs for Good day.

  • Historically, many open source conversations were about cost savings, but this wasn’t the case at this event. The conversations have shifted to collaboration, innovation, and using open source to build trust.
  • Several of the people representing governments talked about how having an OSPO helped them build connections to other people involved in open source within their organizations while also allowing them to build connections and partnerships to collaborate and learn from others. Many countries view open source as being critical to their success as a country and in serving the needs and improving the livelihoods of their people.
  • The newly formed Trinidad and Tobago OSPO and Kenya OSPO are part of an initiative to create a replicable, scalable model of OSPOs across the global south with a goal of serving countries beyond just their governments to promote open source. 
  • Governments want to use open source, but struggle with procurement processes, which requires different policies to contribute, add new features, and maintain open source projects. Governments have been more willing to fund new features, but often struggle to fund the invisible maintenance of the software that everyone uses, which creates risks for the public that they represent. Germany’s Sovereign Tech Fund (now under the Sovereign Tech Agency) was created as one way to address these risks and make strategic investments in core digital infrastructure.

So far, I’m really enjoying the event and am looking forward to the next two days!

Update: I’ve followed this up with a second blog post: UN Open Source Week Part 2: Digital Sovereignty and Resilience.