[ospo book] fix resource link in 05-chapter.md

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

@@ -6,7 +6,7 @@
 
 - [Introduction](#introduction)
 - [A Case of Organizational Impact](#a-case-of-organizational-impact) - `✅ Assessment`
-- Resources - `📚 Continue Here`
+- [Resources](#resources) - `📚 Continue Here`
 
 
 ## Introduction
@@ -15,7 +15,7 @@
 
 Metrics for metrics sake benefit no one. Consider these metrics: 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. Some example reasons are: 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.
 
 In the past, it may have been possible to get away with knowing little to nothing about important open source projects. This is no longer a viable option, however, so as we get to know the open source projects we care about we can use open source community metrics to help us. In this chapter, we consider how community metrics can be placed in context and how together they improve insight to drive better strategic decisions across an organization.
 
@@ -52,15 +52,15 @@
 
 **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? 
@@ -72,7 +72,7 @@
 
 ### 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.
 
@@ -80,7 +80,7 @@
 
 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.
 
@@ -103,6 +103,6 @@
 `📚 Continue Here`
 
 - [CHAOSS Practitioner Guides](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., 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.