Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create osrb.md #256

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
74 changes: 74 additions & 0 deletions docs/bok/Artifacts/osrb.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,74 @@
## Creating an Open Source Review Board

Creating an Open Source Review Board (sometimes known as "Advisory Councils) for any open source contributions coming outside of a FINTECH enterprise involves establishing a structured group responsible for evaluating and guiding open source contributions made by the company's employees. This board ensures that these contributions align with the company's strategic interests, comply with legal and regulatory standards, risk and security standards as well as foster positive relationships within the open source community.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Creating an Open Source Review Board (sometimes known as "Advisory Councils) for any open source contributions coming outside of a FINTECH enterprise involves establishing a structured group responsible for evaluating and guiding open source contributions made by the company's employees. This board ensures that these contributions align with the company's strategic interests, comply with legal and regulatory standards, risk and security standards as well as foster positive relationships within the open source community.
Creating an Open Source Review Board (sometimes known as "Advisory Councils") for any open source contributions coming outside of a FINTECH enterprise involves establishing a structured group responsible for evaluating and guiding open source contributions made by the company's employees. This board ensures that these contributions align with the company's strategic interests, comply with legal and regulatory standards, risk and security standards as well as foster positive relationships within the open source community.


**Read below for a structured approach to forming such a board**

### Define the Purpose and Scope

**Objective**
- Clarify the review board's primary goal, which could include ensuring that open source contributions enhance the company's reputation, comply with legal standards, and align with its strategic goals.

robmoffat marked this conversation as resolved.
Show resolved Hide resolved

**Scope**
- Determine the types of projects or contributions that require review. This might encompass code contributions/enhancements, documentation, participation in open source project governance, starting new open source projects or taking these open source projects into foundation incubation.

### Establish Governance and Policies


**Composition**
- The board should include members from diverse backgrounds, such as legal experts specializing in intellectual property and open source licensing, software engineers with experience in open source projects, security experts, risk and representatives from product and strategy teams.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

might be best to provide a bullet-list here that people can check off. Does cover the bases though

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was listed at the bottom of the doc - we can move this section to meet it there.


**Policies**
- Develop clear policies covering aspects such as intellectual property management, contribution guidelines, compliance with open source licenses, security protocols, and conflict of interest disclosures.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a difference between the OSRB and the OSPO? Seems like with this definition they overlap quite a lot.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I got this back from ChatGPT when asking what the difference was:

The Open Source Program Office (OSPO) and the Open Source Review Board (OSRB) are both crucial in managing an organization's engagement with open-source software, but they serve distinct functions and have different scopes of responsibility. Understanding the differences between them is key to appreciating how organizations can effectively leverage open-source software while mitigating risks and contributing back to the community.

Open Source Program Office (OSPO)

An OSPO is a dedicated office or team within an organization that is responsible for coordinating and facilitating the organization's open-source activities. Its responsibilities are broad and strategic, encompassing the oversight of all open-source engagements, contributions, and compliance across the entire organization. Key functions of an OSPO include:

Strategy Development: Defining the organization's open-source strategy, including how open-source can be used to achieve business goals, and setting policies for open-source contributions and usage.
Community Engagement: Building and maintaining relationships with the open-source community, including contributing to open-source projects and possibly launching open-source projects under the organization's banner.
Education and Advocacy: Promoting the use of open-source within the organization, educating employees on best practices, and advocating for open-source values.
Compliance and Governance: Ensuring that the organization complies with open-source licenses, managing intellectual property in open-source contributions, and setting up governance structures like the OSRB.
Tooling and Infrastructure: Providing tools and infrastructure to support open-source development, contribution, and compliance within the organization.

Open Source Review Board (OSRB)

The OSRB, on the other hand, is typically a component of the governance structure that an OSPO might establish. It has a more focused role, primarily concerned with reviewing and approving open-source usage and contributions to ensure compliance with policies, licenses, and security standards. Key functions of an OSRB include:

