[OSPO Book] Update 05-chapter.md - OSPO Metrics with CHAOSS

ospo-book/content/en/05-chapter.md

@@ -1,7 +1,100 @@
 ---
-title: "Chapter 5"
-status: To be Done
+title: "Chapter 5: Measuring and Communicating Impact by your OSPO"
+status: In Progress/In Review
 weight: 70
 ---
 
-# TBD
+## Introduction
+
+Metrics for metrics sake benefit no one. The average age of issues is 10.3 days. The total number of pull requests was 121 last month. We had 3 new companies join our community over the past 15 days. Without context, these metrics provide no insight, yet we are driven to reach for metrics to provide insight into our complex open source engagements. 
+
+There are a number of reasons why we need insights into open source projects. an organization built from open source would like to track contributions back to key projects. an organization that participates in an open source ecosystem wants to recognize potential failures and provide stabilizing resources as needed. an organization wants to do their part to ensure the longevity of open source software, in particular, the software that is meaningful to their business. And, of course, an organization needs to remain compliant with upstream license requirements and attend to security issues that can impact the ways they work.
+
+Knowing little to nothing about important open source projects is no longer a viable option, and open source community metrics can play an important part to gain insights into the projects we care about. In this chapter, we consider how community metrics can be placed in context and how this placement improves insight to drive better strategic decisions throughout an organization.
+
+## Measuring and Communicating Impact
+
+Beyond helping understand one open source project or a collection of projects, metrics can also play an important role in communicating impact. Finding consistent and meaningful ways to communicate impact is important for any organization unit, including open source program offices. Following the goal-question-metric approach used in the CHAOSS project, we present four goals that open source program offices can consider, alongside associated questions that can provide insight to the associated goals. Stemming from these goals and questions, we recommend a series of metric-related CHAOSS [Practitioner Guides](https://chaoss.community/about-chaoss-practitioner-guides/) to provide specific recommendations within an organization.
+
+Open source projects bring together companies with diverse skill sets and backgrounds, collaborating and sharing experiences to drive technological innovation, cultivate new talents, and improve overall development skills and competitiveness. Through open source projects, companies can directly engage with users, understand their needs, and update and refine products in a timely manner. Active and influential open source projects can also attract potential users and increase product exposure and market share. Additionally, users can become part of the development community, participating in product development and testing, promoting mutual communication and collaboration. 
+
+Open source projects provide a platform for companies to communicate and share technical knowledge, troubleshoot solutions, build best practices, and access necessary resources and technical support to accelerate product development and optimization. Communicating impact can be an important way to tie open source community metrics to key organization performance indicators. This playbook is meant to help companies take important steps toward tying open source community metrics to demonstrable impact. 
+
+### Communicating Impact: Open Source
+
+Beyond helping understand one open source project or a collection of projects, metrics can also play an important role in communicating impact. Finding consistent and meaningful ways to communicate impact is important for any organization unit, including open source program offices. Following approaches used in the CHAOSS project, we present four goals that open source program offices can consider concerning open source project engagement. Stemming from these goals, we recommend a series of metric-related considerations that could prove pertinent to specific organizational concerns. 
+
+![Communicating Impact Image](https://github.com/todogroup/ospology/blob/main/ospo-book/static/images/CHAOSS.Health.Impacts.png)
+
+#### Goal 1: Partner Impact
+
+Open source project work is premised on collaboration, a collaboration that often involves unexpected partnerships. These partnerships are aimed at developing non-differentiating technologies that each partner needs, yet does not necessarily have the resources or inclination to produce alone. Open source projects bring together organization members to work together in the pursuit of shared problems and this proximity can result in benefits beyond any one shared open source technology. Improved open source partnerships can have positive secondary effects, including stronger ties with upstream vendors, improved understanding of market rival positions, and direct interaction with downstream users. Key questions regarding partner impact include: 
+
+* What other companies are involved in our open source projects of interest?
+* What other companies are involved in our pull requests?
+* How are other companies involved in our pull requests?
+* What is the composition of involved companies as our vendors, rivals, and customers? 
+
+#### Goal 2: Community Impact
+
+There are ways that an organization can support community engagement by employees (e.g., contribution guidelines, intellectual property management, and license support). Support will often include why the community is important to your organization -- including a time and prioritization component in how much time an employee spends in external/upstream work. companies can observe employees as good citizens for reasons of personal and organizational gain, and help employees understand their importance in bridging between the organization and the community. Key questions to consider regarding community impact include: 
+
+* What percentage of employee contributions are merged?
+* What percentage of employee issues are closed without conversation?
+* How many of our employees have maintainer or leadership roles in key open source projects?
+* Have upstream contributions helped modernize tech skills for employees?
+* Which projects do our employees make over 50% of the contributions?
+
+#### Goal 3: Ecosystem Impact
+
+Working with open source is never easy as rival corporations may dominate upstream projects that your organization is interested in, upstream projects may unexpectedly change licenses, and contributor agreements, whether individual or organizational, can be complex to understand and adhere to. Clearly, such challenges can be overcome and often include strategic engagement with the projects your organization aims to benefit from. Open source ecosystems are economic and social systems comprising different companies, motivations, and requirements intended to support production and demands. In an effort to ensure the efficiency and durability of any open source ecosystem, companies must not only monitor the ecosystem's long-term viability but also engage within the ecosystem when problems are identified and stabilization is required. Key questions to consider regarding ecosystem impact include: 
+
+* What percentage of our suppliers provide open source software bills of material?
+* What is the long-term viability of the open source projects we rely on?
+* What is the risk to the ecosystem if an open source project becomes unviable?
+
+#### Goal 4: Organizational Impact
+
+Engagement with open source communities includes working in the upstream to effectively use open source software in organizational products. In this, there is a need to monitor the intake of open source software for infosec, legal, and engineering reasons. Companies can establish software intake processes, working with teams to either technically track or socially consider issues related to open source intake. organization impact can also include working downstream with projects and companies that rely on your organizational products. This can include working to gain a clearer picture of  the open source that is in your shipped products. Organizations can work in securing and regulating their own internal open source processes in an effort to improve product development activities. Key questions to consider regarding organization impact include: 
+
+* What characteristics does an organization inspect related to inbound open source software? 
+* What product-level software and infrastructure contains open source software dependencies? 
+* How is OSPO strategy aligned with organizational strategy and departmental objectives?
+* How often is OPSO strategy used to guide business decision making processes?
+* How does the use of open source influence organizational value?
+
+## A Case of Organizational Impact: Open Source Use and Intake
+
+Measurement of open source projects helps your OSPO go beyond just communicating impact by taking steps to improve projects in ways that reduce your risk and make their use even more impactful for your organization. As part of an OSPO’s open source strategy, you can consider improvements that will allow you to show even greater impact for your efforts in future years. These improvements can be in open source projects that stem from within your organization and in the important upstream projects where your employees contribute. The CHAOSS project has a series of [Practitioner Guides](https://chaoss.community/about-chaoss-practitioner-guides/) that can help you address the prior goals and questions and demonstrate impact by increasing contributor sustainability, improving responsiveness, and expanding organization participation. 
+
+As an example of organizational impact, Linåker et al. (2024) conducted a study that explored how open source intake processes could be constructed to accommodate considerations of open source project health-related measures. Analyzing the health of open source projects is a critical practice for organizations to ensure the robustness and reliability of their software systems, both when considering the intake of new open source components, and in monitoring existing dependencies already integrated and deployed in production. If the level of upstream open source project health is insufficient, an alternative sourcing decision needs to be considered (e.g., adopt another open source solution or build something from scratch), or if possible and strategically motivated, contribute and engage in the concerned open source project to improve its health.
+
+### The Many Facets of Open Source Project Health
+Analyzing the health of an open source project is, however, a complex task. A survey of literature highlights 107 different health-related concerns ranging across social and technical issues, both in project-centric and ecosystem-wide contexts (Linåker et al., 2022). Through interviews with 17 industry and community experts, the 107 different indicators were condensed into a framework of 21 health aspects considering community productivity and stability, orchestration, and production processes and outputs. For each of the 21 aspects, several attributes were defined to help break down and enable the analysis of a concerned aspect regarding the health of an open source project.
+
+Interviewees stressed that organizations need to be aware of the type and traits of the open source project being analyzed, as these factors may influence how the different health aspects of the health framework potentially should be applied and evaluated. Factors included the life cycle, complexity, and governance concentration of the open source project and its strategic importance to the organization analyzing the project as part of its intake process. When introducing open source project health assessments, organizations need to consider these factors and accordingly only compare between open source projects with similar traits (e.g., complexity and life-cycle stage) (Lumbard et al., 2023).
+
+As highlighted by a majority of the interviewees, each organization needs to answer the question of what aspects and attributes to use and how to consider the various types and traits of open source projects, as they each faced unique risks and challenges based on their specific context, such as industry, market, and technology. Further, as collecting and analyzing all data points is a cumbersome and costly process, there needs to be prioritization of what aspects and attributes to consider when designing health assessments as part of the intake process.
+
+### Implementing Health Assessments in Practice
+In their study, Linåker and colleagues (2024) demonstrated how their health framework can be tailored through the application at a large international automotive manufacturer. They narrowed down health attributes to a questionnaire and designed a candidate process suited to the company's needs based on interviews, focus groups and trials within the company.
+
+The proposed process' focus on semi-automating the health assessments, where open source components at the intake stage are manually inspected using standardized checklists with automated tool support as needed. Inspections need to be lightweight yet rigorous enough to capture the concerned health aspects of importance. A lightweight documentation process is also used to persist and index analysis for future follow-up, peer-review, and training.
+
+A quantitative screening and monitoring process is additionally required for open source components already integrated and deployed. This process should idealy be automated as large amounts of dependencies commonly exist, and manual overviews and inspections are not applicable. Tooling should ideally be customized and integrated into CI/CD pipelines or run on regular occasions.
+
+The quantitative screening should run high-level tests on dependencies tailored based on the type of ecosystem and dependencies and flag projects, directing attention where indicators together point towards potential open source project health issues. Concerned developers or analysts then follow up with manual inspections. For the tooling, open source projects such as CHAOSS’s GrimorieLab and Augur provide initial candidates to adopt and tailor based on internal needs.
+
+Continuous training and follow-ups are critical to implementing a health assessment process. Workshops for introducing checklists and analysis processes are suggested, as well as recurrent feedback sessions for presenting analyses of OSS projects, thereby encouraging discussions, knowledge-sharing, and a critical mindset. Ideally, the health assessment is integrated as a standard practice in software development and Q&A.
+
+### Summary of a Case of Organizational Impact: Open Source Use and Intake
+The case study of Linåker et al. (2024) presents organizations with a valuable approach for proactively identifying potential health issues of open source projects that they rely on. Findings can be used as practical guidance and complement when consulting existing sources such as the CHAOSS project and the OpenSSF scorecard project. Applying the approach Linåker et al., (2024) for diagnosing symptoms early and applying necessary treatments, organizations can mitigate risks and ensure their OSS dependencies' long-term viability and security. This proactive approach enhances the stability and reliability of software products and contributes to the overall sustainability of the open source ecosystem.
+
+## Resources
+CHAOSS Practitioner Guides. Available at: https://chaoss.community/about-chaoss-practitioner-guides/
+
+Linåker, J., Olsson, T., & Papatheocharous, E. (2024). How to Assess the Health of Open Source Software dependencies in an Organization's Intake Process: Insights from an Interview-survey and Case Study. Under review in a Software Engineering journal.
+
+Linåker, J., Papatheocharous, E., & Olsson, T. (2022). How to characterize the health of an Open Source Software project? A snowball literature review of an emerging practice. In the 18th International Symposium on Open Collaboration. DOI: https://doi.org/10.1145/3555051.3555067
+
+Lumbard, K., Germonprez, M., and Goggins, S. (2023). An Empirical Investigation of Social Comparison and Open Source Community Health, Information Systems Journal, 34(2), 499-532.