Foundations and Essential Elements

Introduction

In this chapter, we will share recommendations on ways to create a solid foundation for building a stable and strong OSPO, capable of covering the open source-related tasks and responsibilities on a day-to-day basis (These tasks will be further explained in the next chapter). We will cover the core concepts necessary to get started with a minimum viable OSPO. This includes strategic aspects and areas of work.

Ingredients for a Minimum Viable OSPO

The first step in establishing an OSPO is to shape and build up the structure. This includes personnel, technology, and budget. It is also important to identify the key stakeholders in your organization who will be involved in open source activities.

The guide A deep dive into OSPO explains all essential information on OSPO structures and operations.

Once this is evaluated, it is recommended to look at the OSPO from two dimensions:

  • The areas of work where the OSPO interacts
  • The strategy it will follow and its framework

The OSPO Flower Diagram

The area of work of your OSPO is also a crucial component to map, as it serves as one of the core ingredients for effectively implementing open source dynamics and philosophy on an organizational level. To achieve this, it is recommended to examine your own organizational architecture and break down open source tasks into small areas of work.

The structure used in this book to represent these areas is shaped as a flower diagram with a number of petals and the OSPO in the center. Each petal represents a certain group of stakeholders with specific activities associated with this group. The OSPO Flower Diagram also represents the specific communication channels, documentation and other material used with each group of stakeholders.

ospoflower ospoflower.pdf

  • Individual Contributors: This petal involves the people behind the OSPO to work with individuals within the organization, focusing on the intrinsic and extrinsic motivators of contributing to open source from an individual point of view. It requires a cultural change effort and may involve activities such as establishing mentoring programs.

  • Management: In this petal, the OSPO focuses on strategy and finding alignment between open source and the overall business/organization strategy. Managers face unique challenges, and using the strengths of open source helps them overcome these challenges effectively.

  • Legal: This petal represents the legal aspects of open source. It deals with understanding and managing legal requirements and obligations related to open source initiatives within the organization. This ensures compliance and reduces legal risks.

  • Business: This petal focuses on how the OSPO ensures all the pieces of the organization structure fit together. It involves sharing best practices across different business/team units and fostering collaboration and knowledge transfer.

  • Open Source Ecosystem: This petal represents the broader open source community and project ecosystem outside the organization. The OSPO engages with this ecosystem, which includes other organizations, projects, and individuals, to exchange ideas, collaborate, and contribute to the larger open source community.

  • OSPO: This represents the inner workings of the OSPO itself. The people within the OSPO collaborate and coordinate all the open source initiatives within the organization. They oversee the activities, ensure smooth operations, and provide guidance and support to other stakeholders involved in open source.

Depending on the complexity of your organization and the resources available to your OSPO, these petals can become more granular and include additional petals with different names.

Creating and Implementing an Open Source Strategy

If an organization’s primary objective is profitability, customer satisfaction becomes a linchpin in the corporate strategy – a focal point for both CEOs and CFOs. For individuals in Open Source Program Offices, effectively communicating the open source strategy to C-level executives demands a keen understanding of the industry landscape and alignment with the key considerations of CEOs and CFOs. This alignment necessitates a clear comprehension of the overarching corporate strategy and identifying technologies within the open source realm that can propel the organization toward its strategic objectives

Victor Lu and Rob Moffat Presentation - Strategy - End Game for FINOS Maturity Model

The people behind an OSPO achieve this by creating and maintaining a framework covering the following aspects: strategy, governance, compliance, and community engagement. The OSPO’s strategy focuses on aligning the organization’s open source usage (consumption), contributions and compliance activities across its projects, products, services, or internal infrastructure to its overall organization objectives.

A strategy creates a high-level consensus on concrete topics and their impact on your organization and the people within it. A good practice is to document this strategy in an open source strategy document.

It is recommended that this document includes a general Q&A section. Additionally, you may consider creating specific how-to guides for specialized areas that interact with the OSPO and open source projects (e.g., marketing, legal, engineering) to address specific challenges. These guides should be tailored to the domain knowledge of the team members involved.

Fostering open source integration within the organization

Effectively executed OSPO work takes into account the elements of an organization’s architecture, as understanding the organization’s goals is fundamental for making informed open source-forward decisions. For instance, in a corporate field, an OSPO might look into the following areas and identify the role that open source plays on each situation:

organization-architecture

Since every organization is unique in its values, business drivers, and culture, it is challenging to provide specific content. However, addressing the following questions can help structure the document effectively:

  • Which open source technology is and which will be important for your organization’s goals and product roadmap?
  • Which open source projects directly and indirectly develop or influence these technologies and your organization’s goals?
  • Which specific practices can best foster a sustainable open source ecosystem?
  • Which organization’s processes have areas for improvement?
  • How can open source support those improvements?
  • How can you make workers champions for open source?
  • How can the message be effectively transmitted to management for their understanding?

Moreover, it is important to identify the open source projects and communities with which you will work. Developing a plan for how you will support these initiatives is crucial. Additionally, you will need to consider the role that open source will play in your organization and how you will integrate open source solutions into your existing IT infrastructure.

Collaboration with external regulators

