Tag Archives: contributor strategy

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

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