Review and Approval: Evaluating proposed use of open-source components in projects and contributions to open-source projects to ensure they meet internal policies and license obligations.
License Compliance: Ensuring that the organization's use of open-source software complies with the terms of open-source licenses, including obligations to disclose source code or attribute copyrights.
Security Review: Assessing the security implications of using or contributing to open-source software and ensuring that security policies are adhered to.
Policy Enforcement: Enforcing the organization's open-source policies at the project level and ensuring that developers and teams comply with these policies.

Key Differences

Scope and Focus: The OSPO has a broad, strategic focus, aiming to integrate open-source into the organization's overall strategy and operations. The OSRB has a more focused, operational role, concentrating on the review and approval process to ensure compliance and manage risks.
Responsibilities: While the OSPO is responsible for the overarching open-source strategy, community engagement, and policy development, the OSRB is specifically tasked with the governance and oversight of open-source usage and contributions.
Position in the Organization: An OSPO is a centralized office that oversees all open-source activities across the organization. An OSRB, however, is often a component of the governance structure established by the OSPO to handle specific tasks related to open-source compliance and security.
In summary, while the OSPO sets the direction and policies for open-source engagement at a strategic level, the OSRB focuses on the governance and compliance aspects, ensuring that the organization's open-source activities align with internal policies and external license obligations.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I work in an OSPO that runs the OSRB or the OS Community Council, or the OS Advisory Council - which vets all OS contributions leaving the company. The article was written through experiential learnings and can be modified as the group deems fit.

If we want to add in where we think the review board should live, just let me know.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In discussion in today's OSR SIG, Amoel talked about how the OSRB provides a layer of governance and arbitration over the OSPO.

His example: should the firm use OpenTOFU? It's a new open source fork of Terraform. Should they contribute? Or avoid? This is something the OSRB would be expected to arbitrate on.


**Decision-making process**
- Outline how decisions will be made, including voting mechanisms, quorum requirements, and conflict resolution procedures.

### Set Up Operational Procedures


**Contribution Process**
- Define the process for submitting contributions for review, including necessary documentation, expected timelines, and communication channels.


**Review Criteria**
- Establish criteria for evaluating contributions, considering legal compliance, strategic alignment, community impact, and security implications.


**Feedback and Approval**
- Implement a mechanism for providing constructive feedback to contributors and a clear pathway for obtaining final approval for contributions. Ideally this will be an in person meeting where the contributors share their vision for their contribution. AFter the presentation the board reviews and determines next steps towards approval or rejection of the contribution.

**Work with your contributing teams**
- Prepare the teams and team members for presenting their projects, contributions and ideas to the board.


### Engage with the Open Source Community


**Community Management**
- Develop strategies for engaging positively with the open source community, including sponsoring events or foundations, contributing to open source foundations, participating in community discussions or reaching out to the projects maintainers that your company relies upon to determine how your enterprise can get involved.

**Transparency**
- Consider making aspects of the review process and policies publicly available to demonstrate the company's commitment to open source principles.

### Monitor and Evolve


**Tracking Contributions**
- Set up systems to monitor approved contributions and assess their impact on both the company and the open source projects involved. Work with your source code management team or OSPO to set up these rules.

**Continuous Improvement**
- Regularly review the board's policies, procedures, and effectiveness, adjusting as necessary to reflect changes in the open source ecosystem, legal standards, and the company's strategic direction.

### Example Board Structure


**Executive Sponsor**
- For an Open Source Contribution model to be successful, your group will need to ensure that you have support from higher leadership. Discuss your model with your CISO, CTO and CIO to get their buy in. This will make for a smooth transition to the open from a highly regulated industry.

**Chairperson**
- A senior leader with a strong understanding of the company's strategic goals and the open source landscape - ideally someone that is in your open source program office if applicable.

**Core Members**
- Legal Counsel (IP and Licensing Specialist)
- Senior Open Source Software Engineer
- Principal engineers from the enterprise for code reviews
- Security Analyst
- Community Manager - This person should be the main point person for all contributors to help guide them through the review board process

### Conclusion

Establishing an Open Source Review Board is a strategic move for a FINTECH enterprise looking to contribute to and create open source projects. By ensuring contributions are strategically aligned, legally compliant, secure and risk adverse and positively received by the open source community, the company can enhance its reputation, foster innovation, and maintain regulatory compliance.