Tag Archives: ospo

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!

General

How OSPOs can Measure the Impact of OSS Funding

So much of the critical infrastructure that we all rely on contains open source projects that are under-resourced and struggling. One (of many) ways to help these projects is by funding development and maintenance so that contributors can focus on this work, but times are tough. Organizations and OSPOs are feeling the pinch, and it can be hard to justify continuing to fund open source projects. Measuring the impact of open source funding is something that I’m passionate about because the best way to continue to get leadership to give you money to fund open source is by showing them the impact of that funding. 

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:

General

Podcast: What Does a Healthy OSPO Actually Look Like?

I’ve been spending quite a bit of time recently reflecting on how Open Source Program Offices (OSPOs) and our work in open source is evolving in a world where most of us don’t have as many resources as we need to support our open source work while at the same time, we’re experiencing an increasing reliance on open source as a key strategy for digital sovereignty. I started doing open source strategy work back in the very early 2000s at Intel, and in the 5 years before CHAOSS, I was in open source strategy roles at Pivotal and later VMware, so I’m looking forward to spending more time working with OSPOs as a consultant. 

My recent conversation with Rachel on the Contribute: Beyond the Code podcast was a great excuse to reflect on some of what I’ve been thinking and writing about related to OSPOs. You can watch the full episode on YouTube, Apple, or Spotify.

We talked about how OSPOs can:

  • demonstrate the value of open source work within an organization.
  • have a bigger impact in open source when they go beyond compliance 
  • scale their efforts through documentation
  • balance internal enablement along with external engagement
  • track the most strategic open source projects for your organization
  • responsibly sunset (archive) open source projects
  • develop processes that make it easy for employees to engage in open source

Additional Reading:

General

OSPO Contribution Strategies to Demonstrate Value

Many OSPOs struggle to demonstrate the value of their organization’s contributions to open source projects. A good way to demonstrate the value of these open source contributions is by showing how the work helps your organization achieve its goals, and this is an approach that I’ve used when working in several different companies.  

Every leadership team has to look across the entire organization and prioritize the efforts that have the biggest overall impact on the organization as a whole. This means that if you want your leadership to continue to staff and fund your OSPO or other open source teams, you need to make the case for why your work is as important or more important than other efforts that are also competing for limited resources. Having a clear open source strategy where you can tell the story of how the open source work helps achieve the organization’s goals is a great way for leadership to understand the importance of the work so that you can continue to do it. 

Clearly articulating the importance of your contributions to upstream projects should be an important piece of that open source strategy. This often has 2 components: 1) identifying which projects are most strategic / critical for your organization and 2) creating contribution strategies for individual projects.

Identifying Strategic Projects

When deciding where to focus your organization’s upstream contributions, I’ve seen a lot of people struggle with the difference between open source projects that are frequently used within an organization vs. the projects that are truly strategic. The way I like to think about this is by asking whether I could easily drop in a replacement. You might use a tiny library in a bunch of your products to make some task quicker and easier, but if you could easily replace it with something else, like another similar library or you could re-write it yourself pretty easily, then it’s not likely to be a strategic project that is critical to your organization. Something like Kubernetes on the other hand is an incredibly complex piece of software that could not be easily replaced, and if you’re relying on it to be able to deliver products and services to your customers, then this would probably be a strategic project for you. You’re unlikely to get much value out of contributing to that tiny library, but you might get value out of contributing to those more strategic projects. 

When I was at VMware, I was responsible for maintaining our list of strategic projects. This came about because executives would ask which open source projects were most important to us, and before creating the strategic projects list, all we had to give them was the list of packages that appeared most frequently in our products, but this wasn’t what leadership wanted. They wanted to know which open source projects were most critical or most strategic for us. We started creating a list of strategic projects by talking to the product leads in our business units to ask them what open source projects they relied on and couldn’t deliver products to our customers without those projects. It provided a window for executives into what projects were most important and most strategic while also helping our business units coordinate with each other when they were engaging in the same projects. 

Contributions Strategies for Individual Projects

This strategic projects list also provided a start toward justifying having people contributing to those projects, but it can help to dive into the details of some of these projects to look at project health, feature maturity, and other aspects of each project to decide where you might need to contribute. For example, when I worked at Pivotal, I was responsible for our open source strategy, and Kubernetes was a big part of that strategy. This was before the VMware acquisition of Pivotal, and we were in the process of making the shift from using Cloud Foundry as the base for our main products to using Kubernetes. This was a huge shift for the company. Pivotal was one of the creators of Cloud Foundry and we had a ton of influence in that project, while we were just getting started with Kubernetes. I spent quite a bit of time talking to the people in leadership who were driving this shift along with the people responsible for driving the individual product strategies with a focus on where we wanted to be in a few years. I also started engaging directly within the Kubernetes community to explore the different aspects of Kubernetes while talking to our engineers about which parts of Kubernetes were missing features or lacking maturity so that we could match what we were going to need in the next few years with the areas within Kubernetes that would need work if we wanted to base our products on top of it.

