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:

• Practitioner Guide: Demonstrating Organizational Value
• Practitioner Guide: Assessing Viability

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:

• CHAOSS Practitioner Guides
• KubeCon talk by Bob Killen: Why is this so hard? Conveying the Business Value of Open Source (slides and video) and the White Whale talk from the Linux Foundation Member Summit.
• Assessing the Viability of Open Source Projects
• Viability: An Open Source CHAOSS Metric (Super)Model
• Metrics for OSS Viability
• Guide for OSS Viability: A CHAOSS Metric Model
• CHAOSScast Episode 84: Community Viability – how Verizon thinks about OSS risk

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

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:

• CHAOSS Practitioner Guides
• Beyond the Repository by Amanda Casari, Julia Ferraioli, and Juniper Lovato
• From Data to Action: Building Healthy and Sustainable Open Source Projects in IEEE’s Computer, pp.74-78.
• Strategy Before Metrics
• Responsibly Sunsetting OSS Projects: A Guide for OSPOs
• Sustainable Open Source Leadership

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

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:

• CHAOSS Practitioner Guides
• Beyond the Repository by Amanda Casari, Julia Ferraioli, and Juniper Lovato
• From Data to Action: Building Healthy and Sustainable Open Source Projects in IEEE’s Computer, pp.74-78.
• Contributor Sustainability Impacts Risk and Adoption of OSS Projects
• Strategy Before Metrics
• Using CHAOSS Practitioner Guides to Improve your OSS Projects
• What can your OSPO do about power dynamics, rug pulls, and other corporate impacts on OSS sustainability?

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

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:

• The Impact of Funding for Sustainable Open Source Projects
• Contributor Sustainability Impacts Risk and Adoption of OSS Projects
• Sustainable Open Source Leadership
• From Data to Action: Building Healthy and Sustainable Open Source Projects
• Funding Open Source Sustainability at CHAOSScon and FOSDEM
• From First PR To Lifelong Impact: Helping People Thrive in Open Source
• Educating the Next Generation of Open Source Project Contributors
• Open Source Software: A Path to Building Leadership Skills

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.

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:

• A Strategic Approach to Demonstrating the Value of OSS Efforts
• A Strategic Approach for OSPOs
• Demonstrating Organizational Value
• More about Demonstrating Organizational Value
• OSPO Contribution Strategies to Demonstrate Value
• CURIOSS: Demonstrating Open Source Value
• Using CHAOSS Practitioner Guides to Improve your OSS Projects
• From Data to Action: Building Healthy and Sustainable Open Source Projects
• Contributor Sustainability Impacts Risk and Adoption of OSS Projects

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:

• Responsibly Sunsetting OSS Projects: A Guide for OSPOs
• CHAOSS Practitioner Guide: Getting Started with Sunsetting an Open Source Project
• CHAOSScast Episode 123: Practitioner Guides: #6 Sunsetting an Open Source Project
• CHAOSS Practitioner Guides
• Assessing the Viability of Open Source Projects
• Stefka Dimitrova on When and How to Deprecate an Open Source Project (Part 1 and Part 2) along with a video from the Open Source Summit in Europe in 2022 about Simple Steps for a Calm “Sunset”. 
• Contributor Sustainability Impacts Risk and Adoption of OSS Projects

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!

While I spend more time talking about open source project governance, I’ve also started thinking more about public governance and how open source can be a key part of a digital sovereignty strategy. But the open source impact on public governance goes beyond just digital sovereignty, which is why I was so excited to be invited by OpenGov Africa to talk more about the intersection between open source and public governance last week. The slides and video for that talk are also online.

Related Resources:

• Good Governance for Open Source Projects
• 4 Minute Governance Overview Video
• Digital Sovereignty Runs on Open Source
• United Nations: OSPOs for Good Day
• UN Open Source Week Part 2: Digital Sovereignty and Resilience
• Open Source Software Driving Digital Resilience, Sovereignty, and Sustainability
• The Impact of Funding for Sustainable Open Source Projects
• Funding Open Source Sustainability at CHAOSScon and FOSDEM

Image by the CNCF (CC BY-NC 2.0)

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:

• Demonstrating Organizational Value
• More about Demonstrating Organizational Value
• OSPO Contribution Strategies to Demonstrate Value
• CURIOSS: Demonstrating Open Source Value
• Using CHAOSS Practitioner Guides to Improve your OSS Projects
• From Data to Action: Building Healthy and Sustainable Open Source Projects
• Contributor Sustainability Impacts Risk and Adoption of OSS Projects
• A Strategic Approach for OSPOs

However, measuring the impact of funding isn’t easy, and there is no one approach, since the goals and objectives for funding vary widely for different types of funding organizations and different open source projects. It’s also important to consider that not all funding provides positive outcomes, since money can introduce tension within projects. In 2024 to help organizations navigate these challenges, I collaborated with several people to write an academic paper on this topic: A Toolkit for Measuring the Impacts of Public Funding on Open Source Software Development. We recently turned this paper into the CHAOSS Practitioner Guide: Funding Impact Measurement, which is much shorter and focused on practical steps that organizations can take to justify the impact of funding provided to open source projects and maintainers. 

The guide talks about the challenges of funding and the lessons we’ve learned along the way in addition to a section to help you navigate the actions that you can take to measure the impact. The “How to Take Action” section of the guide has three sections. 

• First, start by understanding the context. This includes understanding the funding objectives and how the funding is structured for the projects being funded, considering project life stages and social structures, and accounting for salary structures and cost factors for different types of contributors across multiple regions.
• Second, look at economic, social, and technological impacts across multiple dimensions. The potential social, economic, and technological impacts can be both positive and negative, direct and indirect, internal (i.e. within a project) and external (i.e. ecosystem), and manifest over different time horizons. The guide contains examples of how to think about each of these areas.
• Third, using various methods to combine scalable quantitative measures along with contextual depth from qualitative data to better understand the funding impact. Mixed-methods approaches offer the best of both words: scalability and contextual depth. The guide and the paper have more details about how to do this.

This post doesn’t tell you how to justify getting new funding for open source efforts, so if you want to start funding open source projects, you need to demonstrate the value of that work to your leadership. There is a Demonstrating Organizational Value practitioner guide, and I’ve talked about demonstrating organizational value in several posts on this blog, which are linked in the “Related Resources” section below to provide a starting point. However, even if you haven’t yet started funding projects, you can still put together a plan for how you’ll measure the impact of that funding as part of demonstrating the value and making a case to your leadership along with the funding request.

I’ll conclude with a short quote from the guide:

“Funders need to be able to understand the impacts of past funding in order to secure buy-in for future funding as well as to 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. We hope that 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.”

If you want help with measuring the impact of your funding or with other OSPO strategy topics, I’m available for consulting engagements.

Related Resources:

• CHAOSS Practitioner Guide: Funding Impact Measurement
• Osborne, C., Sharratt, P., Foster, D., Boehm, M., 2024, ‘A Toolkit for Measuring the Impacts of Public Funding on Open Source Software Development’, paper presented to OpenForum Academy Symposium, Boston,  Massachusetts, 13-14 November, Available at https://doi.org/10.48550/arXiv.2411.06027 
• CHAOSS Funding Impact Measurement WG (meets every other Wednesday)
• The Impact of Funding for Sustainable Open Source Projects
• Funding Open Source Sustainability at CHAOSScon and FOSDEM
• CHAOSS Practitioner Guide: Demonstrating Organizational Value
• Demonstrating Organizational Value
• More about Demonstrating Organizational Value
• CURIOSS: Demonstrating Open Source Value