Dark and light blue Chihuly glass sculpture with curved octopus-like tentacles planted in a garden next to blue thistles in the Seattle Chihuly Garden.
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.