Final Review for chapter 4 #500
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Adding the changes that came from the final review during Chapter 4 meeting. During the call and the next two weeks, the changes were included using [this doc](https://github.com/todogroup/ospology/edit/main/ospo-book/content/en/04-chapter.md)for chapter intro and this doc for [activity table](https://drive.google.com/open?id=12wqqdCLgkTIor_onHvhCtLPE-Tsn44k2oWVxnisb6TM&authuser=0) Contributors in this PR: - Alice Sowerby - Cornelius Schumacher - Gergely Csatari - Ana Jiménez These people are already acknowledged in the OSPO Book contributors section. Thank you! Signed-off-by: Ana Jimenez Santamaria <ana@todogroup.org>
✅ Deploy Preview for ospobook ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for ospomindmap canceled.
|
Signed-off-by: Ana Jimenez Santamaria <ana@todogroup.org>
Signed-off-by: Ana Jimenez Santamaria <ana@todogroup.org>
Signed-off-by: Ana Jimenez Santamaria <ana@todogroup.org>
Signed-off-by: Ana Jimenez Santamaria <ana@todogroup.org>
Signed-off-by: Ana Jimenez Santamaria <ana@todogroup.org>
Signed-off-by: Ana Jimenez Santamaria <ana@todogroup.org>
CsatariGergely
requested changes
Jul 27, 2024
| | **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 | | ||
| To get an overview of the potential activities an OSPO can handle, we recommend first examining the OSPO Mind Map. The OSPO Mind Map outlines the main responsibilities, roles, behaviors, and team sizes within the ecosystem of an Open Source Program Office. |
There was a problem hiding this comment.
Suggested change
| To get an overview of the potential activities an OSPO can handle, we recommend first examining the OSPO Mind Map. The OSPO Mind Map outlines the main responsibilities, roles, behaviors, and team sizes within the ecosystem of an Open Source Program Office. | |
| To get an overview of the potential activities an OSPO can handle, we recommend first examining the [OSPO Mind Map](https://ospomindmap.todogroup.org/). The OSPO Mind Map outlines the main responsibilities, roles, behaviors, and team sizes within the ecosystem of an Open Source Program Office. |
|
|
||
| ## Recommendations (TBD) | ||
| 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 less complex and not focused on corporate structures. |
There was a problem hiding this comment.
Suggested change
| 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 less complex and not focused on corporate structures. | |
| 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](02-chapter.md#maturity-model-1---open-source-engagement-adoption-by-dr-ibrahim-h)—as it is less complex and not focused on corporate structures. |
I'm not sure if the anchor will work in the rendered hugo page, but shold be something like this.
| | Activities | Value for OSPO | Value for Org | | ||
| | -------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| | Define open source compliance rules and practices | Facilitate the definition of the organization's open source compliance rules and practices between the legal and business stakeholders. | 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 | | ||
| | Rules, and policies on using open source (criteria for using open source software, open source health) | A consensus 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 healthy, fixing security vulnerabilities, implementing new features and release regularly. | |
There was a problem hiding this comment.
Suggested change
| | Rules, and policies on using open source (criteria for using open source software, open source health) | A consensus 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 healthy, fixing security vulnerabilities, implementing new features and release regularly. | | |
| | Rules, and policies on using open source (criteria for consuming open source software, considerations on the governance and health of the open source communities, etc) | A consensus 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 healthy, fixing security vulnerabilities, implementing new features and release regularly. | |
| | Define open source compliance rules and practices | Facilitate the definition of the organization's open source compliance rules and practices between the legal and business stakeholders. | 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 | | ||
| | Rules, and policies on using open source (criteria for using open source software, open source health) | A consensus 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 healthy, fixing security vulnerabilities, implementing new features and release regularly. | | ||
| | Rules, and policies on contributing open source (criteria on how to engage in the community, how to transfer rights, CLAs) | The organization has clear policies to follow. | Policies and practices ensure that there are no contributions risking company value. | | ||
| | ISO/IEC 5230 (OpenChain) Compliance | | Clear rules how to deal with open source software following an industry accepted standard | |
There was a problem hiding this comment.
Suggested change
| | ISO/IEC 5230 (OpenChain) Compliance | | Clear rules how to deal with open source software following an industry accepted standard | | |
| | ISO/IEC 5230 (OpenChain) Compliance | Ensures that the OSPO follows a minimum standard of industry best practices. | Clear rules how to deal with open source software following an industry accepted standard | |
| | Rules, and policies on using open source (criteria for using open source software, open source health) | A consensus 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 healthy, fixing security vulnerabilities, implementing new features and release regularly. | | ||
| | Rules, and policies on contributing open source (criteria on how to engage in the community, how to transfer rights, CLAs) | The organization has clear policies to follow. | Policies and practices ensure that there are no contributions risking company value. | | ||
| | ISO/IEC 5230 (OpenChain) Compliance | | Clear rules how to deal with open source software following an industry accepted standard | | ||
| | Inventory of used open source software | | Base for overall risk management. Important tool to be able to deal with concrete issues of specific projects (security problems, license changes, lifecycle issues, etc.) | |
There was a problem hiding this comment.
Suggested change
| | Inventory of used open source software | | Base for overall risk management. Important tool to be able to deal with concrete issues of specific projects (security problems, license changes, lifecycle issues, etc.) | | |
| | Inventory of used open source software | Base for overall risk management. Important tool to be able to deal with concrete issues of specific projects (security problems, license changes, lifecycle issues, etc.) | Same as for the OSPO | |
|
|
||
| | Activities | Value for OSPO | Value for Org | | ||
| | --------------------------------------------------------------------------- | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| | Open sourcing previously proprietary projects | | Get the benefits of strategic involvement in and with open source | |
There was a problem hiding this comment.
Suggested change
| | Open sourcing previously proprietary projects | | Get the benefits of strategic involvement in and with open source | | |
| | Open sourcing previously proprietary projects | Build open source community leadership capabilities in the organization | Get the benefits of strategic involvement in and with open source | |
| | Activities | Value for OSPO | Value for Org | | ||
| | --------------------------------------------------------------------------- | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| | Open sourcing previously proprietary projects | | Get the benefits of strategic involvement in and with open source | | ||
| | Establish an “upstream first” policy | | Lead open source projects and make them part of the primary value creation of the organization | |
There was a problem hiding this comment.
Suggested change
| | Establish an “upstream first” policy | | Lead open source projects and make them part of the primary value creation of the organization | | |
| | Establish an “upstream first” policy | The OSPO can lean on the established leaders of the company open source projects | Lead open source projects and make them part of the primary value creation of the organization | |
| | --------------------------------------------------------------------------- | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| | Open sourcing previously proprietary projects | | Get the benefits of strategic involvement in and with open source | | ||
| | Establish an “upstream first” policy | | Lead open source projects and make them part of the primary value creation of the organization | | ||
| | Supporting autonomy of contributors and maintainers of open source projects | | Having people being dedicated to only open source work, the organization can strategically strengthen important open source projects in the most organic and effective way. | |
There was a problem hiding this comment.
Suggested change
| | Supporting autonomy of contributors and maintainers of open source projects | | Having people being dedicated to only open source work, the organization can strategically strengthen important open source projects in the most organic and effective way. | | |
| | Supporting autonomy of contributors and maintainers of open source projects | Allows the scalability of open source leadership and creates "open source" champions in the company | Having people being dedicated to only open source work, the organization can strategically strengthen important open source projects in the most organic and effective way. | |
| > | ||
| > 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. |
There was a problem hiding this comment.
Suggested change
| > 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. | |
| > 2. Automation Security Checks: Implement automated security checks, such as the [OpenSSF Scorecard](https://scorecard.dev/), to continuously evaluate the security posture of projects. This proactive measure can highlight vulnerabilities or anomalies that merit further investigation. |
|
|
||
| > 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. |
There was a problem hiding this comment.
Suggested change
| > 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. | |
| > 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 and open source governance models. This understanding will help them make informed decisions when using or contributing to open-source projects. |
|
@anajsana @CsatariGergely do you need anything from me / can I help in any way? |
Signed-off-by: Jan van den Berg <koozz@linux.com>
|
Hi @anajsana @todogroup/book-reviewers , sorry for the delay in getting to review this. I have changed my notification settings so that hopefully I get notified when I am tagged :( I think this chapter needs a full copy edit and I can't get a the GH interface to let me do that in this PR. That could be my lack of experience. I will get a copy of the file from the branch to edit it and send back. |
@anajsana I have edited a copy of the file locally, do you want me to create a PR? |
Thank you @alice-sowerby ! If you could add the copy edit changes to this PR instead of creating a new one, it will be awesome. Just let me know if you need help! |
|
@anajsana I will see if I can figure out how to do it, and let you know if I hit any problems - thank you! |
|
@alice-sowerby created a new PR with these changes + copy edits. See: #503 Tag this as duplicated and Closing with no merge. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adding the changes that came from the final review during Chapter 4 meeting. During the call and the next two weeks, the changes were included using this docfor chapter intro and this doc for activity table
Contributors in this PR:
These people are already acknowledged in the OSPO Book contributors section.
Thank you!