学习如何参与日常运营

简介

In this chapter, we will introduce the key tasks and responsibilities of an Open Source Program Office (OSPO) on a day-to-day basis, as well as the core concepts to get started with a minimum viable OSPO. This includes the strategy aspect, layers of work, and pillars of support.

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 would be directed to 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, with main focus 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 help 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 among them.

  • 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

The way the people behind an OSPO achieve this is 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 goals with 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.

Understanding the relevance of open source 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:

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.

Understanding the relevance of open source outside the organization

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.

In order 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 on open source and its community.

collaboration-outside

Consequently, when formulating strategies, it is essential for the Open Source Program Office (OSPO) to develop a plan on how to approach and communicate with these regulators, clearly defining the roles they will play in the policy-making process.

评估开源项目办公室的成熟度

✅ 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. The article argues against the use of maturity models in DevOps for a few reasons:

  • Maturity models may focus on reaching a specific end goal, which can hinder innovation and experimentation in DevOps, where continuous improvement is key.
  • Maturity models may tend to encourage standardization and conformity rather than promoting creative problem-solving and trying new approaches, which are important in DevOps.
  • Maturity models may follow a linear progression, assuming there is a fixed path to reach maturity. However, DevOps is a complex process that requires adaptability and flexibility.

Open Source 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:

  • Software Usage
  • 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. OSPO Maturity model stages include:

  • Awareness: This pre-stage represents the early phase of OSPO maturity. Organizations in this stage are exploring the potential benefits of open source. They typically experiment with open source solutions.

  • Ad hoc: In the ad hoc stage, organizations start recognizing the value of open source and begin integrating it into their IT infrastructure. However, open source operations are still managed in an ad hoc manner, often on a case-by-case basis.

  • Security, Education, and Strategy: At this stage, organizations aim to formalize their open source operations by establishing dedicated OSPOs to manage their open source activities. These OSPOs take responsibility for ensuring compliance with legal and regulatory requirements, as well as developing and implementing open source strategies on how to use open source software in a sustainable way. This stage also contemplates the education on contirbuting to open source projects bu helping on its security adn sutainability.

  • Community, Education, and Engagement: Organizations in this stage have mature OSPOs that oversee all aspects of their open source contributions and (if needed) and new open source projects. The OSPO is responsible for establishing best practices and standards for the open source projects they have activity. They ensure that all open source projects align with the organization’s strategy and actively engage and sustain open source communities.

  • Leader and Advisor: Open source is regarded as a critical component of the organization’s IT infrastructure and open culture. The OSPO takes on the role of ensuring effective and efficient use and contribution of open source across the organization. They also manage relationships with open source communities and stakeholders, acting as a leader and advisor.

反模式

🚫 OSPO Antipatterns

TBD

资源

📚 Continue Here

最后修改 November 24, 2023: Update 03-chapter.md for guide links issue (f32844f)