General

Freeriding and Rebellion: An Investigation of Open Source Vendor Relicensing and Member Hard Forking Events

I’m thrilled to share that the relicensing and forks research that Matt Germonprez and I have been working on over the past 3 years has finally been published in Information Systems Journal, an A-level academic publication! “Freeriding and Rebellion: An Investigation of Open Source Vendor Relicensing and Member Hard Forking Events” is available via open access for anyone to read, and I recommend viewing it in PDF format, since the table formatting is a bit better than in the web version.

Here’s the abstract if you want a preview before you give it a read:

Open source engagement is an ongoing effort in which members continuously interact with evolving project dynamics. Engagement extends beyond writing code or setting policy; it is a shared practice of understanding, negotiating, and adapting to the social and technical structures that define a project. As members continually evaluate their project engagement, collective action threats may arise that impact the overall functioning and sustainability of a project. In our research, we investigate collective action threats and governance practices in relation to a recent trend of vendor defined licence changes that result in project members creating hard forks. Drawing on a netnographic analysis of three cases, Elasticsearch → OpenSearch, Terraform → OpenTofu, and Redis → Valkey, we develop theoretical and practical insights into what collective action threats and governance practices are present, their relationships, and who is involved in them within open source projects that experience relicensing and related hard fork events. Our research provides theoretical and practical implications that show how freeriding accusations become the justification for unilateral, non-incremental adaptation to a project’s boundary regulation and how these governance changes are tied to rebellion as project members reposition themselves within shifting open source landscapes and realign their future open source project engagements.

This is the second place that the research has been published this month, since a short article on a related topic targeted at practitioners was also published in IEEE’s Computer: Value Capture Dynamics in Open Source (also open access).

This research has been a long road that started with me being curious about the organizational dynamics in open source projects that were forked when the original project moved under a proprietary license. I was involved briefly in the OpenSearch community in 2021, but when Valkey was forked from Redis in March 2024 (not long after the OpenTofu fork of Terraform in September 2023), I started gathering and analyzing data that I began sharing in presentations in the summer of 2024. This quickly turned into a short paper, The New Dynamics of Open Source: Relicensing, Forks, and Community Impact, which was presented at the OpenForum Academy (OFA) Symposium November 2024. 

Those initial findings evolved as the forks evolved, and Matt Germonprez and I began thinking about the broader implications of these dynamics. We began giving presentations about power dynamics, rug pulls, and other corporate impacts on open source sustainability to get more feedback. There is a video from the Open Source Summit in August 2025 that you can watch on YouTube and Jon Corbett did a lovely job of summarizing it in his LWN Coverage of the talk. The idea was also turned into a blog post for The New Stack: Clouds, Code, and Control: The New Open Source Power Struggle. 

After a couple of these presentations, Matt Germonprez and I started working on how we turn the data and these ideas into a published academic paper, which you can read today in Information Systems Journal. A huge thank you to Matt, since without him, I would not have been able to get this research published in an academic journal of this quality!

This may be the conclusion of this line of research, since we’ve both moved on to other areas of interest. I’m looking forward to seeing more of Matt’s continuing research into open source supply chains while I focus on consulting (I’m available for consulting engagements focused on open source strategy, contributor strategy, improving project governance, and related topics). I hope you enjoy reading more about our research!

Related links:

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

General

Fixing the leadership gap threatening open source projects

I’m excited to be attending and presenting at my first ASF Community Over Code in October! It’s an event that I’ve always wanted to attend, but for whatever reason, I could never quite fit it into my schedule … until now. 

White ASF leaf logo and Community Over / Code Glasgow 2026 on a purple background.
Community Over / Code Glasgow 2026

This seems like the perfect time and place to deliver a brand new talk about what we can do to fix the leadership gap threatening open source projects. Anyone who knows me, or who regularly reads this blog, has seen that open source sustainability is an important topic for me, and open source needs sustainable leadership. We’re in a situation now where current leaders are burning out, retiring, or otherwise becoming unable to continue, which is creating a leadership gap with not enough new people having the opportunities or skills needed to move up within a project. The talk focuses on three topics: inclusive leadership principles, recruiting leaders, and good governance with a final section summarizing the actions that we can all take as individuals to fix the leadership gap. This blog post provides a preview of the talk.