I used all of this information to create a written strategy that clearly tied our open source Kubernetes work back to our overall company mission and goals, and I was able to get people allocated to upstream Kubernetes by showing how our long term product strategies relied on specific areas within the Kubernetes code base, and outlining where we needed to make contributions to support those products. We then continued to track those contributions so that we could show the value that we were providing back to the company. 

This was my approach when I was at Pivotal and later VMware, but every company and every open source project is unique, so this requires customizing your approach so it works for your organization. The CHAOSS project has an entire Practitioner Guide on the topic of Demonstrating Organizational Value with some additional ideas for how to demonstrate and frame the business value of your open source work. If you want feedback or help with your open source strategy and how to demonstrate value for your organization, I’m also available for consulting engagements.

Additional Resources:

Photo by Ian Hutchinson on Unsplash

General

OSPO Information at Scale

The economy is tough right now, and many OSPOs (Open Source Program Offices) are feeling the pinch. We’ve been seeing layoffs and downsizing that have impacted quite a few OSPOs, which has left people needing to continue to do much of the same work, but with fewer people.

I’ve always been a fan of using documentation for scalability, and there are some common questions people tend to ask me, so I try to turn those into blog posts. This allows me to provide information to a wider variety of people, but also, when I get questions, I can send a link to a blog post along with some additional advice and/or resources depending on how they asked the question. The work that OSPOs do within organizations lends itself nicely to providing information at scale, since that work often involves policies, advice, and best practices that can be used by other people working across the rest of the organization.

When I was at VMware, we had a robust set of self-service best practice guides and resources available internally to all employees. It had sections about compliance that were focused on allowed licenses and internal processes, but it went way beyond just compliance. We had best practices for how to participate in open source communities, how to manage open source projects, automated testing, releasing open source projects, and so much more. We also had a Slack channel where people could ask questions, and the answers often involved a link to one of these resources. But the best part was that often those answers and links came from people outside of the OSPO. Within the OSPO, we monitored the channel carefully to make sure that people were providing accurate information, and even though we had a large OSPO, VMware was a very large company, and our guides along with the Q&A channel really helped us scale.

Unfortunately, our guides were not publicly available, so I can’t link to them, but I have included a link to some similar policy examples and templates that others have published in the additional resources section below. If you lead or work in an OSPO, I encourage you to think about how you can use documentation and Q&A channels to help scale your work, and if you want feedback or help with scaling your OSPO or related topics, I’m available for consulting engagements.

Additional Resources: 

Photo by Ilya Semenov on Unsplash

General

SCALE 23X: Corporate Impacts on OSS Sustainability

I’m thrilled to be going back to SCALE this year to talk about corporate impacts on open source sustainability!

I’ve blogged here before about the New Power Dynamics in Open Source: Rug Pulls, Relicensing, and Forks along with What your OSPO can do about power dynamics, rug pulls, and other corporate impacts on OSS sustainability, so my talk at SCALE will be an evolution of those ideas.

Here’s a quick video about why I love SCALE and a preview of my presentation topic.

I hope to see some of you at SCALE in Pasadena!

Additional Reading:

General

A Strategic Approach for OSPOs 

I think we’ve all been on teams where everyone is working, but no one is thinking about whether it’s the “right” work. It can be too easy to go on autopilot and keep doing the same things without thinking about whether / how those activities fit within the goals of the overall organization. I’ve built my career around taking a strategic approach to the work that my team is doing by making sure that our efforts support the overall strategies of the organization. Most recently, I did this as Director of Open Source Community Strategy at VMware and before that as Pivotal’s Open Source Strategy Lead. I’ve given loads of conference talks and written many blog posts with this strategic approach as the underlying theme. Last week, I read a LinkedIn post and blog post from David Hirsch that got me thinking more about this, and those ideas just kept rolling around in my head until I decided that I should blog about how OSPOs (Open Source Program Offices) can take a more strategic approach. 

One piece of David’s post talked about how OSPOs can play a critical role in digital sovereignty for European companies by helping them make better technology choices at a strategic level. I believe that this is absolutely critical for European companies, but thinking strategically is also important for all OSPOs, which is the focus of this post.