Organizations are subject to various external regulators that influence and shape their policies and processes. These regulators ensure compliance with legal requirements, ethical standards, and industry-specific guidelines. Some external regulators include:

  • Government Agencies: Government bodies establish and enforce laws and regulations that impact organizations.
  • Industry Regulators: Many industries have their own regulatory bodies or professional associations that set guidelines and standards for organizations to follow.
  • Consumer Protection Agencies: Consumer protection agencies ensure that organizations provide fair and safe products or services to consumers.

For open source to be successful and sustainable within an organization, it is crucial to collaborate not only with the open source community but also with external regulators. This collaboration ensures a clear understanding of open source principles when creating policies that affect the ecosystem. The primary objective is to work together and make informed decisions by fully grasping the implications of open source and its community. Thus, it is recommended that the OSPO consider ways to develop a plan for approaching and communicating with regulators, clearly defining the roles they will play in the policymaking process.

Assessing Maturity of Open Source Program Office

✅ Assessment

The Existing Debates Around Maturity Models

Before deepening dive into maturity levels, we want to emphasize that this book is informative and people should adapt its content to their organization needs. Where maturity models can be useful, organizations can either use maturity models or not. For instance, this article discusses about open source models within the DevOps community.

Open Source Maturity Models vs. OSPO Maturity Models

In many cases, an OSPO may not be able to tackle all the tasks simultaneously. It often needs to evaluate its past achievements and progress in order to effectively plan and incorporate new milestones into its roadmap. This is where maturity models come into play.

It’s important for readers to recognize the distinction between measuring an organization’s level of engagement in open source (organizational level) and assessing the maturity of the OSPO team/entity itself (team unit level).

Regarding the organization’s engagement, there are already various models available that help assess the maturity of open source involvement. Examples include Ibrahim’s Enterprise Open Source Involvement Stages and the FINOS’ Open Source Maturity Model. To simplify this topic for this book, these models can be summarized into four main stages:

  • Open source usage (also called consumption)
  • Community participation
  • Community contribution
  • Leadership

On the other hand, the OSPO maturity model assists organizations in gauging their progress in establishing a mature OSPO. It helps identify the specific areas where they need to concentrate their efforts and improve their practices and its creation might come at any level of the open source journey of an organization.

Simple checklist

The TODO OSPO checklist offers a simplified set of common milestones to both early-stage and seasoned OSPOs in navigating each stage of the previously mentioned OSPO maturity model. Please note that an OSPO might remove, add, or edit some content of this checklist to adapt it to their organization’s needs.

Pre-stages

  • Create and publish a common set of values and principles around open source usage, contribution and creation as an organization
  • Define program branding (e.g., OSPO, open source initiative, head of open source operations).
  • Define structure, budget and necessary cross-functional staff to get started
  • Define an action plan for the upcoming years
  • Define communication plan about OSPO activities to the organisation

Stage 1

  • Manage security risks and legal risk and licenses, creating new procedures and documentation to ensure employees use open source in the organization according to its license terms.
  • Create education programs to help developers decide when to use open source in creating new products or services.
  • Set up specific software inventory processes to create an organization-wide software bill of materials (SBOM).
  • Overall, recognize the value of open source when developing software, hardware, using datasets to train machine learning models, etc and the need for security scorecards, compliance, education, and an SBOMs.

Stage 2

  • Define compliance process for contributions and interactions with open source communities
  • Lay out best practices in interacting with OSS projects such as how to request features, file bug reports, and contribute basic code.
  • Communicate to workers, policymakers and other open source stakeholders the importance of contributing to and not merely consuming (also called usage) to open source (including advocating for and driving event sponsorships, booking project leads and maintainers as speakers or panelists in public coding forums, and securing organizational resources to mission-critical open source projects).
  • Incentivize developers and non-developers (lawyers, project managers, technical writers, etc) to participate in open source projects critical to their operations (contributing code, field expertise, documentation, etc), to the degree that workers become highly active contributors.
  • Contributions are focused to a narrow business critical set of functionalities in open source projects, and they are sponsored by the organisation (contributions are not a hobby project of individual employees)

Stage 3

  • Initiate and host, or act as primary sponsors of open source projects critical to your organization.
  • Create and launch open source projects to establish broad credibility in the open source community.
  • Dedicate one or more full-time employee(s) to a project, and accept responsibility for nurturing a project community and ensuring its health.
  • Develop internal processes, playbooks, working hours, checklists, tooling, and other mechanisms to vet, organize, and operate open source projects and to prepare and coach their leaders.

Stage 4

  • Become a strategic partner for technology decisions, helping to guide choices and shape long-term commitments to projects.
  • Advise the CTO and technology leadership on which open source projects to adopt or remove from the organization’s technology stack.
  • Take the lead on benchmarking what constitutes an acceptable open source project.
  • Help organizations understand and navigate through the different open source project governance models.

Recommendations

💡 Recommendations

Scenario #10

There is a lack of consistency in how open source understanding and value is perceived across the organization, leading to confusion and potential risks.

Recommendation: Establish and enforce a consistent understanding of open source throughout the organization to ensure a stable and strong foundation for the OSPO. Creating publicly available FOSS and/or Open Source manifestos, principles, and websites is an effective way to foster a common understanding of values, principles, and goals among all teams and subsidiaries

Resources

📚 Continue Here

Last modified September 16, 2024: Some suggestions for change and/or discussion (c1eb0c8)