Inclusive Leadership Principles

It’s important to have a variety of leadership roles that can act as a stepping stone to allow people to lead in smaller areas before moving to whatever you have as a top level leadership position. This can take the form of someone becoming a committer or reviewer, and then becoming maintainer. It might mean managing a community, leading documentation, managing projects, or becoming a chair of a working group, and then later moving on to a board or steering committee.

We’ve all seen projects where the same people sit in the same leadership positions year after year without providing opportunities for other contributors to move up within the project. If leadership positions aren’t available on a regular basis, then it can be difficult or impossible to promote people into leadership, which is why terms for boards or steering committees are important. Contributors can become disillusioned and disengaged if they don’t feel like there are enough opportunities within a project.

New and existing contributors feel more included when they can see other people in leadership positions who are like them. Without diverse leadership, underrepresented groups may face challenges in participating in and contributing to projects, losing valuable talent and ideas. It’s also important for people in leadership roles to role model good behavior and help others understand what behavior is appropriate within your project. Tolerating bad behavior unwittingly sets the expectation that this behavior is acceptable in your project, which can drive new and existing contributors away. 

Recruiting Leaders

This is a hard problem to solve. Sometimes it can be really difficult to get people to contribute to your project, and unfortunately, there is no magic or one size fits all solution. Some people are contributing as part of their job while others might contribute to gain experience or learn something. Clear communication, working in the open, public roadmaps, having good onboarding documentation, and reducing friction are key to helping people stick around. Having good first issues or help wanted labels are excellent places to start because these help people find something that they can work on while they learn more about the project. But, good first issues and help wanted labels are passive requests for help, so I also encourage people to be proactive and specific about ways that people can help. Asking someone specific to review a PR or answer a question from a user demonstrates that you recognize their unique expertise and want their help. 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 can help with recruiting into these roles. It can help to think about this as a ladder where contributors can climb up to become reviewers and those reviewers can become maintainers. What’s important is to document it and make sure that people understand how they can climb the ladder and gain more responsibilities within the project. Having a contributor ladder helps set expectations for the roles and encourages people to think about how they might take on areas of increasing responsibility within the project. As you get more of the humans moving into maintainer roles, you can reduce the load of the existing maintainers.

Good Governance

Projects can work toward more inclusive leadership practices where people feel welcome and included in project leadership, but you also need to have good governance practices and processes that make it possible for people to feel included and move up within the project. Good governance is a key element in fixing the open source leadership gap. I actually have a second talk on this topic in the Governance and Policy track at Community Over Code, and I’ve covered governance extensively here on this blog, so I’ll just share a few highlights as they relate to the leadership gap.

The tricky thing about governance is that it needs to be proactive. The time to work on governance is when things are going well. If you wait until there is a crisis within your community, you might not have the right processes for dealing with that crisis, and when a project is in crisis, it will be much more difficult to come to an agreement about governance.

Governance is one of those things that is never really finished. The governance processes that you need when you have only a couple of maintainers is likely to be insufficient if the project grows dramatically. As your projects evolve, your governance and your leadership should evolve along with them. But changing your governance processes to evolve with the changing needs of the project can be hard. People have feelings and any kind of change can be difficult, but this is especially true in many open source projects where people often become deeply and personally invested in their projects.

Take Action

Fixing the leadership gap in open source won’t just happen without all of us taking action. Here are a few suggestions for what you can do as an individual to help ensure that open source projects have the leadership to be sustained over time.

One of the things we can all do, but especially those of you working in companies, is to provide funding for open source, which can help to reduce the pressure on open source maintainers and projects. It can provide a way to pay more people to devote their time to an open source project. You can donate to individual projects via platforms like Open Collective or GitHub Sponsors. You can contribute to things like the Open Source Pledge. You can fund open source research via the Software Stewardship Lab. There are many ways to fund open source, and that’s something that we can all do.

Those of us who are established in our careers and in open source projects can use our influence and reputation in a project to help others gain visibility and opportunities that eventually result in someone new moving into leadership positions. We call this sponsorship, which is more than just mentoring, and can include things like inviting someone to co-present or join a panel at an event, providing opportunities to collaborate together on some aspect of a project, or other activities that give people new opportunities to learn and lead. 

I mentioned earlier that we’ve all seen projects where the same people sit in the same leadership positions year after year without providing opportunities for other contributors to move up within the project. If you’re one of those people, it might be time to take a hard look at whether you’re still providing the value to the project that you once did, or are you taking a space that could be offered to an up and coming person doing great work in the project?

This is something that I have personally been thinking hard about over the past several years, and I’ve started giving up leadership roles to allow other people to have the same opportunities I’ve had.

Summary

Fixing the leadership gap that is threatening open source project health and sustainability won’t just magically happen. It’s going to take work, and it’s going to require action from all of us, so take a hard look at the projects you’re involved in, and look critically at your own behavior. Think about how you can improve the governance for the projects you’re involved in and what you can do to improve inclusivity within those projects. Consider what you can do to help others move up within open source projects and how you can be a role model for leadership in open source. And most importantly, drive the change that you want to see.

If you want to attend this talk and other great talks on similar topics, I hope to see you at Community over Code in Glasgow October 11-14!

If you want feedback or help with sustainable leadership, governance, or related open source topics, I’m available for consulting engagements.

Additional Reading:

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

General

Part 4: Assessing Impact Using CHAOSS Practitioner Guides

This final post in my series about using the CHAOSS Practitioner Guides focuses on determining impact for two specific cases: Funding Impact Measurement and Research Software Impact. If you haven’t already read the previous posts in the series, I encourage you to pause and read those first:

Funding Impact

Much of the critical infrastructure that we all rely on is made up of open source projects that lack the resources to be properly maintained over the long term. Funders need to be able to understand the impacts of past funding in order to secure buy-in for future funding as well as adapting and/or innovating funding approaches whilst mitigating ineffective or even harmful approaches. We all benefit from more public institutions, philanthropic organizations, and companies giving money to open source; when done in a way that positive impact is the ultimate goal and objective.

The Practitioner Guide: Funding Impact Measurement has several things to consider when measuring impact:

  • Start by understanding the context. Accounting for funding objectives, project life stage and social structure, and regional and organizational cost factors is an important first step in measuring funding impact, since it provides important context.
  • Economic, social, and technological impacts can be both positive and negative, direct and indirect, internal (i.e. within a project) and external (i.e. among a project’s ecosystem of dependents and users), and manifest over various time horizons. When assessing the impacts of open source funding, there may be a tendency to focus on technological impacts, which may in part be due to the nature of open source or the relative ease of measuring data from repositories. However, the potential impacts of funding extend beyond the code itself, and it is crucial to consider economic and social impacts on projects and their wider ecosystems of dependents and users.
  • Methods. When it comes to measuring the impacts, funders can consider a breadth of methods for impact measurement. We recommend using a mixed methods approach, which provides a way to combine scalable quantitative measures along with contextual depth from qualitative data to better understand the funding impact.

This guide helps organizations measure the impact of their funding initiatives so that we can increase the funding to open source projects to drive future improvements and allow these projects, and the people working on them, to become healthier and more sustainable over time. Most of this guide came from a paper that I co-wrote with Cailean Osborne, Paul Sharratt, and  Mirko Boehm, so a big thank you to my co-authors and others from the CHAOSS Funding Impact Working Group for supporting this guide!

Research Software Impact

Looking at the impact of research software requires a very different approach from the corporate context, so we have a guide dedicated to that topic: Practitioner Guide: Research Software Impact. Software and open source community work does not have a history of being part of reappointment, tenure, and promotion cases and has not represented a traditional outcome of university research work. To make this even more complicated, there are no consistent international practices for using software identifiers or citing software. A huge thanks to Matt Germonprez and Clare Dillon for writing this one!

The guide highlights the importance of open source software and community work as significant scholarly outputs using several metrics for determining research software impact:

  • Contributor Absence Factor. For researchers and evaluators, the contributor absence factor is helpful in understanding how an open source project is growing to include contributors who are responsible for more than 50% of the code base.
  • New Contributors. A steady influx of new contributors may indicate a healthy, inviting project, while declines can be a signal for potential challenges in engagement or accessibility.
  • Project Velocity. A researcher can use the Project Velocity metric to report project velocity of their own open source project and compare project velocity across a portfolio of projects.
  • Change Requests. The Change Requests metric tracks the proposals for modifications to a project’s source code that have been submitted for review during a given time frame.
  • There are also additional metrics, like software citations and external funding, that may be used if they are available.

The guide focuses on the impact of open source software and/or communities created and maintained by individuals and teams as part of their research role, including evaluators who are part of researcher reappointment, tenure, and promotion cases. This guide focuses on open source software and communities developed and maintained by a researcher or team to recognize the social and technical impact from that work.

Summary

These are very different guides that both focus on assessing impact within slightly niche topics that only apply in specific situations. However, they would also be useful when brainstorming ways to assess impact in other situations. 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. In particular, I’m interested in working with organizations who need help assessing the impact of their open source funding initiatives.

Additional Resources:

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

General

Part 3: Determining Value and Viability Using CHAOSS Practitioner Guides

This third post in the series about using the CHAOSS Practitioner Guides is quite different from Part 1 and Part 2, which both covered the Getting Started Practitioner Guides with Part 1 focused on contributor sustainability, responsiveness, and organizational participation and Part 2 focused on security, diverse leadership, and sunsetting. All of the topics in those earlier posts are ones that are addressed on a project by project basis. If you haven’t read the previous posts, you might want to pause now and read them before continuing here.

This post is focused on two of our more advanced / expert practitioner guides that help organizations look more holistically at open source initiatives that span across projects. This post is particularly relevant for Open Source Program Offices (OSPOs), but can be used by anyone focused on open source with a variety of different types of organizations. This post covers two more complex topics with guides that are much more extensive than the getting started guides:

Demonstrating Organizational Value

Open source teams and OSPOs often experience pressure from leadership to drop and / or reduce their open source contributions to focus on internal initiatives that deliver more value to the organization. This puts open source teams in the position of needing to justify their work in open source to demonstrate that it has as much or more value than other initiatives that employees could be working on. However, it can be difficult to frame the justification in ways that resonate with leadership and clearly articulate how the organization benefits from continued contributions to an open source project. Thank you to Bob Killen for providing quite a bit of the content for this guide based on his experiences when he worked at Google.

The Practitioner Guide: Demonstrating Organizational Value has a framework for demonstrating value that includes:

  • Goals. Start by focusing on supporting your organization’s goals. The priority for investment (allocating staff or other resources) in open source can be framed as a combination of criticality and project health risk that is unique to your organization.
  • Criticality. Determine which open source projects are the most critical for your organization by looking at dependencies, opportunities to influence projects, and supportability of the projects you use.
  • Health Risk. Assess the project health risk of the open source projects that are important for your organization using a variety of metrics highlighted in the guide.
  • Priority. Prioritize within your limited resources using a combination of criticality and project health risk as determined above.
  • Value. Use all of this to measure and frame the value in ways that your leadership can see why contributions to certain projects are important to helping the organization achieve its goals.

One guide can’t possibly cover everything about demonstrating the value of your organization’s open source efforts, so this is just a fraction of the potential ways that open source investments can be tracked and tied back to goals while effectively describing the value of the contributions. It requires the right framing and ensuring that resources are allocated where they may have the most value; however, the framing and resource allocation will be different in almost every situation, since it depends on your organization’s unique needs. 

Assessing Viability

Evaluating the viability and the risk that comes with specific open source projects is important to avoid disruptions that hamper the ability for your organization to deliver products and services to customers, especially when a key dependency suddenly becomes unviable. Assessing the viability of open source projects, especially ones that have the potential to impact the business, is a good first step toward managing risk and reducing the chances of potential business disruptions. A huge thank you to Gary White for writing most of the content in this guide based on his viability assessment experiences within the Verizon OSPO. 

The Practitioner Guide: Assessing Viability walks through several categories of metrics that should be considered when assessing viability:

  • Compliance and Security assesses a project’s licensing fit, vulnerability risk, and maintenance activities. It is important for users to comply with any responsibilities they may hold to an organization or to the creators of a project.
  • Governance metrics are useful to show the intention or lack of intention in the project’s governance and help define decision-making processes. The ability to contribute, understand, or depend on a project is highly coupled to the effort behind governance.
  • Community metrics indicate how the community maintains a project and how much interest there is generally. A key aspect of viability is community activity and adoption, because without an active community, an open source project is not likely to continue to evolve and grow. The idea is that an active community surrounding a project is more likely to drive better performance, vulnerability management, and feature-completeness to ease development downstream.
  • Strategy metrics help to determine the influence that individuals and organizations have within a project. 

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.

Summary

Determining value and assessing viability are topics that may seem distinct, but quickly become intertwined, especially within OSPOs. When determining value, one step is to look at how important or critical the project is within your organization. Those critical or strategic projects should also get a viability assessment, which can help to determine project health, which is the other side of the value equation in the guide. Both of these guides used together can help your organization justify the value of your open source contributions both from the strategic side (organizational value) and for understanding and mitigating risks (viability). Check back next week for the final post in this series, Part 4: Assessing Impact Using CHAOSS Practitioner Guides.

As always, if you want help with either of these topics or more generally need advice or feedback on 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 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

Launching the Software Stewardship Lab

I’m excited to be a part of the new Software Stewardship Lab, which is launching today! The Software Stewardship Lab is a new organization dedicated to funding research on open source sustainability, a topic very near and dear to me that I’ve been focused on for the past few years. The entire technology ecosystem relies on open source infrastructure, and there are some great organizations funding maintainers and projects, but at the Software Stewardship Lab, we’re focused on funding the research that helps us all answer questions about important topics like analysis of critical dependencies and packages analysis, which ones are / are not well-maintained, and how the maintainers of those open source projects are handling the load while avoiding burnout. 

I’m part of the team shepherding this effort. Many of the others are people that I’ve been following and have a deep respect for the work that they have been doing, so I am looking forward to continuing to learn from all of them! The team includes: Our Executive Director Vlad-Stefan Harbuz (Open Source Pledge / Open Source Endowment), Andrew Nesbitt (ecosyste.ms), Miranda Heath (report on burnout in Open Source), Daniel Roe, (Nuxt / npmx), Matias Capeletto aka patak (npmx), Mike McQuaid (Homebrew), and myself.

But we can’t do this alone. We’re looking for organizations to fund the important research that we’re doing at the Software Stewardship Lab, so that people can get paid for focusing on research around software supply chain security and maintainer burnout. Please have a look at our sponsorship page for more details about how you can help support this critical work.

You can learn more about the lab by reading our announcement post and exploring our website.

I mentioned earlier that open source sustainability is a deeply important topic for me. I think it’s important for maintainers to have the funding and other resources that they need to build projects that can become sustainable over the long haul. I’ve written many articles related to open source project sustainability, so I won’t say more now, but will instead point you to a few previous posts from my blog:

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

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

General

Measuring OSPO Value: A new Linux Foundation Report

Regular readers of this blog know that helping organizations demonstrate the value of their open source efforts is something I’ve been focused on for a while, and it’s one of the consulting services that I offer. I recently summarized some of my thoughts on this topic into a single blog post where you can learn more: A Strategic Approach to Demonstrating the Value of OSS Efforts.

This is why I was so delighted to review and provide feedback on a recent Linux Foundation report on this topic along with writing a blog post summarizing the report. The blog post originally appeared on the Linux Foundation blog, but I wanted to also re-post it here for reference.

Measuring OSPO Value

Originally posted on 29 June 2026 at https://www.linuxfoundation.org/blog/measuring-ospo-value

Open Source Program Offices (OSPOs) play important roles within organizations, but that role isn’t always appreciated or understood within the executive team or by other stakeholders. In the current financial climate, some OSPOs have been the targets of cutbacks and layoffs, so this is a particularly important time for OSPOs to be clear about the value that they provide to their organization. Leaders within every organization are responsible for making sure that their organization focuses on the activities that have the biggest impact on helping that organization achieve their goals. As a result, OSPOs need to be able to demonstrate that the value of their work can have a larger impact on the organization than the other initiatives that are also competing for resources. As the CHAOSS OSPO Metrics Working Group co-chair and CHAOSS board member, the topic of measuring OSPO value is one that I have cared deeply about for years, and I recently gave a talk on this topic at the Open Source Summit North America in May. This is why I was so excited to read Ibrahim Haddad’s latest report, Measuring OSPO Value: A Framework for ROI, Resilience, Risk Foresight, and Strategic Influence, and share a few highlights from the report in this blog post.

It’s easy to say that OSPOs should be better at measuring value, but it’s not quite that straightforward. OSPO value has always been difficult to measure because much of the work is preventative, the effects are distributed throughout the organization, the impact is spread across multiple time horizons, and the work is cross-functional. However, it’s become increasingly urgent with the ubiquity of open source software impacting revenue-critical systems, security and supply chain expectations increasing, regulations having a bigger impact on open source, and AI-generated code adding complexity.

There is no one way to measure OSPO value, so the report uses a framework with 4 interrelated dimensions that can help OSPOs reason about value from multiple perspectives that can be applied through the lens of their unique organizational goals.

ROI and cost avoidance. In my experience, when executive leadership and finance are questioning an OSPO’s value, they usually start by asking questions about ROI, but this narrow framing doesn’t tend to be particularly useful in my opinion. OSPOs don’t typically generate direct revenue, but they can have an impact on cost avoidance, including reduced duplication, improved efficiency, and lower maintenance costs that can be used for financial justification.

Resilience. Engineering and security leadership on the other hand want to better understand how the OSPO is helping the organization avoid disruption through preparation related to visibility and management of dependencies, SBOM coverage, licensing or provenance concerns, and readiness around engineering decisions. When this is done well, everything proceeds smoothly and crises are avoided, but this is why measuring resilience proactively is an important part of measuring OSPO value.

Risk foresight. While resilience is about preparedness, risk foresight is about detecting potential issues early enough to mitigate the impact and avoid incidents. This includes detecting potential license issues, governance problems, supply chain concerns, security vulnerabilities, and regulatory / policy changes. This value can be measured and communicated by documenting near-misses and creating a narrative around how the OSPO took action to prevent the issues. The CHAOSS Assessing Viability Practitioner Guide provides additional insight into this dimension.

Strategic influence. This dimension measures an OSPO’s long-term value, including how the OSPO strategically invests in the open source ecosystem with presence, engagement and influence in technologies, standards, and organizations that are critical for the organization now and in the future. We also covered some of this in the CHAOSS Demonstrating Organizational Value Practitioner Guide.

The report also highlighted a few principles for building a measurement system across these 4 dimensions, including measuring outcomes (not activities), focusing on a smaller number of indicators, using both quantitative and narrative approaches, explicitly documenting assumptions, distinguishing between enabled value and owned value, avoiding metrics that punish disclosure, designing for maturity, stating framework limits, and having metric continuity. Ultimately, all of this work to measure and demonstrate value needs to be communicated to executives and other stakeholders in a way that they can understand the importance of the OSPO. Ibrahim’s report has more details on tailoring communications to specific audiences, using scorecards, evolving your approach over time, and a practical roadmap for implementation.

If you work in an OSPO or do open source work within an organization, now is the perfect time to rethink how you measure and demonstrate the value of this work, and this report is a great way to get started or get you thinking about how you can improve your existing approach to measuring OSPO value.

Link to read the full report.

I hope you enjoyed reading this blog post! 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

From Active To Archive: Shepherding Repositories Through Their Sunset

I’ve blogged before about how not every open source software project can or should live on forever: priorities change, technologies evolve, and interests shift over time. 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. This was the premise behind the CHAOSS Practitioner Guide: Getting Started with Sunsetting an Open Source Project.

The Open Source Program Office at the Digital Service at the Centers for Medicare and Medicaid Services in the US Government built on the CHAOSS sunsetting practitioner guide, contributed their improvements back into the guide, and built tooling to automate some of the tasks! They’ve done some excellent work, so I was thrilled when they asked me to join them to talk more about all of this at the recent Open Source Summit North America! The slides and video are available if you want to have a look at what we discussed.

Additional Reading:

General

United Nations Open Source Week

I’ve been fortunate to be able to attend the UN Open Source Week event again this year at the United Nations Headquarters in New York City where they bring the open source community together with government and policy folks to facilitate collaboration and information sharing. For these first several days, the overarching theme is around digital sovereignty with people seeing open source as a way to build public goods together. There were concerns about how technology has been consolidated into the hands of a few, but that open source and events like this one help us change that by embracing the freedom that open source offers. AI is seen as both an opportunity and a challenge with some AI cheerleading, while also expressing concerns that AI is trained mostly on the work of a few with many people not being represented in the training data. Overall, open source is seen as a partnership model to allow all of us to build public goods together. 

Dawn smiling standing next to the UN Open Source Week Sign

One of my favorite things about this event is how people use it as an opportunity to get people together outside of the main event. While it may not seem like FOSDEM and a UN event would have much in common, they both have many side events that spring up to take advantage of the people they bring together. Like with FOSDEM, some of my best moments at the event have been during the conversations that I’ve been having with other open source folks during breaks, lunch, parties, and the hallway track!

The first day, I took advantage of the Maintainathon, which was part of the main program, but was organized separately by the Sovereign Tech Agency (STA) who brought an entire maintainer delegation with them to the event. It was great seeing people talking and collaborating around the specific concerns that maintainers have ranging from governance issues to more technical concerns. This was covered well already in the STA’s LinkedIn post.

My Tuesday started with a breakfast hosted by the STA at the German House. We had short remarks from Sovereign Tech Agency Managing Director Adriana Groh, Parliamentary State Secretary Thomas Jarzombek from Germany’s Federal Ministry for Digital Transformation and Government Modernisation, Amandeep Gill, UN Under-Secretary-General and Special Envoy for Digital and Emerging Technologies, Dr. Wolfgang Gehring, OSPO Lead at Mercedes-Benz Tech Innovation, Bastien Guerry, Head of Partnerships at Software Heritage, and Tiffany Farriss, CEO of Palantir.net and longtime Drupal Association board member. You can read more in the STA LinkedIn post about the breakfast.

On Wednesday, I was invited by the CURIOSS crew to their side event hosted at the Alfred P. Sloan Foundation offices as a special guest where we had some really interesting demos and discussions about measuring open source impact for academic OSPOs.

A few of us from CHAOSS started the day on Thursday with a breakfast meetup at a nearby coffee shop where I got to have interesting conversations with some awesome CHAOTICs before the main event!

OSPOs for Good

Thursday is the OSPOs for Good day, which is the main reason that I attend the UN Open Source Week. Again, the overarching theme has been about digital sovereignty. 

It started with a few keynotes. H.E. Amal El Fallah Seghrouchni, Minister Delegate in charge of Digital Transition and Administrative Reform, Kingdom of Morocco talked about how open source plays a fundamental role for long-term control of critical digital services to produce contextualized solutions to meet the needs of Moroccan people and are making strategic investments in open source to benefit from international cooperation while remaining in control of their future. Angellah Jasmin Kairuki, Minister of Communication and IT, United Republic of Tanzania spoke about how OSPOs allow governments to share and reuse what works for digital public goods with open source as a critical trigger for digital sovereignty that puts citizens first to change the posture from passive consumers. Bernardo Mariano Junior, Assistant Secretary-General and Chief Information Technology Officer, UN Office of Information and Communications Technology talked about how this event brings open source passion to the united nations from across the globe with open source as a strategic enabler allowing us to move faster toward digital sovereignty. Jim Zemlin, CEO of The Linux Foundation talked about AI and open source making similar points as what he delivered in the recent Open Source Summit North America. Louise McKeever, Chief Information Officer, Department of Agriculture, Food, & the Marine in Ireland spoke about their policy of open source first and how open source provides transparency, flexibility, and resilience for digital sovereignty.

Up next in the main room was a panel about Open Source and Digital Sovereignty in a Connected World moderated by Ruth Suehle who opened by talking about how the UN charter reflects open source principles. Sachiko Muto talked about how open source is coming to the top of the agenda again as it has been before, but now public sector OSPOs are the key to turning these endorsements of open source into operational capability to make it a reality. OSPOs unlock the ability to collaborate across both private and public sectors with public sector OSPOs playing a key role. Adriana Groh spoke about how the STA shows that the government can play a role in supporting the open source ecosystem via public money for public code, but there is also a need to be able to demonstrate impact for how you’re spending public money. Volunteers don’t maintain public infrastructure, like roads and bridges, so we shouldn’t expect them to maintain our critical digital infrastructure, either. Frank Karlitschek talked about how open source is strategic and critical in today’s geopolitical environment, but challenges for adoption are not technical. Arun Gupta spoke about OSPOs as a catalyst for interoperability and choice. 

After this we moved into breakout sessions. The first one I attended was about Financing Open Source and Digital Public Goods: A Multi-Stakeholder Approach discussing how we pay to sustain the digital ecosystem that we need over the long-term with a multi-stakeholder approach. DPGs need sustainable business models and implementers acting in the public interest to support those DPGs over the long-term. It should be a state responsibility to support the digital infrastructure that we all rely on, and the STA is piloting an impact measurement framework based on CHAOSS metrics to show that the public money has been well-spent. Supporting open source is not about charity, and governments need to get involved. Using tax payer money requires accountability for open source, but needs to be done in a way that doesn’t place the burden on those open source maintainers.

For the second breakout I went to ‘From Policy to Practice: Establishing Government OSPOs in Low- and Middle-Income Countries’, because I’m interested specifically in learning more about the progress they’ve made since I last heard about the OSPOs in Kenya and the Republic of Trinidad and Tobago. These 2 OSPOs were funded by the EU as pilots to build capabilities to allow more use of open source and to do it in a way that is more likely to be successful. There are also many commonalities between these 2 OSPOs and how they were established. Here’s an overview of what each of them are working on:

  • Kenya OSPO: Embedded in the Ministry to be self-sustaining over time. Their implementation needs to be aligned with core strategies of the Kenyan government and data protection policies. Focus areas include: training programs for open source to build capacity, programs for the local developer community, German-Kenyan digital dialog on open source, and as a foundation for the Kenya open source sovereign stack to make it easier for the government to select from the many OSS projects.
  • Trinidad & Tobago OSPO: Aligns with key strategies and plans focused on digital sovereignty. They are also embedded in the Ministry to be self-sustaining and have a remit to support the entire government. Focus areas include: a new national open source policy (including procurement policies putting open source first), shepherding a government-wide repository and software asset management register, a partnership with the University of West Indies for training government staff, and advising on OSS projects (including NextCloud implementation).  Historically, many countries have relied on big, proprietary software companies because they don’t have the capabilities and the OSPO is designed to change this and build these capabilities locally both for public servants and school children to build the next generation.

The next main session was about Open Source at the United Nations. The digital divide remains a problem in many less developed countries. Open source isn’t a niche issue, it’s essential as a practical pathway to bridge digital divides, and the UN is working hard to strengthen their use of open source to go further, faster. Open source allows the different groups within the UN to collaborate together and share ideas to build transparent and resilient technologies while protecting the free flow of information. The UN has been shifting to using open source more strategically to address geopolitical risks with flexibility and independence.

The final OSPOs for Good panel is Strategic Independence Across Layers of Governance. Open source is central to the digital policy agenda at the EU, and it is a fundamental part of their digital sovereignty strategy. This requires a transition from consuming to participating and collaborating. It’s not about standing apart, but moving to shared stewardship around the world. Open source provides strategic independence for governments to choose the solutions that best meet the needs for their specific countries. Open source itself isn’t the end goal; it needs to meet the needs of a country and support their goals. Brian Behlendorf worries about the long-term sustainability of open source software built by governments where they could be a single election away from no longer supporting a particular technology, but by working together with the private sector we might be able to work together for more sustainable open source software. Nithya Ruff mentioned that OSPOs can serve as a function to direct changes and connect institutions across governments for strategic independence and collaboration in open source.

I really enjoyed the entire OSPOs for Good day, and I’m looking forward to the Open Source Week Community Day tomorrow!

Open source, research, and other stuff I'm interested in posting.