Being proactive and thinking strategically about how you are helping your organization meet their goals and objectives is something that can help your OSPO stand out as an important part of the business. This is especially true for new OSPOs, since it can help you justify continuing and growing your open source efforts, but it’s also something that established OSPOs should revisit regularly to make sure that you are still doing work that is valued within your organization. OSPOs often struggle to demonstrate the value of their work in a way that resonates with the people in leadership positions within their organization. Creating and regularly updating an open source strategy can help OSPOs frame their discussions with leadership to demonstrate the value of their open source efforts in ways that resonate with leadership and show how the open source works fits into the strategy of the organization as a whole. Once you have an OSPO strategy that aligns with the strategy of your organization, then you can figure out what you need to measure to show whether you are achieving your goals.

Another area that can benefit from an OSPO’s more strategic approach is in assessing risks and viability of the open source projects that your organization is consuming. Many organizations don’t have a rigorous or strategic process for selecting the most viable dependencies. Often product teams, or even individual software developers, select open source projects because they fill a particular technical need without any assessment of the viability of the project or the risks they might be taking by using it. Is the project controlled by a single company or a foundation? Who contributes to the project? Is the project at the risk of a rug pull or similar disruptions? Assessing the viability of open source projects, especially ones that have the potential to impact your business, is a good first step toward managing risk and reducing the chances of potential business disruptions. But it’s also important to look beyond just assessing the viability of individual projects and to look at viability and risk with a more holistic approach that includes assessing the risks associated with cloud infrastructure, data storage and access, use of AI models, vendor lock-in, and more.

Another critical piece of an OSPO’s strategy is around contribution to open source projects. By having employees actively participating and contributing to the projects that are most strategic for your organization, they can influence project direction, fix bugs, add features, otherwise improve the health and sustainability of the critical projects for your organization. I also like to think of contribution as a way to anticipate and mitigate risks as part of thinking about viability. When assessing viability, you can include whether contributing to a project might help improve viability. Organizations have the power and resources to make real improvements within open source projects, and corporate involvement and contribution can positively impact the sustainability of our projects.

I only scratched the surface of a few topics here. It isn’t possible to cover every part of an OSPO’s strategy in one blog post, so there are certainly other areas, like business impacts, licensing and compliance, governance, policies, and more. What’s important is to think about what your organization is trying to achieve and how your OSPO can play a strategic role in helping your organization be successful. If you want feedback or help with your open source strategy, I’m available for consulting engagements.

Additional Resources:

Photo by Karolina Kołodziejczak on Unsplash

General

Responsibly Sunsetting OSS Projects: A Guide for OSPOs

Not every open source software project can or should live on forever: priorities change, technologies evolve, and interests shift over time. From a corporate perspective, you don’t want to have neglected or abandoned open source projects with security vulnerabilities owned by your organization. However, responsibly sunsetting an open source project is more than just clicking the archive button on your repository. You should also be thinking about how you communicate the change and give any existing users time to transition. 

Your organization’s customers and the users of your open source projects might trust the projects found in your repositories because of their relationship with your organization. This is why it’s particularly important for companies to monitor the open source projects owned by the organization and responsibly sunset them when they will no longer be updated. One of the benefits of having an OSPO is that they can help the rest of the organization with processes and best practices for responsibly sunsetting projects. 

When I worked in VMware’s OSPO, we had a process for monitoring and sunsetting projects that we’ve documented in the CHAOSS Practitioner Guide: Getting Started with Sunsetting an Open Source Project. This guide uses change requests, new issues, and forks as metrics that can help you identify abandoned or neglected projects along with people who might still be using those projects. The guide also has communication steps for what to do before you archive the project, and there is even a section with special considerations for sunsetting active projects, which can happen when a company is making a shift in strategy and no longer plans to work on a project.

All of these details can be found in the guide, and you can also listen to the CHAOSScast podcast episode where Stefka Dimitrova and I recently discussed the guide and the process we used at VMware. Here’s a short quote from the guide:

“Many open source projects, even widely used ones, become abandoned for a variety of reasons (e.g., evolving interests, family situations, employment changes), but abandonment can be done in a responsible way by proactively sunsetting the project (Miller et al. 2025). Sunsetting is an important consideration for corporate environments where it can be easy to lose track of projects that were created by employees who later walked away from the project and left if abandoned. You don’t want abandoned open source projects with security vulnerabilities sitting in your organization’s source code repositories where someone might trust that project simply because they trust your organization. Finding inactive projects and responsibly sunsetting them is a good business decision and something that many open source teams / Open Source Program Offices (OSPOs) do on a regular basis.”

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

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

Additional Reading: