diff --git a/ospo-book/content/en/04-chapter.md b/ospo-book/content/en/04-chapter.md index 1943b5f6..648bfce8 100644 --- a/ospo-book/content/en/04-chapter.md +++ b/ospo-book/content/en/04-chapter.md @@ -1,90 +1,128 @@ --- -title: "A Deep Dive into Day-to-Day Operations" +title: "4 - Day-to-Day Operations" status: Completed weight: 60 --- -* [Introduction](#introduction) -* [Assessing Daily Operations](#assessing-maturity-of-open-source-program-office) - `โœ… Assessment` -* [Recommendations](#recommendations) - `๐Ÿ’ก Recommendations` -* [Resources](#resources) - `๐Ÿ“š Continue Here` +- [Introduction](#introduction) + - [Assessing Daily Operations using the OSPO MindMap](#assessing-daily-operations-using-the-ospo-mindmap) - `โœ… Assessment` + - [Getting started with OSPO MindMap](#getting-started-with-ospo-mindmap) + - [OSPO MindMap Limitations](#ospo-mindmap-limitations) + - [Recommendations](#recommendations) - `๐Ÿ’ก Recommendations` + - [Scenario #10](#scenario-10) + - [Scenario #11](#scenario-11) + - [Resources (TBD)](#resources-tbd) - `๐Ÿ“š Continue Here` # Introduction -Understanding the day-to-day activities of those managing open source operations within an organization is crucial for several reasons. First and foremost, it sheds light on the fundamental tasks that an OSPO must focus on to ensure the organization's -technology strategy and aefforts aligns with open source best practices. This knowledge helps to streamline engineering processes and maintain compliance with open source licenses and security measures. +OSPO day-to-day operations encompass a broad spectrum of activities aimed at enhancing open source engagement and compliance within the organization, including: -OSPO day-to-day operations encompass a broad spectrum of activities aimed at enhancing open source engagement and compliance within the organization, including providing personalized technical support on licensing and software selection, leveraging automation tools for process efficiency and security, -developing and disseminating educational materials, strategically allocating resources, managing risks through comprehensive assessments of the tech stack, sponsoring and engaging with open source communities and foundations, measuring technical debt in projects, and facilitating coordination -across various organizational divisions to align both technical and non-technical objectives. - -- **Personalized Technical Support:** Involves answering questions on all aspects of open source, including license +- **Direct Open Source Support:** Involves answering questions on all aspects of open source, including license compliance, selecting open source software, and interactions with vendors. It also includes engaging with the community and partners, securing sponsorships, and organizing open source events. -- **Automation tools:** Efficiency in process automation is key because policies alone may not always be effective as - they are not always followed. Managers are usually seeking effective options for automation tooling, including for - security automation and reporting, such as the integration of scorecards. +- **Automation Tools:** Creating process automation to support open source policies is important because policies alone may not always be effective. Managers know that their workers will not always follow policy and therefore want effective options to automate use, management and tracking of open source components. Automation is useful in many areas of open source including licence compliance, and security. -- **Documentation, Training, and Education:** Crucial to ensure that individuals are qualified to assess projects. - Developing training materials and documentation and aiding teams to produce these across different departments are key +- **Documentation, Training, and Education:** An OSPO can play a leading role in ensuring that individuals are qualified to assess open source projects for use in the organization. Developing training materials and documentation and/or aiding teams to produce these across different departments are key tasks. -- **Resource Allocation:** Requires a strategic approach to prioritize effectively. +- **Resource Allocation:** There can be a lot of areas that an OSPO can offer value to an organization. Therefore, prioritizing work and allocating resources strategically and tactically is an important activity that will improve the OSPO's impact. + +- **Risk Management:** OSPOs are well-placed to take a holistic view on the risk that the organization faces when using open source projects. It is useful for the OSPO to assess the risks by obtaining a comprehensive view of the organization's tech stack. This may include generating SBOMs which allow the OSPO to consider the risks in software from vendors, legacy software, and proprietary software as well as in open source. This is more about a business assessment perspective rather than just data gathering, as risk can only be managed, not eliminated. Optimizing SBOMs is about balancing risks against benefits. + +- **Sponsoring Open Source Communities and Foundations:** Your organization depends on open source. The projects in open source are only as healthy as their communities, and you can invest your time and money in supporting communities either directly or through Foundations. These relationships need to be understood and managed with care to achieve outcomes that will benefit the projects and your organization. Sometimes money is not the best fix for a problem, and fostering a closer partnership and providing development, marketing, or programmatic support is more useful. + +- **Measuring Technical Debt:** Providing knowledge on how to measure the technical debt on an open source project helps to determine the risks associated with the project and, when done in collaboration with the project community, is a form of educational advocacy to help projects improve and sustain themselves. + +- **Coordinating with Various Parts of the Organization:** It can be helpful to check that you know all your stakeholders, and have the right amount of interaction with them. Take a look at the OSPO flower diagram (Chapter 3) for help mapping interactions. + +- **Giving Advice on Open Source Consumption:** The OSPO considers both the strategic view on which open source projects to consume and on the best practice for using the selected projects. The OSPO should provide reference materials and guidance on how the company should select which open source projects it uses and how it manages them. Guidelines and policy can be purely technical or can include considerations based on open source project health and practices, like the [Secure Supply Chain Consumption Framework (S2C2F)](https://github.com/ossf/s2c2f/blob/main/specification/Secure_Supply_Chain_Consumption_Framework_(S2C2F).pdf). + +## Assessing Daily Operations using the OSPO MindMap + +### Getting Started with OSPO MindMap + +To get an overview of the potential activities of an OSPO we offer you the [OSPO Mind Map](https://todogroup.org/resources/mindmap/). The OSPO Mind Map outlines the main responsibilities, roles, behaviors, and team sizes within the ecosystem of an OSPO. + +### OSPO MindMap Limitations + +The contributors to this book have identified challenges in implementing the mind map, particularly in filtering responsibilities based on the organization's level of open source engagement. Because of this, the aim of this chapter is to provide an in-depth classification of these activities, grouped by levels of open source engagement. This book uses Ibrahim H.'s open source activity engagement model โ€” previously seen in Chapter 2 โ€” as it is relatively simple, and is not focused on corporate structures. -- **Risk Management:** Involves assessing the risks the organization faces. Obtaining a comprehensive view of the - organization's tech stack, such as generating SBOMs, and considering software from vendors, legacy software, and - proprietary software is crucial. This is more about a business assessment perspective rather than just data gathering. - Decisions need to be made on whether to optimize SBOMs or to allocate time to other areas. +| Consumer / User Stage | +| --- | -- **Sponsoring Open Source Communities and Foundations:** Providing insights into the dynamics and complexities of open - source governance and models is part of this. +| Activities | Value for the OSPO | Value for the Organization | +| -------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Define open source compliance rules and practices | An explicit consensus on the organization's open source compliance rules and practices between the legal and business stakeholders. | The organization knows that it has a managed approach to the legal aspects of open source consumption, which can be maintained and improved over time. Each company has different aspects of open source compliance, interpretations of licenses and different risk appetite (e.g dealing with regulations). Having well-defined compliance rules and practices is the first step toward deterministic open source compliance | +| Define rules and policies on using open source (criteria for using open source software which relate to open source health) | Consumption of open source projects is not just viewed through the compliance lens, but is considered more holistically and includes the risks associated with unhealthy projects. A consensus is built in the company related to the hygiene related to consumed open source components. The organization has clear policies to follow. | Consumed open source projects are lower in risk because they are healthy, fixing security vulnerabilities, implementing new features and release regularly. | +| Define rules and policies on how to contribute to open source (criteria on how to engage in the community, how to transfer rights, Contributor License Agreements) | The OSPO can increase awareness of the two-way relationship with open source projects. Using policies supports a consistent and ethical approach. The organization has clear policies to follow. | Policies and practices ensure that the organization considers how to jointly build value with open source projects. Contributions made are likely to improve the company reputation, not damage it. | +| Adopt ISO/IEC 5230 (OpenChain) Compliance | The OSPO can implement an international, defined standard rather than creating one from the ground up. | The organization can demonstrate its compliance with an internationally-recognized standard. | +| Manage an inventory of open source software used in the organization | The OSPO is aware of the surface area of open source software it is overseeing. | The organization has a base for overall risk management. This is an important tool for dealing with issues relating to specific projects (security problems, license changes, lifecycle issues, etc.) | +| Training on open source awareness | Providing training on open source increases visibility of the role of open source, visibility of the OSPO and its value, and improves understanding of how the organization uses and engages with open source. | Increases the competence present in the organization to work with open source software through an awareness of open source value, licensing, and contributions etc. | +| Introduce tools for license compliance | Provide structure and visibility for licence compliance within the organization, which helps inform management strategy. | Automation is essential to be able to address risks with a reasonable amount of effort and measure effectiveness of efforts to improve compliance. | +| Clarify how to support open source software | Ensure that open source software is adopted with appropriate understanding of how it can be supported. | The organization should be aware of the hidden costs of using open source software in production scenarios. External support for open source components can sometimes be bought from a vendor or a service provider. Alternatively, other options are to managed the support yourself with the help of the community (being realistic in considering what a community can be expected to support), or going with the risk of not having support which may be appropriate for scenarios where the risk is low. | -- **Measuring Technical Debt:** In open source projects requires understanding maturity and governance models. +| Participant Stage | +| --- | -- **Coordinate with Various Parts of the Organization:** Map interactions with teams based on the OSPO flower diagram, - distinguishing between technical questions (engineering) and non-technical questions (business, design team). -- **Advise on open source consumpiton** define a set of advices about how the company should select what open source is - consumed and how the consumption is made. Advices can be purely technical or considerations based on open source - project health and practices, like the - [Secure Supply Chain Consumption Framework (S2C2F)](https://github.com/ossf/s2c2f/blob/main/specification/Secure_Supply_Chain_Consumption_Framework_(S2C2F).pdf). +| Activities | Value for the OSPO | Value for the Organization | +| ---------------------------------------------- | -------------- | ----------------------------------------------------------------------------------------------------------------- | +| Financially supporting open source communities | Better relationship with communities, more influence. | Better stability in the ecosystem and software supply chain that the organization relies on. | +| Membership of open source organizations | Membership benefits such as co-marketing, event discounts. | Engagement with the communities the organization relies on. Potential influence and access to strategically useful information. Supporting the ecosystem. | +| Trying InnerSource | Staff in the organization will get hands-on experience with open source methodologies, which builds awareness, understanding, and advocacy. | The organization will build skills in its workforce that will contribute to better use of, and engagement with, open source projects. | -## Assessing Daily Operations +| Contributor Stage | +| --- | -This section presents a detailed overview of the operational considerations necessary for managing open source initiatives within organizations. This section is structured to cover several key areas: the core reasons for Open Source Program Offices (OSPOs) to prioritize specific tasks, the tangible benefits these tasks -provide to the organization, the scope of engagement with open source in terms of usage and contribution, and an inventory of tools and services that support these efforts. +| Activities | Value for the OSPO | Value for the Organization | +| -------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Create contribution policy and process | Managing open source contributions becomes easier. | Having clear procedures means that the organization can offer open source contributions in a legally safe way, for open source projects, the organization, and its employees. | +| Qualification of contributors | Contributors require less oversight and make good ambassadors. | Skilled contributors make better contributions into publicly-visible projects. This means less risk to the organization. | -| Category | Fundamental Reasons for OSPOs to Focus on This Task | Perceived Value | Using Open Source (Scope) | Contributing to Open Source (Scope) | Tools / Services | -|---------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| **Automation in License Compliance** | Streamline license management to facilitate easier discovery of licenses and minimize the approval processes required from developers when using open source tools. | Automation in license compliance reduces manual oversight, accelerates development workflows, and ensures compliance with open source licenses without burdening developers with lengthy approval processes. | Explore automation tools that assist developers in organizations in scanning and identifying open source licenses they can use, and speed up the compliance process. | Explore automation tools that assist developers in organizations in scanning and identifying open source licenses to projects they would like to contribute as employees, and speed up the compliance process. | License checker for NPM ecosystem: [https://github.com/onebeyond/license-checker](https://github.com/onebeyond/license-checker) | -| **Automation in Security** | Enable tools and best practices for integrating security measures, such as scorecards, into daily operations. | Automation in security practices and vulnerabilities exploration in open source projects allows effective risk management. | Explore automation tools that assist developers to self-assess security risk on specific projects, without burdening them with lengthy approval processes. | Explore automation tools that assist developers to self-assess security risk on projects they would like to contribute as employees, without burdening them with lengthy approval processes. | OSFF Scorecard [https://github.com/marketplace/actions/openssf-scorecard-monitor](https://github.com/marketplace/actions/openssf-scorecard-monitor) | -| **Measuring Performance** | Inform strategic adjustments and operational enhancements. | Measuring performance facilitates transparent assessment of the OSPO's effectiveness. | TBD (ping CHAOSS OSPO metrics WG to give input on this). | N/A | N/A | -| **Strategy and its Impact** | A unified strategy influences daily operations. | Guiding decisions on contributions to open source projects, engagement with community initiatives, and the balancing of organization and community benefits. | Enable decision makers understand the critical importance of supporting open source projects (and its community) and foundations, and the different ways to offer support. | Frameworks that support strategic planning and execution. | N/A | -| **Personalized Support / Q&A Sessions**| Actively involve employees and managers in open source activity engagement. | Increase and improve open source knowledge and expertise across the organization's teams. | Answering questions on everything about open source, including license compliance, selecting open source software, and dealing with vendors. | Answering questions on everything about open source, including license compliance, selecting open source software, and dealing with vendors. | Internal developer portals / Issue tracker systems / Chatbots / webinars / AMA sessions / IRC | -| **Advocacy and Education** | Advocating for the importance of education in open source and creating resources to support it. | Ensure that people are qualified to judge a project (governance models, maturity, etc) and measure the technical debt on an open source project. | Build training and documentation, and assist teams in creating these materials across different teams. | Providing knowledge on how to measure the technical debt on an open source project, including maturity models and governance models, is a form of educational advocacy to help projects improve and sustain. | External open source training and certification courses, customized training courses adapted to the organization's goals. | -| **Community Integration** | Integrate organization's activities effectively with the open source projects and foundations (financial as well as resource support) as well as community dynamics. Map interactions with technical (engineering) versus non-technical teams (business, design team). | Allocate effective financial and resource support to critical open source projects that organization's employees use/engages. | How to get sponsorship, run open source events, and integrate effectively with the open source community and its foundations. | How to get sponsorship, run open source events, and integrate effectively with the open source community and its foundations. | N/A | -| **Business Assessment on Risk Management** | Assess risks that the organization is facing, including an overview of the tech stack. | Assistance in evaluating which open source projects to use and how to prioritize resources effectively. | E.g., business assessment to determine whether optimizing SBOMs or focusing on other areas is more beneficial (dealing with vendor-supplied software, legacy software, proprietary software). | E.g., business assessment to determine whether optimizing SBOMs or focusing on other areas is more beneficial (dealing with vendor-supplied software, legacy software, proprietary software). | N/A | +| Leadership Stage | +| --- | +| Activities | Value for the OSPO | Value for the Organization | +| --------------------------------------------------------------------------- | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Open sourcing previously proprietary projects | The OSPO can reduce the burden on the Engineering (and other) departments. | New opportunities will open up to improve the codebase of a commoditized component through collaboration in public. More strategic involvement in open source. Access to new expertise. | +| Establish an โ€œupstream firstโ€ policy | Offering the organization a way to get more value for the same, or smaller, amount of effort. | The organization can support or even lead open source projects and make them part of the primary value creation of the organization without losing its competitive differences, and while benefiting from the contributions of a whole community. | +| Supporting autonomy of contributors and maintainers of open source projects | In-house experts in open source are valuable to the OSPO. | Employing people who are dedicated to only open source work means the organization can strategically strengthen important open source projects in the most organic and effective way. | -## Recommendations (TBD) +## Recommendations -### The OSPO should have secured resources for strategic contributions +### Scenario #10 -- Scope: If the company has strategic targets related to open source, its OSPO should be capable to control resources to - drive the execution of the strategy. +Social Engineering Attack on Upstream xz/liblzma: A [social engineering attack targeted the xz/liblzma](https://research.swtch.com/xz-timeline), an essential open source library. The attack was meticulously planned, gaining trust within the community before executing a malicious attack. This incident was discovered inadvertently by an unrelated project, underscoring the sophistication and stealthiness of such vulnerabilities. The challenge for Open Source Program Offices (OSPOs) lies in identifying and mitigating these vulnerabilities, which are not always apparent until after they occur. Despite existing procedures and policies, OSPOs recognize the need for mechanisms to proactively measure and respond to such threats. -- Recommendation: To ensure the continuity of contributions needed for the strategy execution the OSPO should either: - - Have a set of dedicated open source developers - - Have a budget for company internal development resources asigned to startegic OSPO tasks - - Have a budget to hire external developers to work on the startegic OSPO tasks +> Recommendation +> +> 1. SBOMs Compliance Ready: Ensure that all software components are documented through Software Bill of Materials (SBOMs). This documentation helps in quickly identifying potentially compromised components once a vulnerability is disclosed. +> +> 2. Automation Security Checks: Implement automated security checks, such as the OpenSSF Security Scorecard, to continuously evaluate the security posture of projects. This proactive measure can highlight vulnerabilities or anomalies that merit further investigation. +> +> 3. Having a Computer Emergency Response Team (CERT) within the organization and having the OSPO collaborate closely with them. This specialized team should be equipped with the tools and authority to respond swiftly to security incidents. Pre-existing relationships within the team facilitate rapid internal communication about the severity of incidents. +> +> 4. Scorecard Management: Keep security and vulnerability scorecards up to date. These scorecards should reflect the latest security checks and assessments, helping in quick decision-making during a crisis. +> +> 5. Automated Feedback Loops: Develop well-automated feedback loops for bug reporting and fixing. Knowing who is responsible for addressing a particular bug and ensuring that this process is as automated as possible can significantly reduce response times. -### Scenario #12 +### Scenario #11 -- Scope: +Licence changes on an Open Source project. OSPOs face the challenge of navigating license changes and assessing software trustworthiness. When [projects like Redis change their terms](https://www.theregister.com/2024/03/22/redis_changes_license/) it can have significant implications for use, distribution, and contribution. OSPOs need to communicate these changes clearly and understand the roles and responsibilities dictated by new license terms. Furthermore, OSPOs are tasked with evaluating the trustworthiness of software, which can vary based on whether a project is maintained by a single vendor or hosted under a foundation. For instance, The [AlmaLinux OS Foundation](https://thenewstack.io/jack-aboutboul-how-almalinux-came-to-be-and-why-it-was-needed/) presents a case where donating a project to a foundation mitigated risks associated with single-vendor governance, thereby enhancing trust in the project. -- Recommendation: +> Recommendation +> +> 1. Educational Initiatives on License Implications: Develop educational materials and sessions for developers and users within the organization to understand the nuances of different licenses. This understanding will help them make informed decisions when using or contributing to open-source projects. +> +> 2. Explicit License Terms: Work with legal teams to ensure that license terms are as explicit and unambiguous as possible. Clear terms help in avoiding misunderstandings and potential legal conflicts. +> +> 3. Software Trust Rating System: Implement a system to evaluate and rate the trustworthiness of software, considering factors like governance structure, maintenance practices, and community engagement. Projects hosted under reputable foundations could be rated higher for trustworthiness due to the oversight and governance provided. +> +> 4. Encourage Foundation Hosted Projects: Advocate for donating projects to foundations to mitigate risks associated with single-vendor control. Highlight successful cases like AlmaLinux to illustrate the benefits of this approach, such as increased trust and community support. +> +> 5. Stakeholder Engagement in License Decisions: Engage a broad range of stakeholders, including developers, legal advisors, and end users, in discussions about license changes or the adoption of new projects. Their insights can help in making balanced decisions that align with the organization's values and risk tolerance ## Resources (TBD)