Tag Archives: ospo

General

Part 3: Determining Value and Viability Using CHAOSS Practitioner Guides

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

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

Demonstrating Organizational Value

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

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

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

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

Assessing Viability

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

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

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

Organizations should be thinking strategically about project risks in light of how they are using the projects. If it’s a critical part of a technology stack, it should be as low of a risk as possible. On the other hand, if an open source project is used as a small part of some non-critical infrastructure, an organization can accept more risk. Assessing viability and thinking about it from the perspective of risk and which risks to accept is an important first step, but it’s also important to think about which risks can be mitigated to improve viability. The best way to mitigate many of these risks is by paying employees to contribute to the projects that are most important to your organization. This provides an opportunity to improve viability and sustainability, but it also provides insight into where the project is heading and how things are going, so that if something changes in the project to further increase risk, it might be easier to anticipate those changes.

Summary

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

As always, if you want help with either of these topics or more generally need advice or feedback on open source strategy, sustainability, governance, or related open source topics, I’m available for consulting engagements.

Additional Resources:

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

General

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