Tag Archives: practioner guide

General

Part 2: Additional Sustainability Topics From the CHAOSS Practitioner Guides

This is the second post in a series, so I encourage you to go back to read the previous post about Building Healthy and Sustainable Projects Using CHAOSS Practitioner Guides if you haven’t already read it. The first post covered the introduction, contributor sustainability, responsiveness, and organizational participation, which were the original 4 guides in the series. 

Shortly after we launched the Practitioner Guide series, we followed up with three additional getting started guides on security, diverse leadership, and sunsetting a project. As I mentioned in the first post in this series, starting with the Practitioner Guide: Introduction – Things to Think about When Interpreting Metrics can help interpret metrics in light of your unique situation. Again, interpreting the metrics and figuring out what they are telling you is only useful if you take the additional step of driving appropriate actions to make decisions and improvements based on those metrics, and each guide provides recommended actions.

Security

Open source project security impacts the health and sustainability for our projects, which ripples out across the entire software ecosystem as dependency / supply chain components. Because security is a complex and critical topic, this Practitioner Guide: Getting Started with Security is designed only to get you started on your path toward improving the security of your project; it is not a comprehensive guide to everything you need to know about open source project security. The guide has suggested starter metrics that include OpenSSF Best Practices Badge, Libyears, and Release Frequency along with additional metrics that might also shed light on the security of a project. 

Recommendations for improvement from the security guide include:

  • Secure your code repository by managing access, implementing branch protection, managing contributions, and more.
  • Create a detailed security policy document (usually in a SECURITY.md file) with instructions for reporting security vulnerabilities along with documenting how the project will respond to those reports, including managing embargoes.
  • Keep your dependencies up to date and use tooling (e.g., Dependabot) to help identify and update your dependencies.
  • Make sure that your security fixes land in a release as soon as possible.
  • Working your way through the OpenSSF Best Practices badge criteria is also a good way to make security improvements.

Diverse Leadership

Without diverse leadership, underrepresented groups may face challenges in participating in and contributing to projects, losing valuable talent and ideas, so a huge thank you to Peculiar C. Umeh who drove the creation of the Practitioner Guide: Getting Started with Building Diverse Leadership! The guide focuses on three key metrics: Board/Council Diversity, Sponsorship (supporting people, not financial sponsorship), and Inclusive Leadership. The data collected can provide valuable insight, but storing, interpreting, and acting upon it requires careful thought to protect identities and be respectful of the people whose data has been collected.

Actions to take include to improve diverse leadership:

  • Start by creating and communicating clear pathways for contributors to grow into leadership roles, which may include creating sponsorship opportunities and transparent criteria for leadership positions.
  • Hold existing leaders accountable for promoting and improving inclusive leadership.
  • Implement programs that encourage diverse representation in leadership and promote diverse perspectives.
  • Regularly monitor and evaluate the diversity of all leadership roles by collecting and analyzing survey data and reporting progress to the community.

This was a challenging guide to write, and it can be a challenge to implement these recommendations. Open source communities are often global and encompass diverse people and backgrounds, so there is a need to avoid imposing a one-size-fits-all approach and be open to adapting strategies to fit the unique needs and values of different groups within your community. Each project should ensure that their practices are inclusive, making all members feel heard and valued, regardless of their background or identity.

Sunsetting (Winding Down and Archiving)

The Practitioner Guide: Getting Started with Sunsetting an Open Source Project is quite different from the other getting started guides because it’s not about making project health improvements or increasing sustainability, but instead about responsibly and proactively shutting a project down when it’s reached a natural end. It’s important to remember that not every open source project can or should exist forever: technologies evolve, corporate priorities change, and people’s interests change. Part of the beauty of open source is that we work in the open as we innovate, and some of those innovative projects will stand the test of time, while others should be responsibly deprecated via a sunset process. The guide looks at several metrics to determine whether a project is still active, Change Requests, Issues New, and Technical Forks, but the guide also covers other reasons for sunsetting a project. 

Once you’ve decided to sunset a project, there are several recommended steps:

  • Communication should start with any existing contributors, since there may be contributors who would like to continue the project. When you decide to sunset the project, this needs to be communicated to existing users in a transparent manner and being clear about the reasons for sunsetting it.
  • Do a code and security review to get it into the best possible shape before archival.
  • Review and resolve open issues and change requests (PRs / Merge Requests), including marking some as ‘won’t fix’.
  • Use the checklists and tools linked from the guide to help with this work.
  • Officially archive the repositories and consider adding the code to Software Heritage for preservation over time.
  • There are also recommendations for handling the special case of sunsetting an active project, which can happen when a company changes strategy or when an individual needs to step away. 

Sunsetting a project is not an indication of failure and should not be positioned as such. Projects have life cycles; they endure for as long as they are needed and then they should be responsibly deprecated when they are no longer needed. Consider providing transition details, and if possible, tooling that helps your existing users transition to an alternative solution if a reasonable one is available. I’d also like to express my thanks to Stefka Dimitrova whose work drove much of the content in the guide and to the team from the US Centers for Medicare & Medicaid Services OSPO who made significant contributions and improvements to the sunsetting guide.

Summary

Improving open source project security and increasing diverse leadership can help a project become more sustainable over time, but when a project has reached the end, it can be responsibly sunsetted, instead of being abandoned. The CHAOSS Practitioner Guide series can help with all of these activities. Come back next week for the next post in this series, ‘Part 3: Determining Value and Viability Using CHAOSS Practitioner Guides’.

As always, if you want feedback or help with open source strategy, sustainability, governance, or related open source topics, I’m available for consulting engagements.

Additional Resources:

As with everything I write, this was written by a human without the use of LLMs or other AI assistance.

General

Part 1: Building Healthy and Sustainable Projects Using CHAOSS Practitioner Guides

Metrics can provide deep insights into our open source projects, but they can also be overwhelming, and because every open source project and every situation is a bit different, metrics require interpretation. And that’s only the first step. Interpreting the metrics and figuring out what they are telling you is only useful if you take the additional step of driving appropriate actions to make decisions and improvements based on those metrics. I’ve been working in open source and using metrics for decades, but for me the metrics have never been what’s important. They are simply the means to an end, a way to make improvements or demonstrate whether we are accomplishing our goals. 

This is why I focused on creating the CHAOSS Practitioner Guide series during my three years as CHAOSS Director of Data Science, and I’m proud of what we, as a community, accomplished with these guides. I’ve written quite a few blog posts about the individual guides, but I wanted to take some time here to reflect on the guides and talk about how they can be used together as a cohesive whole. The guides roughly break into two categories, which I’ll address in a series of four blog posts. The first category focuses on health and sustainability of open source projects. This post is about the first category, ‘Building Healthy and Sustainable Open Source Projects’, with part 2 coming next week to cover ‘Additional Sustainability Topics From the CHAOSS Practitioner Guides’. The second category of guides are the more advanced ones dealing with complex topics, like value, viability, and impact, that span multiple projects. Part 3 in the series focuses on value and viability while part 4 will cover determining impact.

Overview

We launched the Practitioner Guide series with a few getting started topics that apply to almost every open source project: contributor sustainability, responsiveness, and organizational participation.

The guides are paired with as ‘Introduction – Things to Think about When Interpreting Metrics’ as a starting guide with more details about how to interpret metrics in light of your unique situation. The introduction has general suggestions about how you should spend time understanding the goals of the project and talking to the people working within the project as key inputs into interpreting metrics. When it comes time to look at the metrics, focusing on trends over time for just a few metrics can help cut through the noise before drilling down into the details where there might be a potential issue. This is why each getting started guide focuses on just a few metrics to get started with tips for expanding to additional metrics as needed.

Every project is a little different, so it’s essential to interpret the metrics in light of a project’s individual needs and ways of operating. It’s also important to remember that metrics are more than just data, they represent actual human beings, so it’s important to be careful about comparing people against each other in ways that might result in the punishment of individuals. The non-human data (e.g., bots, automation, AI) should also be carefully taken into account in your interpretation of metrics. The Introduction – Things to Think about When Interpreting Metrics guide has more details about how to think about metrics and use what you’ve learned productively and ethically.

Contributor Sustainability

The Practitioner Guide: Getting Started with Contributor Sustainability focuses not just on determining whether you have enough contributors to sustain a project over the long-term, it also has tips for increasing contributor sustainability while keeping in mind that new contributors can also create additional burdens on the time of already overloaded maintainers. The guide includes Contributor Absence Factor, Contributors, and Types of Contributions as the key metrics to start investigating contributor sustainability.

To improve contributor sustainability, here are just a few of the recommendations from the guide:

  • Start by looking at your existing contributor base to determine whether you have people who are ready to step into a maintainer role, even if they start by maintaining just a sub-project. If there are people who are almost ready, some mentoring or reviewer roles might be a good first step. 
  • Before starting to recruit new contributors, it might help to review and update existing contributor guides and other onboarding documentation to help people get up to speed quickly while requiring less help from existing maintainers.  
  • Good first issues and help wanted labels can help new contributors get started on something productive, especially if those issues are created with the information that a new contributor needs to know to accomplish the task.
  • Be proactive about asking people for help with specific tasks. Knowing that we’re wanted and appreciated makes us feel good, which can be a strong motivator to contribute to an open source project or to continue contributing.
  • Defining the roles and responsibilities for contributors, reviewers, and maintainers as a contributor ladder where contributors can climb up to become reviewers and those reviewers can become maintainers can help with recruiting new people into these roles. 
  • Think about how people can move into leadership positions to be responsible for documentation, community management, marketing and other important roles.

Responsiveness

Responsiveness is one of the most important factors in attracting newcomers and retaining existing contributors for a project. The Practitioner Guide: Getting Started with Responsiveness uses Time to First Response, Time to Close, and Change Request Closure Ratio as the key metrics to help determine whether a project is responding to requests in a timely manner. It can be tempting to attempt to solve issues with responsiveness by putting more pressure on existing maintainers by asking them to respond more quickly and resolve more contributions, but this rarely solves the long-term problem. It might result in short-term gains, but it could be damaging to the community and the project over time if you are burning out your maintainers by not resolving the underlying problems that are causing the lack of responsiveness in the first place.

Some suggestions for improving responsiveness from the guide include:

  • As suggested in the contributor sustainability guide, start by looking at whether you can promote some existing contributors into reviewer or maintainer roles.
  • Use the project’s contributing documentation to set expectations about when to expect a response to a contribution.
  • Use issue and change request templates to help contributors make good contributions that require less work from maintainers.
  • Talk to your maintainers and find out where they are spending too much of their time and focus documentation or recruitment in those targeted areas.

Note that responsiveness is hard to diagnose because many things can impact responsiveness, so don’t be discouraged if your first attempt doesn’t result in improvement.

Organizational Participation

Organizations can have a significant impact on the health and sustainability of an open source project. On the one hand, organizations can help sustain projects over time by employing people to work on projects, but they also introduce risk (e.g., from relicensing, strategy shifts, acquisitions) when one organization is too dominant. From a contribution standpoint, it can be difficult if one organization has all of the influence and other people don’t feel like they are participating as equals.

The Practitioner Guide: Getting Started with Organizational Participation uses three primary metrics, Organizational Influence, Organizational Diversity, and Elephant Factor, to understand organizational participation. 

The recommendations for improving organizational participation depend on whether the improvement is coming from the dominant organization. From the dominant organization:

  • Contribution documents should be clear about whether contributions are accepted from people outside of the organization and whether those people can move into leadership positions. Transparency and setting expectations can reduce frustration from other contributors.
  • Spend some time thinking about why the project isn’t getting contributions from other organizations. Is all of the work happening in the open, and can others easily find decisions and discussions in public channels? If not, some work might be required to redirect private conversations into the public channels.
  • Promote opportunities to contribute via social media, conferences, and other channels.
  • Use your existing connections to other organizations who are using the project to encourage specific people to contribute.

From outside of the dominant organization: 

  • Engage in the project to determine whether contributions are really welcome.
  • If so, encourage your employees to contribute to the project as part of their time at work. Don’t expect employees to contribute to work projects in their free time.

Being transparent is critical. Saying one thing in the documentation and doing another can damage your organization’s reputation more than just being honest and transparent about how people can (or cannot) contribute to a project. If you are considering using an open source project as a key component of your organization’s products or infrastructure, you should think very carefully about that decision when that project is controlled by a single organization.

Summary

Increasing contributor sustainability, improving responsiveness, and garnering participation from a variety of organizations can all help improve the health and sustainability for an open source project. Check back next week for the second blog post in this series about security, diverse leadership, and sunsetting an open source project.

As always, if you want feedback or help with open source strategy, sustainability, governance, or related open source topics, I’m available for consulting engagements.

Additional Resources:

As with everything I write, this was written by a human without the use of LLMs or other AI assistance.

General

A Strategic Approach to Demonstrating the Value of OSS Efforts

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. The topic of demonstrating open source value is one that I’ve been blogging about and giving presentations about frequently over the past year, so this blog post is a way for me to collect all of that work in one place to make it easier for people to find.

In the CHAOSS OSPO Working Group, which I co-chair, the topic of how to demonstrate the value of our work in open source has been a popular topic since we started the group many years ago. However, given the current financial climate and the number of OSPOs that have been the targets of cutbacks and layoffs, this feels like a particularly important topic right now.  This is why we created a CHAOSS Practitioner Guide all about Demonstrating Organizational Value, which I blogged about when the guide was launched.  In a second blog post on the topic, More about Demonstrating Organizational Value, I talked about the episode of CHAOSScast where Bob Killen and I joined Harmony Elendu to share our thoughts about how organizations can more effectively demonstrate the value of their open source efforts.

I expanded on this topic in another blog post, OSPO Contribution Strategies to Demonstrate Value. This post highlights how to articulate the importance of your contributions to upstream projects as part of a broader open source strategy, which often has 2 components: 1) identifying which projects are most strategic / critical for your organization and 2) creating contribution strategies for individual projects. The blog post has examples of how I did this when I worked at VMware and Pivotal.

I’ve also presented on this topic several times recently, but I wanted to highlight the two most recent talks, since they are the most comprehensive examples of these presentations. I blogged about my talk for the folks from CURIOSS (Community for University and Research Institution OSPOs) where I expanded on the content in the guide to also include more about how to demonstrate value in a university context. I further expanded it beyond corporate and university contexts to include how government / public sector organizations can demonstrate the value of their work in my talk at the Open Source Summit in Minneapolis a few weeks ago. Here’s the video and slides for this most recent version of the talk.

If you want feedback or help with your open source strategy and how to demonstrate value for your organization, I’m available for consulting engagements.

Related blog posts:

General

Responsibly Sunsetting OSS Projects: A Guide for OSPOs

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

If you want feedback or help with your sunsetting process or related OSPO topics, I’m available for consulting engagements.

Additional Reading:

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.

If you want feedback or help with your open source strategy and how to demonstrate value for your organization, I’m available for consulting engagements.

Related blog posts: