提升企业开源开发有效性和影响力的路线图

2023 2月

Ibrahim Haddad 博士

战略计划副总裁（AI 和数据）

序言：Jessica Murillo，IBM 副总裁兼交付实践负责人

Foreword..................................3

Introduction................................5

Hire developers from the project’s community........................... 7

Support and allocate time for upstream contributions........... 7

Create a mentorship program..........................................................8

Offer training.........................................................................9

Participate in and host open source events.................................9

Provide a flexible IT infrastructure .................................................9

Track developer code contributions ............................................. 10

Identify focus areas with a broad impact................................... 10

Foster internal collaboration.............................................. 10

Implement inner sourcing practices ..............................................11

Recommendations and lessons learned......................................12

Be patient.............................................................................12

Embrace a flexible IT infrastructure ..................................................12

Adopt proper success metrics...........................................................12

Use a lightweight approval process ....................................................12

Share information........................................................12

Make strategic contributions .......................................................13

Partner with product teams..........................................................13

Grow open source talent....................................................14

Conclusion.............................................................. 15

Acknowledgments.........................................................17

Feedback........................................................................17

Linux Foundation resources .............................................17

About the author.................................................... 18

目录

序言 3

介绍 5

从项目社区雇用开发人员 7

支持并分配时间用于上游贡献 7

创建导师计划 8

提供培训 9

参与并主持开源活动 9

提供灵活的 IT 基础设施 9

跟踪开发人员的代码贡献 10

确定具有广泛影响的重点领域 10

促进内部协作 10

落地内源实践 11

建议和经验教训 12

保持耐心 12

拥抱灵活的 IT 基础设施 12

采用适当的成功指标 12

使用轻量级审批流程 12

分享资讯 12

做出战略贡献 13

与产品团队合作 13

培养开源人才 14

总结 15

致谢 17

反馈 17

Linux 基金会资源 17

关于作者 18

Foreword

序言

“In real open source, you have the right to control your own destiny.” – LINUS TORVALDS, CREATOR OF THE LINUX KERNEL

“在真正的开源中，你有权掌握自己的命运。”

-- LINUS TORVALDS，Linux 内核的创始人

A lot has changed in the past 20 years since technology companies, like IBM, began their open source journey. In the first 10 years, enterprises started by contributing to open source projects to help fill their needs; they made strategic investments in technology, collaboration and communities and built an entirely new ecosystem. In the next 10 years, we saw the emergence of hyperscale cloud providers and Fortune 500 companies that shifted from being passive consumers to proactive participants in open source communities. This heightened collaboration spurred even faster innovation.

过去 20 年间，自 IBM 等科技公司开启开源之旅后，发生了许多变化。在最初的 10 年里，企业开始通过贡献开源项目来满足自身需求；他们对技术、协作和社区进行战略性投资，建立了全新的生态系统。接下来的 10 年，我们看到了超大规模云提供商和财富 500 强公司的出现，它们从被动的消费者转变为开源社区积极的参与者。这种加强的合作推动了更快的创新。

We have learned that companies who only participate in open source on an ad-hoc basis cannot achieve long-term success. The key is for companies to take a more structured, enterprise approach, putting open source at the core of their technology strategy. To truly benefit from the open source community model, each contributor is responsible for making the necessary investments in those communities. This includes providing open source developers from your company with the proper tooling, training, and mentoring to become strong community contributors and grow into leaders. It means we need to work together to solve not only the problems that scratch our own itch, but by broadening the scope of influence and focusing our time and talent to improve the code base and remediate issues in open source software if they arise. That is what it means to be a good member of an open source community.

我们已经深刻意识到，仅仅偶尔参与开源项目的企业无法获得长期成功。关键在于企业采用更具结构化、更具企业化的方法，将开源置于其技术战略的核心。为了真正从开源社区模式中获益，每个贡献者都应该对这些社区进行必要的投资。这包括为来自贵公司的开源开发人员提供合适的工具、培训和指导，帮助他们成为强大社区贡献者并成长为领导者。这意味着我们需要齐心协力，不仅要解决自己迫切的问题，还要拓宽影响范围，将我们的时间和才能投入到改善开源软件代码库和修复出现的漏洞上。这才是成为一个优秀开源社区成员的真正含义。

This document provides an overview and step by step guide for companies to engage in open source development, no matter where you are on your journey.

本文档为企业参与开源开发提供了概述和分步指南，适合于在开源路上的每一家企业。

JESSICA MURILLO

IBM 副总裁兼交付实践负责人

Introduction

介绍

Corporate participation in open source has reached an all-time high and continues to grow as organizations realize the value of consuming and contributing to open source projects (FIGURE 1). In addition, the nature of corporate (also called enterprise) participation continues to evolve as organizations increasingly discover that open sourcing proprietary technologies can create new sources of value and more robust product ecosystems.

随着企业逐渐意识到消费和贡献开源项目的价值，企业对开源项目的参与程度达到了历史最高水平，并仍然在持续增长（图1）。 此外，随着组织越来越多地发现，开源专有技术可以创造新的价值来源和更强大的产品生态体系，公司（也称为企业）参与的性质也在不断演变。

Enterprise open source development has challenges, which we discussed in detail in "A Deep Dive into Open Source Program Offices: Structure, Roles, Responsibilities, and Challenges."

企业开源开发存在挑战，我们在 “深入了解开源程序办公室：结构、角色、职责和挑战” 有详细的讨论。

The enterprise open source journey is challenging (FIGURE 2), and an organization needs to address this to build its open source leadership. If the organization has a clear plan to implement internal practices and address those known challenges, the journey becomes easier. For instance, the Linux Kernel is the largest collaborative software project in the world, and getting involved in the development process can be overwhelming.

企业开源之旅充满挑战（图 2），但企业需要解决这一问题，以建立其开源领导力。如果组织有一个明确的计划，来实施内部实践并解决这些已知的挑战，那么开源之旅会变得更容易。 例如，Linux内核是全球最大的协作软件项目，参与开发的过程是超级难的。

If you are one of the organizations that rely on the Linux Kernel for their products and services, investing time and resources into improving your internal development abilities, contributions process, and syncing your development with the upstream project can pay off immensely in the long run.

如果您是依赖 Linux 内核提供产品和服务的企业之一，那么投入时间和资源提高你们企业的内部开发能力、贡献过程，并将企业的开发与上游项目同步，长远来看可以带来巨额的回报。

Fortunately, since so many organizations and individuals have been successful at contributing to the Linux Kernel, there is a clear path to improve your own Linux Kernel contributions and aim for a leadership role.

幸运的是，由于如此多的组织和个人已经成功地为 Linux 内核做出了贡献，因此有一条清晰的路线，可以改进您自己对 Linux 内核的贡献，并起到领导者的作用。

FIGURE 1

图1

OPEN SOURCE STRATEGIC IMPACT​

开源战略影响​

• Accelerates the development of open solutions

• Provides an implementation to an open standard

• 加速开源项目解决方案的开发

• 提供开放标准的实现

• Commoditizes a market

• Reduces the process of nonstrategic software assets

• Provides an implementation to an open standard

• Shares development costs

• 使市场商品化

• 减少非战略软件资产的处理流程

• 提供开放标准的实现

• 分摊开发成本

• Drives demand by building an ecosystem for products and services

• 通过构建产品和服务生态系统来驱动需求

• Partners with others

• Engages customers

• Strengthens relationships with common goals

• 与他人合作

• 吸引客户

• 通过共同目标加强关系

Several factors drive and motivate participation in open source projects:

推动和激励参与开源项目的几个因素：

• Reducing the amount of work needed from product teams

• 减少产品团队所需的工作量

• Minimizing the cost to maintain source code and internal software branches

• 最大限度地降低维护源代码和内部软件分支的成本

• Improving code quality

• 提高代码质量

• Supporting faster development cycles

• 支持更快的开发周期

• Producing more stable code to serve as the base for products

• 生成更稳定的代码作为产品的基础

• Improving the organization's reputation in critical open source communities

• 提高组织在关键性开源社区中的声誉

Organizations often upstream modifications to open source projects, which is a fundamental aspect of the open source methodology. Following this approach, enterprise developers submit internal changes to the open source project for evaluation for acceptance into the main development tree. This process achieves several technical and nontechnical benefits for the enterprise due to such contributions (see FIGURE 3).

组织经常对上游开源项目进行修改，这是开源方法论的一个基本方面。 遵循此方法，企业开发人员向开源项目提交内部更改以进行评估，以便加入到主开发树中。 由于这些贡献，该流程为企业带来了多项技术和非技术的利益。 （请参阅图 3**）。

This report covers several practices enterprises can adopt to help grow their footprint in open source projects.

本报告涵盖了企业可以采用的几种做法，以帮助扩大他们在开源项目中的足迹。

FIGURE 2

CHALLENGES ENTERPRISES FACE AS PART OF INSTITUTIONALIZING OPEN SOURCE DEVELOPMENT PRACTICES

图2

企业在推行开源开发实践时面临的挑战

Hire developers from the project's community

从项目社区雇佣开发人员

This critical step allows your organization to gain skills and recognition immediately. Hiring two or three people is a great start toward making a noticeable impact on a large project, such as the Linux Kernel, attracting further hires and allowing enough resources to mentor existing junior developers.

这一关键步骤可以让你的组织立刻提升技能、获得认可。想对一个大型项目（例如Linux 内核）产生明显的影响，雇佣两三个人是一个很好的开始，这样可以吸引更多的员工， 并有足够的资源来指导已有的初级开发人员。

It is crucial to align corporate interests with individual interests.

让个人兴趣与公司利益保持一致非常重要。

It will be hard to motivate a senior open source developer to work on a given project when their interests do not match those of their employers. For instance, a memory management expert may not be interested in working on file systems; therefore, finding a match in interests is critical.

当高级开源开发人员的兴趣与雇主的兴趣不匹配时，会很难激励他们参与特定的项目。 例如一位内存管理专家可能对文件处理系统的工作根本不感兴趣；因此，找到兴趣的匹配点是 至关重要的。

Support and allocate time for upstream contributions

支持并分配时间用于上游贡献

The core principle for hiring open source developers is to support an organization's open source strategy, development, and upstream activities; however, in most cases, there is the expectation that open source developers will need to be available to support product teams due to their expertise and influence in their respective open source projects. It is also common for product teams to exercise their influence in an attempt to hijack the time of the open source developers by having them work on product development as much as possible. If this happens, many open source developers will head to the door, seeking new opportunities that allows them to work on their upstream project before an organization realizes what just happened.

雇用开源开发人员的核心原则是支持该组织的开源战略、开发和上游活动；然而，在大 多数情况下，由于开源开发人员在各自开源项目中的专业知识和影响力，人们期望他们能够支持产品团队。 产品团队利用开源开发人员的影响力，试图抢夺开源开发人员的时间、让其尽可能多地参与产品开发，这也很常见。 如果发生这种情况，许多开源开发人员会直奔门口离开，去寻求容许他们在上游项目上工作的新机会，此时这个组织可能还未意识到发生了什么。

FIGURE 3

图3

BENEFITS OF UPSTREAMING CODE​

上游代码的好处​

• Lower maintenance efforts for internally managed code, i.e., minimizes technical debt.

• 减少内部管理代码的维护工作，即最大限度地减少技术债务。

• Upstreamed code becomes visible to others and receives peer review and feedback, leading to improvements.

• 上游的代码对其他人可见，接收同行评审和反馈，进而可以优化改进。

• Upstream contributions provide stability to the project. They send a signal that the project is useful and important, which helps attract new contributors.

• 上游贡献为项目提供了稳定性。它们发出了一个重要信号，表明该项目有用的且重要，这有 助于吸引新的贡献者。

• Builds a positive relationship between the contributing organization and the project community.

• 在贡献组织和项目社区之间建立积极正向的关系。

• Upstreaming code is an effective way to provide technical leadership and influence the project.

• 上游代码是提供技术领导力和影响项目的有效方法。

• Upstreaming contributes to easier compliance and improved security due to centralizing code in upstream repos.

• 由于将代码集中在上游项目仓库中，有助于更轻松地遵从代码合规，提高 安全性。

• Upstream contributions are an effective means of ensuring stability in a company's software supply chain.

• 上游贡献是保护公司软件供应链稳定的有效手段。

• Helps organizations recruit talent from projects and retain their own developers by engaging them with the open source innovation engine.

• 帮助组织从项目中招募人才，同时通过让组织现有的开放人员参与开源创新引擎来吸 引留住他们。

Therefore, creating and maintaining a separation of upstream work and product work is essential. In other words, a followed practice is to provide open source developers with guaranteed time to meet their upstream aspirations and responsibilities, especially if they are maintainers. For junior developers, or other internal developers using open source in product components, such interactions with the upstream community will increase their language, communication, and technical skills. In the absence of such an upstream time guarantee, it is easy for these team members to become an extension of product teams, resulting in their upstream focus drying up in favor of product development.

因此，隔离上游工作和产品工作是必不可少的。换句话说，一个可 遵循的做法，是为开源开发人员提供有保证的时间，来满足他们的上游意愿和责任，尤其是当他们担任项目维护者时。 对于初级开发人员，或者其他在产品组件中使用开源的 内部开发人员，与上游社区的这种互动将提高他们的语言、沟通和技术能力。 如果无法保证上游开发时间的情况下，这些团队成员很容易成为产品团队的延伸，导致他们 的上游投入枯竭转而支持产品开发。

Create a mentorship program

创建导师计划

Set up a mentorship program where senior, experienced open source developers mentor junior, less experienced developers. Typically, a mentorship program runs for three to six months, during which the mentor supervises the mentee's work, assigns tasks, and ensures proper results. The mentor also conducts code reviews and provides feedback on anything the mentee produces before the mentee pushes the code to the upstream project.

建立一个导师计划，让资深的、有经验的开源开发人员来引导初级的、经验较少的开发 人员。通常情况下，导师计划持续3至6个月，在此期间，导师将监督学员的工作，分配 任务，并确保适当的结果。在学员将代码推送到上游项目之前，导师也会进行代码审查 并对学员的产出内容提供反馈。

This exercise aims to increase the number of developers contributing code to the upstream project and improve individual effectiveness by increasing the quality of code and the percentage of code accepted into the upstream project. In general, four to five mentees should work with a given mentor, and, ideally, they should work in the same area as the mentor to make code reviews more efficient.

这种练习的目的，是通过提高代码质量和上游项目接受代码的比例，来提升为上游项目贡献 代码的开发人员数量和个人效率。一般来说，4到5名学员与一位指定的导师一起工作， 理想情况下，他们应该与导师在同一领域工作，这样可以让代码审查更高效。

Formalize open source human resources tracking & performance metrics​

正式制定开源人力资源跟踪和绩效指标​

Mature open source organizations almost always have an open source developer track in their HR system. So, individuals hired as open source developers have a good sense of how their careers will progress within the organization. Additionally, organizations often need to adjust their performance-based bonuses and metrics to include goals related to open source development work. Closed source developers' performance metrics are often different from those of open source developers. For example, if an open source developer advocates for the implementation of a given feature, successfully gathers interest, and volunteers to write the code, how would they be rated, especially if they may not have written a single line of code?

所有成熟的开源组织，在他们的HR系统中几乎都有一个开源开发人员赛道。这样被雇用为 开源开发人员的个人，就非常清楚他们在组织内的职业发展。此外，组织往往需要调 整其基于绩效的奖金和指标，以包含与开源开发工作相关的指标。闭源开发人员的绩效指 标通常与开源开发人员的绩效指标不同。例如，如果一个开源开发人员倡导实现一个特 定的功能，成功地吸引到社区兴趣，并有志愿者们自愿编写代码，那么他们将如何被评价， 特别是如果他们自己可能没有编写一行代码的话？

Finally, organizations should allow a work-from-home (WFH) policy for open source developers regardless of the general corporate policy. During COVID-19, we witnessed organizations institute WFH policies to allow employees to be productive while under quarantine. It was a fascinating experiment for WFH policies, as organizations continued to operate, innovate, and produce, even though most of their employees worked from home. A WFH policy is almost mandatory in the open source world because open source developers are located worldwide, making hiring and retaining them easier.

最后，组织应该忽略常规的公司政策，允许开源开发人员远程办公。在COVID-19期间， 我们目睹了各组织制定的远程办公政策，让员工在隔离期间保持高效产出。对于远程办 公政策来说，这是一次引人入胜的实验，尽管他们的大多数员工都在家远程办公，但组织仍 继续运营、创新和生产。在开源世界，远程办公政策几乎是强制性的，因为开源开发 人员遍布全球，使得招聘和留住他们变得更加容易。

Offer training

提供培训

It is only possible for organizations to hire some of the senior and most expert developers. They are always looking for ways to increase the competence of their developers in a given technical domain; therefore, in addition to specialized training, organizations need to offer training on the open source development model and the basic concepts of open source legal compliance.

组织只可能聘任一些高级的、专家级的开发人员。他们总是在寻找方法来提升开发者在特定领域的能力。因此，在专业化培训之外，组织还需要开展关于开源开发模型和开源合规基本概念的培训。

Sample training courses include:

举例来说，培训课程包括：

• An open source development methodology course that teaches staff new to open source how open source development works and how to get best engaged with the project community

• 开源开发方法论课程：向刚接触开源的员工讲授开源开发的工作原理，以及如何更好地参与项目社区；

• An open source compliance course that teaches staff the basics of compliance principles and open source licensing. The course often includes modules covering the organization's policy and process.

• 开源合规课程，教导员工遵循开源原则和开源许可的基础知识。该课程通常涵盖了组织政策和流程的内容。

The Linux Foundation offers several technical training courses specific to open source technologies and several nontechnical courses, such as this free online open source compliance training for developers.

Linux基金会提供了一些针对开放源码的技术培训课程和非技术课程，例如上述面向开发人员的开源合规免费在线课程nontechnical courses。

Participate in and host open source events

参与并主持开源活动

Mature open source organizations support and encourage their developers to host, attend, and participate in open source conferences and events, including local community meetups, hackathons, and summits. Such participation helps open source developers connect personally with their peers, build relationships, and participate in technical discussions that guide the direction of the respective open source projects.

成熟的开源组织会对支持并鼓励自己的开发人员主持、参加和参与开源会议和活动，包括本地社区聚会、黑客马拉松和峰会。这种参与有助于开源开发人员与他们的同行建立个人联系，打造关系圈，参与并指导与各自开源项目有关的技术讨论。

As an organization that uses and adopts open source software, it is highly recommended to facilitate for your open source developers the process of attending and presenting at open source events. You can also sponsor big and small events to increase external visibility within the open source global community or simply target events tailored for specific open source projects. As a bonus benefit, such events are also great venues to look for talent.

作为使用开源软件的组织，强烈建议为开源开发人员提供便利，让其参加开源活动并进行演示。也可以赞助大大小小的活动， 以提升在全球化开源社区中的知名度，亦或者针对特定开源项目量身定制活动。作为额外的惊喜，此类活动也是发现人才的好去处。

Provide a flexible IT infrastructure

提供灵活的IT基础设施

Provide a flexible IT infrastructure that allows open source developers to communicate and work with the open source and Linux Kernel communities without any challenges. Additionally, set up an internal IT infrastructure that matches the tools used externally to help bridge the gap between internal teams and the Kernel community or any other open source project community for that purpose.

提供灵活的IT基础设施，使开源开发人员能够毫无阻碍地与开源社区和Linux内核社区进行交流和合作。此外，建立一个与外部使用的工具相匹配的内部IT基础设施，以减少内部团队与内核社区或任何其他开源项目社区之间的距离感。

Open source development uses three primary domains of IT services: knowledge sharing (wikis, collaborative editing platforms, and public websites), communication and problem solving (mailing lists, forums, and real-time chat), and code development and distribution (code repositories and bug tracking). Making some or all of these tools available internally properly supports open source development. However, this might conflict with existing organization-wide IT policies. If so, it is vital to resolve these conflicts and allow open source developers to use familiar tools.

开源开发使用IT服务的三个主要务领域: 知识共享(wiki、协作编辑平台和公共网站)，沟通和解决问题(邮件列表、论坛和实时聊天)，以及代码开发和分发(代码存储库和bug跟踪)。在内部提供这些工具的部分或全部，能为开源开发提供适当的支持。然而，这可能与组织现行的整体IT策略相冲突。如果出现这种情况，应重点解决这些冲突，并允许开源开发人员使用熟悉的工具。

Track developer code contributions

跟踪开发人员的代码贡献

Create an internal system to keep track of developer contributions and impact. Contributions can include upstream development, supporting product teams, knowledge transfer (mentoring, training), visibility (publications, talks), launching new open source projects, and establishing internal collaboration projects with other teams or groups.

搭建一个内部系统来跟踪开发人员的贡献和影响。贡献可以包括上游开发、支持产品团队、知识转移(指导、培训)、知名度(出版物、演讲)、启动新的开源项目，以及与其他团队或小组建立内部协作项目。

With this data, you can compare contributions from various internal development teams to identify where source code contributions are coming from.

根据这些数据，我们就可以把来自不同内部开发团队的贡献进行比较，以确定源代码贡献的来源。

For instance, you can use these metrics to compare your performance to other organizations involved in the Kernel ecosystem. This approach helps better inform you about the overall developer ecosystem for the project. In addition, these metrics provide a much better idea of your strengths and weaknesses and can help inform your overall development strategy.

例如，我们可以利用这些参数，与Kernel生态系统中的其他组织进行性能方面的比较。这种方法可以帮助我们更好地了解项目开发人员的整体生态系统。还可以更好地了解自身的优势和不足，从而影响整体开发战略。

Identify focus areas with a broad impact

确定具有广泛影响的重点领域

Contribute to and focus on areas that benefit more than one business unit or more than one product. This contribution model, driven by the criticality of software components, allows you to provide value and show return on investment across multiple business units, increasing your chances for more funding and support.

致力并专注于能让多个业务单元或多个产品受益的领域。这个基于软件重要性驱动的贡献模型，可以帮助我们提供价值并掌握横跨数个业务单元的投资回报，从而有机会获得更多资金和支持。

Foster internal collaboration

促进内部协作

Create collaboration projects with other business units that use the specific open source projects in their products. These collaborations can take one or more of many forms:

与其他在产品中使用特定开源项目的业务单元创建协作项目。这些合作可以采取一种或多种形式:

• Deliver training to their developers.

• 为开发人员提供培训。

• Run a workshop on a specific topic or problem.

• 举办针对特定主题或问题的研讨会。

• Develop new functionality.

• 开发新功能。

• Troubleshoot and resolve issues and bugs.

• 排除以及解决问题和 bug 。

• Upstream existing code for which they lack resources.

• 对缺乏资源的代码向上溯源。

• Help get them off an old fork and onto a mainline version.

• 帮助他们从一个旧的分支到一个主线版本。

These collaborations aim to help the product teams understand their needs and fulfill their product goals via open source enablement.

这些协作旨在帮助产品团队理解他们的需求，并通过开放源代码实现其产品目标。

Implement inner sourcing practices

落地内源实践

Inner sourcing is the application of open source methodologies to development projects inside the organization. The goal is to incubate the same capabilities within the enterprise as those in the open source community and to foster new employee-toemployee relationships that are cross-functional and touch on multiple product domains.

内源是开源方法论在组织内部开发项目的实际应用。其目的是在企业内部孵化出与开源社区一样的能力，以此来促进跨职能并且涉及多产品领域之间员工与员工之间的协作。

FIGURE 4

图4

BENEFITS OF ADOPTING INNERSOURCE PRACTICES IN THE ENTERPRISE

在企业采用内部开源实践的好处

• Releases cadency faster
• 更快的发布周期
• Improves source code quality
• 提高源代码质量
• Increases motivation
• 增加动力
• Increases internal information sharing
• 增加内部信息共享
• Reduces costs of development
• 降低开发成本
• Increases internal collaboration
• 增加内部协作
• Increases morale, retention
• 提高士气，提高员工留存率
• Increases internal communication
• 增加内部沟通

Open source principles work well on large-scale projects distributed across an enterprise. Many Fortune 500 organizations have adopted them externally and internally for the same reasons: faster releases, improved quality, increased innovation and communications, information sharing, reduced costs, greater and more effective collaboration, and increased employee morale and retention.

开源原则适用于企业内部大规模分布式项目的研发。很多财富 500 强企业在内外部采用开源都是基于同一个原因：加快发布、提高质量、增强创新与交流、信息共享、降低成本、更好及更有效地协作以及提高员工士气和留存率。

Inner sourcing prepares organizations to work effectively with external open source communities. It encourages employees to interact with colleagues elsewhere and with external community members without switching contexts. In addition, new employees familiar with this development model may integrate more quickly into established workflows. Finally, business partners are probably already using many of these development practices, so when an organization adopts inner sourcing practices, it is also strengthening its integration with the commercial ecosystem.

内源使组织能够与外部开源社区有效合作。它鼓励员工和其他地方的同事以及外部社区成员互动，而且无需切换上下文。除此之外，熟悉这种研发模式的新员工可以更快速的融入到既定的工作流程中。 最后，企业的业务合作伙伴可能已经在使用其中的许多开发实践，因此，当一个组织采用内部采购实践时，它也在加强与商业生态系统的集成。

Recommendations and lessons learned

建议和经验教训分享

Be patient​

保持耐心​

It takes considerable time to grow internal open source expertise. The goal from an enterprise perspective is to find people with enough peer recognition to be influential in the community. There are typically three pillars to this: domain expertise, open source methodology, and working practices.

培养内部开源专业知识需要相当长的时间。从企业的角度来看，目标是找到在社区中具有足够同行认可的人，能够在其中产生影响力。通常有三个支柱：领域专业知识、开源方法论和工作实践。

Shift to a more collaborative environment​

转向更协作的环境​

Internal organization dynamics must be favorable to open source efforts. Implementing these practices requires a shift from traditional software development practices to a more open and collaborative mindset. As an open source leader inside your organization, you will face several challenges in funding resources, justifying ROI, getting upstream focus, etc. These often require a major shift in mindset and a lot of education up the command chain.

内部组织动态必须有利于开源工作。遵循这些实践需要从传统的软件开发转向更加开放和协作的心态。作为组织内的开源领导者，您将面临一些挑战，诸如寻找资金来源、证明投资回报率、获得上游关注等。这通常需要在思维方式上进行重大转变，并在指挥链上进行大量教育。

Embrace a flexible IT infrastructure​

拥抱灵活的IT基础设施​

These open source practices require an IT infrastructure free from many limiting IT policies and a computing environment that supports open source development.

这些开源实践要求有一个摆脱许多限制性IT政策的IT基础设施，以及支持开源开发的计算环境。

Adopt proper success metrics​

采用适当的成功度量指标​

Proper open source metrics drive the desired development behavior. Unfortunately, the traditional metrics often used in product organizations only apply in the context of open source development. For example, we have had multiple instances of the upstream implementation of desired functionality because of OSG developers that lobby for support from the community.

适当的开源度量指标推动期望的开发行为。不幸的是，在产品组织中通常使用的传统度量指标，只适用于开源开发的环境。例如，由于OSG开发人员游说社区支持，我们已经有了多个所需功能的上游实现实例。。

In this case, the number of changesets or lines of code does not matter as much, as the technical leadership team members provide to get code upstream and reduce our downstream maintenance efforts. The metrics we track account for things like this.

在这种情况下，变更集或代码行数并不那么重要，因为技术领导团队成员提供的是将代码上游化，以减少我们的下游维护工作。我们跟踪的度量指标需要涵盖这些方面。

Use a lightweight approval process​

使用轻量级的批准流程​

Organizations have transitioned from highly complex and cumbersome policies to a more straightforward approach for receiving, reviewing, and approving source code contributions. Dedicated open source teams often receive blanket approval to contribute to open source projects. This is not the case for other groups, which need different approval levels depending on the nature of the contributed code (e.g., simple bug fixes, code to improve existing functionality, code that offers new functionality, or starting a new project). This is a function of the balance between all parties involved: legal, engineering, and open source.

组织已经从高度复杂和繁琐的政策过渡到了对源代码贡献的更为简单的方法，包括接收、审查和批准。专门的开源团队通常获得全面批准，可以为开源项目做出贡献。对其他团队来说，情况并非如此，它们需要根据贡献代码的性质（例如，简单的错误修复、改进现有功能的代码、提供新功能的代码或启动新项目的代码）获得不同的批准级别。这取决于所有参与方之间的平衡：法务、工程和开源。

Share information​

共享信息​

The organization must share information and priorities across different divisions. To illustrate this, assume you are on an open source team and request to support the implementation of a driver, but you cannot access the hardware manual and instructions. This situation sounds a bit like playing darts with the lights off; therefore, information sharing is critical to successful internal collaborations between the open source teams and everyone else.

组织必须在不同部门之间分享信息和优先事项。为了说明这一点，假设您在一个开源团队中，并请求支持驱动程序的实现，但您无法访问硬件手册和说明书。这种情况听起来有点像在灯光熄灭的情况下玩飞镖；因此，信息共享对于开源团队与其他人之间的内部协作至关重要。

Make strategic contributions​

进行战略性贡献​

Focus your contributions on upstream projects that would directly benefit the organization's strategy and products. In open source development, it is easy to get carried away by hopping between different exciting projects. However, in an enterprise setting where the open source group is a cost center, your driving force should be to focus on open source projects that support product development. Open source teams often perform a yearly review of the product portfolio they support and focus their involvement on open source projects commonly used across as many products as possible. Such a methodology drives priorities and is a great way to remain focused on what's essential, justifiable, and fundable.

将您的贡献重点放在能够直接有利于组织战略和产品的上游项目上。在开源开发中，很容易在激动人心的不同项目之间跳跃而得意忘形。然而，在一个企业环境中，开源团队是一个成本中心，您的驱动力应该是专注于支持产品开发的开源项目。开源团队通常会对其支持的产品组合进行年度审查，并将他们的参与重点放在尽可能多的产品常用的开源项目上。这种方法可以推动优先事项，并且是一种有效方法，使企业专注于重要的、可证明的和可资助的事情。

Partner with product teams​

与产品团队合作​

Be the upstream partner for product teams; they often feel like they are working inside a pressure cooker, especially in a consumer electronics environment. They often seem understaffed, need more critical resources to support parallel upstream development, and are under constant pressure for feature delivery within tight schedules. In such an environment, it is easy to overlook the benefit of upstreaming in favor of short-term time savings, which can, unfortunately, lead to technical debt that has a higher cost in the long term.

成为产品团队的上游合作伙伴；他们经常感觉自己好像在高压锅内工作，尤其是在消费电子产品环境中。他们常常显得人手不足，需要更多的关键资源来支持并行上游开发，并在紧张的时间表内承担着持续的功能交付压力。在这种环境中，很容易忽视上游化的好处，而倾向于短期节省时间，不幸的是，这可能导致长期成本更高的技术债务。

Open source teams can help by being a partner that focuses on delivering the necessary code upstream, reducing this technical debt.

开源团队可以转变为专注于向上游交付必要代码，成为产品团队的合作伙伴，从而减少这种技术债务。

FIGURE 5

图5

RECOMMENDED PRACTICES FOR CONTRIBUTING TO OPEN SOURCE PROJECTS 为开源项目做贡献的推荐实践

• Design & implement with upstreaming in mind to increase the likelihood of patch acceptance.

• 设计和实现时考虑上游，以增加补丁被接受的可能性。

• Ensure the contribution improves or introduces functionality that is useful for a broad base of users.

• 确保贡献改进或引入对广泛用户有用的功能。

• Stay involved in upstream development post merging with the upstream project.

• 在与上游项目合并后，保持参与上游开发。

• Document the code to make it easier to understand and to lower the barrier for new contributors.

• 做好代码相关的文档，使其更容易理解，并降低新贡献者加入的门槛。

• Upstream for the right reasons.

• 以正确的原因将代码上游化

• Upstreaming is not a code retirement strategy.

• 上游化不是一种代码退休策略。

• Listen to feedback, and act upon it---rework the code based on the peer review process.

• 倾听反馈，并根据同行评审过程重塑代码。

• Follow proper coding style, and secure code guidelines.

• 遵循适当的编码风格和安全代码指南。

• Follow the processes set by the project for submitting code, new features, etc.

• 遵循项目设置的流程提交代码、新功能等

Grow open source talent​

发展开源人才​

Grow open source talent in specific technology areas relevant to your products. Hiring a few resources from outside the organization is easy, but this approach has several limitations. The alternative approach is to convert your existing developers into open source contributors via training on the technical domain and open source methodology. You can then pair these developers with a mentor to further expand their skills.

培养与产品相关的特定技术领域的开源人才。从组织外部聘请一些资源很容易，但这种方法有局限性。替代方法是通过在技术领域和开源方法的培训，将现有开发人员转化为开源贡献者。然后，将这些开发人员与导师配对，以进一步扩展他们的技能。

Encourage developers outside the open source team to learn from and contribute to the open source community. We provide as much help as we can with upstream code contributions.

鼓励开源团队之外的开发人员向开源社区学习并做出贡献。尽力提供上游代码贡献方面的帮助。

Still, we need more resources and sometimes need a deeper understanding of products that might be necessary to identify where we can adequately upstream code. Better involvement in the open source community from teams outside our own allows us to get more critical code upstream and improves our ability to interact with the community.

尽管如此，我们仍然需要更多的资源，有时需要对产品有更深入的了解，这样才能确定将产品的哪些部分进行上游化。 外部的团队可以更好地参与开源社区，使我们能够获得更关键的上游代码，并提高我们与社区互动的能力。

Conclusion

总结

You must earn open source leadership, but you can lose it through a lack of participation. Regular, ongoing participation and contribution are the only ways to ensure your organization maintains open source leadership.

你必须赢得开源领导力，但你可能会因为缺乏参与而失去它。定期、持续的参与和贡献 是确保组织保持开源领导力的唯一方法。

Hopefully, this paper makes the task of improving your enterprise's open source practices more manageable. Following some of the recommended practices will go a long way toward developing internal open source expertise. You can leverage this expertise to improve your products and services and reduce the cost of code maintenance. Many organizations have had considerable success through the use of these strategies.

希望本文能使提升您的企业开源实践的任务变得更加可控。遵循这些推荐的实践将对发 展内部开源专业技能大有裨益。您可以利用这些专业知识来改进您的产品和服务，并降 低代码维护成本。许多组织通过使用这些战略取得了相当大的成功。

FIGURE 6 图6

MASTERING OPEN SOURCE SOFTWARE

掌握开源软件

Master open source software requires you to mastering the three critical Cs:

掌握开源软件需要你掌握三个关键C：

• Consumption

• 消费

• Establish internal infrastructure to enable proper practices for open source software consumption: policy, process, checklists, and training.

• 建立内部基础设施，以支持开源软件使用的正确做法：政策、流程、检查表和培训。

• Compliance

• 合规

• Enable open source compliance practices within your development process to ensure proper fulfillment of open source license obligations once products ship.

• 在企业的开发过程中启用开源合规实践，以确保在产品发货后正确履行开源许可义务。

• Contribution

• 贡献

• Enable your developers to engage within open source projects via a policy and a lightweight process and access to legal support. Provide training on open source development models and best practices.

• 使企业的开发人员能够通过政策和轻量级的流程参与开源项目，并获得法律支持。提供关于开源开发模式和最佳实践的培训。

FIGURE 7

图7

TOP 10 TIPS FOR MASTERING:

十大窍门掌握：

OPEN SOURCE CONSUMPTION

开源消费

How can you build a healthy environment for open source consumption within your organization? And how can you get ready for the next phase (i.e., becoming a contributor)?

您如何在组织内部建立一个健康的开源消费环境？您如何为下一阶段做好准备（即成为贡献者）？

• 1. Establish a policy and process to guide open source usage.
• 1. 建立一个政策和流程来指导开源使用。
• 2. Set up a team to oversee approvals for all open source usage.
• 2. 建立一个团队来监督所有开源使用的批准。
• 3. Understand your open source product strategy and core values.
• 3. 了解您的开源产品战略和核心价值观。
• 4. Provide the enabling IT infrastructure and tooling.
• 4. 提供支持的IT基础设施和工具。
• 5. Setup an open source license compliance program.
• 5. 建立一个开源许可合规计划。
• 6. Offer training to your staff and manager.
• 6. 为您的员工和经理提供培训。
• 7. Track everything, measure, improve, and communicate.
• 7. 跟踪一切，衡量，改进和沟通。
• 8. Adopt open source practices for your internal development.
• 8. 采用开源实践进行内部开发。
• 9. Identify incoming open source code through your software suppliers.
• 9. 通过软件供应商识别传入的开源代码。
• 10. Identify key open source projects, and start contributing to them.
• 10. 识别关键的开源项目，并开始为它们做贡献。

FIGURE 8

图8

ELEVEN TIPS FOR MASTERING:

11个需掌握的技巧：

OPEN SOURCE CONTRIBUTIONS

开源贡献

How can you build a healthy environment for open source contributions within your organization?

如何在组织内为开源贡献构建一个健康的环境？

• 1. Establish a policy and process to guide open source contributions.
• 1. 建立一个政策和流程来指导开源贡献。
• 2. Set up a team to oversee approvals for all open source contributions.
• 2. 成立一个团队来管理所有开源贡献的审批。
• 3. Focus contributions in the areas that will enable your technologies.
• 3. 将贡献集中在能够使能您的技术的领域。
• 4. Provide the needed IT infrastructure and tooling for contributors.
• 4. 为贡献者提供所需的IT基础设施和工具。
• 5. Offer training to your staff on contribution best practices.
• 5. 为您的员工提供关于开源贡献最佳实践的培训。
• 6. Track contributions, measure impact, improve, and communicate.
• 6. 跟踪贡献、衡量影响、改进和沟通。
• 7. Establish a mentorship program to train less experienced developers.
• 7. 建立一个导师计划，培训经验不足的开发人员。
• 8. Provide contributions guidelines, How-To's, Do's and Don'ts.
• 8. 提供贡献指南，讲清楚如何做，可以做什么以及不可以做什么。
• 9. Make open source legal support accessible to developers.
• 9. 让开发者可以获得开源法律支持。
• 10. Hire from the open source communities you value the most.
• 10. 从你最看重的开源社区招聘。
• 11. Always follow community processes / practices of specific projects.
• 11. 始终遵循具体项目的社区流程/实践。

Acknowledgments

致谢

The author would like to express his sincere appreciation to his Linux Foundation colleagues Hilary Carter, Jason Perlow, Melissa Schmidt, Jessica Murillo and Barry Hall for their valuable reviews and feedback. This report has benefited immensely from their experiences, reviews, and contributions.

作者在此对Linux基金会同事Hilary Carter、Jason Perlow、Melissa Schmidt、 Jessica Murillo和Barry Hall的宝贵评论和反馈表示衷心的感谢。从他们的 经验、评审和贡献中，本报告受益匪浅。

Feedback

反馈

The author apologizes in advance for any spelling errors or possible errors and is grateful to receive corrections and suggestions for improvements.

作者对任何拼写错误或可能出现的错误提前道歉，并非常感激能收到更正和改进建议。

Linux Foundation resources

Linux基金会资源

• E-book: A Deep Dive into Open Source Program Offices: Structure, Roles, Responsibilities, and Challenges • E-book: A Guide to Enterprise Open Source • E-book: Open Source Compliance in the Enterprise • E-book: Open Source Audits in Merger and Acquisition Transactions • Linux Foundation Open Source Best Practices for the Enterprise Guides • Linux Foundation Open Source Compliance Program • TODO Group • The Software Package Data Exchange® • Linux Foundation Training & Certification • Linux Foundation Events

• 电子书： 深入理解开源项目办公室：结构、角色、责任和挑战

• 电子书： 企业开源指南

• 电子书： 企业中的开源合规性

• 电子书： 并购中的开源审计交易

• Linux基金会企业开源最佳实践

• Linux基金会开源合规计划

• TODO Group

• [软件包数据交换SPDX]®(https://spdx.dev/)

• Linux基金会培训&认证

• Linux基金会事件活动

twitter.com/linuxfoundation [facebook.com/TheLinuxFoundation] linkedin.com/company/the-linux-foundation [youtube.com/user/TheLinuxFoundation]

About the author

关于作者

Dr. Ibrahim Haddad is the vice president of strategic programs at the Linux Foundation. He focuses on facilitating a vendor-neutral environment for advancing the open source AI platform. Haddad leads the Linux Foundation AI & Data Foundation and the PyTorch Foundation. His work and the work of both foundations support companies, developers, and the open source community in identifying and contributing to the technological projects that address industry and technology challenges for the benefit of all participants. Throughout his career, Haddad held technology and portfolio management roles at Ericsson Research, the Open Source Development Labs, Motorola, Palm, Hewlett-Packard, Samsung Research, and the Linux Foundation. He graduated with honors from Concordia University (Montréal, Canada) with a Ph.D. in computer science. He is fluent in Arabic, English, and French.

Ibrahim Haddad博士是Linux基金会战略项目副总裁。他致力于促进一个供应商中立的 环境来推进开源AI平台发展，他是LF AI& Data基金会和PyTorch基金会的执行总监， 他的工作以及这两个基金会的工作是为企业、开发人员和开源社区提供支持，以解决行业和技术挑战的项目做出贡献， 让所有参与者受益。在他的职业生涯中，Haddad曾在爱立信研发、开源开发实验室、摩托罗拉、Palm、惠普、三星和Linux基金会担任技术和项目组合管理职 位。他以优异成绩毕业于康考迪亚大学（加拿大蒙特利尔），获得计算机科学博士学位。 他精通阿拉伯语、英语和法语。

@ibrahimhaddad @IbrahimAtLinux IbrahimAtLinux.com Latest fun project: Tux NFT Club

[@ibrahimhaddad] [@IbrahimAtLinux] [IbrahimAtLinux.com] 最新的兴趣项目: Tux NFT俱乐部

Founded in 2021, Linux Foundation Research explores the growing scale of open source collaboration and provides insight into emerging technology trends, best practices, and the global impact of open source projects. Through leveraging project databases and networks and a commitment to best practices in quantitative and qualitative methodologies, Linux Foundation Research is creating the go-to library for open source insights for the benefit of organizations the world over.

成立于2021年的 Linux基金会研究， 致力于探索不断扩大的开源协作规模，并提供对新兴技术趋势、最佳实践和开源项目的全球影响 的洞察。通过利用项目数据库和网络，以及对定量和定性分析的最佳实践的承诺，Linux 基金会研究中心正在创建开源洞察基础库，以造福于世界各地的组织。

Copyright © 2023 The Linux Foundation

版权所有 © 2023 Linux基金会

This report is licensed under the Creative Commons Attribution-No Derivatives 4.0 International Public License.

本报告采用CC BY-ND 4.0国际公共许可证授权。

To reference the work, please cite as follows: Ibrahim Haddad, Ph.D., "A Road Map to Improve the Effectiveness and Impact of Enterprise Open Source Development," Foreword by Jessica Murillo, The Linux Foundation, February 2023.

如需参考该文，请引用以下内容：Ibrahim Haddad博士， "提升企业开源开发有效性和 影响力的路线图“，前言：Jessica Murillo，Linux基金会，2023年2月。

解决开源软件中的网络安全挑战

The current state of open source software security and methods to address and improve your cybersecurity posture

开源软件安全和方法的现状以及解决并改善您的网络安全状况的方法

In Partnership With:

联合出品：

Open source software (OSS) has become an integral part of the technology landscape, as inseparable from the digital machinery of modern society as bridges and highways are from global transportation infrastructure. According to one report, typically 70% to 90% of a modern application stack consists of pre-existing OSS, from the operating system to the cloud container to the cryptography and networking functions, sometimes up to the very application running your enterprise or website. Thanks to copyright licenses that encourage no-charge re-use, remixing, and redistribution, OSS encourages even the most dogged of competitors to work together to address common challenges, saving money by avoiding duplication of effort, moving faster to innovate upon new ideas and adopt emerging standards.

开源软件（OSS）已成为技术领域不可或缺的一部分，就像桥梁和高速公路是全球交通基础设施施密不可分一样，已经和现代社会的数字机器紧密结合在一起。据报告显示，现代应用程序栈通常由 70％ 至 90％ 的现有开源软件组成，从操作系统到云容器，再到加密和网络功能，甚至是支撑企业或网站运行的应用程序本身。由于版权许可证鼓励免费重复使用、重新混合和重新分发，开源软件鼓励企业合作共同解决共同的挑战，即使是最激烈的竞争对手，也可通过避免重复工作来节省资金，并更快地创新和采用新兴标准。

However, this ubiquity and flexibility can come at a price. While OSS generally has an excellent reputation for security, the communities behind those works can vary significantly in their application of development practices and techniques to reduce the risk of defects in the code, or to respond quickly and safely when one is discovered by others. Often, developers trying to decide what OSS to use have difficulty determining which ones are more likely to be secure than others based on objective criteria. Enterprises often don't have a well-managed inventory of the software assets they use, with enough granular detail, to know when or if they're vulnerable to known defects, and when or how to upgrade. Even those enterprises willing to invest in increasing the security of the OSS they use often don't know where to make those investments, nor their urgency relative to other priorities.

然而，这种普遍性和灵活性是有代价的。 虽然 开源软件通常在安全方面享有盛誉，但这些作品背后的社区在降低代码缺陷风险中的应用开发实践和技术，或在他人发现缺陷时快速安全响应方面可能存在很大差异。 通常情况下，试图决定使用哪种 开源软件的开发人员很难根据客观标准确定哪些 开源软件比其他 开源软件更安全。 企业通常没有对其使用的软件资产进行良好管理的清单，没有足够详细的细节来了解它们何时或是否易受已知缺陷的影响，以及何时或如何升级。 即使那些愿意投资增强其使用的开源软件安全性的企业，也经常不知道在哪些方面进行投资，以及这相对于其他优先事项的紧迫性。

However, fighting security issues at their upstream source - trying to catch them earlier in the development process, or even reduce the chances of their occurrence at all - remains a critical need. We are also seeing new attacks that focus less on vulnerabilities in code, and more on the supply chain itself - from rogue software that uses "typosquatting on package names to insert itself unexpectedly into a developer's dependency tree, to attacks on software build and distribution services, to developers turning their one-person projects into "protest-ware" with likely unintended consequences.

然而，在上游源头上解决安全问题 - 试图在开发过程的早期发现它们，甚至减少它们发生的机会 - 仍然是一个关键的需求。我们也看到了新的攻击，它们较少关注代码中的漏洞，而更多地关注供应链本身 - 从使用“包名称上的域名仿冒将自己意外插入开发人员的依赖树”的流氓软件，到对软件构建和分发服务的攻击，再到开发人员将他们的单人项目变成可能会产生意想不到的后果“抗议软件”。

To address the urgent need for better security practices, tools, and techniques in the open source software ecosystem, a collection of deeply invested organizations came together in 2020 to form the Open Source Security Foundation (OpenSSF), and chose to house that effort at the Linux Foundation. This public effort has grown to include hundreds of active participants across dozens of different public initiatives housed under 7 working groups, with funding and partnership from over 75 different organizations, and reaching millions of OSS developers. This report presents analysis that we intend to use to help support that effort. You can see a complete copy of my prepared testimony at: Testimony to the US House Committee on Science and Technology - Open Source Security Foundation (openssf.org).

为了满足开源软件生态系统中对更好的安全实践、工具和技术的迫切需求，一系列深度投资的组织在 2020 年聚集在一起，成立了开源安全基金会 （OpenSSF），并选择将这项工作设在 Linux 基金会。这项公共努力已经发展到包括数十个不同公共计划的数百名积极参与者，这些计划位于7个工作组下，来自超过75个不同组织的资金和合作伙伴关系，并覆盖了数百万个开源软件开发者。本报告介绍了我们打算用来帮助支持这项工作的分析。您可以在以下位置查看我准备的证词的完整副本：美国众议院科学和技术委员会的证词 - 开源安全基金会（openssf.org）。

Brian Behlendorf

布赖恩·贝伦多夫

General Manager, Open Source Security Foundation

总经理，开源安全基金会

The Linux Foundation

Linux 基金会

Introduction​

介绍​

Open source software (OSS) has had a tremendous impact on the development and distribution of the software we depend on today. Through its collaborative and open way of both developing and sharing software components, OSS has served as a key engine for innovation and encouraged the widespread reuse and sharing of core software components. Today, nearly all applications are composed of components dependent upon other components, creating a supply chain that involves hundreds of components and multitiered dependencies.

开源软件 (OSS) 对我们今天所依赖的软件的开发和分发产生了巨大影响。通过其开发和共享软件组件的协作和开放方式，开源软件已成为创新的关键引擎，并鼓励核心软件组件的广泛重用和共享。 如今，几乎所有应用程序都由依赖于其他组件的组件组成，从而形成了一个涉及数百个组件和多层依赖项的供应链。

Organizations of all sizes are heavily reliant on software, and much of that software supply chain consists of open source software components. Because of this, open source software has cybersecurity implications: the software supply chain is an attractive entry point for people and organizations interested in theft, disruption, or exploitation for economic or political gain. The attack surface today is changing from those in traditional cybersecurity threat models. Defects in small libraries that are widely used across the software ecosystem can cause systemic risk, as we've seen with incidents such as Log4shell.

各种规模的组织都严重依赖软件，其中大部分的软件供应链包含开源软件组件。正因为如此，开源软件具有网络安全的影响：软件供应链是入侵者利用进行盗窃、破坏或为了经济或政治利益而开发的一个有吸引力的入口点。如今，攻击面正在从传统的网络安全威胁模型中改变。在整个软件生态系统中广泛使用的小型库中的缺陷可能会导致系统性风险，正如我们在 Log4shell 等事件中所见到的那样。

Security challenges​

安全挑战​

Addressing the security of open source software components requires a different approach from traditional approaches of securing proprietary, vendor-supported software. The more loosely structured and community focused nature of OSS development presents a more challenging environment for addressing software security. The distribution of OSS projects is bookended by a small number of large visible projects (like the Linux kernel and Kubernetes) to a very large number of small projects. Smaller projects typically have fewer contributors and resources, and are therefore more likely to adopt a minimalist approach to development and security.

解决开源软件组件的安全问题需要与保护专有、供应商支持软件的传统方法不同的方法。开源软件的开发结构更加松散和以社区为重心，这种性质使得解决软件安全问题变得更具挑战性。开源软件项目的发布范围从少数几个大型可见项目（如Linux内核和Kubernetes）到非常多的小型项目。小型项目通常具有更少的贡献者和资源，因此更有可能采用简单的方法来对待开发和安全。

The tremendous benefits and prevalence of OSS in organizational software, combined with the vulnerability of the OSS software supply chain, puts us at a crossroads. Organizations and companies that use open source software need to become more aware of what dependencies they are using, proactively and regularly monitoring all components for usability, trustworthiness, and vulnerabilities. Ultimately, open source software is a two-way street: consumers of open source software must contribute back to the OSS communities to ensure the health and viability of the dependencies they rely on. Merely using open source software, without contributing back, is not enough. What is required is both to 1) incorporate the nature of OSS dependencies into standard cybersecurity and development practices and 2) contribute back to the OSS communities that organizations rely on.

开源软件在组织软件中所带来的巨大好处和普及性，加上开源软件供应链的脆弱性，让我们处于一个十字路口。使用开源软件的组织和公司需要更加了解它们所使用的依赖项，积极地和定期地监控所有组件的可用性、可信性和漏洞。最终，使用开源软件与回馈开源社区应该是一种互惠互利的关系：开源软件的消费者必须向开源软件社区做出贡献，以确保他们依赖的依赖项的健康和可行性。仅仅使用开源软件而不进行贡献是不够的。需要的是将开源软件依赖项的性质纳入标准的网络安全和开发实践中，并向组织依赖的开源软件社区做出贡献。

Research approach​

研究方法​

This report focuses on OSS security perspectives and how to improve OSS security and sustainability.

本报告的关注点在开源软件安全，以及如何改善开源软件的安全性和可持续性。

Research began in March 2022 with fifteen interviews of open source software maintainers and cybersecurity experts. These qualitative interviews helped to shape the scope of the research and the design of the quantitative survey instrument.

研究始于 2022 年 3 月，进行了 15 次开源软件维护者和网络安全专家的访谈。这些定性访谈有助于塑造研究范围和设计定量调查工具。

A worldwide survey was fielded in April 2022, targeting the following roles:

• Individuals who contribute to, use, or administer Oss
• Maintainers, core contributors, and occasional contributors to OSS
• Developers of proprietary software to use OSS
• Individuals with a strong focus on software supply chain security

2022 年 4 月，针对以下角色进行了一次全球调查：

• 贡献、使用或管理开源软件的个人
• 开源软件的维护者、核心贡献者和偶尔的贡献者
• 使用开源软件的专有软件开发人员
• 强烈关注软件供应链安全的个人

The survey included four sections:

• Screening questions and demographics
• OSS security perspectives. Sample size is 539 and margin of error (MoE) is +/- 3.6% at a 90% confidence level.
• OSS best practices for secure software development. Sample size is 72. Only OSS maintainer and core contributors were invited to complete this section of the survey. Because of the technical detail that was characteristic of this section, it was not addressed as part of this report and instead will be discussed in a separate report to be published in 2022 Q3.
• Improving OSS security. Sample size is 433 and margin of err (MoE) is +/-4.0% at a 90% confidence level.

该调查包括四个部分：

• 筛选问题和人口统计学信息
• 开源软件安全视角。样本量为 539，置信度水平为 90%，误差率(MoE)为 +/- 3.6%
• 为安全软件开发提供最佳实践。样本量为 72，只邀请了开源软件维护者和核心贡献者完成本部分的调查。由于这一部分的技术细节较多，本报告没有对其进行讨论，将在2022年三季度发表的另一份报告中进行讨论。
• 改进开源软件安全。样本量为 433，置信度水平为 90%，误差率(MoE)为 +/- 4.0%。

For more information about this research approach and sample demographics, see the methodology section of this paper. The data provided by Snyk is based on over 1.3 million projects and was collected from April 1, 2021 until March 31, 2022. Snyk's efforts were primarily focused on understanding how five key languages/ecosystems (.Net, Go, Java, JavaScript, and Python) are influencing the complexity of the software supply chain. This data was gathered from the use of Snyk Open Source, a static code analysis (SCA) tool free to use for individuals and open source maintainers.

更多有关此研究方法和样本统计信息的信息，请参阅本文的方法部分。 Snyk 提供的数据基于超过 130 万个项目，采集周期为 2021 年 4 月 1 日至 2022 年 3 月 31 日。Snyk 的工作主要集中在了解五种关键语言 / 生态系统（.Net、Go、Java、JavaScript 和 Python）如何影响软件供应链的复杂性上。这些数据是通过使用 Snyk 开源工具收集的，该工具是一个静态代码分析（SCA）工具，供个人和开源维护人员免费使用。

Open source software security perspectives​

开源软件安全观点​

Initial questions in this survey were designed to understand organizational commitment to security that covers OSS development and use and beliefs about the security of the OSS and its dependencies in use. Responses to these questions suggest that organizations collectively have been slow to make software security a priority.

该调查的初始问题旨在了解组织在涵盖开源软件开发和使用方面的安全承诺以及对正在使用的开源软件及其依赖性安全性的信念。对这些问题的回答表明，组织在使软件安全成为优先事项方面进展缓慢。

Many organizations do not have a security policy that covers OSS​

许多组织没有涵盖开源软件的安全政策​

One of the most startling findings of this research, as shown in Figure 1, is that only 49% of organizations have a security policy that covers OSS development or use. 34% of organizations indicate that they do not have a security policy for OSS development and usage, and 17% of respondents were not sure if their organization had a plan or not. If we prorate this 17% based on the existing distribution of responses, the number of organizations with a security policy covering OSS rises from 49% to 59%, and those without a policy rise from 34% to 41%.

这项研究最惊人的发现之一是，如图 1 所示，只有 49％ 的组织拥有涵盖开源软件开发或使用的安全策略。34％的组织表示，他们没有开源软件开发和使用的安全策略，17％的受访者不确定他们的组织是否有计划。如果将这17％根据现有的回答分布来按比例分配，则拥有涵盖开源软件的安全策略的组织数量从49％上升到59％，而没有策略的组织则从34％上升到41％。

Figure 1: Organizations with a security policy covering OSS

图1：有涵盖开源软件的安全政策的组织

Do you have an open source security policy in place for open source development or usage? (select one)

您是否已为开源软件的开发或使用制定了开源安全政策？（请选择一项）

Yes：
是

No：
否

Total：
不知道（英文应该是错了，坐标轴上是Don't know）

Having a security policy covering OSS indicates that you have a security action plan that includes the many OSS components in use. Without a software security policy, organizations may expose themselves to a significant amount of financial and reputational risk because they may not be evaluating software before its inclusion and/or may not be prepared for the inevitable updates due to software vulnerabilities (OSS or not).

拥有涵盖开源软件的安全策略表示您拥有包含许多使用的开源软件组件的安全行动计划。如果没有软件安全策略，组织可能会面临相当大的财务和声誉风险，因为他们可能没有在将软件包含进项目之前进行评估，或者可能没有为由于软件漏洞（无论是开源软件还是其他软件）而不可避免的更新做好准备。

Note that we intentionally did not have any special requirements on how the security policy covering OSS was stated. Some organizations have a single policy on software, and then only have specific statements for OSS in the relatively few cases where OSS would be sensibly different. This would be an application of the so-called "Hellekson's Law" ("a more specific policy can be improved for the general case by removing delimiters that narrow the policy scope, "e.g., deleting "open source" from an "open source software" policy typically improves it). For our purposes this is fine. We simply let the respondents identify whatever applied to their organization.

请注意，我们有意没有对涵盖开源软件的安全策略有任何特殊要求。一些组织只有一个关于软件的策略，然后仅在开源软件有相对少的情况下才有特定的声明。这是所谓的“Hellekson 定律”的应用（“通过删除缩小策略范围的分隔符，例如，从“开源软件”策略中删除“开源”，可以改进通用情况下的更具体策略）。对于我们的研究目的来说，这是可以接受的。我们只是让受访者确定他们所在组织适用的情况。

The one benefit of the distribution shown in Figure 1 is that we can statistically compare and contrast the characteristics of organizations with a security policy against those without one. Understanding these comparative differences helps us describe the OSS security journey that organizations are on.

图 1 所示的分布的一个好处是，我们可以对拥有安全策略的组织与没有安全策略的组织进行统计学比较和对比。了解这些比较差异有助于我们描述组织在开源软件安全方面的旅程。

Small organizations shoulder disproportionate OSS security risk​

小型组织承担着不成比例的开源软件安全风险​

This survey included organizations of various sizes (based on the number of worldwide employees). The survey sample was distributed by organization size as follows: small organizations (44%, 1-499 employees), medium organizations (20%, 500-4,000 employees), large organizations (35%, 5,000+ employees), and 1% don’t know or are not sure.

本次调查涵盖了各种规模的组织（根据全球员工人数划分）。调查样本按组织规模分布如下：小型组织（44％，1-499 名员工），中型组织（20％，500-4,000 名员工），大型组织（35％，5,000 名及以上员工），1％ 不知道或不确定。

The measure of security policy covering OSS by organizational size is shown in Figure 2. Immediately noticeable is the difference in distributions between organizations with 1-499 employees and those with 500 employees or more. Just 41% of small organizations have an OSS security policy, compared to 56%-57% of larger organizations. This significant difference indicates that small organizations behave differently than larger organizations when it comes to OSS security policy adoption.

按组织规模衡量涵盖开源软件的安全政策的情况如图 2 所示。立即显着的是，1-499 名员工的小型组织和 500 名员工以上的组织之间的分布差异。只有 41% 的小型组织拥有开源软件安全政策，而大型组织的开源软件安全政策采用率在 56%-57% 之间。这个显著的差异表明，小型组织在开源软件安全政策采用方面的行为与大型组织不同。

Figure 2: A distribution of OSS security policy by organization size

图 2：按组织规模分布的开源软件安全策略

Do you have an open source security policy in place for open source development or usage? (select one) by Enterprise size

您是否有针对开源软件开发或使用的开源安全策略？按企业规模（选择一项）


Yes: 
是

No: 
否

Don't know: 
不知道

1 to 499 Emp: 
员工数 1～499

500 to 4999 Emp: 
员工数 500~4999

5000+ Emp: 
员工数 5000+

Source: 2022 Open Source Supply Chain Security Survey.
来源：2022年开源供应链安全调查。

One reason that small organizations are OSS security challenged is economies of size. Small organizations have small IT staff and budgets, and the functional needs of the business often take precedence so that the business can remain competitive. Lack of resources and time were the leading reasons why organizations were not addressing OSS security best practices.

小型组织开源软件安全面临挑战的原因之一是规模经济。小型组织拥有较少的 IT 人员和预算，业务的功能需求通常具有优先性，以使业务能够保持竞争力。缺乏资源和时间是组织未能解决开源软件安全最佳实践的主要原因。

While it is disappointing that 44% of small organizations do not have an OSS security policy, an additional concern is that close to 30% of larger organizations also do not have an OSS security policy. Small organizations can rationalize increased financial, reputational, and legal risk, but this becomes tenuous for medium organizations and insupportable for large organizations with 5000+ employees. Medium and large organizations likewise complain about not enough having resources or time to address OSS security needs. Surprisingly, a lack of awareness about security best practices is more often identified by large organizations as a reason for not attending to OSS security needs than lack of time.

虽然令人失望的是，44% 的小型组织没有开源软件安全策略，但更令人担忧的是，接近 30% 的大型组织也没有开源软件安全策略。小型组织可以理性地解释为增加财务、声誉和法律风险，但对于 5000 多名员工的中型和大型组织来说，这变得岌岌可危。中型和大型组织同样抱怨没有足够的资源或时间来应对开源软件安全需求。令人惊讶的是，大型组织更常常将缺乏安全最佳实践的意识视为不关注开源软件安全需求的原因，而不是时间不足。

Many Organizations score poorly on OSS security​

许多组织在开源软件安全方面得分低​

We asked organizations how secure their open source software is today. Responses to this question are shown in Figure 3. Overall, 59% of organizations feel their OSS is either somewhat secure or highly secure. For organizations with an OSS security policy, this value rises to 70%. It falls to 45% for organizations without a security policy.

我们询问了组织关于他们的开源软件安全性的评估。这个问题的回答如图 3 所示。总体而言，59% 的组织认为他们的开源软件在某种程度上是安全的或者非常安全的。对于有开源软件安全策略的组织，这个比例上升到了 70%。而对于没有安全策略的组织，这个比例则下降到了 45%。

Figure 3: OSS security today

图 3：当今的开源软件安全情况

How secure is your open source software today? (select one) by Do you have an open source security policy in place for open source development or usage?

您的开源软件今天有多安全？按您是否有一个用于开源开发或使用的开源安全策略进行分组（选择一项）

65
Weighted Avg of responses
Score range: 0 -100

65
回答的加权平均分
分数范围：0～100

Yes：
是

No：
否

Total：
综合

Highly Insecure：
非常不安全

Somewhat Insecure：
有些不安全

Neither Insecure or Secure：
中性

Somewhat Secure：
有些安全

Highly Secure：
非常安全

Don’t Know：
不知道

Source: 2022 Open Source Supply Chain Security Survey.
来源：2022年开源供应链安全调查。

A simple weighted average of all responses shows a composite score of 65 for all organizations, which is a poor grade. Organizations with an OSS security policy score a 70, and organizations without a policy score a 58.

简单的加权平均所有回答的分数显示，所有组织的综合分数为 65 分，这是一个不好的分数。拥有开源软件安全策略的组织得分为 70 分，而没有策略的组织得分为 58 分。

The secure development of OSs is also at risk​

开发或使用开源软件的安全问题同样存在风险​

Similarly, Figure 4 shows how secure the process for developing or using OSS is today. Using the same responses shown in Figure 3, the results are nearly identical. Across all organizations, 59% believe that their development processes are somewhat secure or highly secure. This value rises to 73% for organizations with an OSS security policy and falls to 47% for organizations without.

同样，图 4 展示了开发或使用开源软件的过程的安全性。使用图 3 中展示的相同回答，结果几乎相同。在所有组织中，59% 的人认为他们的开发过程是相对安全或高度安全的。对于拥有 OSS 安全策略的组织，这个值升至 73%，而对于没有安全策略的组织，则下降至 47%。

Figure 4: Security of OSS development and use today

图 4：如今的开源软件开发和使用的安全性

How secure is your process for developing or using open source software today? (select one) by Do you have an open source security policy in place for open source development or usage?

您是否已经针对开源开发或使用实施了开源安全策略？（选择一项）按照您是否对开源开发或使用实施了安全策略，您认为您目前的开源软件开发或使用流程有多安全？（选择一项）

65
Weighted Avg of responses
Score range: 0 -100

65
回答的加权平均分
分数范围：0～100

Yes：
是

No：
否

Total：
综合

Highly Insecure：
非常不安全

Somewhat Insecure：
有些不安全

Neither Insecure or Secure：
中性

Somewhat Secure：
有些安全

Highly Secure：
非常安全

Don’t Know：
不知道

Source: 2022 Open Source Supply Chain Security Survey.
来源：2022年开源供应链安全调查。

The similarity of this distribution when compared to Figure 4 also yields a weighted average of 65 and organizations with the security policy score 71 and organizations without a policy 58.

与图 4 相比，这个分布的相似性也产生了一个加权平均值为 65，安全策略得分为 71，没有策略的组织得分为 58。

Across organizations, there is a belief that the security of OSS development and use will improve to a weighted average score of 72 by the end of 2022 and 77 by the end of 2023. Later in this report, you will see that an organizational cornerstone of their OSS security strategy is for the vendor community to provide security tools with greater intelligence. Other key elements of their OSS security strategy include a more complete understanding of best practices for secure software development and greater CI/ CD automation to eliminate manual actions and opportunities that expose the pipeline to security risks.

跨组织而言，人们认为到 2022 年底，OSS 开发和使用的安全性将提高到加权平均分数为 72，到 2023 年底将提高到 77。在本报告的后面部分，您将看到，组织制定的 OSS 安全策略的基石是让供应商社区提供更具智能的安全工具。他们的 OSS 安全策略的其他关键要素包括更全面地了解安全软件开发的最佳实践，并实现更多的 CI / CD 自动化以消除手动操作和可能导致安全风险的机会。

Who drives OSS security policies?​

谁推动了开源软件安全策略？​

Figure 5 superficially creates a conundrum: how do organizations without a top-down OSS security policy have people responsible for defining OSS security policy? Additionally. not having an OSS security policy doesn't mean that groups aren't addressing OSS security in ad hoe ways.

图 5 表面上制造了一个难题：没有由上而下的开源软件安全策略的组织如何有负责定义开源软件安全策略的人？此外，没有开源软件安全策略并不意味着各组没有以临时方式解决开源软件安全问题。

Across organizations, just 31% vest responsibility for defining an OSS security policy in the hands of a CIS and/or security team. The second leading choice of multiple teams at 16% suggests that instead of policy being established by a CIS, it evolves across the Software Development Life Cycle (SDLC) based on the focus of the team. Because a security focus should exist across the CI/CD pipeline, multiple teams are needed to implement OSS security policy. Reliance on open source maintainers at 13% overall can be workable 1f the maintainers are either part of the organization or known to the organization - but it sdems recklessly optimistic to put trust in OSS projects with unknon provenance.

跨组织而言，仅有 31% 的组织将定义 OSS 安全策略的责任归属于 CIS（计算机信息安全）和 / 或安全团队。16% 的多个团队作为第二选择表明，政策的制定不是由 CIS 确定的，而是根据团队的重点在软件开发生命周期 (SDLC) 中逐步形成。由于在 CI/CD 管道中应存在安全重点，因此需要多个团队来实施 OSS 安全策略。总体上依赖于开源维护者的 13% 可能是可行的，前提是维护者要么是组织的一部分，要么已知于组织，但是如果信任来源未知的 OSS 项目，这种做法似乎过于乐观。

Figure 5: Responsibility for OSS security policies
Who is responsible for defining your open source security policy? (select one) by Do you have an open source security policy in place for open source development or usage?

图5：开源安全策略的责任
谁负责制定您的开源安全策略？（选择一项）按您是否有适用于开源开发或使用的开源安全策略？

Yes：
是

No：
否

Total：
综合

Security team and /or CISO：
安全团队/CISO

Multiple teams：
多个团队

Open source maintainers：
开源维护者

No one：
没有人

Developer or care contributor：
开发人员或贡献者

Operations or Bite Reliability Engineers (SREs)：
运维或可靠性工程师（SREs）

Contributors from other teams：
其他团队的贡献者

Don’t Know：
不知道

Source: 2022 Open Source Supply Chain Security Survey.
来源：2022年开源供应链安全调查。

The percentages in Figure 5 are especially revealing. Across organizations with an OSS security policy, 80% vest the definition of an OSS security policy with the CISO/security team, multiple teams, or open source maintainers. This contrasts with organizations without an OSS security policy where 40% of these same groups are involved with OSS security in some capacity.

在图 5 中的百分比特别说明了问题。在有开源安全策略的组织中，80％的组织将开源安全策略的定义授予CISO/安全团队、多个团队或开源维护人员。这与没有开源安全策略的组织形成对比, 在没有开源安全策略的组织中，同样的团队有40％以某种方式参与开源安全。

Perhaps one positive indicator in Figure 5 is that only 30% of organizations without an OSS security policy admit that no one is addressing OSS security. This means that 70% of these organizations are addressing OSS security in part through ad hoc means, suggesting that organizations without an OSS security policy are not completely adrift and have some grassroots activities to address OSS security needs.

或许在图 5 中令人欣慰的一个指标是，仅有 30% 的没有开源安全策略的组织承认没有人在处理开源安全。这意味着 70% 的这些组织通过一些临时手段部分地解决了开源安全问题，表明没有开源安全策略的组织并非完全漂泊无助，有一些基层活动来解决开源安全需求。

Organizations are not effectively managing the security of their dependencies​

组织未能有效地管理其依赖项的安全性​

Dependencies are a characteristic of modern development. Direct dependencies are typically components or services called directly by your code. Indirect or transitive dependencies are essentially dependencies of your dependencies (in typically many tiers).

依赖项是现代开发的一个特征。直接依赖通常是被你的代码直接调用的组件或服务。间接或传递依赖实际上是您依赖的依赖（通常是多个层次）的依赖。

Vulnerabilities exist in component code for many reasons. Contributing factors include the programming language used, the CI/CD process in use, the education and skill of the developer in developing secure software, and the scope of testing. Complicating matters is that vulnerability management is not a perfect science. Vulnerability scanning normally identifies many false positives based on the information available to the scanning tool. Conversely, an actual vulnerability in a component may not matter if the code linked to the vulnerability is never executed and/or will only provide trusted data to the vulnerable code.

组件代码存在漏洞的原因有很多。其中的因素包括使用的编程语言、使用的 CI/CD 过程、开发人员在开发安全软件方面的教育和技能以及测试的范围。复杂化问题的是，漏洞管理并不是一门完美的科学。漏洞扫描通常会基于扫描工具可用的信息识别出很多误报。相反，如果与漏洞相关的代码从未被执行，或者只会向漏洞代码提供可信数据，那么组件中的实际漏洞可能就不重要了。

What is known is that organizations are not well-positioned to manage their vulnerabilities. Only one response in Figure 6 indicates that organizations are confident in the security of their direct dependencies.

已知的是，组织机构无法很好地管理它们的漏洞。在图6中，只有一个回答表明组织机构对其直接依赖项的安全性感到有信心。

Figure 6: Vulnerability concerns across direct dependencies
图 6：对直接依赖项的漏洞担忧

How concerned are you that the direct dependencies your software relies on might be malicious or compromised? (select one) by Do you have an open source security policy in place for open source development or usage?
你对软件所依赖的直接依赖项可能是恶意或受到攻击有多担忧？（选择一个）你是否已经为开源开发或使用制定了开源安全策略？

Yes：
是

No：
否

Total：
综合

Source: 2022 Open Source Supply Chain Security Survey.
来源：2022年开源供应链安全调查。

Direct dependencies are easy to track but we struggle with indirect dependencies
直接依赖项易于跟踪，但我们难以处理间接依赖项

We don’t have good controls to address this & it concerns me
我们没有好的控制措施来解决这个问题，这让我感到担忧

We have strong controls & I’m confident in the security of our direct dependencies
我们有强有力的控制措施，我对我们的直接依赖关系的安全性感到有信心

We don’t have good controls to address this but it doesn’t concern me
我们没有好的控制措施来解决这个问题，但我并不担心

Don’t Know：
不知道

Across all organizations, only 24% have confidence in the security of their direct dependencies. This value rises to 36% for organizations that have an OSS security policy but falls to just 9% of organizations without such a security policy. Organizations reporting that dependencies are easy to track (37%) may be correct in understanding their dependencies, but this doesn't mean that these dependencies are collectively secure.

所有组织中，只有 24% 的组织对其直接依赖项的安全性感到有信心。对于有开源安全策略的组织，这个值上升到 36％，但对于没有安全策略的组织，这个值只有 9％。 报告依赖项项易于跟踪的组织（37％）可能正确地理解了它们的依赖项，但这并不意味着这些依赖项总体上是安全的。

Snyk - Dependencies drive complexity​

Snyk - 依赖关系驱动复杂性​

Dependencies are one of the key components driving much of the conversation about the software supply chain. Professionals in both development and security teams are increasingly aware that securing their enterprise does not depend entirely on their organization. Instead, we are having to look further and further, down the rabbit hole of "Where did this code come from?" It's hard enough to understand where everything originated when you're trying to test code written in-house. When you add dependencies two, three, or more levels deep, it becomes daunting to even consider the problem.

依赖项是推动软件供应链讨论的关键组成部分之一。开发和安全团队的专业人员越来越意识到，保护他们的企业并不完全依赖于他们的组织。相反，我们不得不越来越深入地查看“这段代码来自哪里？”的问题。当您尝试测试内部编写的代码时，了解所有代码的起源已经很难了。当您添加两个、三个或更深层次的依赖项时，甚至考虑这个问题都变得令人生畏。

The libraries we call in our code, the code snippets we pull from the internet, and the tools we include in container configurations are all examples of direct dependencies. In each of these cases we are relying on third-party code explicitly to fulfill a specific need or purpose.

直接依赖项是我们在代码中调用的库、从互联网获取的代码片段以及包含在容器配置中的工具等。在这些情况下，我们明确地依赖第三方代码来满足特定的需求或目的。

Measuring the number of dependencies per project, therefore, makes a good starting point for understanding how complex the problem of tracking dependencies really is. As shown in Figure 7, the average number of dependencies per project stretches from Python, with 25 dependencies per project, to JavaScript's 173 per project.

因此，衡量每个项目的依赖关系数量是了解跟踪依赖关系问题的复杂性的好起点。如图 7 所示，每个项目的平均项数量从 Python 的 25 个到 JavaScript 的 173 个不等。

Does that mean JavaScript is inherently more complex than .Net (49 dependencies), Go (56 dependencies), or Java (40 dependencies)? Not necessarily. In the case of JavaScript, each dependency often has a single purpose and small scope, rather than a library that fulfills multiple purposes with a large scope.

这是否意味着 JavaScript 本质上比 .Net（49 个依赖项）、Go（56 个依赖项）或 Java（40 个依赖项）更复杂？不一定。在 JavaScript 的情况下，每个依赖项通常只有一个目的和小的范围，而不是一个具有大范围的多个目的的库。

Neither approach is more or less secure than the other but knowing which dependencies you rely on (and how trustworthy they are) is an important part of vulnerability management. Sadly, only 24% of the respondents in this survey felt they had strong controls in place to handle the security of their dependencies.

这两种方法都不比另一种更安全，但了解你依赖的依赖项（以及它们的可信度）是漏洞管理的重要组成部分。不幸的是，在此次调查中，只有 24% 的受访者认为他们已经采取了强有力的措施来处理其依赖项的安全性。

Figure 7: Average dependency count per project by language
图 7：按语言每个项目的平均依赖项数量

（下面几个编程语言不翻译）
.Net
Go
Java
JavaScript
Python

Source: 2022 Open Source Supply Chain Security Survey.
来源：2022年开源供应链安全调查。

Average dependencies per project
平均每个项目的依赖项数量

Recent efforts by the US Government to encourage, and even mandate, organizations to create a Software Bill of Materials (SBOM) is evidence of how important it is to have a handle on dependencies. Tracking direct dependencies is a significant issue by itself. Indirect, or transitive, dependencies mark the real start of complexity. Each of the libraries referenced in a project incorporates additional code to perform its own function, and each of those third-party libraries may rely on other libraries as well. Organizations who want a complete accounting of their transitive dependencies should be requiring SBOMs from their suppliers and investing in tools to consume these SBOMs.

美国政府最近鼓励甚至强制要求组织创建软件清单（SBOM）的努力，证明了掌握依赖项关系的重要性。追踪直接依赖项本身就是一个重大问题。而间接或传递性依赖项才是复杂性的真正开始。每个在项目中引用的库都会包含额外的代码来执行其自身的功能，而每个这样的第三方库可能也依赖于其他库。想要完整记录传递依赖关系的组织应该要求其供应商提供 SBOM，并投资于消费这些 SBOM 的工具。

Figure 8 is patterned directly after Figure 6, except that it focuses on transitive dependencies. Transitive dependencies are objectively more difficult to evaluate as the level of dependency increases. The result is that fewer organizations believe that their transitive dependencies are secure

图 8 直接复制了图 6 的结构，不过它专注于间接依赖项。随着依赖程度的增加，间接依赖项的评估变得更加困难，因此，越来越少的组织认为它们的间接依赖项是安全的。

Figure 8: Vulnerability concerns across transitive dependencie
图 8：跨传递依赖项的漏洞问题

How concerned are you that the indirect (transitive) dependencies your software relies on might be malicious or compromised? (select one) by Do you have an open source security policy in place for open source development or usage?
您担心您的软件间接（传递）依赖项可能存在恶意或被攻击的风险吗？ （选择一项） 您是否为开源开发或使用制定了开源安全策略？

Figure 8 shows that just 18% of organizations are confident in the security of their transitive dependencies. Once again, this value rises to 27% for organizations that have an OSS security policy but plummets to just 5% for organizations without a security policy.

图 8 显示，只有18%的组织对其传递依赖项的安全性有信心。同样，这个值对于制定了开源安全策略的组织上升至27％，但对于没有安全策略的组织则下降至5％。

A recent discussion with David A. Wheeler, a leading authority on OSS security, yielded this insight, "I think many organizations often don't update their OSS software, even when the older version of the OSS has widely-known vulnerabilities. That's not unique to OSS, many organizations also often don't update old versions of proprietary software with widely-known vulnerabilities

与开源软件（OSS）安全方面的权威专家大卫·A·惠勒（David A. Wheeler）的最近一次讨论得出了这样的见解：“我认为许多组织经常不更新他们的开源软件，即使旧版本的开源已经被广泛知晓的漏洞所影响。这不仅仅是开源的问题，许多组织也经常不更新旧版本的专有软件，而这些软件也有广泛已知的漏洞。”

Snyk - Dependency creates vulnerability​

Snyk - 依赖关系创建了漏洞​

How many vulnerabilities are there in my project? We estimated this by totaling known vulnerabilities in a particular project combined with the known vulnerabilities of its dependencies (presuming that the vulnerabilities in the dependencies were exploitable). The Net projects in our data had 23 vulnerabilities per project on average, with Go at 34, Java at 90, JavaScript having 47, and Python at 36. This covers both errors introduced in development and vulnerabilities in transitive dependencies. According to Snyk's data, approximately 40% of all vulnerabilities are from these transitive dependencies. We further broke down the count of vulnerabilities per project in Figure 9 to highlight the effect of severity by language.

我的项目中有多少漏洞？我们通过汇总一个特定项目中已知的漏洞以及其依赖项的已知漏洞数量来估计。假设依赖项中的漏洞是可利用的。我们的数据中，.Net 项目平均有 23 个漏洞，Go 项目有 34 个漏洞，Java 项目有 90 个漏洞，JavaScript 项目有 47 个漏洞，Python 项目有 36 个漏洞。 这包括开发中引入的错误和传递依赖项中的漏洞。根据 Snyk 的数据，大约 40% 的漏洞来自这些传递依赖项。我们在图 9 中进一步分解了每个语言的漏洞计数，以凸显严重性的影响。

A large part of the value of SCA tools is finding where vulnerabilities are being introduced by the use of known bad libraries. Is your code incorporating an older version of a library with known vulnerabilities? Is the package still maintained or is it abandoned? Did you accidentally get a library pretending to be the one you actually wanted? These are just a few of the potential issues that could get a package flagged.

SCA 工具的很大一部分价值在于发现由于使用已知存在漏洞的库所引入的漏洞。您的代码是否正在使用一个存在已知漏洞的旧版库？该软件包是否仍在维护中或已被放弃？您是否意外获取了一个假冒您实际需要的库？这些也只是可能会导致软件包被标记的一些潜在问题。

Knowing the number of vulnerabilities in your own project helps you understand how your efforts compare to global numbers. Organizations that see data far different from the baseline number of vulnerabilities in a project can investigate the causes of a disparity. It could be as simple as different ways of measuring the same metric. On the other hand, the difference in numbers could indicate poor coding practices or a large number of old libraries being part of a standard. Without policies and standards that require vulnerability tracking, you may never know.

了解自己项目中漏洞的数量有助于了解自己的努力与全球数据相比的情况。看到与项目中基线漏洞数量迥然不同的数据的组织可以调查差异的原因。这可能只是衡量同一指标的不同方法。另一方面，数字的差异可能表明糟糕的编程实践或大量的旧库作为标准的一部分。如果没有要求跟踪漏洞的政策和标准，您可能永远不会知道。

Figure 9: Average count of vulnerabilities by language and severity

图 9：按语言和严重程度划分的平均漏洞数量

Vulnerability Severity
漏洞严重程度

Critical：
严重

High：
高危

Medium：
中危

Low：
低危

（编程语言不翻译）
.Net
Go
Java
JavaScript
Python

Source: 2022 Snyk user data.
来源：2022年 Snyk 用户数据。

Tracking vulnerabilities introduced by transitive dependencies is one of the hardest challenges in DevOps today. Think about a project that has fifty dependencies; if the average project has five critical vulnerabilities, just the first level of dependencies could lead to 200+ critical vulnerabilities. Each layer down expands the problem dramatically. Luckily, most vulnerabilities are tightly constrained by the factors needed to exploit them.

跟踪由传递依赖引入的漏洞是当今 DevOps 面临的最大挑战之一。考虑一个有 50 个依赖项的项目；如果平均每个项目有 5 个严重漏洞，那么仅第一级依赖关系就可能导致 200 多个严重漏洞。每一层依赖都会大大扩大问题的规模。幸运的是，大多数漏洞都受到利用所需因素的严格限制。

How organizations are addressing and prioritizing their cybersecurity needs​

组织如何解决和优先考虑其网络安全需求​

A key finding of this research is that security, as it applies to OSS, is a rapidly evolving domain. Each of the primary threat vectors (source threats, build threats, and dependency threats) identified in the SLSA (Supply Chain Levels for Software Artifacts) model will require multiple actions on the part of most organizations to address. However, because OSS security is also rapidly evolving, increased functionality and tool consolidation should help reduce the complexity that organizations face in addressing software supply chain security needs.

该研究的一个关键发现是，与开源软件(OSS)相关的安全性是一个快速发展的领域。SLSA（软件工件供应链级别）模型中确定的每个主要威胁向量（源威胁、构建威胁和依赖威胁）都需要大多数组织采取多个行动来应对。然而，由于开源软件的安全性也在快速发展，增加功能和工具整合应该有助于减少组织在应对软件供应链安全需求方面面临的复杂性。

This section of the report describes how organizations are addressing how vulnerabilities in code are found, how security of OSS components is evaluated, what security-focused tools are being used, and what security-related activities are most important.

本报告的这一部分描述了组织如何解决代码中的漏洞如何被发现，如何评估开源组件的安全性，使用了哪些专注于安全的工具，以及哪些与安全相关的活动最为重要。

Figure 10: Finding vulnerabilities in your dependencies
How do you find out about vulnerabilities in your dependencies? (select all that apply) by Do you have an open source security policy in place for open source development or usage?

图表 10：发现依赖项中的漏洞
您如何了解依赖项中的漏洞？（选择所有适用项）按照您是否有针对开放源代码开发或使用的安全策略进行筛选。

Source: 2022 Open Source Supply Chain Security Survey.
来源：2022 年开源供应链安全调查。

Industry vulnerability notifications
行业漏洞通知

Automated monitoring of packages for known vulnerabilites
自动监测已知漏洞的软件包

Notifications form package maintainers
来自软件包维护者的通知

Industy blogs and news site
行业博客和新闻网站

Through an external security audit
通过外部安全审计

We find out when they are exploited in the wild
我们发现了漏洞当它们在外面被利用了

Trust groups
信任的群体

Hackers
黑客

Don’t Know
不知道

Organizational approaches to identifying vulnerabilities in dependencies​

组织内识别依赖漏洞的方法​

A common question in addressing OSS security is how to comprehensively identify vulnerabilities across your dependencies. Figure 10 shows that there are four commonly used techniques to identify vulnerabilities. The leading approach practiced by 53% of organizations is to subscribe to one or more vulnerability catalogs from CISA (US-CERT), NIST (NVD), MITRE (CVE), security product & service vendors, and/or catalog aggregators (like FIRST) that aggregate content from leading worldwide sources. These subscriptions have the advantage of pushing vulnerability notifications to their subscribers.

在处理开放源代码软件（OSS）安全问题时，一个常见的问题是如何全面地识别依赖关系中的漏洞。图10显示了四种常用的识别漏洞的技术。53%的组织采用的主要方法是订阅来自CISA（美国国家信息安全局），NIST（美国国家标准与技术研究所），MITRE（通用漏洞披露系统）以及安全产品和服务供应商和/或目录聚合器（例如FIRST）的一个或多个漏洞目录，这些目录汇集了来自全球领先的信息源的内容。这些订阅的优点是向其订阅者推送漏洞通知。

The second leading approach is automated monitoring — or scanning of packages for known vulnerabilities — and is practiced by 49% of organizations. One challenge with this approach is that it’s often difficult to map vulnerability reports to the component(s) containing the vulnerabilities. For example, there may be a vulnerability reported in some component foo, but often there are many components and forks named foo so users often can’t be confident when a report is relevant. While it’s a best practice to scan code formulaically based on time, changes to the code base and the identification of relevant vulnerabilities, a comprehensive approach to this technique is still on the horizon.

第二个主要方法是自动化监控或扫描已知漏洞的软件包。这种方法被49%的组织所采用。这种方法的一个挑战是，往往很难将漏洞报告映射到包含漏洞的组件上。例如，可能会报告某个组件foo中存在漏洞，但通常有许多命名为foo的组件和分支，因此用户经常无法确定报告的相关性。虽然根据时间、代码库的更改和相关漏洞的识别来公式化地扫描代码是最佳实践，但是这种技术的全面方法仍然需要探索。

Notifications from package maintainers are leveraged by 47% of organizations and can provide a conduit to keep packages updated when supported by maintainers. Industry blogs and news sites are used by 43% of organizations and can facilitate the timely delivery of information for a better sense of importance.

软件包维护者的通知被47%的组织所利用，当维护者支持时，可以提供更新软件包的渠道。行业博客和新闻网站被43%的组织使用，可以促进及时传递信息，以获得更好的重要性感知。

Snyk - How long will it take to fix?​

Snyk - 需要多长时间来修复？​

Once a vulnerability has been identified, the next logical question is “How long is this going to take to fix?” The answer is all too often, “I don’t know. It’s complicated.” Unsurprisingly, the question becomes even more complex when we apply it to the software supply chain. Our dependence on third-party code, especially transitive dependencies, often make that question difficult or impossible to answer.

一旦发现漏洞，下一个合理的问题是“修复需要多长时间?” 答案往往是：“我不知道。这很复杂。” 不出所料，当我们将其应用于软件供应链时，这个问题变得更加复杂。我们对第三方代码的依赖，尤其是传递依赖，经常使得这个问题难以或不可能回答。

Looking at the average time to fix by language in Figure 11, we see that Snyk’s data shows that Go has the best time to fix at 49 days, while .Net is the obvious laggard at 148 days to fix a vulnerability. While some maintainers might be able to fix vulnerabilities in days or hours, there have been a few vulnerabilities that took years to remediate.

观察图 11 中按语言分组的平均修复时间，我们可以看到 Snyk 的数据显示 Go 语言具有最佳的修复时间，为 49 天，而 .Net 则是明显的落后者，需要 148 天来修复漏洞。虽然一些维护者可能能够在几天或几小时内修复漏洞，但也有一些漏洞需要数年时间才能修复。

Figure 11:
Average time to fix by language

图 11：
按语言修复漏洞的平均时间

（坐标轴编程语言不翻译）

Source: 2022 Snyk user data.
来源：2022 年 Snyk 用户数据。

We expect that popularity and awareness influence the time to fix. A popular project is more likely to attract other collaborators, and additional collaborators can speed up incident response time. In addition, if a project is popular, awareness by users (including via technical press news) is likely to be larger.

我们预计受欢迎程度和意识会影响修复时间。一个受欢迎的项目更有可能吸引其他协作者，而额外的协作者可以加快事件响应时间。此外，如果一个项目很受欢迎，用户（包括通过技术新闻媒体）的关注度可能会更高。

A popular project can affect a significant portion of all projects. As an example, the Spring Framework library is found in 9% of all Java projects. The team responsible for Spring Framework responded quickly to fix the Spring4Shell remote code execution vulnerability when it was identified in the spring of 2022. But what if that vulnerability had existed in a less responsive yet popular package?

一个受欢迎的项目可能影响所有项目的重要部分。例如，Spring 框架库在所有 Java 项目中都有 9％的使用率。当在 2022 年春季发现 Spring4Shell 远程代码执行漏洞时，负责 Spring 框架的团队迅速做出了修复。但如果该漏洞存在于一个反应较慢但受欢迎的软件包中会怎样呢？

Figure 12: Finding vulnerabilities in your code
How do you find out about security vulnerabilities in your code? (select all that apply) by Do you have an open source security policy in place for open source development or usage?

图 12：发现代码中的安全漏洞
如何发现您的代码中的安全漏洞？（选择所有适用项）根据您是否制定了开放源代码安全策略来决定。

We find them in CI when a SAST tool runs
我们在 CI 中运行 SAST 工具时发现它们

We find them when using Software Composition Analysis (SCA) tools or services
我们在使用软件构成分析（SCA）工具或服务时发现它们

We find them in our IDE using an extension for static code analysis
我们在 IDE 中使用静态代码分析扩展程序时发现它们

They get identified during peer review
它们在同行评审期间被识别

Publication in the National Vulnerability Database
发布到国家漏洞数据库

We use a command-line tool to detect them
我们使用命令行工具检测它们

Through an external security audit
通过外部安全审计

We find out when they are exploited in the wild
我们在它们被实际利用时发现

Bug bounties help disclose them
赏金计划有助于披露它们

We don’t
我们不知道

Other
其他

Don’t Know
不知道

Organizational approaches to identifying vulnerabilities in code​

组织内识别代码漏洞的方法​

Finding security vulnerabilities in code requires multiple approaches, much like finding vulnerabilities in dependencies. Figure 12 identifies the leading ways that developers find security vulnerabilities. The leading approach used by 39% of organizations, of the options included in the survey, is to use a SAST (Static Application Security Testing) tool. SAST tools are immensely useful during development because they can be configured to run automatically as part of a CI (continuous integration) process and can often identify specific line(s) of code responsible for a vulnerability.

发现代码中的安全漏洞需要多种方法，就像发现依赖项中的漏洞一样。 图表 12 显示了开发人员发现安全漏洞的主要方式。在调查包括的选项中，39% 的组织使用 SAST（静态应用程序安全测试）工具，这是最常用的方法。SAST 工具在开发过程中非常有用，因为它们可以配置为作为 CI（持续集成）过程的一部分自动运行，并且通常可以确定负责漏洞的具体代码行。

The second leading approach practiced by 33% of organizations, among the survey options, is to use an SCA (software composition analysis) tool. Use of these tools can be automated, and they typically address manifest scanning and binary scanning to identify known security vulnerabilities, licensing issues, or quality problems. While this capability is more closely associated with finding vulnerabilities in dependencies, including SCA in the build process helps OSS security activities to shift left.

第二个主要方法是SCA（软件构成分析）工具，SCA工具被在调查选项中的33%中的组织使用。使用这些工具可以自动化，并且通常涉及清单扫描和二进制扫描，以识别已知的安全漏洞、许可问题或质量问题。虽然这种能力更与发现依赖项中的漏洞密切相关，但将SCA纳入构建流程有助于将开源软件的安全活动向左移动。

Finally, a SAST tool can be used within an IDE providing the developer with a more immediate, hands-on, and configurable approach to manual security testing. What this approach lacks in automation is more than compensated for in direct and timely developer involvement. Figure 12 shows that 30% of organizations leverage this approach.

最后，SAST工具可以在集成开发环境（IDE）中使用，为开发人员提供更直接、及时和可配置的手动安全测试方法。虽然这种方法缺乏自动化，但直接且及时的开发人员参与可以弥补这一不足。图12显示，30% 的组织利用这种方法。

Although just 29% of organizations use peer review to help identify vulnerabilities in code, peer review and a reliance on multifunctional teams is a best practice and cornerstone of agile development.

尽管只有29%的组织利用同行评审来帮助发现代码漏洞，但同行评审和依赖于多功能团队是敏捷开发的最佳实践和基石。

Although this particular survey question did not offer tool choices other than SCA and SAST, Figure 14 does and confirms the leading popularity of SCA and SAST tools.

尽管此项调查问题未提供除SCA和SAST之外的工具选择, 但图14提供了其他工具的流行度, 并确认了SCA和SAST工具的领先流行度。

Snyk - Dependencies in the real world​

Snyk - 现实中的依赖关系​

When talking about direct and transitive vulnerabilities, the actual pervasiveness of transitive vulnerabilities is easy to overlook or dismiss. As observed earlier, nearly 40% of the vulnerabilities we detect originate in third-party code. Two examples of recent, high profile vulnerabilities, Log4Shell and Spring4Shell, give us an opportunity to compare the nature of direct vs. transitive dependencies in the real world.

当谈到直接和传递性漏洞时，我们容易忽视或忽略传递性漏洞的实际普遍性。正如先前观察到的，检测到的近40％的漏洞源于第三方代码。最近出现的两个备受关注的漏洞 “Log4Shell” 和 “Spring4Shell” 为我们提供了比较现实世界中直接依赖和传递性依赖性质的机会。

Last Christmas, Log4Shell was the bane of security teams and developers across the globe. The log4j-core project has been used extensively to enable logging in millions of projects. Because of this, nearly 52% of the vulnerabilities we detected were present because of a direct dependency on the log4j-core code base. (It’s important to note that we counted direct dependencies first, so a project with both direct and indirect dependencies would be counted as direct.)

去年圣诞节，Log4Shell 是全球安全团队和开发人员的噩梦。log4j-core 项目已被广泛使用，在数百万项目中启用日志记录功能。由于这个原因，我们发现的近52％的漏洞存在于直接依赖 log4j-core 代码库的项目中。（需要注意的是，我们首先计算直接依赖项，因此既有直接依赖项又有间接依赖项的项目将被视为直接依赖项。）

In contrast to Log4j, over 90% of the Spring Framework core was transitive, called by code one layer or more removed from the developer. The Spring Framework can be described as the ‘plumbing of enterprise applications’, which helps explain why it’s a transitive dependency so often. This is a very common example of how vulnerable code gets incorporated into projects, and why it’s important to track transitive vulnerabilities.

与 Log4j 相比，超过90％的Spring框架核心是传递性的，Spring框架由代码调用而距离开发人员一层或更多层。Spring 框架可以被描述为“企业应用程序的管道”，这有助于解释为什么它经常是一个传递性依赖项。这是一个非常常见的漏洞代码被纳入项目的例子，也是为什么跟踪传递性漏洞很重要的原因。

Prerequisites to using OSS​

使用开源软件的前提条件​

Using open source components can help to reduce cost, speed time to market, and free staff up to engage in more innovation and value- added activities. There is no “right way” to evaluate the security of OSS packages, but Figure 13 indicates that on average organizations use three of the approaches listed.

使用开源组件可以降低成本，加速产品进入市场的时间，以及释放员工从事更多的创新和增值活动。虽然评估开源软件包的安全性没有“正确的方法”，但是图 13 表明了组织平均使用列出的三种方法。

The most common approach used by 44% of organizations is to have developers examine source code. A review of source code can speak volumes about the quality of the code, which is highly correlated with its security.

最常见方法是让开发人员检查源代码，该方法被44%的组织机构所采用。对源代码的审查可以充分说明代码的质量，这与其安全性高度相关。

A second approach relied on by 40% of organizations is to assess the community that supports the project or component. An active community and an organized approach to contribution and maintainership are seen as positive signs for a project.

第二种方法是评估支持项目或组件的社区，该方法被40%的组织机构所依赖。一个活跃的社区和有组织的贡献和维护方法被视为项目的积极信号。

The third most popular strategy, observed at 36% of organizations, is using third-party tools to help developers find and vet components.

第三种最受欢迎的策略，在36% 的组织中观察到，是使用第三方工具来帮助开发人员查找和审核组件。

A variety of additional manual activities are used by organizations, including reviewing the frequency of releases/ commits (35%), analysis of registry/package manager information (33%), and reviewing usage statistics such as repository ratings or download statistics (30%). These help establish the viability and commitment of the community to the component.

组织使用各种额外的人工活动，包括查看发布/提交的频率（35%），分析注册表/包管理器信息（33%），以及查看使用情况统计信息，例如存储库评级或下载统计信息（30%）。这些有助于建立社区对该组件的可行性和承诺。

Figure 13: Reviewing the security of OSS packages
图 13：审查开源软件包的安全性

How do you check the security of the open source packages that you use? (select all that apply)
你如何检查你使用的开源软件包的安全性？（选择所有适用项）

Source: 2022 Open Source SupplyChainSecuritySurvey.
来源：2022 年开源供应链安全调查。

We use tools to examine its source code
我们使用工具检查其源代码

We check that the project has an active community
我们检查该项目是否有一个活跃的社区

We use a tool like Snyk Advisor, Libaries.io, or similar tools to serach for open source packages
我们使用像 Snyk Advisor、Libraries.io 或类似的工具搜索开源包

We look at the frequency of releases/ commits/ etc.
我们查看发布 / 提交等的频率

We use the information in the registry or package manager
我们使用注册表或包管理器中的信息

We look at repository ratings or package downloads statitics
我们查看存储库评级或软件包下载统计信息

We manaually review/ inspect its source code
我们手动检查其源代码

We check  that the project has a responsible disclosure policy (such as a SECURITY.md)
我们检查该项目是否有负责任的披露策略（例如 SECURITY.md）

We ask others if they believe the security of the project is adequate
我们询问其他人是否认为该项目的安全性足够

We don’t check it
我们不检查它

Don’t Know
不知道

Using multiple security testing tools is an OSS best practice​

使用多个安全测试工具是开源软件的最佳实践​

On average, organizations in the study used between two and three security testing tools. Using third-party tools can significantly improve your OSS security posture because of their scope, scalability, automation potential, and coverage across the SDLC. As budgets, resources, and time allows; using more tools can be advantageous since they all add value in different ways.

平均而言，研究中的组织使用了两到三种安全测试工具。使用第三方工具可以显著改善您的 OSS 安全状况，因为它们的范围、可扩展性、自动化潜力和覆盖整个 SDLC。在预算、资源和时间允许的情况下, 使用更多工具可能是有利的，因为它们都以不同的方式增加价值。

Figure 14 shows that preference is higher for SCA tools (47%) than for any other tool category. The ability of SCA tools to identify vulnerabilities and license compliance across an organization’s portfolio of components and dependencies, in a highly automated way, is immensely valuable.

图 14 显示，对 SCA 工具的偏好高于任何其他工具类别（47%）。SCA 工具在高度自动化的方式下，可以识别组织组件和依赖项组合中的漏洞和许可证合规性，这是极其有价值的。

Figure 14: Security tools in use when developing OSS

图 14：在开发 OSS 时使用的安全工具

What security tools do you regularly use when developing open source software? (select all that apply) by Do you have an open source security policy in place for open source development or usage?

在开发开源软件时，您定期使用哪些安全工具？（选择所有适用项）您是否针对开源开发或使用制定了开源安全策略？

Software Composition Analysis (SCA) tools
软件组件分析工具（SCA）

Static Application Secuirty Testing (SAST) tools
静态应用程序安全性测试 (SAST) 工具

Infrastructure as Code (IaC) tools
基础设施即代码 (IaC) 工具

Web Applications Scanners
Web 应用程序扫描器

Security Test Cases in software quality testing
软件质量测试中的安全测试用例

Infrastructure as Code scanners
基础设施即代码扫描器

Fuzz Testing tools
模糊测试工具

Threat modeling tools
威胁建模工具

Cloud Secruity Posture Mgmt (CSPM)
云安全姿态管理（CSPM）

Other
其他

Don’t Know
不知道

Other than SCA tools, additional choices become complex based on the organization’s approach to DevOps and preferences regarding security testing. SAST tools (37%), IaC tools (36%), and web application scanners (32%) all effectively compete for developer and security team attention. Web application scanners and fuzz testing tools together make up the dynamic application security testing (DAST) tool domain. Realistically, the use of both SAST and DAST tools makes sense because both help organizations find vulnerabilities. However, IaC tools are invaluable in helping to script and automate CI/CD activities, eliminating many of the manual and ad hoc activities that consume time that could be better spent elsewhere.

除了 SCA 工具之外，根据组织的 DevOps 方法和安全测试偏好，其他选择会变得复杂。SAST 工具 （37%）、IaC 工具 （36%） 和 Web 应用程序扫描程序 （32%） 都有效地争夺了开发人员和安全团队的注意力。Web 应用程序扫描程序和模糊测试工具共同构成了动态应用程序安全测试 （DAST） 工具域。实际上，同时使用 SAST 和 DAST 工具是有意义的，因为两者都可以帮助组织发现漏洞。但是，IaC 工具在帮助编写脚本和自动化 CI/CD 活动方面非常宝贵，消除了许多耗时的手动和临时活动，省下的时间可以更好地花在其他地方。

An honorable mention goes out to the remaining tools on the list. Some of these tools are relatively new, but each of them offers a unique value proposition that adds value to improving OSS security.

我们还要向剩下的工具表示敬意。这些工具中有些是相对较新的，但它们每一个都有独特的价值主张，为提升开源软件安全增添了价值。

Examining the tool use profiles of organizations with a security policy versus those without provides an overview of where organizations often start their OSS security journey, and what this journey looks like as it matures.

分析具有安全策略和没有安全策略的组织在使用工具方面的差异，可以提供有关组织开始和成熟过程中的开源软件安全旅程的概述。

The most important ways to improve OSS security​

提升开源软件安全最重要的方法​

The data in Figure 15 is likely the most important collection of key findings in this report. When asked which of the following activities are important to improving the security of OSS, organizations were permitted to give multiple responses.

图 15 中的数据可能是本报告中最重要的关键发现集合。当被问及以下哪些活动对提高开放源码软件的安全性很重要时，允许各组织作出多重回答。

The most important activity — confirmed by 59% of organizations — identified a desire to have vendors add increased intelligence to, and to be responsible for, security tooling. There are two ways to interpret what this means. The first is that end user organizations view the vendor community as a force multiplier, because more intelligent tools can ease the burden on developers or security professionals in exchange for licensing fees. Organizations and vendors both perceive this as a win-win scenario assuming competitive market dynamics. An alternative way to interpret this is that end-user organizations are struggling to understand how to address security concerns and welcome the opportunity to share/grant this responsibility to vendors and service providers who have more extensive expertise.

最重要的活动， 得到59%的组织证实， 确定了让供应商增加安全工具智能并负责安全工具的愿望。有两种方法可以解释这意味着什么。第一种解释是，最终用户组织将供应商社区视为力量倍增器，因为更智能的工具可以减轻开发人员或安全专业人员的负担，以换取许可费。假设市场动态竞争激烈，组织和供应商都认为这是一个双赢的局面。另一种解释方式是，最终用户组织正在努力了解如何解决安全问题，并乐于与具有更广泛专业知识的供应商和服务提供商共享 / 授权这种责任。

Another way to look at this is that end user organizations have scarce resources, and more intelligent tools are expected to provide higher value in a transparent way (meaning having no or inconsequential impact on developer productivity). This is the most seamless way to improve software security without material changes to process models.

另一种看待这个问题的方式是，终端用户组织资源有限，更加智能的工具预计以透明的方式提供更高的价值，意味着对开发人员生产率没有或者只有微不足道的影响。这是在不对过程模型进行重大更改的情况下提高软件安全性的最无缝方法。

The second most important activity is to source comprehensive best practices/certifications for secure software development (cited by 52% of organizations). The strong interest by end user organizations in best practices for secure software development is exciting to see. This suggests that these organizations are invested in understanding how to address OSS security. The good news is that there are already several trusted sources who can address this need:

• There are a variety of sources to identify best practices/ certifications for evaluating projects themselves. This includes the OpenSSF Best Practices badge, the OpenSSF Scorecards project, the CNCF paper on best practices for supply chain security, and SLSA (https://slsa.dev)
• This also suggests an interest in encouraging developers to learn best practices & acquire certifications. The good news is that these are available. For example, OpenSSF’s developing secure software (LFD121) provides both a training course and certification of completion for individuals who pass the final exam. This course is sponsored by the OpenSSF which is part of the Linux Foundation.

第二个最重要的活动是为安全软件开发提供全面的最佳实践/认证（52%的组织引用）。最终用户组织对安全软件开发最佳实践的浓厚兴趣令人兴奋。这表明这些组织在了解如何解决开放源码软件安全问题方面进行了投资。好消息是，已经有几个值得信赖的来源可以满足这一需求：

• 有多种来源可以确定评估项目本身的最佳实践/认证。这包括OpenSSF最佳实践徽章，OpenSSF记分卡项目，CNCF关于供应链安全最佳实践的文件和SLSA（https://slsa.dev）。
• 这也表明鼓励开发人员学习最佳实践和获得认证的兴趣。好消息是这些都可用。例如，OpenSSF 的安全软件开发（LFD121）提供培训课程和通过期末考试获得认证的个人证书。该课程由 OpenSSF 赞助，是 Linux 基金会的一部分。

Figure 15: Activities for improving the security of open source software

图 15：改善开源软件安全的活动

Which of the following activities are important to improving the security of the open source software supply chain? (select all that apply)

以下哪些活动对于改善开源软件供应链的安全性很重要？（选择所有适用项）

Added intelligence to existing software security tools (SAST, DAST, SCA, SBOMs, IaC scanners, CSPM)
增加软件安全工具的智能化（SAST，DAST，SCA，SBOM，IaC 扫描程序，CSPM）

Comprehens ive best practices/ certification for secure software development
全面的安全软件开发最佳实践 / 认证

More automation to eliminate pathways to compromise security and reduce developer fatigue
更多自动化以消除威胁安全的途径并减轻开发人员的负担

Security audits
安全审计

Increased incentives by employers to contribute to open source projects
雇主提供更多的激励鼓励员工参与开源项目

Peer review of source code
源代码的同行评审

Required use of MFA by developers and releasers
要求开发人员和发布者使用多因素认证

Vulnerability reporting system that is low-touch and low-latency
低成本、低延迟的漏洞报告系统

Identification of mission-critical software to be hardened against attack
识别需要加强防攻击的关键软件

Cryptographic signatures
使用加密签名

Use standardization to reduce the complexity and difficulty in addressing open source software security
标准化以减少处理开源软件安全性的复杂性和难度

Use of memory safe programming languages
使用内存安全编程语言

Verification through the use of reproducible builds
通过使用可重现构建来验证

Use of SBOMs
使用 SBOMs

Globally unique identification of specific software components/ releases
全球唯一标识特定软件组件 / 发布版本

Other
其他

Don't know or not sure
不知道或不确定

Source: 2022 Open Source Supply Chain Security Survey.
来源：2022 年开源供应链安全调查。

In third place for most popular activities around secure software development, we see a tie between increased automation to reduce attack surfaces and security audits, which were cited by 49% of organizations. The use of IaC tools can provide a reliable path to increased automation of CI CD activities. These tools have proven to be popular across organizations in this survey, and in the right hands, they can be extremely effective. Security audits are also a valuable way to gauge the current state of security for some or all of the organization’s applications. However, security audits — as measured through the eyes of maintainers who participated in the survey — were not valued nearly as highly. While security audits can be invaluable at comprehensively assessing an organization’s security risks, the organization must be positioned to act upon the findings of that audit — which seems a bridge too far for organizations without a security policy. However, note that there were only 72 maintainers participating in this survey, and 78% of them had not participated in an external security audit. It’s possible that security audits are so rare that few software developers have experienced them (and thus can only guess about their advantages).

最受欢迎的安全软件开发活动，增加自动化以减少攻击面和安全审计并列第三，这两项活动被 49% 的组织提到。使用基础架构即代码（IaC）工具可以提供可靠的路径来增加 CI CD 活动的自动化。

这些工具在本次调查中已被证明受到组织的欢迎，在正确的使用下可以非常有效。安全审计也是衡量组织某些或所有应用程序当前安全状态的有价值方式。但是，从参加调查的维护者的角度来衡量安全审计，它们的价值远不如前两项。虽然安全审计可以全面评估组织的安全风险，但组织必须有能力对审计结果进行行动 - 这对于没有安全策略的组织来说似乎过于困难。但请注意，本次调查只有 72 名维护者参加，其中 78％的人没有参加过外部安全审计。安全审计可能非常罕见，以至于很少有软件开发人员经历过它们（因此只能猜测它们的优势）。

Increased incentives by employers to encourage OSS contributions by employees were identified by 41% of organizations. While this is a fantastic idea and would tremendously help create a closed-loop environment for OSS, this point will be discussed in more detail in the next section of this paper.

41%的组织认为雇主为鼓励雇员贡献开放源码软件而采取的激励措施有所增加。虽然这是一个绝妙的主意，并且将极大地帮助创建开源软件的闭环环境，但本文的下一节将更详细地讨论这一点。

The IT industry must take a more active rol to improve OSS securit and sustainability​

IT 行业必须承担更积极的角色，以改善开源软件的安全性和可持续性​

Open source software has thrived as an alternative engine of innovation for organizations and developers alike. The pervasive use of OSS is testimony to the impact that it has had on the IT industry. However, OSS security and quality requires a full lifecycle commitment which creates additional investments in resources, time, and developers when compared to current practice. This section of the report introduces a variety of OSS security and sustainability challenges and solicits advice from organizations on how to address them.

开源软件作为组织和开发人员等的替代创新引擎而蓬勃发展。 开源软件的广泛使用证明了它对 IT 行业的影响。 然而，开源软件的安全性和质量需要完整生命周期的承诺，与当前实践相比，这会导致在资源、时间和开发人员方面产生额外的投资。 报告的这一部分介绍了各种开源软件安全和可持续性挑战，并征求组织关于如何解决这些挑战的建议。

Improving the security of oss development​

改进开源软件开发的安全性​

Organizations and developers are no strangers to the importance of best practices for secure software development. The significance of best practices for OSS development was initially voiced in Figure 15 as the 2nd most important activity for improving OSS security. Best practices have been voiced again by 73% of organizations in Figure 16 as the leading way IT industry organizations can improve the security of OSS development. IT industry organizations (such as the Linux Foundation) have taken this responsibility seriously and are delivering best practices content across a variety of channels.

通过提供最佳实践来改善开源软件开发的安全性，这再次表明了最佳实践的重要性。IT 行业组织（例如 Linux 基金会）已经认真对待这一责任，并通过多种渠道提供最佳实践内容。 组织和开发人员对安全软件开发最佳实践的重要性并不陌生。 在图 15 中， 开源软件开发最佳实践的重要性最初被表述为提高开源软件安全性的第二重要活动。 图 16 中，73% 的组织再次表示最佳实践是 IT 行业组织提高开源软件开发安全性的主要方式。 IT 行业组织（如 Linux 基金会）认真对待这一责任，并通过各种渠道提供最佳实践内容。

The 2nd leading improvement, identified by 61% of organizations, is providing tools for analyzing and remediating security vulnerabilities in OSS components. This need is being addressed as part of the OpenSSF’s open source Software Security Mobilization Plan. This plan was released at the Open Source Software Security Summit II in Washington DC on May 12-13, 2022. This plan is available at https://openssf.org/oss-security-mobilization-plan/.

第二个主要改进是为分析和修复开源软件组件的安全漏洞提供工具，61% 的组织认可这一点。这个需求正在 OpenSSF 的开源软件安全动员计划中得到解决。该计划于 2022 年 5 月 12 日至 13日在华盛顿特区举行的 “开源软件安全峰会 II” 上发布。该计划可在 https://openssf.org/oss-security-mobilization-plan/ 获取。

Figure 16: How organizations can improve the security of OSS development

图 16：IT 行业组织可以如何提高开源软件开发的安全性

What are some of the ways that IT Industry Organizations could improve the security of developing open source software? (select all that apply)

以下哪些方法是 IT 行业组织可以提高开源软件开发安全性的方法？（选择所有适用项）

Source: 2022 Open Source Supply Chain Security Survey.
来源：2022 年开源供应链安全调查。

Define best practices for secure software development
定义安全软件开发的最佳实践

Provide tools for analyzing and remediating security vulnerabilities of the top 500 open source components
提供分析和修复前 500 个开源组件的安全漏洞的工具

Provide more training in secure and memory safe programming for the broader open source software community
为更广泛的开源软件社区提供更多的安全和内存安全编程培训

Provide funds to support maintainers for analyzing and remediating security vulnerabilities of the top 500 open source code components
为支持分析和修复前 500 个开源代码组件的维护者提供资金

More formal processes for evaluating the security of incoming software
更正式的流程来评估入站软件的安全性

Provide funds to more nascent projects that show significant potential
为显示出重大潜力的新兴项目提供资金支持

Other (please specify)
其他（请具体说明）

Don't know or not sure
不知道或不确定

The 3rd ranked improvement identified in Figure 16 by 53% of organizations is to provide more training in secure and memory safe programming. Sadly, many software developers have not been trained on how to develop secure software. As noted earlier, there are some courses available today, including one from the OpenSSF, and there is interest in expanding these courses further. Virtually all languages are memory safe by default. C, C++, and Assembly are the only remaining languages in common use that are not memory safe by default. Training courses and books on alternative programming languages are readily available.

在图 16 中被 53% 的组织认可的改进方法是提供更多安全和内存安全编程方面的培训，该方法是排名第三的改进建议。不幸的是，许多软件开发人员并没有接受过如何开发安全软件的培训。正如前面提到的，今天已经有一些课程可用，包括来自 OpenSSF 的课程，并且有兴趣进一步扩展这些课程。几乎所有语言默认情况下都是内存安全的。默认情况下，几乎所有语言都是内存安全的。C、C++ 和汇编是常用的唯一默认不内存安全的语言。关于替代编程语言的培训课程和书籍随时可用。

Improving open source software resourcing​

改进开源软件资源分配​

OSS resourcing is a growing challenge because of the need to improve the security and quality of OSS components. The Open Source Software Security Mobilization Plan, put forward by the OpenSSF, aims to address the following:

• Secure OSS production. Focus on preventing security defects and vulnerabilities in code and open source packages in the färst place.
• Improving vulnerability discovery and remediation. Improving the process for finding defects and fixing them.
• Shorten ecosystem patching response time. Shorten the response time for distributing and implementing fixes.

开放源码软件的资源资源是一个日益严峻的挑战，因为需要提高开放源码软件组件的安全性和质量。OpenSSF提出的开源软件安全动员计划旨在解决以下问题：

• 安全的的开源软件生产。专注于防止代码和开源包中的安全缺陷和漏洞。
• 改进漏洞发现和修复。改进发现缺陷并修复缺陷的过程。
• 缩短生态系统补丁响应时间。缩短分发和实施修补程序的响应时间。

This plan is estimated to cost in the vicinity of $70 million to $110 million per year and is designed to provide a blueprint and services including education, training, tools, and processes to secure the top OSS projects. While this plan will provide a useful model for OSS projects in general, there are millions of ongoihg OSS projects. How will funding for many of these projects be accomplished?

这个计划的预计成本大约为每年 7,000 万至 1.1 亿美元，旨在提供一个蓝图和服务，包括教育、培训、工具和流程，以保障顶级开源项目的安全。虽然这个计划将为一般的开源项目提供有用的模型，但仍有数百万正在进行的开源项目需要资金支持。那么这些项目的资金来源将是如何解决的呢？

Figure 17 addresses this dilemma. The leading response shared by 63% of organizations suggests that employers should provide or increase an incentive to contributors of meaningful OSS projects. If end-user organizations elected to "give back" to the oss communities they depend on, it would attract more contributors and improve the security and quality of those OSS components.

图 17 解决了这个困境。63% 的组织表示，最重要的反应是雇主应该提供或增加对有意义的开源软件项目贡献者的激励。 如果最终用户组织选择 “回馈” 他们依赖的开源软件社区，它将吸引更多的贡献者，提高这些开源软件组件的安全性和质量。

Figure 17: The most important ways to improve OSS resourcing
图 17：提高开源软件资源的最重要方式

What are the three most important ways that open source project resourcing can be improved? (select all that apply)
什么是改进开源项目资源的三个最重要的方法？（选择所有适用的选项）

Source: 2022 Open Source Supply Chain Security Survey.
来源：2022 年开源供应链安全调查。

Employers should provide or increase an incentive to contributors for meaningful contribution to open source projects including dependencies
雇主应该提供或增加对做出有意义的开源项目贡献者的奖励，包括其依赖项

Industry adoption of standards for interoperability across tools to make it less painful for developers to build pipelines and workflows
行业应采用跨工具的互操作性标准，以减少开发人员构建管道和工作流程的痛苦

Cloud service providers should sponsor free or deeply discounted tools and services to open source projects
云服务提供商应为开源项目赞助免费或深度折扣的工具和服务

Employers should give contributors access to security analysis tools they're used to using at work
雇主应给予贡献者使用其在工作中熟悉的安全分析工具的权限

Employers should contribute to a Linux Foundation fund that redirects 100% of this fund to open source projects of merit
雇主应向 Linux 基金会基金捐赠资金，将该基金的 100％重新分配给有价值的开源项目

Other
其他

Don't know or not sure
不确定或不确定

Industry adoption of standards for interoperability across tools and discounted resources provided by CSPs (Cloud Service Providers) to OSS projects resonate across 51% of organizations in this study. Interoperability concerns were frustrating and are a characteristic of immature markets. The fragmented nature of today's software security markets suggests that consolidation will occur and help address this problem although the timeframe is unknown.

该研究显示，51％的组织对行业采用工具间互操作性标准以及CSP（云服务提供商）提供的折扣资源产生共鸣。互操作性问题令人沮丧，是不成熟市场的一个特征。当今软件安全市场的分散性表明，尽管时间框架不确定，但整合将发生并有助于解决这个问题。

The concept of cloud service providers providing support for secure OSS development is intriguing. Having access to a portfolio of tools adept at secure software development at deeply discounted prices would be a win for developers. It could also be a win for CSPs as an on-ramp to more conventionally priced runtime services. However, whether this idea has been vetted with CSPs is unknown as is their overall receptivity to the idea.

云服务提供商为安全的开源软件开发提供支持的概念令人感兴趣。以深度折扣价格获得一系列适用于安全软件开发的工具组合对于开发者来说是一种胜利。对于云服务提供商而言，它也可能是一个通向更常规价格的运行时服务的入口。 然而，该想法是否已经经过了云服务提供商的审查，以及云服务提供商对该想法的整体接受程度尚不清楚。

44% of developers at organizations also embrace having their employer establish a sandbox for developing OSS projects using the same tools they are already familiar with. This is also an intriguing idea and would qualify as yet another perk provided by an employer to their employees who contribute to material OSS projects.

44% 的组织开发人员赞同让雇主建立一个沙箱，使用他们已经熟悉的相同工具进行开源软件项目的开发。这也是一个有趣的想法，可以作为雇主提供给为重要的OSS项目做出贡献的员工的另一个福利。

Although the ideas presented as responses in Figure 17 are speculative, they all reflect the realization that secure OSS development will require additional investment which needs to be provided by the community that benefits from the value derived from OSS.

尽管图 17 中呈现的想法都是推测性的，但它们都反映了这样一个认识：安全的开源软件开发需要额外的投资，而这些投资需要由受益于开放源码软件价值的社区提供。

Snyk - Broken Containers​

Snyk - 损坏的容器​

Vulnerability management is complicated enough to start with, but the advent of containers, virtual machine images, IaC, and microservices complicate it even further. While many organizations are still improving how to handle vulnerabilities in their own code, and starting to examine direct and transitive dependencies in depth, fixing the vulnerabilities introduced by containers is still a struggle. Container images (among other constructs) are often "black boxes" that organizations do not examine further.

漏洞管理本来就很复杂，但容器、虚拟机镜像、IaC 和微服务的出现使得漏洞管理更加复杂化。虽然许多组织仍在改进如何处理其自己的代码中的漏洞，并开始深入研究直接和传递依赖项，但修复由容器引入的漏洞仍然很困难。容器镜像（以及其他构造）通常是组织不进一步检查的“黑匣子”。

Returning to our examples of recent vulnerabilities, as of the time of this writing, only 8% of container projects with Spring Framework dependencies have fully remediated the Spring4Shell vulnerability. In contrast, Log4Shell has been resolved in nearly 25% of all containers.

回到我们最近漏洞的示例，截至本文撰写时，只有 8% 的容器项目使用 Spring Framework 依赖项已经完全解决了 Spring4Shell 漏洞。相比之下，几乎 25% 的容器已经解决了 Log4Shell 漏洞。

Because containers can be ephemeral, the act of creating and destroying containers provides an opportunity for implementing updates that could occur rapidly and significantly improve existing vulnerability dynamics. Changing the code in one container configuration could potentially result in hundreds of updated containers. The flip side is that one container configuration forgotten or missed can also easily result in the same number continuing to be vulnerable. This later challenge is one readily resolved through the use of SBOMs.

由于容器可以是短暂的，创建和销毁容器的过程为实施更新提供了机会，这些更新可能会快速地显著改善现有的漏洞动态。在一个容器配置中更改代码可能会导致数百个更新后的容器。另一方面，如果一个容器配置被遗忘或错过，同样数量的容器也很容易继续存在漏洞。后面的这种挑战可以通过使用SBOMs轻松解决。

Improving OSs sustainability​

提高开源软件的可持续性​

OSS sustainability is an important topic for anyone who depends on OSS. For small OSS projects maintained by a single person, challenges exist. Sustainability requires continuity over time. To achieve this requires the successful ability to transfer maintainer responsibilities to additional maintainers.

对于任何依赖于开源软件的人来说，开源软件的可持续性是一个重要的话题。对于由单个人维护的小型开源软件项目，存在一些挑战。可持续性需要长时间的连续性。要实现这一点，需要成功地将维护者的职责转移给其他维护者。

Figure 18 helps prioritize key activities to help address OSS sustainability. Across organizations, 64% report that maintainers should plan for their own retirement by bringing new maintainers into the project. This is the preferred path forward but requires attention to nontechnical activities focused on process and communication. Adding a second maintainer to a project and transferring responsibility from the original maintainer are likely to be some of the most difficult activities a project must overcome.

图 18 有助于优先考虑能帮助解决开源软件的可持续性的关键活动。在各个组织中，64% 报告称维护者应该通过引入新的维护者来规划自己的退休计划。这是未来的首选方案，但需要关注流程和沟通等非技术活动。向项目添加第二个维护者并从原始维护者转移责任可能是项目必须克服的一些最困难的活动之一。

Recognizing the challenges of transferring project responsibility, 58% of organizations believe that if a project reaches its end of life the retiring maintainer should clearly identify on the repo that the software is no longer being maintained.

认识到转移项目责任的挑战，58%的组织认为，如果项目到达其生命周期的终点，退休维护者应该在代码库中清楚地标识出软件不再得到维护。

An alternative path for transferring maintainership responsibility is to find a foundation or IT industry organization that will create a new home for the project. 55% of organizations endorsed this path forward although it may prove to be nearly as complex as independently finding a new maintainer.

转移维护责任的另一种选择是寻找一个基金会或IT行业组织，为项目创建一个新的家。55% 的组织支持这种前进的方式，尽管它可能证明几乎与独立寻找新的维护者一样复杂。

Figure 18: Improving OSS sustainability How should open source software sustainability be addressed if the maintainer(s) on a project decide to retire? (select all that apply)

图 18：提高 OSS 的可持续性 如果项目的维护者决定退休，应如何解决开源软件的可持续性问题？（选择所有适用项）

Source: 2022 Open Source Supply Chain Security Survey.
来源：2022 年开源供应链安全调查。

Encourage retiring maintainers to request and add new maintainers to the project
鼓励退役维护者请求并添加新的项目维护者

Encourage retiring maintainers to clearly identify on the repo that the software is no longer being maintained
鼓励退役维护者明确在存储库上标识软件不再维护

Look for ways to transition the project to an independent foundation
寻找将项目转移到独立基金会的方式

Look for ways to transition the project to a large scale user of the project
寻找将项目转移到大规模项目用户的方式

Look for ways to raise funding to encourage the current maintainer to continue
寻找筹集资金的方法，以鼓励当前维护者继续维护

Other
其他

Don't know or not sure
不确定或不清楚

Conclusions and recommendations​

结论和建议​

Too many organizations are not prepared to address OSS security needs​

太多组织没有准备好应对开源软件安全需求​

Across the 500+ organizations participating in this OpenSSF survey, at least 34% did not have an OSS security policy in place (Figure 1). The percentage of organizations without a security policy is likely to be around 40% after prorating those respondents who didn't know the status of an OSS security policy for their employer. OSS use is pervasive across end-user organizations and IT vendors/service providers (who somewhat evenly comprise our sample) and the 60/40 yes/no split on having an OSS security policy persists across virtually all 22 industries represented in our sample. This indicates that not having an OSS security policy is not specific to certain industries or organization types but instead is widely found across business environments.

在参与本次 OpenSSF 调查的 500 多个组织中，至少有 34％没有制定开源软件（OSS）安全策略（图 1）。在按比例计算那些不知道其雇主的 OSS 安全策略状况的受访者后，没有安全策略的组织比例可能达到 40％左右。OSS 在终端用户组织和 IT 供应商 / 服务提供商中普及（它们在样本中几乎均衡），而在我们样本中代表的几乎所有 22 个行业中，60/40 的有 / 无 OSS 安全策略分布均存在。这表明，没有 OSS 安全策略不是特定于某些行业或组织类型，而是广泛存在于商业环境中。

Small organizations must prioritize developing an OSS security​

小型组织必须优先考虑制定开源软件安全政策​

In the wake of numerous high-profile attacks across the software supply chain over the last several years, this finding is disappointing. Every organization needs to have a CISO and OSPO (open source Program Office) or a person or persons vested with key CIS and OSPO responsibilities. We recognize that small organizations with less than 500 people were significantly more likely to not have an OSS security policy (Figure 2). Small organizations, therefore, need to prioritize and limit their CISO and OSPO agenda so it can be achievable with a partial FT. Once key CISO and OSPO capabilities are resident in the organization an OSS security policy will follow.

在过去几年中，软件供应链中发生了许多备受瞩目的攻击，这一发现令人失望。每个组织都需要有一位 CISO（首席信息安全官）和 OSPO（开源项目办公室）或一位或多位负责关键 CIS 和 OSPO 职责的人员。 我们认识到，少于 500 人的小型组织更有可能没有开源软件安全策略（图 2）。因此，小型组织需要优先考虑并限制其 CISO 和 OSPO 议程，以使其成为部分全职任务。一旦关键的 CISO 和 OSPO 能力在组织中得到了落实，OSS 安全策略就会随之而来。

Using additional security tools is a leading way to improve osS security​

使用更多的安全工具是提高开源软件安全性的一种主要方式​

There are at least 10 tool categories that have a focus on addressing OSS security. Organizations on average use 2.8 security tool categories among the survey options. SCA and SAST tools are the leading tools used to address OSS security among those options (Figure 14). The use of IaC tools (which indirectly address security) and web application scanners (part of the DAST category) round out the portfolio that many organizations use.

至少有 10 个工具类别专注于解决开源软件安全问题。在调查选项中，组织平均使用 2.8 个安全工具类别。软件组成分析（SCA）和 静态应用程序安全测试（SAST）工具是解决开源软件安全问题中最常用的工具（见图 14）。使用 IaC 工具（间接解决安全问题）和 Web 应用程序扫描器（动态应用程序安全测试 DAST 类别的一部分）是许多组织使用的其他工具。

The security tools market has numerous tool categories because the overall domain extends from source code management through build, package, delivery, and deployment. This is basically the entire software lifecycle. Software security must be managed across each step and accomplishing all of this with just two or three tool categories is not feasible. Therefore, organizations should take a closer look at adjacent and complementary security tools markets and determine where incremental tools can add the most value.

安全工具市场拥有众多的工具类别，因为整个领域从源代码管理到构建、打包、交付和部署都有涉及，基本上涵盖了整个软件生命周期。必须在每个步骤上管理软件安全性，但仅使用两到三个工具类别来完成所有这些工作是不可行的。因此，组织应该仔细研究相邻和互补的安全工具市场，并确定增量工具可以在哪些方面增加最大价值。

Figure 14 also shows that organizations with an OSS security policy have a higher frequency of security tool use than those organizations without an OSS security policy. This same dynamic is in place based on organizational size where large organizations have a higher frequency of security tool use than small organizations. Security tool use is therefore one of the most obvious and powerful ways to improve your OSS security posture.

图 14 还显示，具有开源软件安全策略的组织比没有开源软件安全策略的组织更频繁地使用安全工具。同样，大型组织比小型组织使用安全工具的频率更高。因此，使用安全工具是改善开源软件安全状况的最明显和最强大的方法之一。

Collaborate with vendors to create more intelligent security tools​

与供应商合作创建更智能的安全工具​

Adding greater intelligence to existing software security tools is viewed by organizations as one of the most important ways to improve OSS security across the supply chain (Figure 15). While tool vendors may see this more as business as usual, tool users see this as a critical requirement to empower existing resources. Because most end-user organizations are resource constrained in IT, a critical objective is to find ways that existing developers can be more productive without adding to their workload. Increased tool intelligence and automation are examples of how to improve software security in a way nearly transparent to developers.

对于组织来说，将现有软件安全工具加强智能化是提高整个供应链中的开源软件（OSS）安全性的最重要途径之一（图 15）。虽然工具供应商可能认为这是日常工作，但工具用户认为这是赋予现有资源的关键要求。 由于大多数终端用户组织在 IT 方面受到资源限制，因此一个关键目标是找到在不增加工作量的情况下提高现有开发人员工作效率的方法。增强工具的智能化和自动化就是如何在几乎不影响开发人员的情况下提高软件安全性的例子。

Implementing best practices for secure software development is the other leading way to improve OSS security​

实施安全软件开发的最佳实践是改善开源软件安全的另一种主要途径​

Understanding best practices for secure software development is identified repeatedly as the leading or a leading way to improve the security of the open source software supply chain (Figures 15 and 16). A primary reason why there is so much interest in best practices is that developing secure software encompasses the entire breadth of the software lifecycle. At each waypoint, from source code management, build services, and packaging to software delivery and deployment there are numerous best practices that need to be followed. This includes literally hundreds of best practices. The Linux Foundation has developed an outstanding free course and certification on developing secure software (LFD121) which can be found on OpenSSF.org.

理解安全软件开发的最佳实践是提高开源软件供应链安全的主要或领先方法之一，这在图 15 和 16 中被反复提到。人们对最佳实践如此感兴趣的一个主要原因是，开发安全软件涵盖了软件生命周期的整个广度。在每个航点，从源代码管理、构建服务和打包到软件交付和部署，都需要遵循许多最佳实践。这包括数百种最佳实践。Linux基金会开发了一个关于开发安全软件（LFD121）的优秀免费课程和认证，可以在 OpenSSF.org 上找到。

Use automation to reduce your attack surface​

使用自动化减少攻击面​

Infrastructure as Code (IaC) tools provide a way to script manual activities so that they can be automated (Figure 15). Reducing or eliminating manual command line-driven CI/CD activities provides fewer ways for developers to skirt policy, bend rules, make mistakes, and expose CI/CD activities to external threats. Use of IaC tools and lad scanners provides organizations with a way to streamline and automate CI/CD activities while simultaneously eliminating some threat vectors, While there will always be use cases for manual intervention by developers, minimizing the need for this is a best practice.

基础设施即代码（IaC）工具提供了一种脚本手动活动的方式，使它们可以自动化（图 15）。减少或消除手动命令行驱动的 CI/CD 活动为开发人员提供了更少的方法来绕过策略、改变规则、犯错误以及将 CI/CD 活动暴露给外部威胁。使用 IaC 工具和漏洞扫描工具为组织提供了一种简化和自动化 CI/CD 活动的方式，同时消除了某些威胁向量。虽然开发人员总是会有手动干预的用例，但最小化对此的需求是最佳实践。

Consumers of open source software should give back to the Communities that support them​

开源软件的消费者应该回馈支持他们的社区​

The introduction to this paper mentioned that open source software is at a crossroads. Those open source projects that experience significant growth must evolve from their modest and somewhat informal origin to address a more demanding and security conscious community of users. This transition does not come easily because it requires increased resources, time, processes, and security. The use of open source software has often been a one-way street where users see significant benefit with minimal cost or investment. In order for larger open source projects to meet user expectations it will be important for organizations to give back and close the loop to improve open source software sustainability. Employers need to provide additional incentives to employees who have material maintainer or core contributor open source roles or responsibilities. This would also serve to encourage a higher level of participation by developers in open source projects to ensure the flow of new talent.

本文的介绍提到，开源软件正处于十字路口。那些经历了显著增长的开源项目必须从其谦逊且有些非正式的起源中发展出来，以应对更苛刻、更注重安全的用户社区。这个转变并不容易，因为它需要增加资源、时间、流程和安全方面的投入。使用开源软件通常是单向的，用户可以在最小的成本或投资下获得显著的利益。为了满足用户的期望，较大的开源项目需要回馈和关闭循环，以提高开源软件的可持续性。雇主需要为那些有实质性维护者或核心贡献者开源角色或责任的员工提供额外的激励。这也将有助于鼓励开发人员更高级别地参与开源项目，以确保新人才的流动。

Methodology​

方法​

The objective of this research was to understand the following:

• The current state of open source software security
• Security practices across the open source software supply chain
• Secure development practices
• How the security and sustainability of open source software can be improved

本研究的目的是了解以下内容：

• 开源软件安全的当前状态
• 开源软件供应链中的安全实践
• 安全开发实践
• 如何改善开源软件的安全性和可持续性

This research project was initiated in 2022 01 at the request of the OpenSSF. The primary research vehicle would be a survey of OSS developers, maintainers, core contributors, and security professionals. However, the research was preceded by interviews with fifteen OSS maintainers and security subject matter experts. These qualitative interviews were performed to ensure that the survey included key security topics important to the OSS community.

该研究项目应 OpenSSF 的要求于 2022 年 1 月启动。主要的研究工具将是对开源软件开发人员，维护者，核心贡献者和安全专业人员的调查。然而，在研究之前，对十五名开放源码软件维护者和安全主题专家进行了访谈。进行这些定性访谈是为了确保调查包括对开放源码软件社区很重要的关键安全主题。

Interviews occurred in March 2022 and the survey was fielded in April 2022. Data was analyzed and this report was drafted as well as peer reviewed in May 2022.

访谈在 2022 年 3 月进行，调查在 2022 年 4 月进行。于2022 年 5 月 进行了数据分析，起草了本报告并进行了同行评审。

All Figures in this survey include results that are rounded to the nearest whole integer percent value. Therefore, totals for segmentation data may not always add to 100%.

本调查中的所有图表结果均按最接近的整数百分比值四舍五入。因此，分段数据的总和可能不总是 100%。

This was a long survey with an average time to complete of 20+ minutes. The completion rate for this survey was under 50%. This explains why there is some variation in the sample size for the above segmentation variables.

本调查为长篇问卷，平均完成时间超过 20 分钟。本次调查的完成率不足 50%。这就解释了上述分段变量样本大小存在一定变异性的原因。

Compretensstive screening enteria were to ensure respondents wouildi have a thigh probability of being able to answer all survey questions. Screening criteria included involvement im open source software, experience in the development or use of open source software, employed or looking for employment, and respondents who self-identify as a real person.

为确保受访者有可能回答所有调查问题，采用了综合筛选标准。筛选标准包括参与开源软件、开源软件的开发或使用经验、在职或寻找工作以及自我确认为真实人士的受访者。

The qualitative dimension of this project included in-depth interviews with selected individuals across industries and in federal cybersecurity policy development or involvement with maintaining open source software.

该项目的定性维度包括对各行各业的选定人士的深入访谈，涵盖了联邦网络安全政策的制定者或参与维护开源软件维护的个人。

About the Authors​

关于作者​

Stephen Hendrick

斯蒂芬·亨德里克

Stephen Hendrick is Vice President of research at the Linux Foundation where he is the principal investigator on a variety of research projects core to the Linux Foundation's understanding of how open source software is an engine of innovation for producers and consumers of information technology. Steve specializes in primary research techniques developed over 30 years as a software industry analyst. Steve is a subject matter expert in application development and deployment topics including DevOps, application management, and decision analytics. Steve brings experience in a variety of quantitative and qualitative research techniques that enable deep insight into market dynamics and has pioneered research across many application development and deployment domains. Steve has authored over 1,000 publications and provided market guidance through syndicated research and custom consulting to the world's leading software vendors and high-profile startups.

斯蒂芬·亨德里克是 Linux 基金会的研究副总裁，他是许多研究项目的首席调查员，这些项目对 Linux 基金会了解开源软件如何成为信息技术生产者和消费者创新引擎至关重要。亨德里克 先生专注于基于 30 多年软件行业分析师开发的主要研究技术。他是应用开发和部署主题的领域专家，包括 DevOps、应用程序管理和决策分析。亨德里克 先生拥有多种定量和定性研究技术的经验，能够深入洞察市场动态，并在许多应用程序开发和部署领域开创了研究。亨德里克 先生已经撰写了超过 1000 篇出版物，并通过综合研究和定制咨询向世界领先的软件供应商和高知名度的初创企业提供市场指导。

Martin Mckeay

马丁·麦基

Martin Mckeay is Snyk's Senior Editorial Research Manager, where he works with teams across the company to build reports that increase the knowledge base of security professionals and developers. With over twenty years as a security professional, Martin started his career in help desk operations, continuously building to more complex and diverse roles over the years. Over the last seven years, Martin has developed the skills to turn data into intelligence and translate 'geek speak' into language understandable by mere mortals.

马丁·麦基是 Snyk 的高级编辑研究经理，他与公司各个团队合作，制作报告，以增加安全专业人员和开发人员的知识库。马丁在安全专业方面已经有超过 20 年的经验，他的职业生涯始于帮助台运营，多年来不断发展到更复杂和多样化的角色。在过去的七年中，马丁已经开发了将数据转化为情报的技能，并将 “极客语言” 翻译成普通人可以理解的语言。

Acknowledgements​

致谢​

This document was authored with the support and collaboration of the following individuals and organizations: Stephen Augustus (Cisco), Brian Behlendorf (Linux Foundation), Hilary Carter (Linux Foundation), Randall Degges (Snyk), Brian Demers, Michael Dolan (Linux Foundation), Kim Lewandowski (Chainguard), Oleg Nenashev (Dynatrace), Mike Milinkovich (Eclipse Foundation), Megan Moore (Synk), Nick O'Leary (FlowForge), Christina Oliviero (Linux Foundation), Ashwin Ramaswami (Plaintext Group), Clark Roundy (Eclipse Foundation), Jed Salazar (Chainguard), Melissa Schmidt (Linux Foundation), Robert Scholte (Apache), Micah Silverman (Snyk), Daniel Stenberg (WolfSSL), Kate Stewart (Linux Foundation), Liran Tal (Synk), Adolfo Garcia Veytia (Chainguard), Derek Weeks (Linux Foundation), David A. Wheeler (Linux Foundation), Sarah Wills (Snyk).

本文档得到以下个人和组织的支持和合作：Stephen Augustus（思科）、Brian Behlendorf（Linux 基金会）、Hilary Carter（Linux 基金会）、Randall Degges（Snyk）、Brian Demers、Michael Dolan（Linux 基金会）、Kim Lewandowski（Chainguard）、Oleg Nenashev（Dynatrace）、Mike Milinkovich（Eclipse 基金会）、Megan Moore（Synk）、Nick O'Leary（FlowForge）、Christina Oliviero（Linux 基金会）、Ashwin Ramaswami（Plaintext Group）、Clark Roundy（Eclipse 基金会）、Jed Salazar（Chainguard）、Melissa Schmidt（Linux 基金会）、Robert Scholte（Apache）、Micah Silverman（Snyk）、Daniel Stenberg（WolfSSL）、Kate Stewart（Linux 基金会）、Liran Tal（Synk）、Adolfo Garcia Veytia（Chainguard）、Derek Weeks（Linux 基金会）、David A. Wheeler（Linux 基金会）和 Sarah Wills（Snyk）。

Disclaimer​

免责声明​

This report is provided "as is." The Linux Foundation and its authors, contributors, and sponsors expressly disclaim any warranties (express, Implied, or otherwise), including implied warranties of merchantability, noninfringement, fitness for a particular purpose, or title, related to this report. In no event will the Linux Foundation and its authors, contributors, and sponsors be liable to any other party for lost profits or any form of indirect, special, incidental, or consequential damages of any character from any causes of action of any kind with respect to this report, whether based on breach of contract, tort (including negligence), or otherwise, and whether they have been advised of the possibility of such damage. Sponsorship of the creation of this report does not constitute an endorsement of its findings by any of its sponsors.

本报告按“原样”提供。Linux 基金会及其作者、贡献者和赞助商明确声明不提供任何形式的保证，包括但不限于对本报告的适销性、非侵权性、特定用途适用性或标题的默示保证。在任何情况下，Linux 基金会及其作者、贡献者和赞助商均不对任何其他方因与本报告有关的任何形式的间接、特殊、偶然或后果性损害负责，无论是基于合同违约、侵权（包括疏忽）还是其他原因，并且无论他们是否已被告知可能出现此类损害。赞助本报告的创建不构成任何赞助商对其调查结果的认可。

Founded in 2021, Linux Foundation Research explores the growing scale of open source collaboration, providing insight into emerging technology trends, best practices, and the global impact of open source projects. Through leveraging project databases and networks, and a commitment to best practices in quantitative and qualitative methodologies, Linux Foundation Research is creating the go-to library for open source insights for the benefit of organizations the world over.

成立于 2021 年的 Linux 基金会研究院探究开源合作不断扩大的规模，提供对新兴技术趋势、最佳实践和开源项目的全球影响的洞察。通过利用项目数据库和网络，并致力于量化和定性方法的最佳实践，Linux 基金会研究院正在创建开源洞见的去处，以造福全球组织。

Copyright 2022 The Linux Foundation
This report is licensed under the Creative Commons Attribution-NoDerivatives 4.0 International Public License.
版权所有 2022 Linux 基金会
本报告受到 知识共享 署名-禁止演绎 4.0 国际公共许可证的许可。

To reference this work, please cite as follows: Stephen Hendrick and Martin Mckeay, “Addressing Cybersecurity Challenges in open source Software,” foreword by Brian Behlendorf, Linux Foundation and Snyk, June 2022

请通过以下格式以引用本文：
斯蒂芬·亨德里克和马丁·麦基，“应对开源软件中的网络安全挑战”，前言由 布莱恩·贝伦多夫 所著，Linux 基金会和 Snyk，2022 年 6 月

Snyk is a developer-first security company that helps software-driven businesses develop fast and build securely. Snyk provides a platform to secure all of the critical components of today’s cloud native application development. Snyk is securing the industry leaders such as Google, Salesforce, Asos, BBC, and Asurion. For more information or to get started with Snyk for free, visit https://snyk.io.

Snyk 是一家以开发人员为先的安全公司，帮助以软件为驱动的企业快速开发和安全构建。Snyk 提供一个平台来保护当今云原生应用程序开发的所有关键组件。Snyk 正在保护行业领袖，如 Google，Salesforce，Asos，BBC 和 Asurion。有关更多信息或免费开始使用 Snyk，请访问 https://snyk.io。

Mentorship in Open Source​

Exploring the Intrinsic, Economic, and Career Value of Mentorship Programs​

开源世界的导师关系​

探索导师计划的内涵、经济和职业价值​

January 2023

2023 年 1 月

Jason Perlow, Editorial Director,

The Linux Foundation

Jason Perlow，编辑部主任，

Linux 基金会

Foreword by Julia Lawall, Senior Scientist, French National Research Institute for Digital Science and Technology (Inria-Paris)

前言作者 Julia Lawall

法国国家数字科学技术研究所（Inria-Paris）高级科学家

In partnership with 合作作者

Contents 目录

Foreword..........................................................................................3
Infographic: LFX Mentorship program...............................................................4
About the LFX Mentorship program study............................................................5
Introduction: The problem that mentorship aims to solve ..........................................6
The roots of mentorship programs in academia......................................................8
The history of mentorships in open source and the technology industry.............................9
The genesis of mentorship at the LF...............................................................9
Mentorships and their impact on succession and diversity within open source.......................11
  Improving diversity.............................................................................11
  A learning experience for mentees (and mentors).................................................12
  Confidence building.............................................................................13
  Community building through mentorship...........................................................15
Mentorship program challenges ....................................................................16
Career benefits of mentorship programs ...........................................................18
Conclusions ......................................................................................22
  Actionable insights ............................................................................22
Final thoughts....................................................................................23
Methodology ......................................................................................24
Demographics......................................................................................24
About the author..................................................................................25
Acknowledgments...................................................................................25

前言............................................................................3
信息图：LFX 导师计划..............................................................4
关于 LFX 导师计划的研究...........................................................5
概述：导师计划希望解决的问题 .......................................................6
导师计划的学术依据................................................................8
开源界与技术界的导师关系历史........................................................9
LF 导师关系的起源.................................................................9
导师关系及其对开源演进和多样性的影响.................................................11
  改善多样性.....................................................................11
  学员（及导师）的学习经历.........................................................12
  建立信心......................................................................13
  通过导师关系建立社区............................................................15
导师计划的挑战 ..................................................................16
导师计划的职业价值 ...............................................................18
结论 ..........................................................................22
  可操作的见解 ....................................................................22
最后的思考.......................................................................23
方法论 .........................................................................24
人口统计学......................................................................24
关于作者........................................................................25
致谢............................................................................25

Foreword​

前言​

The ability to create software is a magical thing. Out of nothing, only an idea, one can construct one’s own world as an object that performs some useful function, entertains, etc. Contributing to open source software provides the opportunity to take this to the next level, allowing the individual to contribute to something of interest to people worldwide. Nevertheless, different open source projects have different coding styles, standards of communication, preferred development tools, etc., and, to facilitate the development process, legitimately expect contributors to conform to a myriad of conventions that are not always written down. This is where mentorship comes in.

软件开发是一件很神奇的事情。只要有一个想法，一个人就可以从零开始，为自己的世界构建一个能执行某些功能的、娱乐性的工具。为开源软件做贡献，提供了一个新的机会，使得个人能为世界各地的人们感兴趣的事情做出贡献，可以将其提升到一个更高的水平。 尽管如此，不同的开源项目有不同的编码风格、通信标准、偏好的开发工具等，并且为了促进开发过程，很希望贡献者能够遵守一些约定，而这些约定并不总是用文字写下来了。 这就是导师关系的用武之地。

I have been involved in mentorship as a mentor for LFX, GSoC, and Outreachy and as a coordinator for the Linux kernel for Outreachy. Interns come to these programs with all different levels of coding skills and learn how they can contribute to software that today has become the foundation of all computing. The chance to work with a mentor provides the chance to explore ideas in a safe space, where the mentor can head off potential problems in algorithm design, coding style, and communication. In exchange, the mentor can ensure that the mentee is exposed to all of the information that the mentor would like a potential contributor to have. As the mentor and mentee in remote mentoring programs such as LFX and Outreachy often come from different countries and cultures, participating in such programs is also a wonderful way to learn more about the world.

我作为 LFX、GSoC 和 Outreachy 的导师，以及 Outreachy 的 Linux 内核的协调员，曾多次参与导师计划。当初有着不同级别的编码技能的实习生，参与到这些项目中，并学习如何为开源软件做出贡献，这些软件如今已成为所有的计算基础。与导师一起工作，提供了在安全空间中探索想法的机会，导师指导学生解决算法设计、编码风格和沟通方面的各种潜在问题。作为交换，导师可以确保学员接触到潜在贡献者能拥有的所有信息。由于 LFX 和 Outreachy 等远程指导项目的导师和学员通常来自不同的国家，拥有不同的文化，参与此类项目也是了解世界的绝妙方式。

Today, many of the mentees I have worked with have interesting jobs in the industry, while some have diverted to further studies. For some, the internship was one of many steps on the way to their current accomplishments, while for others, the internship represented a rupture in their career, from a position that they were not satisfied with to one that they found more rewarding. Some continue to do work related to the Linux kernel, others explore other directions, and some unexpectedly found their Linux kernel experience applicable in a different area. I am immensely proud of all of them. Mentorship is incredibly rewarding for the mentees, the mentors, and the organizations that benefit from the mentee’s contributions. I would like to thank the various organizations that make these internship programs possible.

今天，与我共事过的许多学员都在该行业找到了有趣的工作，而有些则转行继续深造。对于一些人来说，实习是他们获得当前成就的众多步骤之一，而对于另一些人来说，实习代表着他们职业生涯的断裂，从他们不满意的职位到他们认为更有价值的职位。 一些人继续从事与 Linux 内核相关的工作，另一些人探索其他方向，还有一些人意外地发现他们的 Linux 内核经验适用于不同的领域。 我为他们所有人感到无比自豪。 对于学员、导师和受益于导师计划的组织来说，辅导学员是令人难以置信的回报。 我要感谢让这些导师计划成为可能的各种组织。

Julia Lawall

Senior Scientist, French National Research Institute for Digital Science and Technology (Inria-Paris)

Julia Lawall

法国国家数字科学技术研究所（Inria-Paris）高级科学家

Infographic: LFX Mentorship program​

FX导师计划​

About the LFX Mentorship program study​

• Linux Foundation (LF) Mentorship helps build diverse communities of developers to address long-term project sustainability issues.
• LF Research assessed the effectiveness of the effort in addressing these issues and the career and economic benefits for mentees.
• The findings in this report are based on a survey of 100 graduates of the 2020 and 2021 LF Mentorship program.

关于 LFX 导师计划研究​

• Linux基金会(以下简称LF)导师计划帮助建立多样化社区的开发人员，指导长期项目的可持续性问题。
• LF 研究并评估了解决这些问题的有效性以及学员的职业和经济利益。
• 本报告的调查结果基于对 2020 年和 2021 年 LF 导师计划的 100 名毕业生的调查。

Introduction: The problem that mentorship aims to solve​

简介：导师计划旨在解决的问题​

Why is it necessary to have open source and LF mentorship programs?

为什么开源与LF导师计划是有必要的？

Open source communities face a two-fold problem: building diverse communities of developers and leadership succession. Mentorship programs help to solve the problem of ensuring robust succession and growth, where many new contributors become part of the community. Just as we require offspring as a human species to guar- antee the health and continuation of our legacy and culture long after the current generation is a living memory, new entrants enable open source to breathe new life and continuity into our communities.

开源社区面临两个方面的问题：建设多元化的开发者社区，以及领导力继承。导师计划有助于解决不断有新的贡献者参与的情况下，如何保障稳健的继承性以及社区成长的问题。就像我们需要作为人类物种的后代来保证我们的文化和遗产在当前这一代人成为鲜活记忆之后很长一段时间内可以持续影响和延续一样，社区的新晋成员能为我们的社区持续的注入新的活力和延续性。

We invest in our communities as beneficiaries of our open source legacy by giving new developers access to knowledge and expe- rience from more experienced participants. By helping new developers to begin, mentors can help ensure that the community continues to grow and thrive long after the founders of these projects cease their direct involvement.

我们通过让新晋的开发者从更有经验的参与者那里的获取知识和经验，作为开源遗产的受益者再投资于我们的社区中。通过协助新的开发者，导师可以协助并保证社区在项目创始人停止直接参与后很长一段时间内可以持续发展壮大。

Investing in our future by providing access to generational knowledge is not the only reason mentorship programs exist. We also wish to foster underrepresented groups—whether women, members of the LGBTQ+ community, people with disabilities, or non-native English speakers—to improve diversity within our communities. Shuah Khan, an open source fellow and Linux kernel maintainer, explains the grounding philosophy of the mentorship program, highlighting the importance of increasing diversity in open source communities, including the Linux kernel:

“The end goal was to have a healthy and sustainable kernel community with diverse viewpoints. Diverse communities are healthy and thriving. Having a different viewpoint in the development process keeps them healthy and relevant and serves the needs of people globally. So, improving diversity and opening up the kernel community of people of different socioeconomic backgrounds was a huge component.”

通过代代相传的知识来投资我们的未来发展并不是导师计划存在的唯一原因。 我们还希望培养一些代表性不足的群体——无论是女性、LGBTQ+ 社区成员、残疾人还是非英语母语人士——以改善我们社区的多样性。 开源研究员和 Linux 内核维护者 Shuah Khan 解释了导师计划的基本理念，强调了增加开源社区多样性的重要性，包括 Linux 内核：

“我们的最终目标是拥有一个有包容不同观点、健康且可持续的内核社区。 多元化的社区代表健康和繁荣。 在开发过程中拥有不同的观点可以使社区保持健康和活力，并满足所有人的需求。 因此，提高多样性和吸纳不同社会经济背景的人，是社区健康发展的一个重要组成部分。“

“Open source software is the backbone of a lot of our world infrastructure in financial, healthcare, telecommunications, you name it—critical internet infrastructure. So, as a result, keeping these communities healthy for the long term is paramount to keeping this infrastructure working.” —SHUAH KHAN, OPEN SOURCE FELLOW AND LINUX KERNEL MAINTAINER

“开源软件是我们世界上许多金融、医疗、电信等领域基础设施的支柱——关键的互联网基础设施。因此，保持这些社区的长期健康发展对于保持这些基础设施的运转至关重要。” —SHUAH KHAN，开源研究员和 Linux 内核维护者

It’s no secret that the open source community and surrounding culture are historically male-dominated. The LF is actively trying to remedy this by involving and engaging members of underrepresented minority communities, including those less economically advantaged.

众所周知，开源社区和周边文化历来由男性主导。 LF 正在积极尝试通过让代表性不足的群体社区的成员参与进来，包括那些经济条件较差的人，来改变这个现状。

An analysis of LFX Mentorship applicant data in FIGURE 1shows that 72% identify as belonging to the middle class.

图1中 LFX 导师计划的申请人数据分析表明，72%的人来自中产阶级。

Khan, who directs the LFX Mentorship program, states that addressing diversity within the open source community is a complex societal issue involving equitable access to resources and opportunities.

LFX导师计划的Khan指出，解决开源社区多样性的问题是一个复杂的社会问题，它涉及了获得资源和机会的公平性。

She says, “It is an issue of people not having equitable access to resources. We have to do our part to make those resources available to people equitably so that they are easier to access, easier for people to self- learn, and thus more accessible for people to get involved in open source and break down barriers. These barriers are based on your background, the language you speak, and also your financial situation and various other reasons.”*

她说，“这个问题涉及到人们无法公平的获取资源。我们必须要尽一份力量，让大家可以更容易的获得和学习，能公平的使用这些资源，打破障碍参与到开源社区中来。这些障碍通常是人们的背景、语言、财务状况和其他原因。”

Providing this kind of access means recognizing these barriers and tailoring services to respect the needs of diverse communities. This can take the form of offering paid mentorships in some instances and free mentorships in others. Khan explains,

提供对导师计划有差异的访问意味着确实存在这些障碍，并调整了对应的服务以尊重不同社区的需求。 比如通过在某些情况下提供付费指导和在其他情况下提供免费指导的形式。 Khan解释说，

“The goal here is to ask, how do we make it easier for people to overcome those barriers? Can we give these folks a little lift by providing resources like free training, free webinars, and paid mentorships? We have added unpaid mentorships because not everyone wants to or can get paid to access this program, as they know our program is a limited resource, and unpaid or credit-only helps us scale it without the funding constraints. So, we try to make it accessible to different needs, career transitions, etc. Our unpaid programs are well received, and we can increase the number of mentees per project.”

“这里，我们需要回答，如何让人们更容易克服这些障碍？ 能否通过提供免费培训、免费网络研讨会和付费指导等资源来帮助这些人？ 我们增加了无偿指导，因为导师计划是一种有限的资源，不是每个人都免费的，也不是每个人都希望通过导师计划赚钱，无偿的帮助我们在没有资金限制的情况下扩展它。 因此，我们试图让它满足不同的需求，比如职业转型等。我们的无偿项目很受欢迎，在每个项目中的也可以增加学员人数。”

“The problem we are trying to fix is a sustainable maintenance cycle. Bringing more people into open source is part of it, but there are many more steps.” —KATE STEWART, VICE PRESIDENT OF DEPENDABLE SYSTEMS, THE LINUX FOUNDATION

“我们试图解决是对项目周期性维护的可持续性。 让更多人参与开源是其中的一部分，但还有很多其他方面。” —KATE STEWART，Linux 基金会 副总裁

It is clear that without bringing in these diverse groups of people, open source culture becomes stagnant, putting our projects at risk in terms of their ability to retain talent and inspire new developers to join them as maintainers or core contributors.

很明显，如果不引入这些不同的人群，开源文化就会停滞不前，使我们的项目在留住人才和激励新开发者作为维护者或核心贡献者的吸引力方面面临风险。

Angela Brown, SVP and GM of events at the LF, explains the value of DEI initiatives from the perspective of acquiring talent. She says,

LF 高级副总裁兼活动总经理 Angela Brown 从获取人才的角度解释了 DEI 计划的价值。 她说，

“We have all these companies that desperately need open source talent, both now and in the coming years. How do we get people prepared for that? Diversity is a big aspect because that is where you’ll find a lot of this talent since these are previously overlooked groups.”

“我们拥有所有这些迫切需要开源人才的公司，无论是现在还是未来几年。 我们如何让人们为此做好准备？ 多样性是一个很大的方面，这是会发现很多这种人才的地方，他们也是之前被忽略的群体 。”

Not only does a lack of diversity hurt the acquisition and retention of talent, but it also translates to attracting fewer developers and is detrimental to code maintenance prospects for those projects. One mentee from the Kubernetes project discussed how mentorship and other DEI programs could help introduce under- represented perspectives into code development to the advantage of the project. As they explained,

缺乏多样性不仅会影响人才的获取和保留，导致更少的开发者的转化，最终不利于这些项目的代码维护。 Kubernetes 项目的一名学员讨论了导师计划和其他 DEI 计划如何帮助将少数派建议引入代码开发，从而使项目受益。 他们如此解释，

“Greater representation from these groups introduces different people with different mindsets looking at a project, so when there’s a problem, we can have various approaches to it, which will help it get solved even faster.”

“这些群体的代表性更强，可以让不同的人以不同的心态看待一个项目，所以当出现问题时，我们可以有不同的方法来解决它，这将有助于更快地解决问题。”

The roots of mentorship programs in academia​

导师计划的根源​

Mentorship programs, specifically for fostering professional communities in the open source realm, have existed in the technology industry for about 17 years, with scholarly publications providing the basis for these programs dating back almost four decades.

在技术行业内，专门为开源领域培养社区方面专业人才的导师计划已经存在了大约 17 年，学术出版物为其奠定了近 40 年的基础。

These works are used to teach Semesters of Code, an evolving undergraduate curriculum that is being taught to computer science students at Johns Hopkins University on open source software engineering by adjunct faculty member Stephen Walli, who is a principal program manager at Microsoft’s Azure Office of the CTO, a board member of the Eclipse Foundation, and a member of the LF Research Advisory Board.

这些学术出版物用于半学年的代码学习课程，这是一门随着技术变化不断更新的本科课程，由兼职教员 Stephen Walli 向约翰霍普金斯大学计算机科学专业的学生讲解开源软件工程，他是微软 Azure 办公软件的 CTO，Eclipse 基金会的董事会成员，以及 LF 研究顾问委员会的成员。

Per Walli, the realization of the importance of mentorship programs began in the late 1980s with the research of Jean Lave, a social anthropologist at the University of California, Irvine, who introduced the concept of learning as participation in ongoing communities of practice. This challenged the conventional theories of learning and education, even to this day.

Per Walli 意识到导师计划的重要性始于 80 年代后期，当时加州大学尔湾分校的社会人类学家 Jean Lave 的研究引入了实习的概念，即参与正在发展中的实践社区。 这挑战了传统的学习和教育理论，直到今天。

Her first work, Cognition in Practice: Mind, Mathematics and Culture in Everyday Life (1988), was a treatise about how ordinary people can do mathematical work in their everyday lives without even realizing it. Her second book, authored with Etienne Wenger, Situated Learning: Legitimate Peripheral Participation (1991), was much more influential in education. In this book, Lave and Wenger proposed the theory that learning is a matter of legitimate peripheral participation in communities of practice.

她的第一部作品《实践中的认知：日常生活中的思维、数学和文化》（1988 年）是一篇关于普通人如何在日常生活中不知不觉地使用到数学的论文。 她与 Etienne Wenger 合着的第二本书 《情境学习：合法的边缘参与》 (1991) 在教育领域影响更大。 在这本书中，Lave 和 Wenger 提出了这样一个理论，即学习是在实践的社区群体中有合法边缘参与的认知过程。

According to Lave and Wenger, learning is not something that only happens in the classroom; it is a process that occurs through social interaction in everyday life. A community of practice is a group of people who share a concern or a passion for something they do and learn how to do it better as they interact regularly.

根据 Lave 和 Wenger 的理论，学习不仅仅是发生在课堂上的事情；而是一个通过日常生活中的社会互动发生的过程。 实践社区是一群人，他们对所做的事情有共同的关注或热情，并在定期沟通经验，交流如何做可以学习得更好。

For example, when children are born, they enter communities of practice, such as their family, and begin to learn the skills and practices of those communities. As they grow older, they move into new communities of practice, such as their peer groups, and continue to learn the skills and practices associated with those communities.

举个例子，一个孩子出生，在一个家庭中生活，就像融入一个实践的社区一样，开始学习家庭里的技能和作法。 随着年龄的增长，他们进入一些新的环境，例如他们的同龄人群体，又继续学习与这些社区相关的技能和作法。

“My open source journey started with a question from a mentor in a workplace mentoring session. The question was, ‘what are you waiting for?’” —SHUAH KHAN, OPEN SOURCE FELLOW AND LINUX KERNEL MAINTAINER

“我的开源之旅始于一位导师在职场辅导会议上提出的问题。 问题是，‘你还在等什么？’” —SHUAH KHAN，开源研究员和 Linux 内核维护者

The situated learning theory describes the drivers of peripheral participation in communities of practice and is very helpful in understanding how people learn in the workplace. Many companies have started mentorship programs based on this theory to help employees learn the skills and practices they need to succeed in their jobs.

情境学习理论描述了外部环境在实践社区中具有一定的驱动因素，这对于理解人们如何在工作场所中学习非常有帮助。 许多公司已经开始根据这一理论开展导师计划，以帮助员工学习在工作中取得成功所需的技能和作法。

Mentorship programs have also been beneficial in other settings, such as schools. In a school setting, mentorship programs allow students to learn from more experienced students or teachers. These programs can also help students develop relationships with adults who can provide support and guidance.

导师计划在学校等其他环境中也大有裨益。 在学校环境中，导师计划引导学生向更有经验的学生或老师学习。 这些计划还可以帮助学生与可以提供支持和指导的成年人建立关系。

In work settings, mentorship programs allow employees to learn from their experienced peers as a learning pathway for career transition and advancing skills in their areas of interest.

而在工作环境中，导师计划允许员工向经验丰富的同事学习，作为职业转型和提升对感兴趣领域技能学习的途径。

The history of mentorships in open source and the technology industry​

开源和技术领域的导师制历史​

Open source mentorships date back to 2005 with the introduction of Google’s Summer of Code, a program the company has run for the last 17 years. It targets college students and provides a stipend (of $1,500 to $6,600, depending on size and location) to work on an open source project. The program has expanded to include high school, postsecondary, and graduate students. Similarly, Google’s Code-In, targeted at 13 to 17-year-olds, ran from 2010 to 2019. Beyond Google, other companies are releasing technology industry mentorship programs, such as Microsoft, IBM, Amazon, Meta, and Red Hat. As with Summer of Code, these programs are typically 12 weeks long and take place during the summer. They are open to students at least 18 years of age who have completed one year of college.

开源导师制可以追溯到 2005 年，当时谷歌推出了 “谷歌的代码之夏”，该公司在过去 17 年中一直在运行该计划。 它面向大学生并提供津贴（根据规模和地点，提供1,500 美元到 6,600 美元）以从事开源项目。 该计划已扩大到包括高中生、大专生和研究生。 同样，谷歌的 “谷歌Code-In” 项目针对 13 至 17 岁的人群，从 2010 年持续到 2019 年。 除了谷歌，其他公司也在发布技术行业指导计划，例如微软、IBM、亚马逊、Meta 和红帽。 与”谷歌代码之夏”一样，这些项目通常为期 12 周，并在夏季向年满 18 岁且已完成一年大学学业的学生开放。

• Microsoft Student Partners is a global program that helps students learn about technology, build their technical skills, and connect with other students. The program provides students access to Microsoft products, technologies, and programs.

• Microsoft Student Partners 是一项全球计划，可帮助学生了解技术、培养技术技能并与其他学生联动。 该计划使学生能够访问 Microsoft 产品、技术和程序。

• The IBM Pathfinder Mentoring Program pairs IBM engineers, designers, and business professionals with university students in the same discipline and enables those students to receive personalized career guidance.

• IBM Pathfinder Mentoring Program 将 IBM 工程师、设计师和业务专家与同一学科的大学生配对，使这些学生能够获得个性化的职业指导。

• The Amazon Mentorship Program is a 12-week program that helps prepare participants for a career in software development. The program includes weekly lectures, coding challenges, and project work. Participants also can shadow Amazon software engineers and attend social events.

• 亚马逊导师计划旨在帮助参与者为软件开发职业做好准备，为期12周。 该计划包括每周讲座、编码挑战和具体项目工作。 参与者还可以跟随亚马逊软件工程师参加社交活动。

• Meta University is a program for undergraduate and graduate students interested in pursuing a career in software engineering. The program includes coursework, internships, and research opportunities.

• Meta大学是一个面向有兴趣从事软件工程职业的本科生和研究生的项目。 该计划包括课程作业、实习和研究机会。

• Red Hat Mentorships is a program that helps students learn about open source software development. The program provides participants access to Red Hat products, technologies, and programs.

• Red Hat Mentorships 是一个帮助学生了解开源软件开发的计划。 该计划为参与者提供红帽产品、技术和程序的访问权限。

Nonprofit organizations like the Apache Software Foundation and the GNOME Foundation also offer mentorship programs.

Apache 软件基金会和 GNOME 基金会等非营利组织也提供导师计划。

• The Apache Software Foundation offers a 12-week mentorship program for students who want to contribute to Apache projects.**

• Apache 软件基金会为想要为 Apache 项目做出贡献的学生提供为期 12 周的导师计划。**

• The Software Freedom Conservancy Outreachy program provides internships for people from groups traditionally underrepresented in free and open source software, such as LGBTQ+. Outreachy does not require prior college attendance, only 18 years of age, to qualify for a mentorship.Marina Zhurakhinskaya, a Ukrainian software developer and prominent FOSS advocate, who lost her long battle with cancer in June of 2022, founded the program.

• Software Freedom Conservancy Outreachy 计划为传统上在自由和开源软件中代表性不足的群体的人们提供实习机会，例如 LGBTQ+(彩虹族)。 Outreachy(外延计划) 不需要事先上过大学，只需要满足18 岁就有资格获得指导。Marina Zhurakhinskaya创立了该计划，她是乌克兰的软件开发人员和著名FOSS 倡导者，她在 2022 年 6 月与癌症的长期斗争中离世。

The genesis of mentorship at the LF​

LF 导师制的起源​

The idea of mentorship at the LF initially came about to bring maintainers into the fold for its Linux kernel project. As with many open source projects, the kernel’s developer population has grown organically—it is not a traditional hire and talent placement scenario. The need to replace developers over time is crucial to the stability and longevity of the project, and mentorship is one way to achieve this. The organization decided to become more intentional about how it could help new developers get up to speed and become productive members of the open source community.

LF 的指导思想最初是为了拉动开发者参与其 Linux 内核项目的维护。 与许多开源项目一样，内核的开发人员数量已经实现了自然增长——不依赖传统的招聘方式。 随着时间的推移，开发者更迭对于项目的稳定性和成长性至关重要，而导师制度是实现这一目标的一种方式。 因此，组织决定更加专注于如何帮助新开发者加快成为开源社区高效产出的成员。

The pilot mentorship program launched within the kernel community in 2019 had a few simple objectives: to help new developers feel welcome, learn the ropes, and accept their first code contributions. Khan identified these objectives and the goal of increasing diversity. She says,

“We identified three reasons for starting the program: diversity, community health, and sustainability. You have to inject new talent and bring in people, new developers that can take over at some point from the aging maintainer population and step into these important roles. So, we felt that the best approach at the time would be having these developers trained by maintainer experts in those areas.”

2019 年在内核社区内启动的试点导师计划有几个简单的目标：让新的开发者有归属感、摸到门道并接受他们的第一个代码贡献。 Khan说，

“我们确定了启动该计划的三个原因：多样性、社区健康和可持续性。 必须注入新的人才并引入新的开发人员，他们可以在某个时候接替退休的维护人员并担任这些重要角色。 因此，我们认为最好的方法是让这些开发人员接受这些维护专家的培训。”

Khan looked at previous examples of mentorship programs at other open source organizations and wanted to broaden mentorships outside of their student-centric focus by inviting industry professionals into the program. This also required unique accommodations that similar programs only previously had. Khan adds,

“I talked to people running mentorship programs at the time, such as Outreachy and Google Summer of Code, and how they viewed the shortcomings of those programs. One part that came up as a big thing was that it would be helpful to have it as a part- time program; thus, we added that early on. We also decided not to restrict it to students because career transition is very important. And I chose to run three sessions, spring, summer, and fall, like a college or university, so that it would be accessible to people globally.

Khan 查看了其他开源组织以前的导师计划案例，并希望通过邀请产业界的专业人士加入该计划来扩大之前以学生为重点的指导。 这也是需要单独进行协调，之前并无先例。 Khan补充道，

“我与当时运行导师计划的人进行了交谈，例如 Outreachy 和 Google Summer of Code的相应人员，以及他们如何看待这些计划的缺点。 把该计划作为一个兼职项目是个很好的事情； 因此，我们很早就添加了这一点。 我们还决定不将其仅限于学生，因为职业转型非常重要。 我选择举办春季、夏季和秋季三个课程，就像学院或大学一样，以便所有的人都可以使用它。

So, for example, the spring session is probably the one that people from the southern hemisphere could participate in because it is their summer. The summer session would be for other people and students. For others, they could fit into a three-month or six-month program.”

例如，春季班可能是南半球的人可以参加，因为那是他们的夏天。 暑期班是为其他人和学生准备的。 对于其他人，他们可以参加为期三个月或六个月的课程。”

“Marina Zhurakhinskaya left an amazing legacy of initiatives to lift people up and change the lives of many. Marina’s passing is a big loss to the open source community and people working toward equity in open source.” —SHUAH KHAN, LFX MENTORSHIP PROGRAM LEAD

“Marina Zhurakhinskaya留下了一系列让人惊叹的举措，来提升人们的境遇并改变许多人的生活。Marina的离世对于开源社区和致力于开源平等的人们来说是一个巨大的损失。” —SHUAH KHAN, LFX导师计划负责人

Another approach to attract industry professionals was opening the program to anyone, regardless of employment status. As Khan explains,

另一种吸引产业界专业人士的方法是向任何人开放该计划，无论其就业状况如何。 Khan解释：

“We don’t require applicants to be unemployed; they can be fully employed, part-time, or of any kind of status. We simply say if you can spend 20 to 40 hours a week learning and advancing your skills, you’re welcome to apply to our program.” “我们不要求申请人脱产； 他们可以是全职、兼职或任何身份。 我们只是说，如果你每周能花 20 到 40 个小时学习和提高你的技能，欢迎你申请我们的项目。”

Khan also explains why they chose not to restrict participants based on demographics:

Khan 还解释了为什么他们选择不根据人口统计的数据来限制参与者：

“Other programs restrict their mentorships to students only or women and LGBTQ+. Some of these are 100% diverse in their population, which is excellent. However, they are fishing from a smaller pond to begin with, which purposefully restricts the size of their addressable communities and programs. We didn’t want to do that; we’re open to everyone.”

“其他项目将他们的指导仅限于学生或女性和 LGBTQ+。 其中一些在其人口中 100% 多样化，这非常好。 然而，他们面向比较垂直的人群，这刻意的限制了对应的社区和项目的规模。 我们不想那样做； 我们向所有人开放。”

The program, now known officially as LFX Mentorships, has since been expanded beyond the Linux kernel to include other open source projects under the LF umbrella, such as Cloud Native Computing Foundation (CNCF), Hyperledger, Open Mainframe Project, ELISA, Zephyr, RISC-V, and Automotive Grade Linux. (FIGURE 2)

该计划现在正式称为 LFX Mentorships，此后已扩展到 Linux 内核之外，包括 LF 旗下的其他开源项目，例如云原生基金会 (CNCF)、Hyperledger、Open Mainframe Project、ELISA、Zephyr、RISC -V 和AGL等社区和项目。 （图 2）

LFX Mentorships are fully matriculated; once a mentee has completed the program, they have “graduated” and are not eligible for additional mentorship for the program to provide opportunities for others. However, the possibility exists of becoming a mentor in the future. Several graduated mentees have been helping as co-mentors, sharing their experiences and realizing that mentoring is rewarding and a continuous learning path.

LFX导师计划是完全制定的；一旦学员完成了该计划，他们将“毕业”，并不再有资格获得额外的导师计划，以便为其他人提供机会。然而，未来有可能成为导师。一些毕业的学员已经作为合作导师提供帮助，分享他们的经验，并意识到导师工作是有益且持续学习的道路。

Mentorships and their impact on succession and diversity within open source​

导师制及其对开源项目内的继承和多样性的影响​

Improving diversity​

提高了多样性​

Ensuring project health is not just about attracting new developers to replace the old; it's also about improving diversity in the open source community to make it more representative of the world. The code submitted to the projects themselves reflects this, where different perspectives worldwide contribute unique features that make the project relevant on a broader scale. Khan provides an example of this from the perspective of energy conservation. She says,

确保项目健康不仅仅是吸引新的开发人员取代旧的开发人员；它还涉及改善开源社区的多样性，使其更具世界代表性。提交给项目本身的代码反映了这一点，世界各地的不同观点贡献了独特的特点，使项目在更大范围内具有相关性。Khan从节能的角度举了一个例子。 她说，

“We have kernel patches to improve power management on devices to help users from places like Africa and Southeast Asia, where they don't have as widespread access to charging infrastructure (for their laptops and mobile phones) as the rest of the world. They might not even have 24/7 electricity, which might be a luxury. California residents now realize they need backups with the wildfires they have been experiencing recently. So, these patches help conserve energy so that applications aren’t power hogs; this is critical to companies that sell products in these areas of the world. Different viewpoints come from diverse experiences, and open source software expresses their needs. We call this scratching our own itch, which results in unique features that benefit us all. That’s where diversity of thought comes into play.”

“我们用内核补丁来改善设备的电源管理，以帮助来自非洲和东南亚等地的用户，在这些地方，他们无法像世界的其他地区那样方便地访问充电的基础设施（用于给他们的笔记本电脑和手机充电）。他们甚至可能没有24小时/7天的全天候电力，这可能是一种奢侈。加州居民现在意识到，他们需要备份电力，以应对最近遭遇的野火。因此，这些补丁有助于节约能源，使应用程序不再那么耗电；这对于在世界上这些地区销售产品的公司来说至关重要。不同的观点来自不同的经历，开源软件表达了他们的需求。我们称此为“挠痒痒”，每个人都有自己的痒处，这会产生有益于我们所有人的独特功能。这就是思想多样性发挥作用的地方。”

Although the program is open to everyone by design, the LF has focused on getting more women and other underrepresented groups involved in LFX Mentorship programs.

尽管该计划在设计上向所有人开放，但LF一直专注于让更多的女性和其他代表性不足的群体参与LFX导师计划。

“We are trying to reach out to groups historically underrepresented within the open source community,” said Khan. “We did a big push, for example, to Black colleges and Hispanic colleges in the summer of 2021 to raise awareness, as a part-time program, to give them the flexibility to work from anywhere, and we are expanding that globally. We don’t require participants to be just students, either. When we say we are inclusive, we don’t say this will be just for women, LGBTQ+, or any particular denomination or group. We say this applies to anybody who wants to get involved with open source but does not know how to get started. So far, these are how our efforts have been, and we’ve seen more women participate. But it could be better. We have consistently improved our numbers since the program's inception in 2019. Our participation from women sits at 20% compared to 17% in 2019.”

Khan说：“我们正在试图接触那些在开源社区中历史上代表性不足的群体。” “例如，我们在2021年夏天大力推动黑人学院和西班牙裔学院提高认识，参加一项兼职计划，让他们能够灵活地在任何地方工作，我们正在向全球扩展这一点。我们也不要求参与者只是学生。当我们说我们具有包容性的时候，我们并不是说这将只针对女性、LGBTQ+或任何其他的特定教派或群体。我们认为，这适用于任何想加入开源但不知道如何开始的人。到目前为止，这就是我们所做的努力，而且我们看到更多的女性参与其中。但这可能会更好。自2019年该计划启动以来，我们的人数一直在不断提高。与2019年的17%相比，我们的女性参与率提高到了20%。

Kate Stewart, vice president of dependable systems at the LF, is passionate about bringing new talent and participants into open source projects. In fact, mentorship programs have been instrumental in recruiting new maintainers and advancing projects without direct funding, such as SPDX (Software Package Data Exchange). According to Stewart, “My involvement in mentorship programs began with the SPDX side from the Google Summer of Code. Way back when the project started, this was the only way we were able to make forward progress on some of our tools.”

LF可靠系统副总裁Kate Stewart热衷于将新的人才和参与者引入开源项目。事实上，在没有直接资金资助的情况下，导师计划有助于招募新的维护人员和推进项目发展，例如SPDX（软件包数据交换）。根据Stewart的说法，“从Google编程之夏开始，我参与SPDX项目的导师计划。早在项目开始时，这是我们能够在某些工具上取得进展的唯一途径。”

“One big reason it’s fulfilling is that this makes a difference in people’s lives. That little bit of encouragement, that little bit of lift, and having access to a mentor they can talk to and ask, is my patch good?”

“它令人满意的一个重要原因是，它改变了人们的生活。一点点的鼓励，一点点的提升，还有一个可以交谈的导师，可以询问我的补丁好吗？”

A learning experience for mentees (and mentors)​

学员（和导师）的一次学习经历​

Mentorship programs can be helpful for both the mentee and the mentor. Mentees can benefit from having someone to look up to and learn from. As Khan notes, mentors can benefit from the satisfaction of helping others grow and develop and introduce them to new approaches to software development. She adds,

导师计划对学员和导师都有帮助。有一个值得仰望和学习的导师，可以使学员受益。正如Khan所指出的，导师可以从帮助他人成长和发展的满足感中获益，也可以从学员那里了解软件开发的新方法。她补充说，

“Mentors could be locked into a way of doing things, as they have been in their role as maintainers for a very long time. So, when somebody new comes in and tries something new, you look at that new approach and go, oh! That makes sense; that’s another way to do things. So, the mentors themselves learn from mentoring. When I’m looking at patches for analysis sent from mentees who are fixing bugs, I am looking at different parts of the kernel that I am not familiar with in some cases. And sometimes, I need to go deep and understand what I am looking at before I can answer the questions from mentees in these areas, so it’s beneficial to me.”

“导师可能会形成了一种固定的做事方式，因为他们担任维护者的角色已经很长时间了。所以，当有新人进来尝试新事务时，你看到那种新方法有效，会很吃惊！这是有道理的; 是另一种做事的方式。所以，导师自己也会从指导中学习进步。当我查看分析学员提交的修复bug的补丁时，我同时也会查看到内核的不同部分，这些部分在某些情况下我并不熟悉。有时，对于学员提出的某些领域的问题，我需要深入分析才能回答，这对我来说也是受益的过程。”

The design of the kernel’s mentorship program helps new developers familiarize themselves with the kernel development process and provide them with guidance and support from more experienced developers. The program is also open to established developers who want to contribute to the kernel but need help with the process. Working with an experienced maintainer can inspire mentees to become maintainers themselves. As one mentee told us,

内核导师计划的设计目的，是帮助新开发人员熟悉内核的开发过程，并为他们提供更有经验的开发人员的指导和支持。该计划也还面向那些想要为内核做出贡献，但需要帮助的成熟开发人员。与经验丰富的维护人员一起工作，可以激励学员成为维护人员。正如一位学员告诉我们的那样，

“Due to the mentorship program, I was able to understand the mindset of the maintainers … and I would happily take the responsibility of maintaining a project if anyone offers me the opportunity.”

“由于导师计划，我能够理解维护人员的心态......如果有人给我机会，我很乐意承担维护项目的责任。”

Mentors can teach new developers about the culture and customs of the open source community, as well as the technical aspects of working on open source projects. They may offer guidance and support while also being a source of inspiration for innovative concepts. In addition, mentorship programs can help build relationships between people of different ages, experiences, and backgrounds. Khan explains,

导师可以向新开发人员传授开源社区的文化和习俗，以及从事开源项目的技术方面的知识。他们可以提供指导和支持，同时也是创新概念的灵感来源。此外，导师计划可以帮助不同年龄、经历和背景的人之间建立关系。Khan解释说，

“One big reason it’s fulfilling is that this makes a difference in people’s lives. That little bit of encouragement, that little bit of lift, and having access to a mentor they can talk to and ask, is my patch good? Or is my communication good on this email list? Or even how we can help them respond to an upstream email conversation. As a mentor, I might ask that they pose specific questions upstream for effective communication. Or the mentee might say to me that the maintainer hasn’t responded to their patch. I can then say, as a mentor, give them more time to respond. Having someone who can watch over you and be an advocate is a big help when you are getting started in open source; it makes you more confident in understanding how the communication dynamic works.”

“它令人满意的一个重要原因是，它改变了人们的生活。一点点的鼓励，一点点的提升，还有一个可以交谈的导师，可以询问我的补丁好吗？或者我在这个电子邮件列表中的沟通是否良好？ 甚至我们可以帮助他们回复上游的邮件问话。作为导师，我可能会要求他们提出具体问题，以便进行有效的沟通。也许学员可能会告诉我，维护者还没有对他们的补丁做出回应。作为导师我可以说，给他们多一点的时间来回应。当一个人刚开始接触开源项目时，如果有人可以在一旁监督并给与指导是一个很大的帮助；这会让你更有信心去了解项目运作的动态方式。”

"You have to understand the technical skills to be an effective maintainer, but you also have to have a lot more social intelligence. Code is easy. People are hard.Maintainership is about people management."

“要成为一个有效的维护者，你必须理解技术技能，但你还必须具备更多的社交智能。代码很简单，但人们很难处理。维护工作涉及到与人的管理。”

As Kate Stewart says, a maintainer requires a unique combination of technical skills and relationship management.

正如Kate Stewart所说，项目的维护者需要兼具技术能力和关系管理能力。

“There is a recognition that the maintainership tasks are different than the coding tasks. Many people like to code, but this is a different set of skills. You have to understand the technical skills to be an effective maintainer, but you also have to have a lot more social intelligence. Code is easy. People are hard. Maintainership is about people management.”

“人们意识到，维护任务与编码任务不同。许多人喜欢编码，但维护任务需要一套不同的技能。你必须了解技术技能，才能成为一名有效的维护人员，但你还必须拥有更多的社交智慧。管理代码很简单。维护好人员很难。维护工作是关于人员管理的。”

Mentorship can also be a fulfilling experience for retired people who can pass on their expertise to the next generation of programmers to stay active in the technology industry. Stewart discusses the individuals she recruits in former executive roles at major corporations to act as mentors:

对于退休人员来说，导师计划也是一种充实的体验，他们可以将自己的专业知识传授给下一代的程序员，让他们在科技行业保持活跃。Stewart讨论了她在大公司的前高管职位中招募的担任导师的人员：

“Many experienced people are retiring—so how do we keep them engaged? These folks have a lot of skills, so how do they pass them on, and how can it become something they enjoy doing? A friend of mine is a couple of years older than me, and he retired from NXP. He’s sitting around at home, puttering around. And I am saying to myself, how can I lure him into working on some open source projects? It’s rewarding and effective for people who have had a full career, don’t want to do a full-time job, but still want to keep their hand in things and be effective.”

“许多有经验的人都要退休了，我们如何让他们参与进来呢？这些人有很多技能，如何传承，如何让他们继续做喜欢的事情？我的一个朋友比我大几岁，他从NXP退休了。他闲坐在家里，到处闲逛。我在想，怎样才能吸引他从事一些开源项目呢？这些人已经有了完整的职业生涯，不想做全职工作，但仍然希望自己动手做事并保持高效，加入开源项目是有益的，也是有效的。”

Confidence building​

构建信心​

While any community needs some form of guidance and support for its members, this is especially true in the open source world. The development of open source software presents unique challenges. Volunteers often develop it, and they may not have professional experience. This also influences their desire to engage in open source in the first place, as expressed by 100 LFX Mentorship mentees surveyed in 2022. FIGURE 3 shows almost two-thirds of mentees lacked some confidence in their ability to engage in open source before they joined the program.

任何社区都需要为其成员提供某种形式的指导和支持，在开源世界中尤其如此。开源软件的开发带来了独特的挑战。志愿者经常编程，但他们可能没有专业的开源项目经验。这也影响了他们参与开源项目的愿望，正如2022年接受调查的曾经参与LFX导师计划的100名学员所表达的那样。图3显示，近三分之二的学员在加入LFX之前对他们参与开源项目的能力缺乏信心。

One of the positive outcomes of surveying mentees was the reported increase in confidence that mentorship programs create. FIGURE 4 shows that 90% of mentees report increased confidence compared to their level before starting the program.

据报告，对学员进行调查的一个积极结果是，导师计划使他们的信心有所增加。图4显示，90%的学员表示，与开始该计划之前的水平相比，他们的信心提高了。

Qualitative interviews confirmed these results. One mentee interviewed from the Linux kernel project said they decided to join the program to level up their technical skills but also gained confidence in communicating with the community for help and advice. They explained,

定性访谈证实了这些结果。采访了一位来自Linux内核项目学员表示，他们决定加入导师计划是为了提升自己的技术技能，但同时也获得了与社区沟通以寻求帮助和建议的信心。他们解释说，

“I found that the kernel community was extremely patient with me… as I dealt with the fact that I need to accept help, suggestions, and advice.”

“我发现内核社区对我非常耐心......我接受了我需要帮助、给与建议和给与忠告的事实。”

Another mentee from CNCF shared a similar reflection on their increased confidence because of the program:

另一位来自CNCF的学员，分享了他们因该导师计划而增强信心的类似经验：

“I believe my ability to explain myself or to present myself has increased … now, whenever I face a problem, I just publicly go on Slack, and I just say I’m facing issues.”

“我确信，在解释或展示自己的作品方面，我的能力有所提高......现在，每当我遇到问题时，我都会去上Slack，说明我遇到了什么问题。”

Mentorship can provide these individuals with the skills and knowledge to succeed. Khan elaborates,

导师制可以为这些人提供成功所需的技能和知识。Khan详细说明，

“Mentees are getting direct access to experts in those projects and benefiting from the experience of maintainers. They get a one-on-one meeting with the maintainers and experts. They can bounce ideas off of mentors before submitting their upstream contributions. That’s a huge confidence-building factor.

“学员们可以直接接触这些项目的专家，并从维护人员的经验中受益。他们与这些维护人员和专家进行一对一的会谈。在提交代码贡献之前，他们可以征求导师的意见。这是一个巨大的建立信心的因素。

So, for example, with the 13 mentees I mentored this last summer, some of the questions they asked me were interesting, such as, was our community open? If we send patches, will you review them? And they ask other development questions, such as the length of the development processes of particular vendors, the ideal time to send patches, how long it takes for a maintainer to review the patches, etc. All of these are questions that come up in one-on-one conversations. They have to sort through a lot of information as part of being a contributor to an open source project, and sifting through that is hard for them. So, when they have one-on-one relationships with mentors, it helps.”

例如，去年夏天我指导了13名学员，他们问我的一些问题很有趣，例如，我们的社区是否开放？ 如果我们发送补丁，你会审查它们吗？他们还问了一些其他的开发问题，例如特定需求的开发过程的有多长、提交补丁的理想时间、维护人员审查补丁需要多长时间等。所有这些问题都是在一对一的对话中出现的。作为一个开源项目的贡献者，他们必须整理大量的信息，而筛选这些信息对他们来说很困难。因此，当他们与导师建立一对一的关系之后，导师会提供很多指导。”

Community building through mentorship​

基于导师计划构建的社区​

“ After graduating from the program, I went on to start my own open source projects in the JuliaLang community. ... I was confident enough that I could start working on my own project to attract open source contributions someday.”

“从该项目毕业后，我在JuliaLang社区开启了自己的开源项目......我有足够的信心，有朝一日我可以开始自己的项目，吸引开源参与者贡献。”

Mentorship can also help to foster a sense of community within the open source world. By providing guidance and support, mentors can help to create an environment where people feel welcome and valued. This, in turn, can encourage more people to participate in open source projects, which can only serve to improve the quality of the software produced. As one mentee told us,

导师计划还有助于在开源世界中培养社区意识。通过提供指导和支持，导师可以帮助营造一种氛围环境，让参与者感到受欢迎和受到重视。这反过来又可以鼓励更多的人参与开源项目，这种良性循环非常有助于提高软件的质量。正如一位学员告诉我们的那样，

“Apart from the technical skills I picked up from my mentorship project, I also learned the art of communicating technical ideas with like-minded people … I could convey my ideas properly, and even though I was just expecting clarifications on what I should not implement, I received a lot of support from the community to kickstart my first open source project.”

“除了从导师计划项目中学到的技术技能外，我还学会了如何与志同道合的人交流技术想法......我可以恰当地传达我的想法，即使我只是想澄清不应该归我实施的内容，我也依然得到了社区的大力支持，因此我启动了第一个开源项目。”

When thinking about how mentorship programs benefit open source, it’s important to consider other intangibles in addition to bringing in new developer blood and how they address diversity issues. Khan states it’s not simply a balance sheet:

在衡量导师计划对开源项目的意义时，除了引入新的开发人员血液以及他们带来的多样性问题之外，还必须考虑其他的无形资产。Khan说这不仅仅是一份资产负债表：

“Bringing in new developers and training them is obvious, right? When new developers come in, they bring in a new point of view, injecting relevant new ideas like when companies hire new people.

“引入新的开发人员并对他们进行培训，这是显而易见的，对吧？当新的开发人员参与时，他们会带来新的观点，注入新的想法，就像公司雇用新人一样。

Similarly, teaching open source philosophy and the importance of open source early on, in the early part of their careers, will be beneficial to them. It’s also beneficial to have more trained open source developers—they come in and already understand the ecosystem, and part of our training helps them understand that ecosystem. All of that is beneficial—it all comes back to the question of the benefits of open source in the first place. So, it’s hard to prove the bottom line. Training and mentoring new developers are part of that bottom line—all this time and money I spend is not a balance sheet. It’s an intangible benefit that you cannot prove. Yes, it’s beneficial, but you cannot put a dollar amount on it.”

同样，在他们职业生涯的早期，尽早传授开源的哲学和开源的重要性，对他们是非常有益的。让更多训练有素的开源开发人员参与进来，也是有益的，他们有的进来时已经对开源生态系统有所了解，而我们的部分培训可以更进一步帮助他们了解该生态系统。所有这些都是有益的，这一切都回到了开源的好处这个问题上。因此，很难证明开源的盈亏状况。培训和指导新的开发人员代表盈亏的一部分，我花费的所有时间和金钱都不是资产负债表的最终表示。这是无法证明的无形利益。是的，它是有益的，但你没法在资产负债表上加上一笔，哪怕是一美元。”

By completing the mentorship program, mentees are subject to the inner workings of creating and maintaining open source projects. This exposure inspires them to continue contributing to projects. As one mentee said, “I have been actively contributing to open-source ever since.” Another mentee shared how their experience supporting a new project during the program made them confident in starting their own projects:

完成导师计划项目后，学员将参与到创建和维护开源项目的内部工作。这种接触将激励他们继续为此项目做出贡献。正如一位学员所说，“从那以后，我一直在积极地为开源做出贡献。” 另一位学员做了分享，说明他们在项目期间所获得的经验，如何让他们对开启的一个新项目充满了信心：

“After graduating from the program, I went on to start my own open source projects in the JuliaLang community. I had seen the ins and outs of project ideation to the completion of an industry- grade software feature. I was confident enough that I could start working on my own project to attract open source contributions someday.”

“从该项目毕业后，我在JuliaLang社区开启了自己的开源项目。我已经了解了从构思项目到打造行业级别软件功能的来龙去脉。我有足够的信心，有朝一日我可以开始自己的项目，吸引开源参与者贡献。”

The LFX Mentorship program can claim a high success rate as to the disposition of mentees toward open source contribution post-graduation. Eighty-five percent of mentees are or are willing to continue contributing to the project they were involved in after mentorship, as illustrated in FIGURE 5.

LFX导师计划在学员毕业后对开源贡献的影响方面，具有很高的成功率。如图5所示，85%的学员正在或愿意在接受指导后，继续为他们参与的项目做贡献。

Mentorship program challenges​

导师计划的挑战​

"Financial incentives are not effective motivators for open source developers in general."

"一般来说, 对于开源开发人员，经济激励并不是有效的激励因素。"

While mentorship programs can help bring underrepresented groups into the field of software engineering and help refresh the maintainer population, there is still room for improvement.

虽然导师计划可以帮助将代表性不足的群体带入软件工程领域，并对维护人员群体的更新有所助力，但仍有改进的余地。

While the LFX Mentorship program has thousands of applicants every year, the selection process weeds out many people who cannot commit to the program. For one, the programs can be time-consuming and require considerable commitment from participants. In many ways, LFX Mentorship participation as a mentee and mentor follows the self-selection model of open source participation. Even more problematic is the need to get more mentors involved; a lack of mentors can lead to frustration and discouragement for the mentees.

虽然LFX导师计划每年都有成千上万的申请者，但选拔过程淘汰了许多无法参与该计划的人。一方面，这些计划可能很耗时，并且需要参与者做出相当大的承诺。在许多方面，LFX导师参与计划包含受训者和导师，他们需要遵循参与开源的自我选择模式。更大的问题是需要让更多的导师参与进来；导师的缺席会导致受指导者感到挫败和沮丧。

To encourage more mentors to join these programs, Kate Stewart would like to see more recognition and incentives for the mentors themselves.

为了鼓励更多的导师加入这些项目，Kate Stewart希望看到对导师本身的更多认可和激励。

"One of our biggest challenges for mentorship is, how do we get to scale? The scientific work has illustrated that people don’t stick around once they are there—some do, and some don’t. So, we have maintainer burnout. So, the question is, how do you get the people who have been mentored to do the next generation of mentoring so we can scale up instead of everything falling on the maintainers?

“我们在指导方面面临的最大挑战之一是，我们如何扩大规模？科学研究表明，人们不会甘于现状，各有取舍。所以，我们会有维护者惰性。那么问题来了，你如何让接受过指导的人继续参与指导下一代，从而帮助我们扩大规模，而不是一切责任都落在维护者身上？

Motivating graduates to co-mentor is proving to be successful. Some graduates view the opportunity to co-mentor with an experienced mentor as an opportunity to learn and something they can show as an achievement. Financial incentives are not effective motivators for open source developers in general."

事实证明，激励毕业生担任共同导师是成功的。一些毕业生认为与经验丰富的导师共同指导也是他们学习的机会，同样利于他们展示自己的成就。一般对于开源开发人员来说，经济激励并不是有效的激励因素。”

"Most of our funding goes to diversity. Many recipients of event travel funding are women from all over the world, so it gives us a more diverse set of people participating in our events compared with what we see in the mentorship program."

“我们的大部分资金得到了多元化的使用。许多活动的差旅资助收益者都是来自世界各地的女性，因此与我们在导师计划中看到的相比，它让参与我们活动的人更加多样化。”

Mentorship programs can help bring underrepresented groups into the field of software engineering, but they face significant challenges in attracting diverse participants and ensuring they have a rewarding experience once involved. Adequate training and support for mentors and mentees can help address these challenges. Additional resources can make it easier for everyone involved to get the most out of the experience. In addition, by connecting individuals from different backgrounds and experiences, mentorship programs can help create a more diverse and inclusive community within software engineering.

导师计划可以帮助将代表性不足的群体带入软件工程领域，但他们在吸引不同的参与者并确保他们一旦参与后获得有益的经验方面面临重大挑战。对导师和受训者的充分培训和支持可以帮助应对这些挑战。额外的资源可以让所有相关人员更轻松地充分利用他们的经验。此外，通过将来自不同背景和经验的个人联系起来，导师计划可以帮助在软件工程中创建一个更加多样化和包容的社区。

Some of this support can come in the form of funding. Angela Brown, SVP and GM of events at the LF, discussed the value of funding an individual’s participation in a program or event. She offers travel funding to early career professionals to attend open source events within her portfolio. When reviewing the demo graphics of those who have previously received funding, she notes,

其中一些支持可以以资金的形式提供。 LF的高级副总裁兼活动总经理Angela Brown讨论了资助个人参与计划或活动的价值。她为早期职业专业人士提供差旅资金，以参加她投资组合中的开源活动。在审查那些先前获得资助的人的demo图形时，她指出，

"Most of our funding goes to diversity. Many recipients of event travel funding are women from all over the world, so it gives us a more diverse set of people participating in our events compared with what we see in the mentorship program."

“我们的大部分资金得到了多元化的使用。许多活动的差旅资助收益者都是来自世界各地的女性，因此与我们在导师计划中看到的相比，它让参与我们活动的人更加多样化。”

Diversity funding is one way to encourage greater representation in the network of early-career open source developers and expose them to more career opportunities within and outside of the mentorship program.

多元化资助是鼓励早期职业开源开发人员在网络中有更多代表性并让他们在指导计划内外获得更多职业机会的一种方式。

But while training and other resources within mentorship programs can help improve the programs themselves, there are also fundamental problems attracting individuals into mentorship programs due to the limited supply of interdisciplinary software developers trained in embedded systems and software engineering regardless of gender, identity, or socioeconomic background.

但是，尽管导师计划中的培训和其他资源可以帮助改进计划本身，但由于受过嵌入式系统和软件工程培训的跨学科软件开发人员供应有限，无论性别、身份或社会经济背景状况如何，吸引个人参与指导计划也存在根本性问题。

This makes it challenging to find qualified individuals willing to participate as mentors and mentees. In addition, many potential mentees may be reluctant to join a program because they do not have the necessary skills or experience.

这使得很难找到愿意作为导师和参与受训的合格人员。此外，许多潜在的学员可能不愿意加入某个项目，因为他们不具备必要的技能或经验。

The problem is not necessarily a lack of technology professionals. A rebound in the percentage of computer science and information degrees conferred by U.S. universities followed a period of decline, accounting for almost 5% of all degrees in 2020, according to the National Center for Education Statistics.¹ According to the U.S. Bureau of Labor Statistics, the expectation is that employment for all computer and math-related jobs will grow 15% over the next decade.²

问题不一定是缺乏技术专业人员。根据美国国家教育统计中心的数据，美国大学授予的计算机科学和信息技术学位比例在经历了一段时间的下降后出现反弹，2020年占所有学位的近5%。¹ 根据美国劳工统计局的数据，预计所有计算机和数学相关工作的就业人数在未来十年内将增长 15%。²

Instead, it is a question of a skill sets gap. Many of these prospective open source developers do not live in geographies where the required skills are taught in educational institutions.

相反，这是一个技能差距的问题。许多这些潜在的开源开发人员并不居住在教育机构教授所需技能的地区。

These limiting factors have led to a disproportionate underrepresentation of mentees from those parts of the world. Seventy-six percent of respondents to the survey indicated that they lived in the Asia-Pacific region, whereas 14% said they lived in EMEA. Only 10% said they lived in the Americas. (See the Demographics section.)

这些限制因素导致来自世界这些地区的受训者比例过低。76%的调查受访者表示他们住在亚太地区，而14%的人表示他们住在EMEA（欧洲、中东和非洲）。只有10%的人表示他们住在美洲。（请参阅人口统计部分。）

Career benefits of mentorship programs​

导师计划的职业福利​

In addition to improving community health by fostering diversity and cultivating a new generation of open source developers within these projects, mentorship programs can have a transformative economic impact on mentees' lives after they graduate.

通过这些项目可以促进多样性和培养新一代开源开发者以改善社区健康，除此之外，导师计划还可以对学员毕业后的生活产生变革性的经济影响。

Receiving compensation and being able to cover living expenses is a key concern for mentees when contributing to open source projects. FIGURE 6 shows that two-thirds of LFX Mentorship mentees had no prior experience getting paid for their open source involvement before beginning the mentorship.

在为开源项目做出贡献时，是否可以获得足以支付生活费用的报酬，是学员关注的一个关键问题。图6显示，在参加LFX导师计划的学员中，有三分之二的人表示，在此之前没有通过参与开源项目而获得报酬的经历。

The lack of compensation is partially due to many mentorship program applicants still needing to fully enter the professional world. Per FIGURE 7, before joining the mentorship program, 85% were students; after completing the program, 63% of former mentees had at least a part-time job.

缺乏酬劳的部分原因是，许多参加导师计划的申请人要求完全进入专业领域。根据图7，85%的申请人在加入导师计划之前还是学生；而63%的学员完成该项目后获得至少一份兼职工作。

Regarding overall compensation before and after graduation, 67% of those employed and willing to discuss the subject saw their incomes increase after graduation from the mentorship program. (FIGURE 8).

关于毕业前和毕业后的总体薪酬，67%的就业者和愿意讨论该话题的人表示，其收入自导师计划毕业后有所增加（图8）。

Mentorship programs can also create new and increased career opportunities for mentees. Participating in a mentorship program can give mentees access to resources and knowledge that are difficult to find elsewhere. After graduation, many mentees find that they have a more extensive network of contacts in their chosen field, which can lead to better job opportunities.

导师计划也可以为学员创造更多新的职业机会。参加导师计划可以让学员获得其他地方难以接触到的资源和知识。毕业后，许多学员发现，在所选领域，他们拥有更广泛的人脉网络，这可以带来更好的工作机会。

Mentors often have a wealth of experience and can provide mentees with valuable advice on which direction to take in their careers. The connection to such an experienced individual is often invaluable for a young professional.

导师通常有丰富的经验，可以为学员提供关于职业发展方向的宝贵建议。与这样一个经验丰富的人建立联系，对于一个年轻的技术人员来说往往是无价的。

Mentors are often well-respected members of the industry and can provide mentees with recommendations or introductions that can help them get the job they want. As FIGURE 9 shows, 69% of LFX Mentorship mentees have seen their career advance or new career opportunities emerge due to participating in the mentorship program.

导师通常是受到行业同仁尊敬的专家，可以为学员提供推荐或引荐，帮助他们找到心仪的工作。如图9所示，参加LFX导师计划的学员中，有69%因此获得了职业提升或新的职业机会。

“The project clarified my vision of where I would like to take my career and where I would like to go within the mainframe. The vision that I have right now is because of that project.”

“该项目明确了我的职业规划，以及我希望在大型机行业里走向何方。我现在的职业愿景就是源于参加过的这个项目。”

Employment is often a gauge of career advancement, and 47% said that the program helped them get a job. (FIGURE 10) 就业往往是职业发展的一个衡量标准，47%的人表示该计划帮助他们找到了工作。（图10）

For those LFX Mentorship program graduates who have jobs, how does this relate to being compensated for open source work? FIGURE 11 shows that over half of those employed receive payment for their open source involvement.

参加LFX导师计划项目毕业后有工作的人，他们的薪酬与开源工作的报酬有什么关系？图11显示，超过一半的员工因参与开源活动而获得报酬。

The LFX Mentorship program clearly changes the lives of its mentees. FIGURE 12 shows that 58% of participants believe the program had a significant or transformative impact on their careers. One mentee interviewed by the Open Mainframe Project told us,

LFX导师计划显然改变了学员的生活。图12显示，58%的参与者认为该计划对他们的职业生涯产生了重大或变革性影响。Open Mainframe项目采访的一位学员告诉我们，

“The project clarified my vision of where I would like to take my career and where I would like to go within the mainframe. The vision that I have right now is because of that project.”

“该项目明确了我的职业规划，以及我希望在大型机行业里走向何方。我现在的职业愿景就是源于参加过的这个项目。”

But perhaps the most astonishing part of the LFX Mentorship program is the level of satisfaction among its graduates. FIGURE 13 illustrates that 99% of former mentees would recommend the program to others, and everyone involved acknowledges that the program was beneficial.

LFX导师计划最令人惊讶的数据也许是毕业生的满意度。图13显示，99%的前学员会向其他人推荐该计划，所有参与的人都承认该计划是有益的。

Conclusion​

结论​

Despite ongoing challenges with scale, mentorship programs, including LFX Mentorship, help college and university students and young professionals gain experience with open source software development, which advances their careers and helps to build a healthy and diverse community of new contributors and maintainers across LF and open source projects.

尽管在规模方面存在持续的挑战，但包括LFX导师在内的导师计划帮助大学生和年轻专业人员获得开源软件开发的经验，这将促进他们的职业发展，并有助于在LF和开源项目中建立一个由新的贡献者和维护者组成的健康、多样化的社区。

The three primary takeaways from the study are:

1. LFX Mentorship participants had prior involvement in open source and IT from a student’s perspective but lacked confidence and work experience. Their confidence improved after participation.
2. Mentees find employment and increased income after the conclusion of the mentorship, and they frequently receive payment for their contributions to open source.
3. The mentorship program is helping build a confident, diverse community of open source developers.

该研究的三个主要结论是：

1. LFX导师制参与者从学生的角度出发，他们曾参与过开源和IT项目，但缺乏信心以及工作经验；参与后，他们的信心有所提高。
2. 辅导结束后，学生们找到了工作，收入也增加了，他们经常收到报酬感谢他们对开源的贡献。
3. 导师计划有助于建立一个自信、多元化的开源开发者社区。

Actionable insights​

可操作的见解​

The LFX Mentorship program is making our project communities more diverse, helping mentees find jobs, and demonstrating overall value, but where do we go to improve scale?

LFX导师计划正在使我们的项目社区更加多样化，帮助学员找到工作，并展示整体的价值，但我们该如何扩大规模呢？

Educate multiple stakeholders on the program's successes​

在项目成功方面对多个干系方进行宣传教育​

LF projects that have invested in LFX Mentorships should be proud of their impact and aware of their return on investment for future funding consideration. Those projects that do not have mentorships in place and are unsure whether a mentorship program will benefit them at their current state of development need only to look to the example set by projects such as the Linux kernel, CNCF, ELISA, Hyperledger, and Open Mainframe—each is devoting significant resources to this effort for the outcomes this report identifies. Additionally, we request our member companies to encourage and promote mentoring by allowing their employees to mentor.

已投入LFX导师的LF项目应为其影响感到自豪，并了解其投资回报，以供未来资金考虑。那些没有导师的项目，并且不确定导师制计划在当前的发展状态下是否会使他们受益，他们只需要看看Linux内核、CNCF、ELISA、Hyperledger和Open Mainframe等项目所树立的榜样，每个项目都在为本报告确定的结果投入大量资源。 此外，我们通过让我们的成员公司员工自行指导的方式，使成员公司鼓励指导、和提高指导水平。

Encourage continued financial support from the open source community​

鼓励开源社区延续资金支持​

An investment in mentorship is an investment in the future health of open source projects. The financial incentive offered to mentees to join the program meets a fundamental need for people at the outset of their careers. Similarly, it may be worth exploring ways to compensate mentors who invest significant time, which may comprise a combination of financial reward with support in the form of human resources, tooling, and other nonfinancial benefits.

对导师的投资是对开源项目未来健康状况的投资。向学员提供的加入该计划的经济激励满足了人们在职业生涯初期的基本需求。同样，值得探索的是如何补偿投入大量时间的导师，这可能包括财务奖励与人力资源、工具和其他非财务利益形式的支持的组合。

As member and partner organizations benefit heavily from the open source projects themselves, they should view funding mentorship as an investment in their own software’s sustainability, increasing the likelihood of a steady stream of future talent that is trained on the platforms they use. An example of this is the recently launched LFX Mentorship Showcase, which allows graduating mentees of the LFX Mentorship program to showcase the work they completed during their session term and connect with prospective employers from our member companies.

由于成员和合作伙伴组织从开源项目本身中受益匪浅，因此他们应该将资助导师关系视为对自己软件可持续性的投资，从而增加在他们使用的平台上培训稳定未来人才的可能性。这方面的一个例子是最近推出的LFX导师展示会，它允许LFX导师计划的毕业生展示他们在课程期间完成的工作，并与我们成员公司的潜在雇主进行联络。

Address geographic barriers that the report identifies​

解决报告中定位到的地理阻隔​

As Southeast Asian participants represent more than 70% of the LFX Mentorship program, this is a powerful indicator that we need to understand the reasons for the gap and improve the geographic makeup of the mentee population in other regions, such as North America and Europe.

目前东南亚参与者占LFX导师计划的70%以上，这是一个强烈的信号，我们需要了解这种差距的原因，并改善其他地区（如北美和欧洲）学员人口的地理组成。

Use tooling for productivity to help maintainers mentor without burnout​

使用工具提高生产力，以帮助维护人员在指导过程中避免倦怠​

The amount of time that mentors invest directly with their mentees is significant, so the more we can use tools to create a “one-to-many” type of paradigm will improve the program’s scalability. Examples of this are in play, such as the 15-minute “Speed Mentorships” recently tested at Open Source Summit North America 2022 and LF Live: Mentorship, a series of webinars held for remote learning that can be attended on demand.

导师与学员直接投入的时间非常长，因此我们越能使用工具来创建“一对多”类型的范例，就越能提高项目的可扩展性。这方面的例子正在进行，例如最近在2022年北美开源峰会上测试的15-minute “Speed Mentorships”和LF Live: Mentorship，这是一系列为远程学习举办的网络研讨会，可根据需要参加。

Final Thoughts​

最后的感想​

The LFX Mentorship program is clearly a success, and we should be doing all that we can to encourage more investment in this valuable initiative. By educating stakeholders on the successes of mentorship programs, seeking donations and funding from among our members and partners, addressing geographic barriers, and using tooling for productivity, we can ensure the longevity of the program and also create a more diverse, confident open source developer community for the long term. By leveraging the power of mentorships, we can continue to improve our open source projects and ensure they remain vibrant for years to come.

LFX导师计划显然是成功的，我们应该尽一切努力鼓励更多的投资于这项宝贵的计划。通过对参与方进行导师计划取得成功的宣传教育，从我们的成员和合作伙伴中寻求捐款和资金，解决地理障碍，并使用工具提高生产力，我们可以确保计划的持久性，并长期创建一个更多元、更自信的开源开发者社区。通过利用导师制的力量，我们可以继续改进我们的开源项目，并确保它们在未来几年保持活力。

We would like to thank our mentors for volunteering their time to share their valuable experience in formal mentoring programs and in hosting LF Live Webinars

我们要感谢我们的导师自愿抽出时间分享他们在正式指导计划和举办LF Live网络研讨会方面的宝贵经验。

Methodology​

研究方法​

• The completion of a survey of graduates of the LF Mentorship program took place from January through March 2022.

• After eliminating duplicate and incomplete records, this analysis is based on 74 participants who came from the 2021 mentorship class, with the remainder completing the program in 2020.

• For N = 100, the margin of error is +/- 8.2% @ 90%.

• After the completion of the initial survey, more than 20 mentees provided additional qualitative feedback.

• Percentage values may not add exactly to 100% due to rounding

• 2022年1月至3月完成了LF导师计划毕业生调查。

• 在消除重复和不完整的记录后，本分析基于来自2021辅导的74名课程参与者，其余学生将于2020年完成课程。

• 对于N=100，误差范围为+/-8.2%@90%。

• 初始调查完成后，20多名学员提供了额外的定性反馈。

• 由于进行了取整运算，百分比值可能无法精确增加到100%

Demographics​

统计数据特征​

A survey of 100 graduates of the 2020 and 2021 LF Mentorship programs yielded the results. Three-quarters of the respondents lived in an Asian country during their mentorship, and 82% were 18–24 years old. Of those currently employed, 69% work in the information technology industry.

对2020年和2021 LF导师计划的100名毕业生进行的调查得出了结果。四分之三的受访者在担任导师期间生活在亚洲国家，82%的受访者年龄在18-24岁。在目前就业的人中，69%在信息技术行业工作。

About the author​

关于作者​

Jason Perlow is a veteran of the information technology industry with over 25 years of experience as an independent consultant for the financial sector and a systems architect, technology strategist, and technical writer at Unisys, IBM, Dimension Data, and Microsoft. Jason led the 8th, 9th, and 10th annual LF Jobs Reports. He co-authored the 2021 State of Open Source in Financial Services research and, as editorial director, is the lead content writer, editor, and manager for LF Projects, LF Research, and Linux.com. In 1999, Jason was the founding senior technology editor of Linux Magazine, where he led coverage of the formation of the LF and has had an op-ed technology column on ZDNET, covering enterprise technology since 2008.

Jason Perlow是信息技术行业的资深人士，拥有超过25年的金融行业独立顾问经验，也是Unisys、IBM、Dimension Data和Microsoft的系统架构师、技术策略师和技术作家。Jason领导了第8、第9和第10届LF年度工作报告。他与人合著了《2021金融服务研究中的开放源码状态》（State of Open Source in Financial Services research），作为编辑总监，他是LF Projects、LF research和Linux.com的主要内容撰写人、编辑和经理。1999年，Jason是Linux Magazine的创始高级技术编辑，他在该杂志上领导了LF的形成报道，并在ZDNET上开设了op-ed技术专栏，自2008年起涵盖企业技术。

Acknowledgments​

致谢​

作者希望感谢我们的赞助商，CNCF、Hyperledger基金会、安全应用程序中启用Linux（ELISA）项目、开放大型机项目和开源安全基金会（OpenSSF）对本研究的支持。特别感谢LF的同事Shuah Khan、Kate Stewart和Angela Brown的见解；Hilary Carter、Lawrence Hecht、Steve Hendrick、Anna Hermansen、Christina Oliviero和Melissa Schmidt提供定量分析和运营支持；以及参加本次调查的所有LFX导师，尤其是本次研究的受访者。

Note​

注释​

This report has been updated since its original release on 01.16.23. This second version, released on 01.19.23, corrects errors found in the original text and graphics.

本报告自2013年1月16日首次发布以来已进行了更新。当前为第二个版，发布于2023年1月19日，修正了原始文本和图形中的错误。

Invest in building a stronger and more diverse community of qualified developers and engineers. LFX Mentorship makes it easy to sponsor and help train the next generation of open source developers by serving the key needs of the community. The program received 10,700 applications, accepted 600+ applicants, and paid $1.5M in stipends. Since its inception in 2019, LFX Mentorship Programs have trained 414 new developers. Several of our graduates are now gainfully employed and continuing to contribute to open source projects. We strongly believe in and are committed to providing learning pathways for new developers of all backgrounds.

投资于建设一个更强大和多样化的合格开发人员和工程师社区。LFX Mentorship通过满足社区的关键需求，为赞助和帮助培训下一代开源开发人员提供了便利。该计划收到了10,700份申请，接受了600多名申请人，并支付了150万美元的津贴。自2019年成立以来，LFX Mentorship计划已经培训了414名新的开发人员。我们的一些毕业生现在已经稳定就业，并继续为开源项目做出贡献。我们坚信并致力于为所有背景的新开发人员提供学习路径。

Founded in 2021, LF Research explores the growing scale of open source collaboration and provides insight into emerging technology trends, best practices, and the global impact of open source projects. Through leveraging project databases and networks and a commitment to best practices in quantitative and qualitative methodologies, LF Research is creating the go-to library for open source insights for the benefit of organizations the world over.

LF研究院成立于2021年，探索不断扩大的开源合作规模，并提供新兴技术趋势、最佳实践和开源项目的全球影响力的见解。通过利用项目数据库和网络，并致力于定量和定性方法论的最佳实践，LF研究正在为全球组织打造一座开源见解的图书馆，以造福全球。

Copyright © 2023 The Linux Foundation

版权所有 © 2023 Linux基金会

This report is licensed under the Creative Commons Attribution-NoDerivatives 4.0 International Public License. To reference the work, please cite Jason Perlow, “Mentorship in Open Source,” foreword by Julia Lawall, The Linux Foundation, January 2023.

此报告受创作共用许可证Attribution-NoDerivatives 4.0 International Public License保护。 在引用这项工作时，请引用Jason Perlow的“开源中的导师制”，由Julia Lawall撰写的前言，The Linux Foundation，2023年1月发布。

The CNCF, part of the LF, hosts critical components of the global technology infrastructure, including Kubernetes, Prometheus, and Envoy. CNCF brings together the industry’s top developers, end users, and vendors and runs the world’s largest open source developer conferences. For more information, please visit www.cncf.io.

CNCF（云原生计算基金会）是 LF（Linux 基金会）的一部分，承载着全球技术基础设施的关键组件，其中包括 Kubernetes、Prometheus 和 Envoy。CNCF 聚集了行业顶尖的开发者、最终用户和供应商，并举办全球最大的开源开发者大会。欲了解更多信息，请访问 www.cncf.io。

The ELISA project aims to make it easier for companies to build and certify Linux-based safety-critical applications— systems whose failure could result in loss of human life, significant property damage, or environmental damage. ELISA members are working together to define and maintain a common set of tools and processes to help companies demonstrate that a specific Linux-based system meets the necessary safety requirements for certification. Launched in February 2019, ELISA works with Linux kernel and safety communities to agree on what to consider when using Linux in safety-critical systems. The project has several dedicated working groups that focus on providing resources for system integrators to apply and use to analyze qualitatively and quantitatively on their systems.

ELISA项目旨在帮助企业更轻松地构建和认证基于Linux的安全关键应用程序- 这些系统的故障可能导致人员生命的丧失、重大财产损失或环境破坏。ELISA成员共同努力，定义并维护一套通用的工具和流程，帮助企业证明特定的基于Linux的系统满足必要的安全认证要求。ELISA于2019年2月推出，与Linux内核和安全社区合作，以就在安全关键系统中使用Linux时要考虑的内容达成一致。该项目有几个专门的工作组，专注于为系统集成商提供资源，以进行定性和定量分析其系统的应用和使用。

Hyperledger Foundation is an open source community focused on developing a suite of stable frameworks, tools, and libraries for enterprise-grade blockchain deployments. It is a global collaboration hosted by The LF and includes leaders in finance, banking, the Internet of things, supply chains, manufacturing, and technology. Built under technical governance and open collaboration, individual developers, service, and solution providers, government associations, corporate members, and end users are all invited to participate in developing and promoting these game-changing technologies.

Hyperledger Foundation（超级账本基金会）是一个致力于开发稳定框架、工具和库以适用于企业级区块链部署的开源社区。它是由LF（Linux Foundation）托管的全球合作项目，包括金融、银行、物联网、供应链、制造业和技术领域的领导者。在技术治理和开放合作的基础上构建，鼓励个人开发者、服务和解决方案提供商、政府协会、企业会员和终端用户参与开发和推广这些具有改变游戏规则的技术。

The LF’s training program features courses developed and taught by expert instructors, many of whom are wellrespected professionals in the open source community. Our certification team performs comprehensive industry and job analyses to ensure every professional certification program we offer meets our exceedingly high standards. Led by our outstanding customer success team, we deliver responsive support and customized training solutions to enable individual and business to successes.

LF的培训计划包括由专家讲师开发和教授的课程，其中很多人在开源社区中拥有很高的声誉。我们的认证团队会进行全面的行业和工作分析，以确保我们提供的每个专业认证计划都满足我们极高的标准。在我们出色的客户成功团队的带领下，我们提供响应迅速的支持和定制培训解决方案，以促使个人和企业的成功。

The Open Mainframe Project was founded in 2015 as a focal point for deploying and using Linux and open source in a mainframe computing environment. With a vision of open source on the mainframe as the standard for enterprise-class systems and applications, the project’s mission is to build community and adoption of open source on the mainframe by eliminating barriers to open source adoption on the mainframe, demonstrating value of the mainframe on technical and business levels, and strengthening collaboration points and resources for the community to thrive. Open Mainframe Project is home to more than 22+ projects and working groups, including ADE, Ambitus, ATOM, CBT Tape, COBOL Check, COBOL Programming Course, COBOL Working Group, ConsoleZ, Feilong, GenevaERS, Linux Distributions Working Group, Mainframe Open Education, Mentorship, Polycephaly, Software Discovery Tool, TerseDecompress, Tessia, Zowe, and Zorow.

开放大型计算机项目（Open Mainframe Project）成立于2015年，旨在成为在大型计算机环境中部署和使用Linux和开源的焦点。该项目的愿景是将开源在大型计算机上作为企业级系统和应用的标准，其使命是通过消除在大型计算机上采用开源的障碍，展示大型计算机在技术和业务层面的价值，以及加强合作关系和资源，推动大型计算机上开源的社区建设和采用。开放大型计算机项目拥有22多个项目和工作组，包括ADE、Ambitus、ATOM、CBT Tape、COBOL Check、COBOL编程课程、COBOL工作组、ConsoleZ、Feilong、GenevaERS、Linux发行版工作组、大型计算机开放教育、导师计划、Polycephaly、软件发现工具、TerseDecompress、Tessia、Zowe和Zorow等。

The OpenSSF is a cross-industry organization that brings together the industry’s most important open source security initiatives and the individuals and companies that support them. The OpenSSF commits to collaboration and working both upstream and with existing communities to advance open source security for all.

OpenSSF是一个跨行业组织，汇集了行业中最重要的开源安全倡议以及支持它们的个人和企业。OpenSSF致力于合作，并在上游和现有社区之间共同推动开源安全的发展。

OSPO 的商业价值

An Exploration of Why Organizations Create, Sustain, and Expand Open Source Program Offices (OSPOs)

探索为什么组织创建、维持、扩大开源项目办公室（OSPOs）

MARCH 2023

Emily Omier, Positioning & Messaging Consultant, Emily Omier Consulting

Chris Aniszczyk, CTO, Cloud Native Computing Foundation

Ana Jiménez Santamaría, OSPO Program Manager, TODO Group

With forewords by Georg Kunz, Open Source Manager, Ericsson, Leslie Hawthorn, Sr. Manager, Red Hat OSPO and Kimberly Craven, Sr. Director, Red Hat OSPO, Office of the CTO

2023年3月

Emily Omier，Emily Omir咨询公司定位与信息顾问

Chris Aniszczyk，云原生计算基金会首席技术官

Ana Jiménez Santamaría，OSPO 项目经理，TODO工作组

爱立信开源经理Georg Kunz、Red Hat OSPO高级经理Leslie Hawthorn和首席技术官办公室Red Hat OSPO高级总监Kimberly Craven作序

Contents​

Forewords ............................................................................................................................................3
Introduction.........................................................................................................................................7
Why do we care about how OSPOs contribute to the business? ................................................................................7
Common threads in unique stories ...................................................................................................................................7
Methodology ..........................................................................................................................................................................8
Organization profiles and the relationship with open source......................................................................................8
What can OSPOs do for organizations?.........................................................................................11
The reasons behind starting an OSPO............................................................................................................................11
The OSPO journey.............................................................................................................................16
Overcoming internal obstacles: Culture and education ..............................................................................................16
A strategic relationship with open source ......................................................................................................................17
The different hats of an OSPO .......................................................................................................18
The Counselor ......................................................................................................................................................................18
The Facilitator.......................................................................................................................................................................18
Ensuring OSPO sustainability............................................................................................................................................18
Measuring an OSPO’s success.........................................................................................................19
Common OSPO KPIs ...........................................................................................................................................................19
The KPI search..................................................................................................................................................................... 20
Conclusion..........................................................................................................................................21
What’s coming in the future? ............................................................................................................................................21
Future research....................................................................................................................................................................21
About the authors .............................................................................................................................................................. 22

目录​

序 ................................................................................3
简介............................7
为何我们关注OSPOs的商业贡献？ ..................................7
独特故事的共同脉络 ................................................7
方法论 .............................................................8
组织简介以及其与开源的关系..................................................................8
OSPOs可以为组织做什么？...........................................11
开启一个OSPO的原因......................................................................11
OSPO之旅........................................16
克服内部阻碍：文化和教育 ..............................................16
与开源之间的战略关系 ...................................17
OSPO的不同角色 ..................................18
顾问 .................................18
推动者........................................18
确保OSPO的可持续性.........................................................18
评估一个OSPO的成功..................................................19
常见的OSPO KPIs ..........................................................19
KPI搜索................................................................. 20
结论....................................................21
展望未来 ......................................................21
后续研究....................................................................21
关于作者 ..................................................................... 22

Forewords​

序​

Open source software continues to transform how entire industries create and use software. Across industries, systems built to a large degree or even entirely from open source software components that communicate via open APIs are replacing proprietary and closed software stacks. Based on collaboration and joint development, open source software has become a fundamental means for driving innovation, fostering technology adoption, and openly sharing knowledge.

开源软件继续改变着整个行业创建和使用软件的方式。在各个行业中，在很大程度上甚至完全由通过开放API沟通的开源软件组件构建的系统正在取代专有和封闭的软件堆栈。基于协作和联合开发，开源软件已成为推动创新、促进技术采用和公开共享知识的基本手段。

While the high-level advantages of open source software are undeniable, it is unfortunately far from simple and straightforward for organizations to leverage those in practice. As the usage of open source software in organizations proliferates and matures, many realize the need for establishing a structured approach to working with open source software. Initially, this need typically emerges from license compliance concerns, but it quickly grows way beyond compliance alone, eventually encompassing business strategy aspects as well.

尽管开源软件的顶层优势是不可否认的，但不幸的是，组织在实践中使用它们远非这么简单直接的事情。随着开源软件在组织中的使用激增和成熟，许多人意识到需要建立一种结构化的方法来使用开源软件。最初，这种需求通常源于许可证合规性问题，但它很快就远远超出了合规性本身，最终也涵盖了商业战略方面。

This report compiles the results of a survey among open source advocates from Open Source Program Offices (OSPOs) across various companies and universities. It provides a broad insight into the motivation behind forming OSPOs and the concrete business value of OSPOs to their respective organizations.

本报告汇集了来自不同公司和大学的开源项目办公室（OSPO）的开源倡导者的调查结果。它为形成OSPO背后的动机以及OSPOs对其各自组织的具体商业价值提供了广泛的视角。

It turns out that, just like open source software itself, OSPOs come in all sorts of shapes and forms. However, irrespective of the concrete implementation of an OSPO, the survey shows that across organizations, the key business value of OSPOs converges toward the same fundamental goals: to establish a framework for an organization’s way of working with open source software and to ensure that open source software is leveraged strategically and well aligned with an organization’s business goals. An OSPO’s responsibilities thereby range from formalizing processes and transforming an organization’s culture to guiding the creation and execution of a long-term open source strategy.

事实证明，就像开源软件本身一样，OSPO有各种各样的形态和方式。然而，无论OSPO的具体实施情况如何，调查显示，在各个组织中，OSPO的关键业务价值指向了相同的基本目标：为组织使用开源软件的方式建立一个框架，并确保开源软件在战略上得到利用，并与组织的业务目标保持一致。因此，OSPO的职责范围从正式化流程和转变组织文化到指导长期开源战略的创建和执行。

Building on the core principles of open source software— collaboration and knowledge sharing—the contributors to this report aim to provide a helpful source of information. It targets both open source champions in organizations who are currently on the journey of establishing an OSPO as well as open source leaders of existing OSPOs, enabling them to clearly define, measure, and communicate the business value of an OSPO.

基于开源软件协作和知识共享的核心原则，本报告的撰稿人旨在提供有用的信息来源。它既针对目前正在建立OSPO的组织中的开源拥护者，也针对现有OSPO的开源领导者，使他们能够清楚地定义、衡量和传达OSPO的商业价值。

Georg Kunz

Open Source Manager, Ericsson

Georg Kunz

爱立信开源经理

As open source software has achieved ubiquity in the technology arena, more organizations are realizing the benefits of working with open source projects and the communities that build them. To harness this strategic potential of open source, direct investment into engaging with project communities is no longer a nice to have but a requirement. OSPOs, once largely extant only at large technology-focused firms, have proliferated across industries as a locus for starting, standardizing, and scaling an organization’s approach to open source.

随着开源软件在技术领域的普及，越来越多的组织正在意识到与开源项目和构建这些项目的社区合作的好处。为了利用开源的这种战略潜力，直接投资参与项目社区不再是一件好事，而是一种要求。OSPO曾经主要只存在于以技术为重点的大型公司，现在已经在各个行业激增，成为启动、标准化和扩展组织开源方法的场所。

In just the past five years, we have seen OSPOs crop up in the fields of automotive, entertainment, financial services, manufacturing, and even within academia and government bodies. Having an OSPO and accompanying dedicated resources to focus a company’s open source strategy creates a framework for harnessing the best possible outcomes for all players involved. Organizations have a clearer view of the software landscape upon which their businesses depend, maintainers of key software projects have a more direct line into organizations using their works, and external would-be collaborators have a welcoming and well-understood entry point to negotiating with the business.

在过去的五年里，我们看到OSPO在汽车、娱乐、金融服务、制造业领域，甚至在学术界和政府机构中涌现。拥有一个OSPO和相应的专用资源来专注于公司的开源战略，为所有参与者创造了一个利用最佳结果的框架。组织对其业务所依赖的软件环境有了更清晰的了解，关键软件项目的维护者可以更直接地进入使用其作品的组织，外部潜在合作者在与业务谈判时有一个受欢迎且广为人知的切入点。

In this report, you will hear from OSPO leaders across a variety of sectors who will share their journey building open source consumption, contribution, and community engagement strategies for their businesses. You will also learn that each OSPO’s goals, success metrics, and approaches to engagement vary depending upon the drivers for establishing the OSPO, an organization’s maturity level with their open source practice, and how internal champions for the OSPO’s work support its growth and strategy. No OSPO is exactly like another, even as they share many common responsibilities.

在本报告中，您将听到来自各个行业的OSPO领导人的发言，他们将分享他们为企业建立开源消费、贡献和社区参与战略的历程。您还将了解到，每个OSPO的目标、成功指标和参与方法都有所不同，这取决于建立OSPO的驱动因素、组织在开源实践方面的成熟度水平，以及OSPO工作的内部支持者如何支持其发展和战略。没有一个OSPO与另一个完全相同，尽管它们有许多共同的责任。

Across our combined 30+ years of experience working in open source, the common thread we’ve seen that unites all OSPOs is their deep value in enabling collaboration and co-creation, whether that’s internally amongst different software teams or competitors working together in an upstream community. OSPOs are one of the few teams with a clear mandate for bi-directional advocacy, both within the organization— establishing norms for engaging with open source projects and championing open source best practices—and externally to the organization, ensuring that a company’s actions in a particular community both serve business goals and advance the technical state of the art for all players.

在我们30多年的开源工作经验中，我们看到的将所有OSPO团结在一起的共同点是，无论是在不同的软件团队内部，还是在上游社区中合作的竞争对手之间，它们在实现协作和共同创建方面都有着深刻的价值。OSPO是少数几个明确授权双向倡导的团队之一，无论是在组织内部，还是在组织外部，都要建立参与开源项目和倡导开源最佳实践的规范，确保公司在特定社区的行动既有助于实现商业目标，又能提高所有参与者的技术水平。

It is precisely because of the flexibility and bi-directional nature of the OSPO’s mission that these groups can be the foundational strategic lynchpin of a business’s technology approach. OSPOs have the freedom to explore and support innovations for the business and to define how this engagement will work to best satisfy the objectives of all players, from engineering talent to business executives to the open source project community itself. OSPOs act as the conduit and connective tissue between each group of stakeholders, diplomatically ensuring the interests of all parties are heard and considered, and negotiating for the best possible outcomes for all parties collaborating and co-creating together.

正是由于OSPO使命的灵活性和双向性，这些团体可以成为企业技术方法的基本战略关键。OSPO可以自由探索和支持业务创新，并定义这种参与将如何最好地满足所有参与者的目标，从工程人才到企业高管，再到开源项目社区本身。OSPO充当每组利益相关者之间的管道和连接组织，在外交上确保各方的利益得到倾听和考虑，并为各方合作和共同创造尽可能好的结果进行谈判。

It is this inward and outward-facing service mission that is the real magic of the OSPO. In this role, the successful OSPO acts as a diplomat for its organization in the wider world, charged with representing the needs of the business to the community and the community’s needs to the business. OSPOs have a unique role to play as stewards of industry-wide best practices, a locus of collaboration and co-creation, and a conduit for change agency as their company evolves in the ever-changing market landscape.

正是这种内向和外向的服务使命才是OSPO真正的魔力。在这一角色中，成功的OSPO作为其组织在更广泛世界的外交官，负责代表社区对企业的需求和企业对社区的需求。随着公司在不断变化的市场格局中的发展，OSPOs作为全行业最佳实践的管理者、合作和共同创造的场所以及变革机构的渠道，可以发挥独特的作用。

For those who have worked in the open source space for the past decades, or for readers who are early in their open source journeys, this whitepaper will present key areas of challenge and opportunity for the OSPO, shared from senior OSPO leaders across a variety of industries. Wherever you may be in your OSPO journey, from having one lone staffer who focuses on open source software license compliance to having a long-established open source strategy, we hope you will find this research valuable in examining the business value of OSPOs for your enterprise. As you examine the findings from open source leaders in a variety of industries, we hope you will see yourself in their journeys and be inspired. We look forward to your organization joining the community of OSPO practitioners contributing to the very foundations of open source practice: how we work together, what we do together, and how we all can derive mutual benefit.

对于那些在过去几十年中一直在开源领域工作的人，或者处于开源之旅早期的读者，本白皮书将介绍OSPO面临的挑战和机遇的关键领域，并由各个行业的OSPO高级领导人分享。无论您身处OSPO之旅哪个阶段，从拥有一名专注于开源软件许可证合规性的员工，到拥有一个长期建立的开源策略，我们希望您能发现这项研究对检验OSPO对您的企业的商业价值有价值。当你审视各个行业开源领导者的发现时，我们希望你能在他们的旅程中看到自己，并受到启发。我们期待您的组织加入OSPO从业者的社区，为开源实践的基础做出贡献：我们如何合作，我们一起做什么，以及我们如何获得互利。

Kimberly Craven

Sr. Director, Red Hat Open Source Program Office, Office of the CTO

Kimberly Craven

首席技术官办公室，Red Hat开源项目办公室，高级主任

Leslie Hawthorn

Sr. Manager, Red Hat Open Source Program Office

Leslie Hawthorn

Red Hat开源项目办公室，高级经理

The Business Value of the OSPO

OSPO 的商业价值

Introduction​

介绍​

Why do we care about how OSPOs contribute to the business?​

我们为什么关心OSPO如何为业务提供助力？​

A well-designed OSPO is the center of competency for an organization’s open source operations and structure.

对一个组织的开源运营和结构来说，一个设计良好的开源项目办公室(OSPO)是核心竞争力。

Why do we need to understand how OSPOs contribute to business goals? Whether it’s to advocate for creating a new OSPO, continue funding the OSPO, or even expand the OSPO, champions will ultimately have to connect the dots between the OSPO and business objectives. Whether in a for-profit business or not-for- profit university, no initiative that can’t be connected to outcomes that matter to the organization is likely to get greenlighted in the first place, nor survive if they can’t make a business case for their existence.

为什么我们需要了解OSPO如何对业务目标提供助力？无论是为了倡导创建新的OSPO、继续为OSPO提供资金支持，还是为了扩大OSPO，支持者最终必须将OSPO与业务目标联系起来。无论是在营利性企业还是非营利性大学，如果一项提议不能与组织关心的结果联系起来，很可能首先就不会得到批准。如果不能为它们的存在提出商业理由，它们也无法生存下去。

“OSPOs as a whole need to be nimble, they need to be always ready for the next change,” said Suzanne Ambiel, director of open source marketing and strategy at VMware. “They need to adapt to the business because they’re serving the business as well as the community. As the business changes and morphs, the OSPO needs to do so as well ... It’s really important that an OSPO be very connected to the business and the business strategy.”

”整个OSPO需要保持敏捷性，始终准备着应对下一个变化“，VMware开源营销和战略主管Suzanne Ambiel表示。”他们需要适应业务，因为他们同时服务于业务和社区。随着业务的变化和发展，OSPO也需要进行相应的调整……一个OSPO与业务和业务战略紧密相连是非常重要的。“

Though OSPOs are generally—but not always—located under the chief technology officer (CTO) and include many software engineers, interest in open source and how a company relates to open source is by no means limited to the engineering department. As we found in interviewing OSPO leaders for this report, the OSPO champions in many organizations were executives who saw both opportunities and, in some cases, potential threats from open source that their companies needed to address strategically. In doing this research, we hope to better understand why open source matters strategically to companies and how OSPOs help organizations proactively manage both the opportunities and threats to their particular business from open source.

虽然OSPO通常（但并非总是）隶属于首席技术官(CTO)，并且由许多软件工程师组成，但并不是只有工程部门才对开源及公司如何与开源相关联感兴趣。正如我们在采访本报告的OSPO领导者时发现的，许多组织中的OSPO倡导者是高管，他们看到了开源带来的机会，也看到了某些情况下开源所带来的潜在威胁，他们的公司需要从战略层面解决好这些问题。通过进行这项研究，我们希望更好地理解为什么开源对公司具有战略意义，以及OSPO如何帮助组织积极管理开源给其特定业务所带来的机遇和威胁。

Hiro Fukuchi, senior alliance manager at Sony, gave an example of this executive interest: The OSPO organized a virtual event with an external expert that the company publicized, and many executives from both Japan and the United States attended.

索尼公司高级联盟经理Hiro Fukuchi举出了一个这种高管对开源有兴趣的案例：OSPO组织了一场虚拟活动，并邀请了一位外部专家参加，该公司对此进行了宣传后，来自日本和美国的许多高管都参加了这次活动。

Common threads in unique stories​

独特故事中的共同线索​

One of the challenges in conducting this research is that while there are certainly common threads, not only is each OSPO unique, but the stories behind their creation in the first place and how they contribute to the organization’s larger goals are also unique. So while we can certainly make some generalizations about why OSPOs matter, who tends to champion them, and how the business value of the OSPO tends to evolve, no two organizations are really alike.

进行这项研究的一个挑战是，虽然肯定存在共同的线索，但每个OSPO都是独特的，而且它们在第一次创建时的故事以及它们如何为组织的更大目标提供助力也都是独特的。因此，尽管我们肯定可以对OSPO的重要性、谁倾向于支持它们以及OSPO的业务价值如何发展做出一些概括，但真正的情况是没有两个组织是完全相同的。

“I was reading the Linux Foundation report that came out a couple of days ago, talking about the different OSPO structures,” said Christine Abernathy, senior director of open source at F5. “What I’ve learned is that they’re not all the same.” Just as OSPOs are all structured differently, there is a lot of diversity in their stated goals and the stories of how they came to be.1

“我正在阅读几天前发布的Linux基金会报告，该报告谈到了不同的OSPO结构”，F5的开源高级总监Christine Abernathy说。“我所学到的是，它们并不都是相同的。”正如OSPO结构都各不相同，它们的既定目标和它们如何成立的故事也存在很多差异。[^1]

[^1] https://www.linuxfoundation.org/research/a-deep-dive-into-open-source-program-offices

[^1] https://www.linuxfoundation.org/research/a-deep-dive-into-open-source-program-offices

Methodology​

研究方法​

For this report, we interviewed 12 OSPO leaders from Europe, Asia, and North America in a variety of industries, including two public universities. All the OSPO leaders interviewed are active in the TODO group. Here are the questions we started with:

为了撰写这份报告，我们采访了来自欧洲、亚洲和北美各行各业（包括两所公立大学）的12位OSPO领导者。所有接受采访的OSPO领导者都活跃在TODO小组中。以下是我们的起始问题：

• How many team members were on the OSPO at launch? How many are there now?

• 在启动OSPO时，团队成员有多少人？现在有多少人？

• What are the rough salary ranges for team members in the OSPO?

• OSPO团队成员的大致薪资范围是多少？

• What background do OSPO team members come from (e.g., engineering, legal, marketing)?

• OSPO团队成员是什么背景（例如：工程、法律、市场营销）？

• What’s your industry?

• 你在什么行业？

• Where is the OSPO located in the organization (e.g.,engineering, legal, marketing)?

• OSPO在组织中属于哪个部门（例如：工程、法律、市场营销）？

• Who was the initial champion for the OSPO?

• 谁是最初的OSPO倡导者？

• How did the champion(s) sell the OSPO internally? What did they say the value of the OSPO would be?

• 倡导者如何在内部推广OSPO？他们说OSPO的价值是什么？

• What outcomes or KPIs were set for the OSPO when it was initially started?

• 在最初启动OSPO时，设置了怎样的目标或KPI？

• How has your understanding of the value of an OSPO, and the specific outcome you expect from your OSPO, changed over time?

• 随着时间的推移，你对OSPO的价值的理解以及你期望从OSPO获得的具体结果发生了怎样的变化？

• Do you expect to get the same business value out of your OSPO in the next five years, or do you expect the value of the OSPO to change?

• 你是否期望在未来五年内从你的OSPO获得相同的商业价值，还是你期望OSPO的价值会发生变化？

• What metrics / measurements were collected to track your progress toward those outcomes? How have these metrics changed over time?

• 你收集了哪些指标/测量结果来跟踪你朝着这些结果的进展？这些指标随着时间的变化发生了怎样的改变？

• What KPIs does your OSPO work toward now? How do you evaluate the OSPO’s success?

• 你的OSPO现在正努力实现哪些KPI？你如何评估OSPO的成功？

Organization profiles and the relationship with open source​

组织概况及其与开源的关系​

An organization’s relationship with open source, and therefore the value that it will get from an OSPO, does seem to depend on what type of company it is. Organizations that are fundamentally technology companies—whose revenue comes from selling hardware or software—experience both different opportunities and threats from open source than organizations whose revenue comes from selling furniture.

组织与开源的关系，以及它因此将从OSPO获得的价值，似乎取决于它是什么类型的公司。本质上是技术公司的组织——其收入来自于销售硬件或软件——从开源中获得的机会和受到的威胁与收入来自于销售家具的组织有所不同。

Technology companies​

技术公司​

For perhaps obvious reasons, companies whose revenue comes from selling hardware or software see the most direct relationship between open source and their business, and the OSPO is a critical part of managing that relationship.

因为种种显而易见的原因，从销售硬件或软件中获得收益的公司最直接地感受到开源和它们业务之间的关系，OSPO是管理这种关系的关键部分。

“Pat Gelsinger, our CEO at the time,” said Ambiel, referring to who was one of the OSPO champions at VMware. “He’s the one who really leaned in and said, ‘We need to build an OPSO, we need to act with strategic intent.’”

“我们当时的CEO是Pat Gelsinger”，Ambiel指的是VMware的一个OSPO倡导者。“他是真正投入的人，他说，‘我们需要建立一个OSPO，我们需要根据战略意图来行动。’”

The need for technology companies to approach open source strategically is a core reason they all gave for forming an OSPO. And while there was often executive involvement, it would be wrong to characterize OSPOs as a purely top-down initiative or one pushed by management on an unwilling team of engineers. Often individual open source enthusiasts within the companies would push for a more formalized relationship with open source at the same time that executives pushed for a more strategic approach. Creating an OSPO was the obvious next step to meet both stakeholders’ needs.

技术公司需要从战略上对待开源是他们组建OSPO的核心原因。虽然经常有高管参与其中，但不能将OSPO视为纯粹的自上而下的计划，或者是一个由管理层强行推动不情愿参与的工程师形成的团队。通常，在公司内部有一些开源个人爱好者会推动更正式的开源关系，与此同时高管们则推行更具战略性的方法。创建OSPO显然是满足利益双方需求的下一步。

Open source wasn’t new at any of the companies we spoke with. They had all been using open source internally for years—and often had even open sourced internal projects in the past—but they were becoming increasingly aware of how open source developers can be part of the adoption curve for their own products, and as a result, how important a decent reputation in the open source ecosystem can be.

在我们采访的所有公司中，开源并不是什么新鲜事。它们一直在内部使用开源——并且通常甚至过去已经开源过内部项目——但它们越来越意识到，开源开发人员可以成为其产品使用曲线的一部分。因此，在开源生态系统中拥有良好的声誉非常重要。

“F5’s business has been moving from primarily hardware to software as a service,” said Abernathy. “A lot of the people who make purchasing decisions like to ‘try before they buy.’ These could be software developers who gravitate toward open source or even companies and governments who want to see your code in the open so that they can check the vulnerabilities.” So in the case of F5, open source is becoming important not just to how the company makes products but also to sales and marketing efforts. The OSPO is necessary to make sure F5 can leverage open source strategically and make informed decisions in situations where open source is relevant.

“F5的业务正在从主要的硬件转向软件即服务”，Abernathy说，“许多决定购买的人喜欢‘试用后再购买’。他们可能是倾向于开源的软件开发人员，甚至是希望在开放环境中查看代码以检查漏洞的公司和政府人员。” 因此，在F5这种情况下，开源不仅对公司的产品制造方式至关重要，也对销售和营销工作至关重要。为了确保F5能够战略性地利用开源，并在与开源相关的情况下做出明智的决策，OSPO是必要的。

Abernathy, who previously worked in the open source office at Facebook (now Meta), outlined the difference between open source at a place like Facebook and a company like F5. “At Facebook, open source is important,” she said. “But not, like, in terms of revenue. They’re not building an open source product .... So here, it’s easier to start thinking about the ROI of open source in a more direct and meaningful way.”

之前在Facebook（现在是Meta）的开源办公室工作的Abernathy概述了在Facebook和F5这样的公司中的开源之间的区别。“在Facebook，开源很重要”，她说，“但不是在收入方面。他们没有构建开源产品……所以在这里，更容易开始以更直接和有意义的方式考虑开源的投资回报。”

In the case of F5, a major trigger for creating the OSPO was the acquisition of open source company Nginx in 2019. The acquisition meant that the Nginx team both joined F5 and became another voice pushing for an OSPO, which also increased the strategic importance of open source.

在F5这种情况下，创建OSPO的一个主要诱因是在2019年收购了开源公司Nginx。这次收购意味着Nginx团队加入了F5，并成为另一个推动OSPO的声音，增加了开源的战略重要性。

For companies like Aiven, whose core business is tightly related to an open source project or projects, a formalized and strategic approach to open source is perhaps even more critical—but something they still often lack without an OSPO. Josep Prat, open source engineering director at Aiven, said that even given the strategic importance of open source, there was always tension between a need to ship product features and a need to contribute back to open source. When there was an expectation for engineers to contribute to open source in addition to all their other responsibilities, open source contributions would always take a back seat. Because of this tension, Aiven’s executive team decided very early on that there should be a dedicated OSPO whose sole job was to contribute to open source and manage the relationship with the open source communities.

对于Aiven这样核心业务与一个或多个开源项目紧密相关的公司来说，正式地、战略性地走向开源的途径可能更为关键，但通常在没有OSPO的情况下他们仍然缺少这个途径。Aiven的开源工程总监Josep Prat表示，尽管开源的战略重要性很高，但在推出产品功能和回馈开源这两个需求之间总是存在紧张关系。当期望工程师除了履行所有其他职责之外，还要为开源做出贡献时，开源贡献总是被放在次要位置。因此，Aiven的高管团队很早就决定应该有一个专门的OSPO，其唯一的工作就是为开源做出贡献，并管理与开源社区的关系。

In no way is it only open source companies or startups who feel like open source is of massive strategic importance. Chris Xie, head of open source strategy at Futurewei, the U.S.-based research and development arm of Huawei, stated that the company has been aware of both the threat and opportunities from open source for more than two decades, and the OSPO is part of how the company approaches both the threats and opportunities from open source.

并不仅仅是开源公司或初创企业认为开源具有重大战略意义。华为美国研发部门未来维（Futurewei）的开源战略负责人Chris Xie表示，20多年来，公司一直清楚开源带来的威胁和机遇，而OSPO是公司应对开源威胁和机遇的举措之一。

End user companies​

终端用户公司​

After the pure technology companies, there are the tech-forward companies who want to emulate many of what they see happening at pure technology companies, especially in terms of software development. These are companies that get their revenue from something other than selling hardware or software, and who wouldn’t say that building either is particularly core to their business. However, technology is critical to their business operations, and they share a desire to be perceived as a technology company as a means to attract top talent and create new revenue streams. One pattern that appears among these companies is that the OSPO and contributing to open source and releasing open source projects are all part of an effort to change the perception of the company as well as to improve the organization’s ability to deliver high-quality software, faster.

在纯技术公司之后，是那些希望效仿纯技术公司做法（尤其是在软件开发方面）的前沿技术企业。这些公司的收入不是来源于销售硬件或软件，而且他们也不会说构建硬件或软件是他们特别核心的业务。然而，技术对他们的业务运营至关重要，他们希望被视为技术公司，以吸引顶尖人才和创造新的收入来源。这些公司之间出现的一个模式是，OSPO、为开源做贡献和发布开源项目都是为改变公司形象以及提升组织能够更快地交付高质量软件的能力而做出的努力的一部分。

“Spotify has been using and creating open source since the very beginning, but at the same time, we didn’t approach it in a strategic way or consider how it created value for the company,” said Per Ploug, OSPO lead at Spotify. “It is critical for us that open source work is elevated to the same level as internal work, so we consider why we do it and how it brings value, so we ensure our engineers invest their time in projects which have impact.”

“从一开始起，Spotify就一直在使用和创建开源软件，但同时，我们并没有从战略的角度看待它，也没有考虑它如何为公司创造价值，”Spotify的OSPO负责人Per Ploug表示，“对我们来说，将开源工作提升到与内部工作同等的水平是至关重要的，因此我们会考虑为什么要这样做以及它如何带来价值，从而确保我们的工程师将时间投入到具有影响力的项目中。”

Read Spotify’s End User Journey Report as an example of how the company’s open source contributions have benefited themselves and projects they care about.

阅读Spotify的《最终用户旅程报告》，就可以了解该公司的开源贡献如何让他们自己和他们关心的项目受益。

In Spotify’s case, the most visible example of this new approach is Backstage, the company’s big bet on building a commercial offering on top of the successful open source project they donated to the CNCF in 2020. Spotify intends to make their investment into Backstage more self-sustainable and to ensure they stay engaged in the open source community long term. Right now, they have more than 40 people working on Backstage. We have very ambitious plans for Backstage, which include a commercial strategy that can both fund those ambitions and result in a better end product for everyone. The goal is to move open source from a cost center to a profit center.

在Spotify的案例中，这种新做法最显著的例子是Backstage，这是该公司在一个成功的开源项目基础上大胆建立的商业产品，而这个开源项目是由该公司在2020年捐赠给CNCF的。Spotify打算让他们对Backstage的投资更加可持续，并确保他们长期参与开源社区。目前，他们有40多人在开发Backstage。我们为Backstage制定了雄心勃勃的计划，其中包括一项商业策略，既可以为这些雄心提供资金，又能为每个人带来更好的最终产品。其目标是将开源从成本中心转变为利润中心。

“Wayfair is a tech company, and it takes the continuous work of many technologists across numerous disciplines to support our operations and growth,” said Natali Vlatko, global lead, OSPO at Wayfair. “In chats with our former CTO, I stressed that the easiest way for us to genuinely and authentically live that mindset is to build technical products. The surefire way to do that is to build open source and invest back into the open source ecosystem.”

“Wayfair是一家技术公司，需要许多不同领域的大量技术人员持续工作来支持我们的运营和增长，”Wayfair的OSPO全球负责人Natali Vlatko说，“在与我们的前任CTO交谈中，我强调过，对我们来说，真正、真实地实现这种理念的最简单方法就是构建技术产品。确保做到这一点的方法是构建开源并回馈开源生态系统。”

While becoming more tech-company-like is certainly a goal for these companies, it remains a means to an end. In some cases, the ends are clear, and it is often being able to hire the best talent as well as improve the quality of the engineering work in-house. Sometimes, though, even these companies start out believing that open source matters but are unable to articulate exactly why or how open source contributes to engineering or business objectives. The establishment of the OSPO helps them clarify how open source is already benefiting the company and determine how to get even more value from open source.

尽管变得更像技术公司肯定是这些公司的目标，但它仍然是达到目的的手段。在某些情况下，目的是明确的，通常是为了能够聘请最好的人才以及提高内部工程工作的质量。但有时，即使这些公司开始相信开源很重要，却无法清楚地阐明开源为什么会或如何为工程或业务目标提供助力。OSPO的建立有助于他们澄清开源是如何使公司受益的，并确定如何从开源中获得更多价值。

“They had a couple of open source projects that didn’t go anywhere,” said Duane O’Brien, director of open source at Indeed, about what was going on at the company before he joined. No one thought they were massive successes. “I don’t think they had a clear picture of what success meant for themselves,” he said.

“他们有一些开源项目没有得到推广，”Indeed的开源主管Duane O’Brien提到他加入之前公司的情况时说。没有人认为它们是非常成功的项目。他说：“我认为他们对自己的成功没有清晰的认识。”

Universities​

大学​

For universities, the value of open source and the related value of an OSPO to oversee the relationship between open source and researchers at the university is different from for-profit companies. However, they often see open source as a way to further the university’s mission—an opportunity that until very recently was largely missed. “They don’t really have a history of being engaged in open source,” said Carlos Maltzahn, director of the Center for Research in Open Source Software at the University of California Santa Cruz. As a matter of fact, he said, while there have been successful open source projects that have originated at a university, in many cases, it’s been a personal project of an individual student or researcher because most universities have little to no support for turning research products into high-impact open source contributions. That’s something he’d like to change and sees the OSPO as a way to support students and researchers who create open source projects and help more projects cross the chasm from a graduate student research project to something used in the wider ecosystem.

对于大学而言，开源的价值和OSPO管理开源和大学研究人员之间关系的相关价值与营利性公司不同。然而，他们通常把开源看作是进一步推进大学使命的一种方式——这是直到最近才被广泛认识到的机遇。“他们真的没有参与开源的历史”，加利福尼亚大学圣克鲁兹分校开源软件研究中心的主任Carlos Maltzahn说。事实上，他说，虽然有一些成功的开源项目起源于大学，但在许多情况下，这是学生或研究人员的个人项目，因为大多数大学几乎没有任何资源支持可以把研究成果转化为具有重大影响力的开源贡献。他希望改变这种情况，他将OSPO视为支持创建开源项目的学生和研究人员的方式，以帮助更多项目跨越鸿沟，从研究生的研究项目到更广泛的生态系统中的应用。

For Jesus Gonzalez-Barahona, professor at Universidad Rey Juan Carlos in Madrid and head of their open knowledge efforts, open source fits into the larger mission related to expanding access to knowledge. “In all of Europe, especially in Spain, universities are rediscovering this idea that we need to produce knowledge for society,” he said. Open source software, but also open access to research, is a way to fulfill this mission.

对于作为马德里的胡安·卡洛斯国王大学的教授和他们开放知识项目负责人的Jesus Gonzalez-Barahona而言，开源符合与扩大知识获取途径相关的更大使命。他说:“在整个欧洲，特别是在西班牙，大学正在重新发现我们需要为社会生产知识的这个想法。” 开源软件，以及研究的开放获取，是实现这一使命的方式。

What can OSPOs do for organizations?​

OSPO 可以为企业提供什么？​

The reasons behind starting an OSPO​

启动 OSPO 项目的理由与动机​

As we look at the value that an OSPO provides, there are two distinct phases. The first phase is the reason behind the OSPO’s creation. The second phase relates to the value that the organization sees as the OSPO matures. In this section, we will address the reasons organizations had for starting the OSPO in the first place and address how the value evolves in a later section. In nearly all cases, there were multiple reasons for starting an OSPO, just as there are multiple reasons for maintaining and expanding the OSPO as it matures. While there can be educational and social reasons for starting and maintaining an OSPO, this report focuses primarily on the business-related reasons behind having an OSPO, as we have focused the research primarily on for-profit organizations.

我们可以从两个不同的阶段，来审视OSPO所带来的价值，第一阶段是成立OSPO项目的原因，第二阶段是在OSPO成熟时，企业所看到的价值。在本节中，我们将首先讨论组织机构启动OSPO的原因，并在后面的部分中讨论价值如何演变。在多数情况下，启动OSPO的原因很复杂，正如随着OSPO成熟时，维持和扩展OSPO有多种原因一样。虽然启动和维护OSPO项目可能有教育和社会的原因，但本报告主要关注拥有OSPO项目背后的商业相关因素，因为我们的研究主要集中在营利性组织上。

Compliance​

合规性​

The most fundamental reason that organizations start an OSPO is because they are aware that their engineers are using open source, but they don’t know if they’re complying with the projects’ licenses. “Open source is unavoidable,” said Cornelius Schumacher, open source steward at DB Systel, the digital partner of Deutsche Bahn.

组织启动OSPO的最根本原因，是因为他们知道自己的工程师正在使用开源，但不确定他们是否遵守了项目的许可规则。 “开源是不可避免的，”德国铁路（Deutsche Bahn）数字合作伙伴DB Systel的开源项目管理员Cornelius Schumacher说。

“Open source is unavoidable”

“开源是不可避免的”

Given this reality, DB Systel needed to make an organized, centralized effort to ensure that the company complied with open source license requirements as well as managed potential security issues. “Risk management was not the only reason [for creating the OSPO], but certainly an important part of the decision,” he said. Because new open source projects are being downloaded and used every day, especially in a large organization, the OSPO’s role is less about conducting a compliance audit and more about putting technology and processes in place to ensure developers are aware of which licenses are or are not acceptable so that it’s easier to conduct compliance audits when necessary.

鉴于这一事实，DB Systel需要进行有组织的集中努力，以确保公司遵守开源许可要求，并管理潜在的安全问题。 “风险管理不是（创建 OSPO）的唯一原因，但肯定是决策的重要组成部分，”他说。 由于每天都有下载和使用新的开源项目，特别是在大型组织中，OSPO的作用与其说是进行合规性审查，不如说是实施技术和流程，以确保开发人员了解哪些许可证可以接受，哪些不可接受，以便在必要时更容易进行合规审查。

Building standardized processes around open source​

围绕开源构建标准化流程​

Related to the compliance issue, there was often also a need to move from an ad hoc way of using open source projects to a more standardized process. “Right now we have too much sprawl across our open source dependencies,” Ploug said. Part of the rationale for creating the OSPO was to streamline those dependencies to avoid having multiple projects that accomplish the same things.

与合规性问题相关，通常还需要从使用开源项目的临时方式转变为更标准化的流程。Ploug说：“现在我们的开源项目依赖规模过于庞大。” 创建OSPO的一部分原因是要简化这些依赖关系，以避免有多个项目执行相同的事情。

“Right now we have too much sprawl across our open source dependencies”

“现在我们的开源依赖规模过于庞大”

This would make many aspects of open source management easier, from license compliance auditing to security to investing strategically in open source projects that are important to the company’s core process.

这使开源项目管理在许多方面变得更加容易，从许可证的合规性审计到安全性，再到对公司核心流程至关重要的开源项目进行战略性投资。

In addition to building standardized processes around how engineers can use open source, there’s also a need to create standard processes about how engineers can contribute to open source projects or even create their own projects. In many organizations, these decisions had previously been made between an individual engineer and their manager, the result of which is a blend of approaches and a lack of certainty about what is acceptable.

除了围绕工程师如何使用开源项目以构建标准化流程之外，还需要创建标准流程，规范工程师如何为开源项目做出贡献甚至创建自己的项目。在许多组织中，以前只是由个别工程师和他们的经理之间做出决定就行，其结果是各种方法的混合，不确定最终会出现什么样的结果，以及这个结果是否可以接受。

Often part of an OSPO’s initial mandate is to create policies about both consuming and contributing to open source that are distributed throughout the engineering organization. The goal is to eliminate bottlenecks and confusion for engineers both in using and contributing back to open source.

OSPO的初始任务的一部分，通常是制定关于使用和贡献开源的政策，这些政策贯穿于整个工程团队中。其目标是消除工程师在使用和贡献开源方面的瓶颈和困惑。

Improving an organization’s reputation​

提升组织的声誉​

Improving an organization’s reputation in the open source ecosystem is an important motivator for many companies to create an OSPO.

提升组织在开源生态系统中的声誉是许多公司创建OSPO的重要动力。

“Our goal was to not only be more strategic and act with intent but also to elevate our reputation in the open source community— to be perceived as and accepted as a responsible, positive contributor to the open source ecosystem,” said Ambiel, of VMware.

“我们的目标不仅是让公司更具战略性，有目的地采取行动，还要提升我们在开源社区中的声誉，努力成为为开源生态系统负责任的、积极的贡献者。”VMware 的Ambiel说。

This is particularly important because if a company shows up to a project without any kind of pre-existing relationship and suddenly needs a new feature, or a bug fixed, that request won’t likely be a priority. Whereas if the company has been consistently investing in being part of the community, when they need something, the community may be more likely to prioritize it.

这一点尤其重要，因为如果一家公司之前没有参与过某个开源项目，就贸然使用它，并且突然需要一个新功能或修复一个bug，那么该请求可能不会作为开源项目的优先事项。 然而如果公司一直致力于成为该社区的一部分，那么当他们需要某些东西时，社区就可能会优先考虑。

“We need to employ people who have commit rights,” said Prat, of Aiven, referring to commit rights on the projects Aiven is built around. The only way to get that is through continual investment in the project, which is why Aiven created an OSPO to ensure the company, and the individuals it employs, are active in the community.

Aiven的Prat说：“我们需要雇用拥有提交权限的人”。他指的是围绕Aiven的项目的提交权。实现这一目标的唯一方法是通过对该项目的持续投资，这就是Aiven创建OSPO的原因，以确保公司及其雇用的个人在社区中活跃。

An OSPO is also a way to share knowledge about how to approach open source. To even be part of the conversation about what it means to use open source strategically, a company probably needs to establish an OSPO. According to Fukuchi, this knowledge sharing is a big part of the value Sony gets from its OSPO.

OSPO也是一种分享如何使用开源知识的方式。关于战略性地使用开源意味着什么，一家公司想要参与这类话题的讨论，需要建立自己的OSPO。根据Fukuchi的说法，这种知识共享的方式，是索尼从OSPO获得的价值的重要组成部分。

Who starts the OSPOs?

谁启动了OSPO项目

While we associate open source with a grassroots effort from individual engineers, the overwhelming trend in the interviews was the support for OSPOs at the executive level. In the case of large technology companies, like VMware and Futurewei, the OSPO champion was the CEO. “The CEO realized, oh, open source is not just about technology,” said Xie, from Futurewei. “It is about business. So they had open source moved into the Chief Strategy Office, which is where we’re now.”

Even in more grassroots initiatives, high-level buy-in is common. “I went to our former CTO with that idea myself,” said Vlatko, of Wayfair. “He was very supportive and said, ‘Yes, go ahead’ but also was very realistic in the sense of I cannot guide you, I’m not an expert. And I said, ‘That’s okay. I’m the expert.’” The obvious takeaway is that in many companies, a strategic relationship with open source is a high-level business concern, not just a technical problem that a group of engineers should solve.

虽然我们将开源项目与个别工程师的基层努力联系在一起，但采访中的一个重要趋势是管理层对OSPO的支持。如对VMware和Futurewei等大型科技公司而言，OSPO的冠军是CEO。 “CEO 意识到，开源不仅仅与技术有关，”来自Futurewei的Xie说。 “这是关于商业的。 因此他们将开源的管理转移到首席战略办公室，这就是我们现在所在的部门。” 即使在较为基层的倡议中，高层的支持也很常见。 Wayfair的Vlatko说：“我亲自向我们的前任首席技术官提出了这个想法” 。他非常支持并说，“好的，请继续吧，但现实是我不能指导你，因为我不是专家。" 我说：“没关系，我是专家”。显而易见的是，在许多公司里，与开源的战略关系是一个高级业务问题，而不仅仅是一组工程师应该解决的技术问题。

Improving an organization’s reputation is ultimately about being able to work productively with others in the industry as well as being part of the conversation about the direction of key projects. “Growing our reputation allows us to be in larger market conversations in the tech world, where we can then have an impact on products and solutions that are important to us,” said Vlatko, of Wayfair.

提高组织的声誉，最终是为了能够与业内其他人进行富有成效的合作，并成为关于关键项目方向的对话的参与者。Wayfair的Vlatko说：“不断提高我们的声誉，使我们能够在科技界参与更大规模的市场对话，这会对我们的重要的产品和解决方案产生影响。”

Expanding access to open knowledge​

扩大对开放知识的访问与获取​

For universities, an OSPO is a way to increase the impact of research and make it more accessible or useful to the wider community, as well as a way to improve students’ access to knowledge.

对于大学来说，OSPO是一种增加研究影响力的方式，使其更容易被广泛的社区所接受或使用，也是方便学生获取知识的一种方式。

“If you have students engaged with reproducing the results, there have already been studies that show that there is a huge, much better learning effect compared to just reading papers.”

“已经有研究表明，相比于仅仅阅读论文，让学生参与研究重现结果，学习效果要好得多。”

“It’s a huge difference whether a student can just read a paper, or they can look at the paper, then go on to an associated public git repository and have all the information there to reproduce the experiment,” said Maltzahn, of UC Santa Cruz. “If you have students engaged with reproducing the results, there have already been studies that show that there is a huge, much better learning effect compared to just reading papers.” This is important for student retention. Many students leave computer science prematurely because they get too frustrated by the steep learning curve of getting brittle experimental systems to work in computing environments even experts don’t fully understand. Incorporating the practicality of open source into how students learn and reducing the frustration they experience can help them be successful with computer science in the short term and software development in the long term.

加州大学圣克鲁斯分校的Maltzahn说：“相对于只让学生阅读一篇论文来说，如果不仅可以查看论文，还可以访问相关的公共git代码库，在那里获得更多信息来重现实验，这两种方式的结果差异很大” 。 “已经有研究表明，与仅仅阅读论文相比，让学生参与重现结果，学习效果要好得多”。这对于留住学生很重要。许多学生过早地离开了计算机科学，因为他们对陡峭的学习曲线感到非常沮丧，因为要在脆弱的实验环境中工作，而有时候这些环境连专家都不能完全理解。将开源的实用性融入学生的学习方式，减少他们的挫败感，可以帮助他们在短期内获得学习计算机科学的成功，在长期内获得软件开发的成功。

Improving development velocity​

加快开发的速度​

No one starts building a product by creating an operating system—nothing would ever get built.

没有人构建产品的第一步是创建操作系统，这样的话什么都做不出来。

“There are parts of our products that consist almost entirely of open source software, and that is a fundamental change in the long history of Ericsson,” said Georg Kunz, open source manager at Ericsson.

爱立信开源经理Georg Kunz说：“我们一些产品几乎完全由开源软件组成，这是爱立信悠久历史中的一个根本性变化。”

Not only does an OSPO bring order to how the company is consuming open source projects, but it can also provide guidance about which projects to use.

OSPO不仅可以规范公司使用开源项目的行为秩序，还会提供使用哪些项目的相关指导意见。

Improve access to talent​

改善获取人才的渠道​

There are two ways that open source improves access to talent. The most obvious way is by allowing organizations to hire higher caliber engineers, either by improving their general reputation in the open source world or even by creating their own open source projects and hiring from the pool of people who become active in those projects’ communities. “My boss and executive sponsor want to know that we have a healthy relationship with the open source community because we need to hire from it,” said O’Brien, of Indeed.

开源提供两种方式以改善企业对人才的获取。最显而易见的方式是，让企业雇用更高水平的工程师，比如提升企业在开源世界的声誉，或企业自己创建开源项目，从项目社区的活跃人群中招聘。Indeed的O'Brien说：“我的老板和公司赞助商，他们想知道我们与开源社区有着健康的关系，因为我们需要从中招聘人才” 。

“One of the biggest challenges we have— like other IT companies—is finding people to do all the software work”

“与其他IT公司一样，我们面临的最大挑战之一，是寻找人员来完成所有软件工作”

The other way an OSPO, and the strategic approach to open source that comes with it, can improve access to talent is by creating open source projects that solve an organization’s problems, particularly when solving problems that are common in many organizations, and solving them doesn’t provide any competitive advantage. “One of the biggest challenges we have—like other IT companies— is finding people to do all the software work,” said Schumacher, of DB Systel. If the company can create an open source project and collaborate with others in the industry, it can leverage tech talent without having to hire more people.

OSPO以及随之而来的开源战略方法为改善获取人才提供了另一种方式，创建开源项目来解决企业的问题，尤其是解决许多企业中常见的问题，解决这些问题并不会提供任何竞争优势。“与其他IT公司一样，我们面临的最大挑战之一，是寻找人员来完成所有软件工作，” DB Systel的Schumacher说。如果公司可以创建一个开源项目并与业内其他企业合作，就可以共享技术人才而无需雇用更多的人。

According to Schumacher, encouraging engineers to both use and contribute to open source is also one way to make them happy and less likely to leave. Similarly, encouraging more engineers to create open source projects and do more work in the open is a way to upskill the workforce you already have.

根据Schumacher的说法，鼓励工程师使用开源，并为开源做出贡献，也是让他们开心并不太可能离开公司的一种方式。同样，鼓励更多工程师创建开源项目并在开放环境中做更多工作，也是提高现有员工技能的一种方式。

“If we are showing our code externally, if we’re showing our technical prowess externally, there is a certain kind of element of needing to put your best foot forward,” said Vlatko, of Wayfair. She says that as Wayfair has encouraged people to work more in the open, they’ve seen code quality and general adherence to best practices improve.

Wayfair的Vlatko说：“如果我们向外展示我们的代码，向外展示我们的技术实力，那么就需要全力以赴。” 她说，由于Wayfair鼓励人们更多地参与开源工作，他们已经看到代码质量有所提高，也开始普遍遵守最佳实践原则。

Mitigating risks​

降低风险​

There are different risks from open source, and a formal OSPO can help mitigate all of them. One reason to formalize the OSPO structure is that one or two engineers are fulfilling an OSPO-like role but without the title or structure. This is what happened at Ericsson. “We basically had a one-person OSPO,” said Kunz. “He took care of everything, mostly focused on compliance, as many OSPOs start out doing. But obviously, that’s not sustainable. This guy should not get run over by a bus.”

开源会面临对不同的风险，正式的OSPO可以帮助降低这些风险。将OSPO组织结构正式化的原因之一是，一两个工程师正在履行类似OSPO的角色，但没有头衔或组织架构。这就是在爱立信发生的事情。“我们基本上只有一个人的OSPO，”Kunz 说。 “他负责一切，主要关注合规性，正如许多OSPO刚开始做的那样。但显然，这是不可持续的，万一这家伙被公共汽车撞倒了呢？”

Creating the OSPO formalizes what has often happened in an ad hoc way, reducing the reliance on tribal knowledge and lowering the risk that the departure of a single critical person could put the company at risk of legal issues, security incidents, or just being left out of the open source conversation.

创建OSPO以一种特别的方式，将经常发生的事情正式化了，减少了对部落知识的依赖，并降低了单个关键人物的离职使公司面临的法律问题、安全事件或被开源对话排除在外的风险。

Security​

安全性​

Ensuring a company is staying as secure as possible—and particularly understanding the software bill of materials going into both internal and external applications—was a recurrent theme about how the OSPO provides value.

确保公司尽可能保持安全，尤其是了解进入公司内部和外部的应用程序的软件材料清单，是关于OSPO如何提供价值的一个反复出现的主题。

“We cannot develop our own security framework without being in tune with what’s being developed collaboratively in the community”

“如果不与社区中协作开发的内容保持一致，我们就无法开发出自己的安全框架”

However, the examples were on a strategic, rather than strict implementation, level. “We cannot develop our own security framework without being in tune with what’s being developed collaboratively in the community,” said O’Brien, from Indeed. “Then you take that, and you apply that across every domain.”

然而，这些例子是在战略层面，而不是严格的实施层面。 “如果不与社区中协作开发的内容保持一致，我们就无法开发出自己的安全框架，”来自Indeed的 O'Brien 说。 “然后你会把它应用到每个领域。”

“By design, it’s a distributed problem,” said Kunz, of Ericsson, about software supply chain security. “It’s not the best engineer who will solve this problem, and you can’t solve this problem with an internal process.” It’s something that requires working with others throughout the industry and the open source ecosystem. An OSPO gives organizations a way to do that, even if the OSPO is not ultimately responsible for implementing security processes. They do share best practices and facilitate collaboration among open source communities, industry actors, foundations, and other stakeholders to lift all security boats.

爱立信的Kunz在谈到软件供应链安全时说：“从设计上讲，这是一个分布式问题”。 “不是由最好的工程师来解决这个问题，也无法通过内部流程来解决这个问题。”这需要与整个行业和开源生态系统中的其他人合作。OSPO为组织提供了一种方法来解决这一问题，即使OSPO最终并不负责实施安全流程。OSPO组织可以分享最佳实践，并促进开源社区、行业参与者、基金会和其他利益相关者之间的协作，以提升所有的安全性。

Security is also a reason why organizations want to be involved and respected community members in projects that are strategically important to them. This allows them to be part of the behind-the-scenes conversations not only about any new features in the pipeline but also to learn about any potential security issues first.

安全性也是组织希望参与，并尊重社区成员参与对其具有战略意义的项目的原因之一。 这使他们能够参与幕后对话，不仅涉及协作中的任何新功能，而且还可以提前了解任何潜在的安全问题。

Who’s in the OSPO?

OSPO 成员

The majority of OSPO leaders we spoke to had a software engineering background, but the work most of them do on a day-to-day basis is often not related to writing code. Instead, there are elements of internal communication, strategic planning, analysis, event planning, and collaboration with external organizations, which include open source communities, foundations, and other industry peers.

我们采访过的大多数OSPO领导者都有软件工程背景，但他们中的大多数人的日常工作通常与编写代码无关。取而代之的是内部沟通、战略规划、分析、活动规划以及与外部组织的合作，包括开源社区、基金会和其他行业同行。

In most cases, OSPO team members, and especially OSPO leaders, were senior engineers or at the management level. In companies with very structured salary bands, the OSPO leadership and team members would be toward the top of the salary ladder.

在大多数情况下，OSPO团队成员，尤其是OSPO领导人，都是高级工程师或管理层。在薪资范围非常结构化的公司中，OSPO领导层和团队成员将处于薪资阶梯的顶端。 考虑到OSPO启动时，对许多组织来说，遵守法律是非常重要的，但值得注意的是，大多数OSPO都可以获得OSPO内部或外部的法律专业知识。没有一个受访者认为，应该扩大法律的作用，或者他们需要额外的法律专业知识。

Given the importance of legal compliance for many organizations when the OSPO starts, it is notable that most OSPOs had access to legal expertise, either inside or outside the OSPO. However, none of the interviewees felt that there should be an expansion of the role of legal or that they needed additional legal expertise.

鉴于许多组织在开设开源计划办公室（OSPO）时對法律合规的重要性，值得注意的是大部分OSPO都能够获得法律专业知识，无论是OSPO内部还是外部。然而，采访对象中没有人认为需要扩大法律角色或获得额外的法律专业知识。

Sustainability​

可持续性​

Sometimes open source projects are abandoned, and that can be bad if you depend on them. “If we have a strong dependency on a single maintainer in Norway, then you should probably do something about the relationship with that person to make sure they stay engaged, either by ensuring that our developers spend time on the projects or by sending some money,” said Ploug, of Spotify. An OSPO both helps identify the risk—otherwise, the fact that it is a single maintainer could be unknown—and identify the best way to mitigate that risk.

开源项目有时也会被放弃，如果你依赖它们，那可能会很糟糕。”Spotify的Ploug说：“如果我们非常依赖挪威的某个项目维护人员，那么可能需要维持与他的关系，以确保他的参与，要么让我们的开发人员花时间维护项目，要么寄钱给他。OSPO既有助于识别风险（比如，你可能都不知道某个项目只有一个人维护）——也能识别减轻该风险的最佳方法。

This precise issue is what led O’Brien, at Indeed, to create the FOSS contributor fund, which is a way for Indeed to financially support maintainers of projects it depends on. The program’s goal is to support maintainers who are at high risk of burnout as a way to mitigate the risk that the project will end up abandoned.

正是这个问题，促使Indeed的O’Brien创建了FOSS 贡献者基金，这是Indeed为其所依赖项目的维护者提供财务支持的一种方式。该计划的目标是支持那些极有可能精疲力竭的项目维护人员，以减少项目最终被放弃的风险。

The OSPO journey​

OSPO之旅​

The first step for many OSPOs, before they can begin to address more strategic concerns, is what many OSPO leaders described as cleaning up the mess of open source, recovering from years of ad hoc approaches to consuming and contributing to open source.

许多OSPO在解决更战略性的问题之前，第一步是清理开源混乱局面，纠正多年来随意使用开源和为开源做贡献的方式，这是许多OSPO领导者所描述的问题。

“We’ve had 10 years of publishing projects without a longer-term plan or formalized ownership,” said Ploug, of Spotify. The OSPO is currently going through all the projects that the company has created, figuring out who owns them—and making sure that ownership is assigned to a team, not an individual. There is also a process of determining which projects can be shut down, which requires confirming that there is no internal use.

“10年来，我们一直在发布项目，但却没有更长期的计划或正式的所有权”，Spotify的Ploug说。OSPO目前正在审查公司创建的所有项目，弄清楚谁拥有它们——确保所有权归属于一个团队，而不是个人。还有一个确定哪些项目可以关闭的流程，这需要确认内部没有在使用这些项目。

Other work that OSPOs often tackle initially is finite and can, at some point, be finished, such as the initial question about which licenses can or cannot be used. Usually, the OSPO can work with the legal team to figure out what is or is not acceptable, but once there is a decision, it doesn’t need revisiting and becomes a matter of communicating to the entire organization what licenses are acceptable in which scenarios.

OSPO最初经常处理的其他工作是有限的，某些情况下可以处理好一些初始问题，比如哪些许可证可以使用、哪些不行。通常，OSPO可以与法务团队合作，确定哪些是可接受的、哪些不是，而一旦做出决定，就不需要再次讨论，而是变成了一个与整个组织沟通的问题，即在哪些场景中可以接受哪些许可证。

But what do organizations do once they have already organized their internal projects, developed frameworks for how to use and contribute to open source, and sufficiently addressed compliance?

但是，当组织已经组织好了其内部项目，制定了如何使用开源和为开源做贡献的框架，并能充分解决合规问题时，它们该做什么呢？

Overcoming internal obstacles: Culture and education​

克服内部障碍：文化和教育​

Once an OSPO has developed policies around using and contributing to open source, a common next step is to spread the word internally. This is not a trivial consideration, especially given that many OSPOs are only a handful of people in an organization with thousands or even tens of thousands of engineers. This internal communication role of the OSPO also goes back to one trigger for creating the OSPO in the first place: a large number of queries coming from software engineers about how to relate to open source.

一旦一个OSPO制定了关于使用开源和为开源做贡献的政策，通常要做的下一步是在内部传播这个信息。这不是容易考虑的事，特别是在许多OSPO只有寥寥数人而他们所处的组织有数千甚至数万名工程师的情况下。OSPO的这种内部沟通角色也可以追溯到最初创建OSPO的一个诱因：来自软件工程师关于如何了解开源的大量咨询。

“When we are talking about contributing to open source software, in the beginning, the question we started with was, ‘are we even allowed to do that?’” said Schumacher, from DB Systel. People just did not know what parameters there were about using, and especially around contributing back to, open source. If one of the first-level goals of an OSPO is to figure out what those parameters are, the secondary goal is to make sure that there is a dissemination of knowledge throughout the organization.

“当我们谈论为开源软件做贡献时，一开始我们要解决的问题是：‘我们是否被允许这样做？’”来自DB Systel的Schumacher说。人们不知道使用开源软件的规范是什么，特别是关于向开源软件做贡献的规范。如果OSPO的第一层目标是确定这些规范，那么第二层目标就是确保在整个组织中传播这些知识。

According to Vlatko, from Wayfair, after setting up an organizational structure in GitHub and figuring out the license types that were acceptable for use, there was an educational campaign to ensure that information was widely known across the organization.

据Wayfair的Vlatko所说，他们在GitHub上设置组织结构并确定了可接受使用的许可证类型后，进行了一项教育活动，以确保该信息在组织内得到广泛传播。

But aside from preemptively answering engineers’ questions about interacting with open source, there is an even larger shift in how people think about open source. “The question has changed a bit from whether or not to do open source to how to do open source strategically,” said Schumacher. “What I’m seeing now, after some time, is that we are looking more into the strategic part of how you can leverage open source, for example, in collaborations with external companies.”

但是除了预先回答工程师有关与开源互动的问题之外，人们对开源的看法发生了更大的变化。“问题已经从是否做开源转变为如何战略性地做开源”，Schumacher说，“在一段时间后，我现在看到的是我们正在更深入地研究如何战略性地利用开源，例如与外部公司合作。”

Even though open source is everywhere, not all organizations have the culture around open source that they want, and opinions about open source are far from universally positive. Some people, from individual contributors to managers and executives, have had bad experiences with open source software or open source communities at some point in their careers, and convincing those people to embrace open source is part of the OSPO’s challenge.

尽管开源无处不在，但并非所有组织都拥有他们想要的开源文化，对于开源的看法也远非普遍积极。有些人，无论是个人贡献者、经理还是高管，在职业生涯的某个阶段都曾经历过与开源软件或开源社区相关的负面经历，说服这些人拥抱开源是OSPO面临的挑战之一。

“We want to create a cultural mind shift and grow the community around open source,” said Abernathy, at F5. This will be a major driver in helping the company play a larger role in the open source ecosystem. In a real sense, OSPOs seek to improve open source’s reputation within the organization just as much as the organization’s reputation within the open source ecosystem.

“我们希望促进文化思维的转变并扩大开源社区”，F5公司的Abernathy说。这将成为帮助公司在开源生态系统中发挥更大作用的重要驱动力。从实质上讲，OSPO试图提升开源在组织内部的声誉，这跟提升组织在开源生态系统内部的声誉一样重要。

A strategic relationship with open source​

与开源的战略关系​

There is no doubt that the strategic importance of open source varies depending on the type of company. For a company like Futurewei, open source alternatives to the “black box” solutions it sells are a fundamental threat to the company’s ability to generate revenue. “And how you deal with this as a business, not a technology decision,” said Xie.

毫无疑问，开源的战略重要性因公司类型而异。对于像Futurewei这样的公司来说，开源解决方案可以代替其销售的“黑盒”解决方案，这是一个根本性的威胁，可能影响其创收能力。“怎样解决这个问题是一项商业决策，而不是技术决策”，谢先生说。

In a similar vein, VMware’s Ambiel stated, “At the end of the day, what does VMware do? We sell software. So, our open source investments need to align with our business aspirations.” The OSPO is there to make sure that happens.

同样的，VMware的Ambiel表示，“归根结底，VMware是做什么的？我们销售软件。因此，我们的开源投资需要与我们的业务愿景保持一致。” OSPO的作用就是确保这一点。

At Spotify, there’s an ambition to spin out the company’s two most successful open source projects into separate business units that will launch commercial products based on the projects, turning the project from a cost center to a profit center. Part of the OSPO’s role at Spotify is to help identify and launch new projects that could potentially become new business units and support them in a way that increases the likelihood of success. THE BUSINESS VALUE OF THE OSPO 17

在Spotify，他们希望将公司最成功的两个开源项目分拆成单独的业务单元，基于这些项目推出商业产品，将项目从成本中心变成利润中心。OSPO在Spotify的角色之一是帮助识别和推出可能成为新业务单元的新项目，并以增加成功可能性的方式支持它们。

The different hats of an OSPO​

开源办公室的不同角色​

The Counselor​

顾问​

Sometimes a strategic approach just means stepping back and taking the time to think through some of the hard questions about what type of engagement model is right for any particular project or how involved the organization should be in each project. There is also the question of when it makes sense to contribute to an existing project versus creating a new project. An OSPO that is having these strategy-level conversations will be able to provide guidelines to engineers so that engineers do not have to consider the business implications of different open source engagement models every time they try to solve a problem.

战略方法有时候仅仅意味着后退一步，花时间思考那些关于特定项目哪种参与模式是对的或者组织应该在每个项目中参与到什么程度等困难的问题。这在考虑是向已经存在的项目贡献还是新建一个项目时也是一个问题。有战略层对话的开源办公室能够为工程师提供指点，以便工程师每次尝试解决问题时不需考虑不同开源参与模式对业务的影响。

The Facilitator​

促进者​

The OSPO also plays a sort of translation role between engineering teams and business interests regarding open source. “How do we ensure that engineers keep having the time to do this, that they can actually prove that it makes sense from a business perspective?” said Abernathy, about how communicating the business value of open source is part of the OSPO’s job at F5. These strategic questions are not always top of mind when the OSPO is first created, especially at less tech-focused companies where open source doesn’t present a direct threat to revenue. But even those companies eventually see that using open source well is about more than mitigating license compliance risk. “Now we are also looking into more cases where it makes sense from a strategic point of view to leverage open source for our own projects or in collaborations with other parties,” said Schumacher, even though he does not think these strategic concerns were as important when the OSPO was initially set up.

开源办公室还在开源相关的工程团队和业务利益之间扮演着一种翻译角色。“我们怎么确保工程师有足够的时间做这些，他们实际上可以从商业的角度证明好处是什么” Abernathy说，如何传达开源的商业价值是 F5 开源办公室工作的一部分。这些开源战略问题并不总是在开源办公室创建时就要考虑的首要问题，特别是开源对收入没有直接威胁的技术不是重心的公司。但是，即使是这些公司最终也会看到良好地使用开源也不仅仅是为了缓和许可证合规风险。“现在我们在更多的情况下研究利用开源为我们自己的项目或者与他方合作的战略意义。” Schumacher 说，即使他不认为这些战略考虑在设立开源办公室时就很重要。

Ensuring OSPO sustainability​

确保开源办公室的可持续性​

Continuity is an ongoing challenge for organizations as they adapt to changes in the business, the competitive landscape, and the larger technological ecosystem. According to “A Deep Dive on OSPOs,” a Linux Foundation whitepaper, OSPOs need to establish a clear, easy reporting process and ensure lines of communication stay open with all the stakeholders. This is important for maintaining internal support for the OSPO, which is critical to ensuring that the organization continues to follow its agreed-upon open source strategy and is able to work sustainability on open source projects and priorities.¹

连续性对组织来说是持续的挑战，因为它们要适应业务，竞争环境和更大的技术生态。根据 Linux 基金会的白皮书《深入开源办公室》，开源办公室需要建立清晰、简单的汇报流程，并确保与所有利益相关方保持沟通渠道畅通。维护开源办公室内部支持对于确保组织继续按照其商定的开源战略和能够在开源项目和优先事项上至关重要。¹

Measuring an OSPO’s success​

衡量 OSPO 的成功​

“When I interviewed for this role, I asked how we’re going to measure success,” Prat said. “They said ‘we don’t know yet.’”

“在我面试这个职位时，我问到我们如何衡量成功”，Prat 说，“他们说‘我们还不知道。’”

This pattern of uncertainty came up often in interviews—that an executive leader championed an OSPO with the understanding that open source is important and that the company needed to take practical, tactical steps to ensure compliance and security, while also figuring out how to engage strategically along the way. In many cases, they did not really know what that looked like, and part of the OSPO’s initial mandate was to figure out what success would look like and how to measure their own progress.

这种不确定的状况在访谈中经常出现 —— 一位高层领导支持 OSPO 并且明白，开源很重要，公司需要采取切实可行的战术行动来确保合规性和安全性，同时也要弄清楚如何在这一过程中进行战略性的参与。在许多情况下，他们真的不知道成功是什么样的，而 OSPO 最初的任务之一是弄清楚成功时的样子以及如何衡量自己的进展。

There were some metrics interviewees talked about using to measure engagement with open source but then ultimately rejected. Pull requests (PRs), for example, are too diverse to provide meaningful information—a PR could be a typo fix or a major feature. Measuring hours worked on open source also did not seem right because it does not measure impact.

受访者提到了一些衡量开源参与度的指标，但最终没有采纳。例如，提交请求（PR）多种多样，无法提供有意义的信息 —— 一个PR可能是一个拼写错误修复或主要功能。衡量开源工作时间似乎也不正确，因为它不能衡量影响。

Deciding what to measure is fairly high-stakes and strategic, part of why the OSPO leaders themselves took on the task of figuring it out. Human nature is to optimize for the things we know we’re being evaluated on, and interviewees talked about the importance of choosing metrics that will encourage engineers throughout the organization to be better open source citizens. Often the metrics applied initially changed as the OSPO matured. For example, at Indeed, there was an initial focus on growing contributors and measuring how many people make open source contributions in any given quarter. After a while, however, they started focusing on growing what they called “sustaining contributors,” who are people that make repeated contributions to the same project—to projects that are strategically important to Indeed. This is because it is easier for maintainers to get five contributions from one person than five contributions from five people, and the larger goal is to make things easier for maintainers.

决定衡量什么是相当高风险的和战略性的，这也是 OSPO 领导者自己承担这项任务的原因之一。人类的本性是针对我们所知道的正在评估的东西进行优化，受访者谈到了选择指标的重要性，这些指标将鼓励整个组织的工程师成为更好的开源世界公民。通常，最初应用的指标会随着 OSPO 的成熟而发生变化。例如，在 Indeed，最初的重点是不断增长的贡献者，以及衡量在任意一个季度有多少人做出开源贡献。然而，过了一段时间，他们开始专注于培养他们所说的“持续贡献者”，即那些对同一项目做出持续贡献的人，这些项目对 Indeed 具有重要的战略意义。这是因为维护人员从1个人那里获得5个贡献，比从5个人那里获得5个贡献更容易，更大的目标是让维护人员更轻松。

Oftentimes, it is simply difficult to quantify what matters about an OSPO’s performance in numbers. “My personal measure of success is to continue to elevate VMware’s reputation and leadership in open source,” said Ambiel. “And the measures of success I have for that are fairly qualitative.” She talked about perception studies, share of voice, and times when the community organically shared VMware’s story or contributions. Individually, those metrics might be squishy, but together they “add up to a body of work that says we’re making progress.”

通常情况下，很难用数字来量化 OSPO 的绩效。Ambiel 说：“我个人衡量成功的标准是继续提升 VMware 在开源领域的声誉和领导力。”，“我对成功的衡量标准是相当定性的。”她谈到了认知研究、声量份额，以及社区有机地分享 VMware 的故事或贡献的次数。单独来看这些指标可能不太可靠，但综合起来看，它们“加起来构成了整体的工作，表明我们正在取得进展。”

Common OSPO KPIs​

常见的 OSPO KPI​

So, what did the OSPOs end up measuring once they had time to consider what metrics encouraged good behavior and were truly aligned with the OSPO’s goals?

那么，一旦 OSPO 有时间考虑哪些指标鼓励了正向的行为并真正符合 OSPO 的目标，他们最终会衡量什么呢？

Sustaining contributors: The number of people in the organization who make regular, repeat contributions to the same project, assuming those projects are strategically important to the organization

持续贡献者： 则指组织中定期、多次为同一项目做出贡献的人数，假设这些项目对组织具有战略意义。

The success of projects released: The external participation and impact of projects the organization releases. O’Brien gave the example of a project Indeed released that the CNCF Sandbox accepted as a measure of huge success. Maltzahn, from UC Santa Cruz, mentioned the importance of measuring not just the projects released, but how successful they became at attracting a broader following outside the university and whether they would be viable long term without the continuing involvement of the university.

已发布项目的成功： 组织已发布项目的外部参与度和影响。O’Brien 举了一个例子， Indeed 发布的一个项目被 CNCF Sandbox 接受了，这就可以作为一个巨大成功的衡量标准。来自加州大学圣克鲁斯分校的 Maltzahn 提到，不仅要衡量发布的项目的重要性，还要衡量这些项目在吸引大学之外更广泛的追随者方面取得了多大的成功，以及如果没有大学的持续参与，这些项目是否长期发展下去。

The reputation of open source internally: Do people even know the OSPO exists? Do they know what the parameters the OSPO has established around how to consume open source, contribute to existing projects, and / or create a new project? Many companies track these internal awareness metrics, as a large part of their role is internal communications.

开源的内部声誉： 人们真的知道 OSPO 的存在吗？他们知道 OSPO 围绕如何使用开源、为现有项目做出贡献和/或创建新项目制定了哪些指标吗？许多公司跟踪这些内部认知指标，因为其很大一部分职责是内部沟通。

The reputation of the organization among the open source community: For the many companies who established an OSPO as a way to improve the organization’s reputation among the larger open source ecosystem, they often track reputation and awareness metrics, such as social media mentions, the number of job applicants who mention the company’s involvement in open source, or the number of employees speaking at open source-related conferences. Some do surveys of developers run by third parties and ask reputation-related questions.

该组织在开源社区的声誉： 对于许多建立 OSPO 以提高该组织在更大的开源生态中的声誉的公司来说，他们通常会跟踪声誉和知名度指标，如社交媒体提及、提及该公司参与开源的求职者数量，或者在开源相关会议上发言的员工人数。一些人通过第三方对开发者进行调研，并提出与声誉相关的问题。

Reducing friction for developers: In addition to tracking how aware the internal team is of policies, OSPOs often track how much friction they create for those developers. If a human needs to approve a request to contribute, for example, how long does it take?

减少开发人员的摩擦： 除了跟踪内部团队对政策的了解程度外，OSPO 还经常跟踪他们给开发人员制造了多少摩擦。例如，如果一个人申请批准贡献，需要多长时间完成？

**Tracking project health: **Tracking the percentage of projects the organization depends on that are “healthy.” Determining a project’s health would often involve tracking the number of active contributors, the frequency of commits, the number of maintainers, and other metrics, including having users and contributors from many different organizations.

跟踪项目健康状况： 跟踪组织所依赖的“健康”项目的百分比。确定项目的健康状况通常包括跟踪活跃贡献者的数量、提交频率、维护者的数量和其他指标，包括来自许多不同组织的用户和贡献者。

External collaboration: How many partners is the OSPO actively collaborating with? This can take the form of participation in joint ventures or sponsored programs, particularly among universities, or being actively engaged in open source foundations and industry groups. Other examples of active, external collaborations include participation in conferences as speakers, delegates, or sponsors, as well as engaging in the research development process, as many of the interviewees in this report have demonstrated.

外部合作： OSPO 与多少合作伙伴积极合作？这可以采取参与联合投资或赞助项目的形式，特别是在高校之间，也可以积极参与开源基金会和行业团体。积极的外部合作的其他例子包括作为发言人、代表或赞助商参加会议，以及参与研发过程，就像本报告中的许多受访者所展示的那样。

There are also joint projects to determine the best metrics to track: The TODO Group and CHAOSS created the OSPO metrics working group ² to help develop better metrics for OSPOs to measure their own success.

也有一些联合项目来确定要跟踪的最佳指标： TODO 小组和 CHAOSS 创建了 OSPO 指标工作组²，以帮助为 OSPO 制定更好的指标，衡量其自身的成功。

The KPI search​

KPI 探索​

Many OSPO leaders stressed that talking about quantitative metrics is not only difficult but can lead to misleading conclusions. Many OSPOs just do not have very measurable goals. “Our goals for the team are relatively high level,” said Kunz, from Ericsson.

许多 OSPO 负责人强调，谈论定量指标不仅困难，而且可能导致误导性结论。许多 OSPO 没有非常量化的目标。爱立信的 Kunz 表示：“我们团队的目标相对较高。”

“I would say we step away from numbers,” said Ambiel, from VMware. “Numbers don’t tell the story and can be misleading in open source.”

VMware 的 Ambiel 表示：“我认为我们要远离数字”，“数字并不能说明问题，而且在开源中可能会产生误导。”

Part of the danger in focusing on numbers, Ambiel said, is that the ultimate goal of the OSPO is to push the company to be a better citizen in the open source ecosystem—and being a good citizen is never-ending. “There isn’t a metric where you can say, okay, I’m done. Check that off,” she said. “You can always lean in; you’re always trying to be better.”

Ambiel 说，关注数字的部分危险在于，OSPO 的最终目标是推动公司在开源生态中成为一个更好的公民，成为一个好公民是没有尽头的。她说：“没有一个指标可以让你说，好吧，我搞定了，检查一下”，“你总是可以更进一步，你总是可以努力变得更好。”

There can also be problems with timespans. “Every company tries to measure things in three-month timespans,” said Prat, from Aiven. But an open source maintainer does not care that you need to meet your quarterly goals for accepted contributions; they do not arrange open source projects around quarterly goals or fiscal years.

时间跨度也可能是个问题。“每家公司都试图在三个月的时间跨度内进行衡量，”来自 Aiven 的 Prat 说。但是一个开源维护者并不关心你是否需要达到接受贡献的季度目标；他们不会围绕季度目标或财年安排来计划开源项目。

There was also a sense that OSPOs are continually evolving and, therefore, the right KPIs to track are also constantly evolving. “We are now searching for that good KPI because our activities are changing, and the status quo has changed, so we need to adjust KPIs,” Fukuchi said.

还有一种感觉是，OSPO 正在不断发展，因此，所要跟踪的合适的 KPI 也在不断发展。Fukuchi 说：“我们现在正寻找好的 KPI，因为我们的活动正在变化，现状也发生了变化，所以我们需要调整 KPI。”

For further reading about OSPO Maturity models, check out these resources here:

OSPO Maturity Model (Whitepaper)

OSPO Maturity Model (Repo)

OSPO Maturity Model (Open Source Blog Article Explained)

进一步了解 OSPO 成熟度模型，请参考以下资源：

OSPO 成熟度模型 (白皮书)

OSPO 成熟度模型 (仓库)

OSPO 成熟度模型 (开源博客文章解读)

Conclusion​

结论​

What’s coming in the future?​

展望未来​

On one point, there was absolute agreement among all interviewees: OPSOs will continue to evolve in the future. In particular, the more established an OPSO is, the more it can think strategically and help the entire organization develop a more strategic, thoughtful approach to open source. What they do not need or expect is more focus on legal and compliance—that is a checkbox that most interviewees feel is more like the bare minimum and that they have got it covered already.

有一点是所有受访者都达成了绝对的一致：OSPO 未来将会持续发展。特别是，OSPO 越是成熟，就越能进行战略思考，并帮助整个组织制定一种更具战略意义、更深思熟虑的开源策略。他们并不需要也不期望更多地关注法律合规性，这是一种检查项，但大多数受访者认为这更像是一个最低要求，并且他们已经覆盖了这一方面。

Several interviewees spoke about expecting OSPOs to play a larger role in influencing which technologies and projects their companies adopt in the future. There was also a hope that OSPOs will be able to dive deeper into the dependency chain to better understand which projects they depend on, even if it is two or three levels down, and track the health of those projects (and contribute where necessary). Others talked about building out automated platforms to handle some of the tasks that are now manual, like approving a request to contribute to a project.

几位受访者谈到，希望 OSPO 在影响其公司未来采用的技术和项目方面发挥更大的作用。也有人希望 OSPO 能够更深入地研究依赖关系链，更好地了解他们所依赖的项目，哪怕只是两三级依赖的项目，并跟踪这些项目的健康状况（以及在必要时做出贡献）。其他人谈到了构建自动化平台来处理一些当前手动执行的任务，比如批准贡献项目的申请。

“The OSPO needs to work on a strategy, set it up, and then bring the R&D folks on board to do the right thing,” said Kunz. The OSPO, Kunz and many others believe, should be working on vision and strategy and making sure they’re working with the right people throughout the company to turn that vision into reality.

Kunz 说：“OSPO 需要基于一项战略来开展工作，建立战略并让研发人员参与进来做正确的事情。”。Kunz 及其他许多人认为，OSPO 应该致力于愿景和战略，并确保他们与整个公司的合适人选合作，将愿景变为现实。

Ultimately, part of the OSPO’s role is to have these conversations about open source, OSPOs, and the business value it delivers. That is part of open source evangelism, which is already part of many OSPOs’ mission. “I think an important part of that is really making people understand the business value,” said Schumacher.

归根结底，OSPO 的部分职责是就开源、OSPO 及其提供的商业价值进行对话。这是开源布道的一部分，也已经是许多 OSPO 使命的一部分。Schumacher 说：“我认为这其中很重要的一个部分是让人们真正理解商业价值。”。

That is not always easy because open source does not always translate neatly to the things business leaders think about, but it’s important. Business leaders often know that open source is important, but they need an OSPO to help them understand why and then use that knowledge to get even more value out of open source.

这通常并不容易，因为开源并不总是能很好地转化为商业领袖的所思所想，但这很重要。商业领袖通常知道开源很重要，但他们需要一个 OSPO 来帮助他们理解为什么，然后利用这些知识从开源中获得更多价值。

Future research​

后续研究​

In this report, we have focused on the value of the OSPO in private institutions. One area of future research we would like to explore is how OSPOs provide value to governments, from municipalities to supra-national organizations. We would also like to do research that explores the role and the value of OSPOs exclusively at institutions of higher learning. If you have any thoughts about either subject or would like to share your insights, contact us at research@linuxfoundation.org.

本报告中，我们重点关注了 OSPO 在私营机构中的价值。我们未来想探索的研究领域之一是 OSPO 如何为政府提供价值，从市政部门到超大型国家组织。我们还想做一些研究，专门探讨 OSPO 在高等院校的作用和价值。如果您对这两个主题有任何想法或想分享您的见解，请联系我们 research@linuxfoundation.org 。

About the authors​

关于作者​

Emily Omier helps open source startups accelerate community and revenue growth with better positioning and messaging for both open source projects and commercial offerings.

Emily Omier通过为开源项目和商业产品提供更好的定位和信息，帮助开源初创公司加速社区和收入增长。

Ana Jiménez Santamaría is the OSPO Program Manager at the TODO Group, a Linux Foundation project that brings together OSPO practitioners to collaborate on developing best practices, tools, and educational resources to drive successful Open Source Offices within organizations. Ana has a strong background in Open Source, DevRel, Community Health Analytics and InnerSource. She previously worked at Bitergia, a software development analytics firm, where she completed her MSc in Data Science. Her thesis focused on measuring the success of Developer Relations in Open Source communities. For more details on her thesis work, check out: https:// anajimenezsantamaria.gitlab.io/. With her commitment to open source education, Ana is dedicated to helping organizations and individuals build healthy connections in the Open Source ecosystem. You can find Ana on Mastodon, LinkedIn, and Youtube.

Ana Jiménez Santamaría是TODO Group的OSPO项目经理，TODO Group是一个Linux基金会项目，将OSPO从业者聚集在一起，共同开发最佳实践、工具和教育资源，以推动在组织内建设一个成功的开源办公室。Ana在开源、技术布道、社区健康分析和内部开源方面有着丰富的背景。她之前在软件开发分析公司Bitergia工作，在那里完成了数据科学硕士学位。她的论文专注于衡量开源社区中开发者关系。有关她的论文工作的更多详细信息，请访问：https://anajimenezsantamaria.gitlab.io/ 。Ana致力于开源教育，致力于帮助组织和个人在开源生态系统中建立健康的联系。你可以在Mastodon、领英和Youtube上找到Ana。

Chris Aniszczyk is an open source technologist with a passion for building a better world through open collaboration. He’s currently a CTO at the Linux Foundation focused on developer experience and running the Cloud Native Computing Foundation (CNCF). In a previous life, he created the Twitter open source program and led their open source efforts. Also, for many years he served on the Eclipse Foundation’s Board of Directors representing the maintainer community and the Java Community Process (JCP) Executive Committee. Furthermore, he’s a partner at Capital Factory where he focuses on mentoring, advising and investing in open source and infrastructure focused startups.

Chris Aniszczyk是一位开源技术专家，他热衷于通过开放合作建设一个更美好的世界。他目前是Linux基金会的首席技术官，专注于开发人员经验和云原生计算基金会（CNCF）的运营。在之前的职业生涯中，他创建了Twitter开源项目，并领导了他们的开源工作。此外，他代表维护者社区和Java社区过程（JCP）执行委员会，在Eclipse基金会董事会任职多年。此外，他还是Capital Factory的合伙人，专注于指导、建议和投资开源和基础设施创业公司。

twitter.com/linuxfoundation

facebook.com/TheLinuxFoundation

linkedin.com/company/the-linux-foundation

youtube.com/user/TheLinuxFoundation

twitter.com/todogroup

github.com/todogroup

linkedin.com/company/todo-group

mastodon.world/@todogroup

TODO is a global community of OSPO practitioners from diverse sectors and regions. Its General Members include representatives from 90+ organizations with extensive experience in running successful open source programs. TODO aims to foster collaboration on best practices, tools, and guidance for managing open source projects through OSPOs.

TODO是一个由来自不同部门和地区的OSPO从业者组成的全球社区。其全体成员包括来自90多个组织的代表，他们在成功运行开源项目方面具有丰富的经验。TODO旨在促进通过OSPO管理开源项目的最佳实践、工具和指导方面的合作。

By sharing experiences and developing common tooling, TODO seeks to improve OSPO adoption and education. Explore TODO’s ongoing initiatives like OSPOlogy and active working groups, and check out the OSPO landscape, OSPO 101 training modules, and TODO Guides to learn more.

通过分享经验和开发通用工具，TODO寻求改善OSPO的采用和教育情况。搜索TODO正在进行的行动，如OSPOlogy和活跃的工作组，并查看OSPO全景图、OSPO 101培训模块和TODO指南以了解更多信息。

Founded in 2021, Linux Foundation Research explores the growing scale of open source collaboration, providing insight into emerging technology trends, best practices, and the global impact of open source projects. Through leveraging project databases and networks, and a commitment to best practices in quantitative and qualitative methodologies, Linux Foundation Research is creating the go-to repository for open source insights for the benefit of organizations the world over.

Linux基金会研究院成立于2021年，已在探究开源合作规模的日益扩大，并提供了对新兴技术趋势、最佳实践以及开源项目全球影响的见解。通过利用项目数据库和网络，以及对定量和定性方法论最佳实践的承诺，Linux基金会研究院正在为世界各地的组织创建开源见解的首选存储库。

This report is licensed under the Creative Commons Attribution-NoDerivatives 4.0 International Public License.

本报告根据CC BY-ND 4.0 License许可证获得许可。

To reference this work, please cite as follows: Emily Omier, Chris Aniszczyk, and Ana Jiménez Santamaría, “The Business Value of the OSPO: An Exploration of Why Organizations Create, Sustain, and Expand Open Source Program Offices (OSPOs),” forewords by Georg Kunz, Leslie Hawthorn, and Kimberly Craven, The Linux Foundation, March 2023.

引用本文时请注明以下内容：Emily Omier、Chris Aniszczyk和Ana Jiménez Santamaría，“OSPO的商业价值：探索组织为什么创建、维持和扩展开源项目办公室（OSPO）”，Linux基金会，2023年3月Georg Kunz、Leslie Hawthorn和Kimberly Craven 所著的前言。

助力全球协作

How Open Source Leaders Are Confronting the Challenges of Fragmentation

开源代码的领导者如何面对分裂的挑战

January 2023

2023年1月

Anthony D. Williams, DEEP Centre Inc.

Foreword by

前言：

Yue Chen, Head of Technology Strategy, Futurewei Technologies, Inc.

Chris Xie, Head of Open Source Strategy, Futurewei Technologies, Inc.

In partnership with

联合

Sponsored by

赞助：

Contents

目录

[Infographic 3]

[信息图表 ..............................................................3]

[Foreword 4]

[前言.................................................................. 4]

[Executive Summary 5]

[执行摘要..........................................5]

[Introduction 8]

[简介.............................. 8]

[Innovation and collaboration 8]

[创新与协作 ..................................................... 8]

[Global inclusion 9]

[全球包容........................................... 9]

[Open source governance 9]

[开源治理........................................................... 9]

[Enabling Innovation and Collaboration 10]

[促成创新与协作............................................................ 10]

[Fragmentation across the software landscape 11]

[整个软件领域的分裂......................................................11]

[Fragmentation challenges and solutions 13]

[分裂的挑战和解决方案 .............................. 13]

[Promoting Global Inclusion 15]

[促进全球包容 ........................................................15]

[The barriers to global participation 16]

[全球参与的障碍........................................ 16 ]

[The building blocks for global inclusion 17]

[全球包容性的基石.................................... 17]

[Transcending Techno-Nationalism 19]

[超越技术-民族主义 ..................................................... 19]

[Will techno-nationalism balkanize open source? 19]

[技术民族主义会使开放源代码巴尔干化吗？................................................... 19]

[Tackling techno-nationalism with transparency and trust 22]

[以透明和信任解决技术民族主义问题 ....................................22]

[Breaking Down the Governance Silos 23]

[打破治理孤岛...............................................................23]

[Maintaining critical open source infrastructure 25]

[维护关键的开源基础设施 ............................................................25]

[Increasing collaboration on technology policy and regulation 28]

[加强技术政策和监管方面的合作............................. 28]

[Conclusion 30]

[结论 ...........................................................30]

[Managing fragmentation 30]

[管理分裂 .................................................... 30]

[Confronting techno-nationalism and fostering global inclusion 32]

[对抗技术民族主义，促进全球包容........................ 32]

[Final thoughts 34]

[最后的想法...................................................... 34]

[About the Author 35]

[关于作者 ................................................... 35]

[Endnotes 36]

[尾注 ...............................................................36]

Copyright © 2023 The Linux Foundation | January 2023. This report is licensed under the Creative Commons Attribution-NoDerivatives 4.0 International Public License

版权所有 © Linux基金会 | 2023年1月。本报告在知识共享署名-禁止演绎 4.0 国际公共许可证授权。

Foreword​

前言​

Starting in the late 1960s as a way to share computer software, open source has become one of the most influential global collaborations representing the collective sum of humanity's knowledge due to its fundamental values of equal access, community-driven development, transparency, and inclusiveness.

自20世纪60年代末期开始作为共享计算机软件的一种方式，开源已经成为全球最有影响力的协作之一，代表着人类知识的集体总和，因为它具有平等获取、社区驱动发展、透明度和包容性等基本价值观。

In the recent past, open source has faced numerous challenges regarding security, sustainability, and legal and license compliance. Owing much to their resiliency, open source communities have collectively worked together in each instance to tackle these issues.

最近，开源面临着许多关于安全性、可持续性以及法律和许可证合规性的挑战。由于其韧性，开源社区在每个实例中共同努力解决这些问题。

But there is a newfound concern. Software fragmentation, politicization, weaponization, and techno-nation- alism could negatively impact open source as a collaborative framework and knowledge base for humanity; As such, these could broadly undermine the original spirit of open source innovation.

但是现在有一个新的问题。软件的分裂、政治化、武器化和技术民族主义可能会对开源作为人类协作框架和知识库产生负面影响；因此，这些可能广泛破坏开源创新的原始精神。

This report represents an open source practitioner's view of these challenges through extensive interviews, validating how global communities can work together to navigate complexities so that the open source mission as a global knowledge base and collaboration platform for humanity remains intact.

本报告代表了开源从业者对这些挑战的观点，通过广泛的采访，验证了全球社区如何共同努力解决复杂问题，以确保开源使命作为人类全球知识库和协作平台保持完整。

We express our sincere gratitude to Hilary Carter of Linux Foundation Research and Anthony D. Williams of DEEP Centre Inc., who shared our vision for this research topic and worked diligently from ideation to fruition. We also thank the many partners who participated and contributed to this research. We trust that this report will serve as a resource for all curious about the power of open source, inspiring participants worldwide to become active contributors to open source projects.

我们向 Linux 基金会研究院（Linux Foundation Research）的Hilary Carter和DEEP Centre Inc.的Anthony D. Williams表示真诚的感谢，他们分享了我们对这个研究课题的愿景，并从构思到实现一直勤奋工作。我们还感谢许多参与和贡献这项研究的合作伙伴。我们相信这份报告将成为所有对开源力量感到好奇的人的资源，鼓舞世界各地的参与者成为开源项目的积极贡献者。

Yue Chen, Head of Technology Strategy

Yue Chen，技术战略主管, Futurewei Technologies, Inc.

Chris Xie, Head of Open Source Strategy Futurewei Technologies, Inc.

Chris Xie，开源战略主管, Futurewei Technologies, Inc.

Executive Summary​

执行摘要​

Over two decades, the open source community has grown immensely. In 2000, there were a handful of high-profile open source projects and a small number of companies and organiza- tions to help steer the community's evolution. Today, the global open source ecosystem consists of millions of projects and an equally large and regionally diverse constellation of participants.

在二十多年的时间里，开源社区已经成长为一个庞大的生态系统。在2000年，只有几个知名的开源项目和一些公司和组织来帮助引导社区的发展。今天，全球开源生态系统包括数百万个项目和同样庞大和地区多样的参与者。

Growing global participation in open source software (OSS) is a testament to the ecosystem's success. However, the proliferation of open source projects and organizations also raises a vital question: Is fragmentation in the open source community impeding its progress?

开源软件（OSS）全球参与的增长证明了该生态系统的成功。然而，开源项目和组织的增多也引发了一个重要的问题：开源社区中的分裂是否妨碍了其进展？

This report draws on interviews with open source leaders to examine fragmentation in the open source ecosystem and investigate why it occurs, where it is beneficial, where it is problematic, and what key stakeholders are doing to confront the challenges of fragmentation. Specifically, the report examines three domains where fragmentation poses challenges: the development of open source solutions, the integration of diverse contributors from various regions of the world, and the governance of open source communities, including the role of foundations in safeguarding critical open source infrastructure.

本报告基于对开源领袖的采访，探讨开源生态系统的分裂，并调查其产生的原因、何时有益、何时有问题，以及主要利益相关者为应对分裂带来的挑战所做的努力。具体而言，该报告研究了3个领域中分裂带来的挑战：开源解决方案的开发、来自世界各地不同贡献者的集成，以及开源社区的治理，包括基金会在保障关键开源基础设施中的作用。

The key findings from the research are as follows:

研究的主要发现如下：

1. Fragmentation is a double-edged sword. While open source leaders acknowledge some fragmentation-related challenges in developing open source solutions, they argue that a decentralized ecosystem will always have an inherent degree of fragmentation and duplication. Moreover, the freedom to independently modify open source code produces a diversity of approaches to solving problems and generates superior solutions. While fragmentation can sometimes result in an inefficient allocation of resources, open source leaders caution that efforts to reduce fragmentation could stifle competition and innovation. In other words, solving the frag- mentation problem risks killing the open source goose that laid the golden egg.

2. There is considerable heterogeneity in the software land- scape when it comes to fragmentation. Ecosystem leaders observe that some domains are highly consolidated, whereas others are highly fragmented. Typically, fragmentation follows a maturity curve, where fragmentation is highest in the early stages of a technology's development and then consolidation increases over time. Examples of consolidated domains include operating systems (Linux), web servers (Apache), and web browsers (Chrome). Fragmented fields include embedded devices, machine learning, and blockchain.

3. The principal downsides of fragmentation include increased costs and complexity for consumers and vendors of open source solutions. Several open source leaders argued that the explosion of projects on GitHub signals an abundance of duplication and risks a diffusion of the community's resources. For vendors, the proliferation of competing projects places a more significant burden on their capacity to support customers. However, end users of open source solutions maintain that the proliferation of projects makes it more challenging to identify, test, and deploy suit- able code libraries. Fragmentation can also reduce the open source effect of having a large community collaborate around a shared platform or standard. Finally, the most unhealthy or disruptive forks are those implemented for non-technical objectives, specifically for techno-nationalist reasons.

4. Once firmly rooted in the United States and Western Europe, today's open source community is increasingly global and cosmopolitan. China, for example, is a signifi- cant consumer of and contributor to open source technol- ogies. Not only do nearly 90% of Chinese firms use open source technologies, but Chinese users are also the second most prolific group on GitHub after users from the United States.¹ However, China is not alone. Many emerging economies contain large communities of open source developers, including India, Russia, Korea, and Ukraine. For low- and middle-income countries, engagement with open source communities is giving rise to new entrepreneurial ventures and accelerating the pace of economic development.

5. Language, culture, and geopolitics remain barriers to participation in open source communities. While open source is flourishing globally, open source project leaders outside of North America point to language, culture, and geopolitics as genuine obstacles to their ability to maximize the participation of talented developers. Although the open source community is increasingly international, several leaders argue that organizations headquartered in the United States have outsized influence in shaping most open source projects. Open source leaders fear that a failure to address diversity and inclusion issues will curtail the open source community's access to talent and ingenuity.

6. Diversity and inclusion are critical to building a robust open source talent pool. The challenges of integrating different languages and cultures into open source communities are not new problems, and there is considerable confidence in the ecosystem's capacity to foster global inclusion. However, open source leaders agree that the community can do more to promote global inclusion. For example, interviewees underlined the need to invest in rapid machine translation capabilities for project communications. Leaders also discussed the importance of promoting open source norms, taming the industry's macho "bro" culture, and fostering professionalism in community dialogues and decision-making.

7. Techno-nationalism poses a severe threat to open source collaboration. Over the past decade, the United States and China have introduced increasingly stringent measures to restrict the transfer of critical innovations beyond national borders. Meanwhile, the war between Russia and Ukraine has heightened geopolitical tensions and made the security of technology supply chains a policy imperative. Numerous inter- viewees cited evidence that geopolitical tensions are creating national or regional silos in global innovation communities. Many open source leaders worry that rising protectionist measures could restrict the distribution of open source code and undermine the community's unfettered approach to inter- national collaboration.

8. Transparent open source development protocols are the best antidote for techno-nationalism. To counter techno- nationalism, open source communities must alleviate fears that national interests or malicious actors could taint or corrupt open source projects. Ecosystem leaders see reputation frame- works with enhanced peer review and third-party audits as a means to instill trust in the software development process. Interviewees also called for open source foundations and proj- ects to position themselves as impartial actors and neutral homes for collaboration. They argue that establishing neutral, inclusive, and transparent structures for cooperation will not only broaden participation but can also reduce incentives for ecosystem participants to create parallel efforts along national or regional lines.

9. The creation of new open source projects has seen a commensurate increase in the number of new founda- tions. One empirical study found over 100 active entities across a wide range of open source projects. Ecosystem leaders say the proliferation of new foundations and initia- tives is leading to a growing sense of engagement over- load and vendor fatigue, with some enterprises choosing to be more selective about how and where they engage. However, as open source becomes increasingly global, many ecosystem leaders welcome the creation of new open source organizations around the world. For example, stakeholders recognize that some regional or sector-based foundations can more effectively cater to the needs of their unique constituents.

10. Ecosystem leaders want foundations to do more to align open source projects. Open source foundations are reluctant to play a lead role in identifying and championing winning open source projects, arguing that picking winners is a marketplace function. However, leaders do see a need for better project curation and want foundations and other ecosystem participants to make greater efforts to align projects with similar objectives. To accomplish this, foundations need to enlist skilled community managers with the experience and know-how to compel diverse stakeholders to forge alignment around shared goals. Leaders also called for foundations to bring similar projects under a shared umbrella to eliminate duplication, economize on overhead, and reduce so-called "vendor fatigue."

11. Securing and safeguarding critical open source infra- structure should be a focal point for collaboration. All ecosystem leaders agree that building trust and confidence in OSS and supporting the ongoing maintenance of critical open source infrastructure are urgent imperatives. Decentralized innovation is producing a remarkable tapestry of open source components that are being widely deployed to support the digital economy. However, leaders observe that maintaining these disparate components is a complex challenge that requires a transparent and coordinated approach and a more significant deployment of funding and resources from the principal beneficiaries of open source infrastructure.

12. The need for enhanced collaboration extends to a range of Internet governance issues. Several ecosystem leaders argued that the open source community has not been as influential or assertive in technology policy dialogues as it should be. They maintain that the absence of a coordinated open source response to such issues has left the playing field open to domination by larger, better-resourced entities. Many would like joint efforts to advance open source advo- cacy on Internet governance issues, including cybersecu- rity, intellectual property, privacy, and antitrust. Ecosystem leaders say greater alignment on policy issues among open source foundations would be helpful, along with the creation of open source program offices (OSPOs) in the public sector to facilitate engagement.

1. 分裂是一把双刃剑。 虽然开源领袖们承认开发开源解决方案存在一些与分裂相关的挑战，但他们认为分裂的生态系统总会具有固有程度的分裂和重复。此外，独立修改开源代码的自由产生了各种解决问题的方法和更优秀的解决方案。尽管分裂有时可能导致资源分配的低效，但开源领袖们警告说，减少分裂的努力可能会扼杀竞争和创新。换句话说，解决分裂问题会冒杀死孵出金蛋的开源鹅的风险。

2. 在软件领域，分裂的情况千差万别。 生态系统领导者观察到，有些领域高度集中，而有些则高度分裂。通常，分裂遵循成熟度曲线，即技术发展的早期阶段分裂最高，然后随着时间的推移，集中度会增加。集中的领域包括操作系统（Linux）、Web 服务器（Apache）和 Web 浏览器（Chrome）。分裂的领域包括嵌入式设备、机器学习和区块链。

3. 分裂的主要缺点是增加了开源解决方案的消费者和供应商的成本和复杂性。 几位开源领袖认为，GitHub 上项目的爆炸式增长标志着资源的过度复制和社区的扩散风险。对于供应商而言，竞争项目的繁多会对其支持客户的能力造成更大的负担。然而，开源解决方案的最终用户认为，项目的增多使得确定、测试和部署合适的代码库更加困难。分裂也可能降低开源社区围绕共享平台或标准进行大规模协作的效果。最后，实现非技术目标的分支，特别是为技术民族主义原因而实现的分支，是最不健康或具有破坏性的分支。

4. 如今的开源社区已越来越全球化和国际化，而不再是早期在美国和西欧扎根的社区。 例如，中国是开源技术的重要消费者和贡献者。几乎90%的中国公司使用开源技术，而中国用户也是继美国之后GitHub上贡献最多的用户。¹ 然而，中国并不是唯一的例子，许多新兴经济体都有庞大的开源开发者社区，包括印度、俄罗斯、韩国和乌克兰。对于低收入和中等收入国家来说，与开源社区的接触正在催生新的企业家精神，并加速经济发展的步伐。

5. 语言、文化和地缘政治仍然是参与开源社区的障碍。 虽然开源技术在全球范围内蓬勃发展，但北美以外的开源项目领导者指出语言、文化和地缘政治确实是影响他们最大化吸引才华横溢的开发者参与的障碍。虽然开源社区越来越国际化，但一些领导者认为总部位于美国的组织在塑造大多数开源项目方面具有不可忽视的影响力。开源领导者担心，如果不能解决多样性和包容性问题，将会限制开源社区获取人才和创新的能力。

6. 多样性和包容性对于建立强大的开源人才库至关重要。 将不同语言和文化融入开源社区的挑战并不是新问题，生态系统有很大信心能够促进全球包容性。然而，开源领导者认为社区可以采取更多措施促进全球包容性。例如，受访者强调需要投资快速机器翻译能力，以进行项目通信。领导者还讨论了在社区对话和决策中促进开源规范、遏制该行业的兄弟文化，并培养专业素养的重要性。

7. 技术民族主义对开源合作构成严重威胁。 过去十年，美国和中国引入了越来越严格的措施，以限制关键创新技术的跨国转移。与此同时，俄罗斯和乌克兰之间的战争加剧了地缘政治紧张局势，并使技术供应链的安全成为政策必须。许多受访者引用证据表明，地缘政治紧张局势正在在全球创新社区中创造国家或地区的信息孤岛。许多开源领袖担心，日益保护主义的措施可能会限制开源代码的分发，并破坏社区对国际合作的无拘束态度。

8. 透明的开源开发协议是技术民族主义的最佳解药。 为了对抗技术民族主义，开源社区必须缓解人们对于国家利益或恶意行为可能玷污或破坏开源项目的担忧。生态系统领袖认为，通过增强同行评审和第三方审计的声誉框架可以建立对软件开发过程的信任。受访者还呼吁开源基金会和项目定位为公正的参与者和协作的中立家园。他们认为，建立中立、包容和透明的合作结构不仅可以扩大参与范围，还可以减少生态系统参与者在国家或地区范围内创建并行努力的动机。

9. 新开源项目的创立使得新基金会的数量相应增加。 一项实证研究发现，有100多个活跃的实体涵盖了广泛的开源项目。生态系统领袖表示，新基金会和新举措的不断增加正在导致日益增加的参与负担和供应商疲劳，一些企业更加谨慎地选择他们参与的方式和位置。然而，随着开源变得越来越全球化，许多生态系统领袖欢迎在世界各地创建新的开源组织。例如，利益相关者认识到，一些地区或行业基础的基金会可以更有效地满足其独特的成员需求。

10. 生态系统领袖希望基金会在协调开源项目方面发挥更大的作用。 开源基金会不愿意在识别和支持优胜劣汰的开源项目方面发挥领导作用，他们认为选择胜者是市场功能。然而，领袖们认为需要更好的项目策划，希望基金会和其他生态系统参与者更加努力地将项目与相似的目标对齐。为此，基金会需要招募有经验和知识的熟练社区经理人，促使不同的利益相关者围绕共同目标形成对齐。领袖们还呼吁基金会将类似的项目纳入共享伞下，以消除重复，节省开支，并减少所谓的“供应商疲劳”。

11. 保护和维护关键的开源基础设施应该是合作的重点。 所有生态系统领袖都认为，建立对开源软件的信任和信心，支持关键开源基础设施的持续维护是紧迫的任务。分散的创新正在产生一个非常广泛的开源组件网络，这些组件被广泛地部署以支持数字经济。然而，领袖们观察到，维护这些不同的组件是一个复杂的挑战，需要透明和协调的方法，以及来自开源基础设施的主要受益者的更大的资金和资源的投入。

12. 需要增强的协作范围包括一系列互联网治理问题。 几位生态系统领袖认为，开源社区在技术政策对话中的影响力或主张力还不够强。他们认为缺乏一个协调的开源响应机制使得更大、更有资源的实体主导了这个领域。许多人希望共同努力推进开源在互联网治理问题上的倡导，包括网络安全、知识产权、隐私和反垄断等问题。生态系统领袖表示，在开源基金会之间加强政策问题的对齐，以及在公共部门设立开源办公室（OSPOs）以促进参与，将会有所帮助。

Introduction​

简介​

Over two decades, the open source community has grown immensely. In 2000, there were a handful of high-profile open source projects and a small number of companies and organiza- tions to help steer the community's evolution. Today, the global open source ecosystem consists of millions of projects and an equally large and regionally diverse constellation of participants.

开源社区已经成长了二十多年。在2000年，只有少数几个备受关注的开源项目和一些公司和组织帮助引导社区的发展。如今，全球开源生态系统包含了数以百万计的项目和同样庞大且具有地区多样性的参与者群体。

Nothing underlines the open source community's growth and global reach like GitHub. In 2010, the social coding platform hosted roughly 100,000 users and 1 million code repositories.² As of October 2022, GitHub hosts 83 million developers, 4 million organizations, and over 200 million open source code repositories.³ Some 74% of its global user base resides outside of the United States, with a significant increase in the share of developers based in Asia, Latin America, and Eastern Europe. Meanwhile, several breakthrough OSS innovations have come from places such as Japan (Ruby), Finland (Linux), and South Africa (Ubuntu).

没有什么能够像GitHub一样突显出开源社区的增长和全球影响力。在2010年，这个社交代码平台托管了大约100,000个用户和1百万个代码库。² 截至2022年10月，GitHub托管了8300万开发者、400万组织和超过2亿个开源代码仓库。³ 其中全球用户群体中有74%来自美国以外，而亚洲、拉美和东欧的开发者人数占比有显著增长。同时，许多突破性的开源软件创新来自于日本（Ruby）、芬兰（Linux）和南非（Ubuntu）等地。

Growing global participation in OSS is a testament to the ecosystem's success. However, the proliferation of open source projects and organizations also raises a vital question: Is fragmentation in the open source community impeding its progress?

开源软件（OSS）在全球范围内的日益增长证明了生态系统的成功。然而，开源项目和组织的不断增多也引发了一个至关重要的问题：开源社区的分裂是否妨碍了它的发展？

On the surface, the open source community's recent track record would suggest otherwise. After all, two-plus decades of open collaboration have resulted in a potent array of reusable software components and fostered unrivaled innovation and creativity in the digital economy. One recent estimate (and most others) suggests that 70% to 90% of most modern application stacks consist of OSS, from operating systems to cryptography and networking functions to the enterprise applications running mission-critical operations for global corporations.⁴

表面上看，开源社区最近的记录似乎表明情况并非如此。毕竟，二十多年的开放合作已经产生了大量可重用的软件组件，并在数字经济中促进了无与伦比的创新和创造力。一项最近的估计（以及其他大多数估计）表明，现代应用程序栈的70%至90%由 OSS 组成，从操作系统到加密和网络功能再到运行全球公司的关键业务操作的企业应用程序。⁴

On the flip side, open source ecosystem leaders are raising legitimate questions and concerns about whether fragmentation in the community could undermine several essential functions vital to a sustainable and thriving ecosystem. For example, consider the fol- lowing three domains:

另一方面，开源生态系统的领导者正在提出合理的问题和关切，即社区的分裂是否会削弱对于可持续和繁荣的生态系统至关重要的几个基本功能。例如，考虑以下三个领域：

Innovation and collaboration​

创新和协作​

The freedom to see, modify, and distribute code has always been the open source community's central tenet, along with the community's decentralized production model, which frequently results in hundreds and sometimes thousands of independent contributors collaborating to build and refine open source code libraries. Even the most ardent of competitors often work together to address shared challenges, thereby avoiding the duplication of effort while moving faster to develop and adopt emerging standards and innovations.

自由地查看、修改和分发代码一直是开源社区的核心理念，与社区分散的生产模式一起，这经常导致数百甚至数千个独立的贡献者合作构建和改进开源代码库。即使是最热烈的竞争对手也经常共同解决共同的挑战，从而避免了重复劳动，同时更快地开发和采用新兴的标准和创新。

The potency of the open source model notwithstanding, the stag- gering existence of 200-million-plus projects on GitHub has stirred a debate. Some open source leaders say the continued proliferation of new projects and coordinating bodies creates healthy compe- tition between rival approaches, and competition drives innova- tion. Other participants argue that the explosion of projects signals an abundance of duplication and risks a diffusion of the community's resources. To what extent could increasing fragmentation in software development efforts create inefficiencies and clutter in the marketplace for open source solutions? And if fragmentation is indeed a problem in some domains, what steps should the community take to align its projects, talent, and resources?

尽管开源模式的潜力无法否认，但在GitHub上存在超过2亿个项目的现状引发了一场辩论。一些开源领袖表示，新项目和协调机构的持续增长在竞争对手之间创建了健康的竞争，而竞争推动了创新。其他参与者则认为项目的爆炸性增长意味着重复的过度和风险扩散社区的资源。在软件开发努力中，增加的分裂在开放源码解决方案市场中会产生低效和杂乱的情况吗？如果在某些领域确实存在分裂问题，社区应该采取哪些步骤来协调其项目、人才和资源？

Global inclusion​

全球包容性​

While open source is flourishing globally, open source project leaders outside of North America point to language, culture, and geopolitics as genuine obstacles to their ability to maximize the participation of talented developers. At the same time, rising global trade tensions and political conflict risk politicizing decision-making and participation in open source development communities. Rising techno-nationalism, for example, has the world's advanced economies engaged in a high-stakes contest to reign supreme in key technological domains. Could techno-nationalist policies balkanize OSS development into regional silos and frustrate efforts to foster greater inclusion and deepen the community's talent pool? Or could open source be the key to avoiding balkanization across technology? As the scope and diversity of the community increase, how can open source project leaders integrate diverse participants and successfully promulgate open source norms, ethics, and best practices?

虽然开源在全球范围内蓬勃发展，但北美以外的开源项目领导人指出，语言、文化和地缘政治是影响他们最大化吸引有才华的开发者参与的真正障碍。同时，全球贸易紧张局势和政治冲突的上升可能会将决策和参与开源开发社区的行为政治化。例如，崛起的技术民族主义让世界上先进的经济体在关键技术领域上进行高风险竞赛。技术民族主义政策会不会将OSS发展分割成区域性孤立，从而阻碍扩大包容性和加深社区的人才池？或者，开源是否是避免技术上的分裂的关键？随着社区的范围和多样性增加，开源项目领导者如何整合不同的参与者并成功地传播开源规范、伦理和最佳实践？

Open source governance​

开源治理​

Good governance is increasingly paramount as OSS becomes a vital component of critical digital infrastructure. For example, quickly identifying and rectifying security vulnerabilities requires timely and effective coordination across the globally decentralized open source community. Several open source foundations have stepped in to help steward new initiatives designed to address the ecosystem's vulnerabilities. However, the population of new open source foundations continues to multiply, raising concerns about the impact of organizational silos on cosystem governance. Are smaller, more focused organizations more efficient and effective in addressing narrower mandates defined by specific industries, regions, and application spaces? Or will the continued proliferation of projects and organizations impede efforts to create global stan- dards, address security vulnerabilities, and promote the adoption of open source solutions?

随着OSS成为关键数字基础设施的重要组成部分，良好的治理变得越来越重要。例如，快速识别和纠正安全漏洞需要全球分散的开源社区进行及时有效的协调。几个开源基金会已经介入，帮助管理旨在解决该生态系统漏洞的新举措。然而，新的开源基金会数量继续增加，引发了对组织壁垒对生态系统治理的影响的担忧。更小、更专注的组织是否更有效率和更有效地处理由特定行业、地区和应用领域定义的狭窄任务？还是继续项目和组织的增加会妨碍全球标准的制定、处理安全漏洞并促进开源解决方案的采用？

This report draws on interviews with open source leaders to examine fragmentation in the open source ecosystem and investigate why it occurs, where it is beneficial, where it is problematic, and what key stakeholders are doing to confront the challenges of fragmentation.

本报告借助开源领袖的访谈，探讨了开源生态系统中的分裂，并研究了它发生的原因、它在哪里是有益的、在哪里是有问题的以及关键利益相关者在应对分裂挑战方面所做的工作。

• Section 2 of the report discusses the benefits and potential pitfalls of fragmentation in the development of open source code.

• Section 3 examines the internationalization of open source and highlights the tools and methods project leaders are deploying to overcome potential barriers to participation in open source communities.

• Section 4 assesses the implications of techno-nationalism for open source collaboration and proposes strategies for reducing the risks of regional balkanization.

• Section 5 provides stakeholder reflections on the state of open source governance and identifies several priorities for increased collaboration between open source foundations.

• Section 6 provides a summary of key findings and recommendations.

• 报告的第二部分讨论了开源代码开发中分裂的利弊。

• 第三部分审查了开源的国际化，并强调了项目领导者为克服参与开源社区的潜在障碍而采用的工具和方法。

• 第四部分评估了技术民族主义对开源协作的影响，并提出了减少区域分裂风险的策略。

• 第五部分提供了利益相关者对开源治理状况的反思，并确定了增加开源基金会之间合作的几个优先事项。

• 第六部分提供了关键发现和建议的摘要。

Enabling Innovation and Collaboration​

促成创新与协作​

In a study of fragmentation in OSS ecosystems, Professor Christopher Yoo at the University of Pennsylvania Law School posits that the inherent freedom of action that characterizes OSS development creates the potential for excessive fragmentation. Excessive frag- mentation, Yoo alleges, creates a host of challenges for the open source community. As Yoo put it:

宾夕法尼亚大学法学院的 Christopher Yoo 教授在一项关于开源软件生态系统分裂的研究中提出，开源软件开发所特有的行动自由创造了过度分裂的可能性。Yoo 称，过度的分裂会给开源社区带来一系列的挑战。以下为原文：

"On the one hand, users' freedom to customize software is integral to the open source movement... On the other hand, infinite flexibility creates costs for the open source community by requiring the diffusion of effort and the duplication of work across multiple projects. Fragmentation also harms device manufacturers and app developers by limiting interoperability and by requiring them to adapt their products for what are now separate platforms."⁵

“一方面，用户定制软件的自由是开源的组成部分。另一方面，无限的灵活性要求在多个项目中分散精力和重复工作，这样会给开源社区带来成本。分裂也损害了设备制造商和应用程序开发人员，因为它限制了互操作性，并要求他们为现在的独立平台调整其产品。”⁵

Yoo's research refers principally to the problem of forking in open source development projects. He argues that the most extreme form of fragmentation occurs when a contributor to an open source project customizes the community's source code to the extent that it is no longer fully interoperable with the rest of the project. The result is to divide the system into two distinct and incompatible versions. Given the economic inefficiencies that ensue, Yoo concludes that "some constraints on the flexibility of open source are thus inevitable."⁶

Yoo 研究的内容主要是指开源开发项目中的复刻问题。他认为，当一个开源项目的贡献者将社区的源代码修改到不再能与项目的其他部分完全互通的程度时，就会出现最极端的分裂形式。最终的结果是将系统分为两个不同的、不兼容的版本。鉴于随之而来的经济效率低下，Yoo 总结为："因此，对开源的灵活性的一些限制是不可避免的。"⁶

In discussing fragmentation with open source leaders, a starting point for many is the recognition that forking and duplication are inevitable and often desirable consequences of a decentralized ecosystem.

在与开源领袖讨论分裂问题时，许多人的出发点是承认复刻和重复是不可避免的，而这往往是去中心化生态系统中不可避免的结果。

Decentralization, several argued, is not necessarily an optimal design for efficiency, but it is a powerful engine for innovation. "The whole open source world is a testament to the power of decentralization," said Rod Beckstrom, former CEO of ICANN and director of the U.S. National Cybersecurity Center. "One conse- quence of decentralization is overlap and redundancy. You cannot end the overlap without central control. You can evolve or nudge a decentralized system, but there is no means to control it."

一些人认为，去中心化不一定是效率最佳的设计，但它能推动创新。ICANN 前 CEO、美国国家网络安全中心主任 Rod Beckstrom 说："整个开源世界证明了去中心化的力量"。"去中心化的一个后果是重叠和冗余。如果没有中央控制，就无法避免重叠。你可以发展或推动一个去中心化的系统，但没有办法控制它。"

Moreover, most participants of the study are comfortable with the reality that a decentralized open source ecosystem will always feature some inherent degree of disorder. As Mark Surman, presi- dent of the Mozilla Foundation, put it, "The point of open source is that it's decentralized. The ability to gather a set of people to col- laborate around a particular problem or domain has always been the challenge and opportunity of open source. Can we pool our resources in a way that we can get enough value back out from the resources that I am putting in? The freedom to convene and collaborate means you will never have perfect order."

此外，大多数研究的参与者都认为去中心化的开源生态系统总是具有一些内在的无序程度。正如 Mozilla 基金会主席 Mark Surman 所说："开源的意义在于去中心化。聚集一群人围绕一个特定的问题或领域进行合作的能力，一直是开源的挑战和机遇。我们能否以一种方式汇集我们的资源，使我们能够从我投入的资源中获得足够的价值回报？召集和协作的自由意味着你永远不会有完美的秩序"。

More fundamentally, open source leaders argue that forking is part of the standard workflow for open source projects and an essential aspect of how software systems evolve and improve over time. "In good forks, you take a code library and address a problem that the community has not previously addressed," said Tim Bird, a senior software engineer with Sony Mobile Communications. "Developers split off to address the new problem and eventually come back together to reintegrate the new code into the larger ecosystem." In practice, Jim Zemlin, executive director of the Linux Foundation, points to several reasons to fragment or fork a component, such as addressing a significant technical problem or solving security issues.

更为根本的是，开源领导者认为，复刻（fork）是开源项目标准工作流程的一部分，也是开源项目随着时间推移而演变和改进的一个重要方式。Sony 移动通信公司的高级软件工程师 Tim Bird 说：”在优秀的复刻库中，你可以利用一个代码库，解决一个社区以前没有解决的问题“。“开发者分开来解决新的问题，并最终回到一起，将新的代码重新整合到更大的生态系统中”。在实践中，Linux 基金会的执行董事 Jim Zemlin 指出了分割或复刻一个组件的几个原因，如解决一个重要的技术问题或解决安全问题。

The freedom to independently experiment with an existing code library is especially beneficial when developers go off to try new ideas, add new features, and explore new use cases for OSS. "The codebases get stronger and stronger as a result," said Mike Dolan of the Linux Foundation, "because developers address their specific use cases without breaking things for everybody else." He adds, "The key part is that developers bring those new fragments back into the core upstream open source project."

当开发者去尝试新的理念，增加新的功能，探索开源软件的新用例时，独立实验现有代码库的自由尤其有益。"代码库因此变得越来越强大，"Linux 基金会的 Mike Dolan 说，"因为开发者解决了他们特定的用例，而没有破坏其他人的东西。" 他补充说："关键的部分是，开发人员将这些新的片段带回核心的上游开源项目中。"

Ultimately, ecosystem leaders agree that decentralized collaboration has resulted in a remarkable tapestry of independent open source components that developers can put together to do something bigger and more useful. "We have a huge variety of software to choose from now," said Bird. "In many ways, we are in the golden age of open source." Jim Zemlin amplifies this point, noting that a typical software package has 4,000 to 5,000 open source components. "The availability of lots of reusable components dramatically increases the efficiency of software development and speeds time to market," said Zemlin. "Enterprises can innovate around the edges. They don't have to build everything from scratch. The availability of reusable components also prevents a lot of fragmentation because everyone is drawing from the same code libraries. Nobody is taking the Linux kernel and creating a new version."

最终，生态系统的领导者们一致认为，去中心化的合作导致了独立的开源组件的非凡织锦，开发者可以把它们放在一起做一些更大、更有用的事情。“我们现在有大量的软件可供选择。”Bird说。“在许多方面，我们正处于开源的黄金时代。” Jim Zemlin 放大了这一点，他指出，一个典型的软件包有 4000 到 5000 个开源组件。Zemlin 说：”大量可重复使用的组件的可用性极大地提高了软件开发的效率，并加快了上市时间”。“企业可以在边缘地带进行创新。他们不必从头开始建立一切。可重复使用的组件的可用性也防止了大量的分裂，因为每个人都是从相同的代码库中提取的。没有人拿着 Linux 内核去创造一个新的版本”。

Even when fragmentation produces overlap and redundancy, open source leaders warn that attempts to control or curtail the freedom inherent in open source development could be more harmful than the fragmentation itself. "Fragmentation is the inno- vation engine," said Mike Milinkovich, executive director of the Eclipse Foundation. "Developers must be allowed to foster new ideas and projects. Anything that brings a draconian order to the production side of the equation is doomed to fail."

即使分裂产生了重叠和冗余，开源领导人警告说，试图控制或削减开源开发中固有的自由，可能比分裂本身危害更大。"分裂是创新的引擎，" Eclipse 基金会的执行董事 Mike Milinkovich 说。"必须允许开发者培养新的想法和项目。任何给生产方面带来严格限制令的东西都是注定要失败的。"

"Over time, competition between rival approaches gives way to increasing consolidation as market forces separate the winners from the losers."

“随着时间推移，市场将赢家和输家区分开来，竞争对手之间也开始进行合作。”

Fragmentation across the software landscape​

软件环境中的分裂​

Open source leaders concede that fragmentation is not a grave problem in the open source ecosystem but part of the essential life cycle in how the community develops software. Fragmentation is not only normal but largely healthy as well. As Astor Nummelin Carlberg, executive director of OpenForum Europe, put it, "The resilience of the system increases when there are competing alter- natives. Competition can also drive innovation. The distributed nature of open source produces a diversity of thought and differ- ent approaches to solving problems."

开源领导者承认，分裂并不是开放源码生态系统的一个严重问题，而是社区开发软件的基本生命周期的一部分。分裂不仅是正常的，而且在很大程度上也是健康的。正如欧洲开放论坛的执行董事 Astor Nummelin Carlberg 所说，"当有竞争性的替代方案时，系统的恢复能力就会增加。竞争也可以推动创新。开源的分布式性质产生了思想的多样性和解决问题的不同方法"。

However, looking across the software landscape, there is considerable heterogeneity in the degree of fragmentation, and leaders suggest that not all of it is desirable. Some domains are highly consolidated, while others feature a multiplicity of different software packages. Typically, the level of fragmentation follows a maturity curve where experimentation (and thus some inherent duplication of effort) is highest in the early stages of developing applications for a given domain. Over time, competition between rival approaches gives way to increasing consolidation as market forces separate the winners from the losers.

然而，纵观整个软件领域，分裂程度有相当大的异质性，而且领导者认为并非所有的分裂都是可取的。领导人表示，并非所有的分裂都是可取的。一些领域是高度整合的，而另一些领域则有许多不同的软件包。通常情况下，分裂程度遵循一个成熟度曲线。在为一个特定领域开发应用的早期阶段，实验（以及一些固有的重复工作）的分裂程度是最高的。随着时间推移，市场将赢家和输家区分开来，竞争对手之间也开始进行合作。

Several open source leaders point to Linux as a quintessential example of healthy consolidation. "Linux has been around for 32 years," said Alan Clark of the CTO Office at SUSE. "It's very mature. Sometimes you get new community distributions of Linux, but they occupy particular niches. In short, we see creativity around the edges, with developers incorporating their innovations into the main kernel."

一些开源的领导人指出，Linux 是一个典型的健康整合的例子。”Linux 已经存在了 32 年。“ SUSE 公司 CTO 办公室的 Alan Clark 说。“它是非常成熟的。有时你会得到新的 Linux 社区发行版，而他们也占据了一席之地。简而言之，我们看到了边缘的创造力，开发者们将他们的创新融入到主内核中"。

Jerry Cuomo, an IBM fellow and VP and CTO of Technology & Consulting, adds that the open source community's ability to foster broad participation in developing and using shared platforms has been enormously beneficial. "Linux has been inviting for diverse col- laboration for decades, but it also invites fierce competition," said Cuomo. "You can contribute your piece to the kernel and then pull in proprietary components to compete with other vendors. The key to its success is the architecture and heavy-handed prescription about keeping people focused on the core Linux kernel. The Apache web server is another example of this. There is only one Apache server, and the Web wouldn't be the same without it."

IBM 研究员、技术与咨询部副总裁兼首席技术官 Jerry Cuomo 补充说，开源社区促进广泛参与开发和使用共享平台的能力为很多人提供了帮助。“几十年来，Linux 一直在吸引各种各样的合作，但它也引发了激烈的竞争，”Cuomo 说，"你可以把你的那部分贡献给内核，然后拉进专有组件，与其他供应商竞争。其成功的关键是架构和关于让人们专注于核心 Linux 内核的重磅规定。Apache 网络服务器就是一个例子。如果只有 Apache 服务器，网络就不可能是现在这个样子了。

Several leaders argued that, in some domains, too much consoli- dation is a more significant concern than too much fragmentation. "In the core areas where open source is prominent, do we have the opposite problem?" asks Mark Surman of the Mozilla Foundation. "Is open source too concentrated? And when is concentration okay? There's a big difference between the collaborative mainte- nance of an open standard and the dominance of a single product. In browsers, you could argue that we need more fragmentation, not less. Look at Google's Chrome. It dominates the market."

几位领导人认为，在某些领域，过多的合并比过多的分裂更令人担忧。"在开源突出的核心领域，我们是否有相反的问题？"Mozilla 基金会的 Mark Surman 问道。”开源代码是否过于集中？什么时候集中是好的呢？开放标准的合作性维护和单一产品的主导地位之间有很大区别。在浏览器方面，你可以说我们需要更多的分裂，而不是更少。比如谷歌的 Chrome 浏览器，现在已经主导了市场。“

By contrast, fragmentation is prominent in domains that are earlier in the maturity cycle and where open source is less established. "Look at various aspects of AI," said Surman. "It's still early days.

相比之下，在成熟周期较早、开放源码建立较少的领域，分裂现象十分突出。"看看人工智能的各个方面，" Surman 说。"这仍然是早期的事情。

There are many players. Perhaps there is some fragmentation in machine learning frameworks. But it should be up to the market to decide which solutions, standards, and products will prevail."

也许在机器学习框架中存在一些分裂现象。但应该由市场来决定哪些解决方案、标准和产品会占上风"。

Where else do open source leaders see challenges with fragmenta- tion? As Tim Bird of Sony put it, "If you don't see the fragmentation, you are not looking very hard. Just look at a range of stacks. There is way too much software that does similar things. It becomes a burden. Both the consumer electronics and automotive industries have issues. Fragmentation in graphic APIs is very painful. There are no standards. Everyone is doing their own thing."

开源领袖们还在哪里看到了分裂的挑战？Sony 的 Tim Bird 指出，”如果认真看，就会看到分裂。看看现在已有的东西就知道了。有太多的软件在做类似的事情，这成为了一种负担。消费电子和汽车行业都有问题。图形 API 的分裂没有标准，这是非常痛苦的。每个人都各自为战。“

Both Bird and Clark describe the embedded device space as rife with fragmentation. "In embedded electronics, there is a natural tendency to fragment," said Bird. "It is different from the desktop and enterprise software space. To conserve resources, you tighten down the screws and build software solutions that are highly customized to the manufacturer's hardware. For example, the television stack is very different across different manufacturers. Developers code the software close to the metal to optimize performance. That causes a lot of fragmentation."

Bird 和 Clark 都说嵌入式设备领域充斥着分裂的现象。”在嵌入式电子产品中，有一个自然的趋势，就是将其分裂。“ Bird 说到。”它与桌面和企业软件领域不同。为了节约资源，你拧紧螺丝，建立高度定制的软件解决方案，以适应制造商的硬件。例如，不同制造商的电视零件是非常不同的。开发者为了优化性能而尽可能地使用底层语言去开发软件。这导致了大量的分裂。“

Gabriele Columbro of FINOS and Linux Foundation Europe, on the other hand, calls blockchain one of the most fragmented domains. "There are too many foundations, platforms, standards, and currencies," said Columbro. "Many players call themselves open source but not openly governed. The result is a proliferation of forks. You don't get consolidation when you don't have clear and transparent governance."

另一方面，FINOS 和欧洲 Linux 基金会的 Gabriele Columbro 称区块链是最分裂的领域之一。”已经有太多的基金会、平台、标准和货币“，Columbro 说。许多项目自称是开源的，但没有开放的管理。其结果是复刻的泛滥。当你没有明确和透明的管理时，你的项目就不会发展。

Fragmentation challenges and solutions​

分裂的挑战和解决方案​

"Open source is reducing fragmentation, not causing it."

”开源正在减少分裂，而不是导致分裂。“

Several leaders consulted for the study see what they describe as problematic instances of fragmentation in the development of open source solutions. So, what are the potential costs to the ecosystem? The principal downsides of fragmentation are increased cost and complexity for consumers and vendors of open source solutions. Fragmentation can also reduce the open source effect of having a large community collaborate around a shared platform or standard, resulting in a less efficient deployment of resources.

接受调研的几位领导人看到了他们所描述的开源解决方案发展中存在的分裂问题的实例。那么，生态系统的潜在成本是什么？分裂的主要坏处是增加了消费者和开源解决方案供应商的成本和复杂性。分裂也会降低开源的效果，让一个庞大的社区围绕一个共享的平台或标准进行合作，导致资源部署的效率降低。

For vendors, the proliferation of competing projects places a more significant burden on their capacity to support customers. "The disadvantage of fragmentation is that it increases costs and causes vendors to deploy more resources," said Alan Clark of SUSE. "You must track what is going on, assess the efficacy of different approaches, and sometimes you have to support multiple solu- tions for your customers. The duplication of effort equals more resources and more cost. And then it creates a challenge around standards and compatibility issues."

对于供应商来说，竞争项目的激增给他们带来了更大的压力。”分裂增加了成本，导致供应商部署更多的资源”，SUSE 的 Alan Clark 说。你必须跟踪正在发生的事情，评估不同方法的功效，有时你必须为你的客户支持多种解决方案。重复的努力意味着更多的资源和更多的成本。继而，它又会引发标准和兼容性问题。

"Without open source, the redundancy and fragmentation just happen behind closed doors with lots of individual proprietary projects." - STORMY PETERS

“如果没有开源，大量的独立项目都会闭门造车，导致冗余和分裂。”- STORMY PETERS

On the other hand, end users of open source solutions maintain that the proliferation of projects makes it more challenging to identify, test, and deploy suitable code libraries. Tim Bird of Sony, for example, argues that fragmentation in the software environ- ment adds time and cost to the development process for device manufacturers. "We look for open source code libraries to tackle particular problems," said Bird, "but when the open source projects proliferate, it requires a lot of research and customization to find a library that is suitable for our needs." Maintenance is another challenge, according to Bird. "When new forks emerge, it splits the community and results in fewer developers on each fork to fix bugs or address security concerns. Fragmentation creates duplica- tion of effort. We lose the open source effect."

另一方面，开源解决方案的终端用户坚持认为，项目的激增使得识别、测试和部署合适的代码库更具挑战性。例如，Sony 的 Tim Bird 认为，软件环境的分裂给设备制造商的开发过程增加了时间和成本。Bird 说，“我们通过寻找开源代码库来解决特定的问题，但当开源项目激增时，需要大量的研究和修改来找到适合我们需求的库。”Bird 表示维护项目也是一个难题。“当新的复刻库出现时，它分裂了社区，导致每个复刻库上修复错误或解决安全问题的开发人员减少。”

According to Jerry Cuomo of IBM, fragmentation can create addi- tional inefficiencies in the marketplace for solutions. "For open source to work well on the business side, you need a healthy eco- system of competing solutions that orbit around shared platforms," said Cuomo. "An enterprise that uses open source needs to know that the vendor will support its solution. Can I trust it? Is it secure? What if the vendor lets you down? What do you do?" Cuomo and others note that enterprises can freely move from vendor to vendor when the vendors work around a shared platform. "They can go for better prices and better solutions," said Cuomo. "It creates healthy competition and lowers lock-in and switching costs for enterprise users. Non-fragmented ecosystems create an open economy. When it's fragmented, you don't have that as much."

据 IBM 的 Jerry Cuomo 说，分裂会造成额外的损失。“要使开源在商业方面运作良好，你需要一个由围绕共享平台的竞争性解决方案组成的健康的生态系统，”Cuomo 说到，“使用开放源码的企业需要知道，供应商将支持其解决方案。他值得信任吗？是不是安全的？如果供应商不支持怎么办？等等。”Cuomo 等人指出，当供应商基于共享平台工作时，企业可以自由地从一个供应商转移到另一个供应商。“他们可以去争取更好的价格和更好的解决方案。”Cuomo 说，“它创造了良性竞争，降低了企业用户的锁定和转换成本。非分裂的生态系统创造了一个开放的经济当它是分裂的时候，你就不会有那么多。”

For the broader ecosystem of contributors to open source solu- tions, there is an argument that duplication and redundancy rep- resent an inefficient deployment of the community's resources. "On the one hand, you can argue that overlapping or redundant efforts are a waste of talent and resources," said Astor Nummelin Carlberg of OpenForum Europe. "On the other hand, we also see gaps in the marketplace, with competing projects in high-demand areas and less focus on critical areas that demand attention."

对于更广泛的开源解决方案的贡献者的生态系统来说，有一种说法是，重复和冗余代表了社区资源的低效部署。“一方面，你可以说重叠或多余的工作是对人才和资源的一种浪费。”欧洲开放论坛的 Astor Nummelin Carlberg 说到，“另一方面，我们也看到了市场上的差距，在高需求的领域有竞争性的项目，而对需要关注的关键领域的关注则较少。”

In the final analysis, fragmentation is a double-edged sword. On the one hand, the software ecosystem needs healthy competition between rival ideas and approaches. Nobody consulted for the study wants to reduce fragmentation at the expense of competi- tion and innovation. Moreover, looking across the entire software landscape, there is a solid case to be made that open source is reducing fragmentation, not causing it. As Stormy Peters of GitHub put it, "Without open source, the redundancy and fragmentation just happen behind closed doors with lots of individual propri- etary projects."

On the other hand, leaders acknowledge that a decentralized open source ecosystem will inevitably produce duplicate projects and, thus, some inefficiencies for vendors and other partici- pants. "For a company like SUSE and other vendors," said Clark, "duplication creates a challenge because we need to be selective regarding which projects we will support. Which projects offer the most robust solution and a supportable future? Which solu- tions are the most relevant to our customers?"

归根结底，分裂是一把双刃剑。一方面，软件生态系统需要对手的想法和方法之间的良性竞争。接受调研的人都不希望以牺牲竞争和创新为代价来减少分裂。此外，纵观整个软件领域，有充分的理由证明，开源正在减少分裂，而不是导致分裂。正如 GitHub 的 Stormy Peters 所说，“如果没有开源，大量的独立项目都会闭门造车，导致冗余和分裂。”另一方面，领导人承认，一个去中心化的开源生态系统将不可避免地产生重复的项目，因此，对供应商和其他参与者来说，会有一些低效的问题。Clark 说，“对于像 SUSE 和其他供应商这样的公司来说，重复给我们带来了挑战，因为我们需要甄别支持哪些项目。哪些项目提供最稳定的解决方案，在未来能一直支持？哪些解决方案最适合我们的客户？”

Some enterprise leaders suggested that open source foundations could intervene in fragmented domains by helping to identify and champion winning solutions. However, foundation leaders pushed back on this idea, asserting that market forces rather than founda- tions should determine the winners. "We help competitors, suppli- ers, and customers all work together and build things in a neutral forum," said Mike Dolan of the Linux Foundation. "And, in an open forum where anybody can participate, people vote by showing up. If they show up with their developers, resources, and buying power, those projects can become de facto standards. That's how the tech industry picks winners."

一些企业领导人建议，开源基金会可以通过帮助识别和支持成功的解决方案来干预分裂领域。然而，基金会领导人对这一想法进行了反驳，声称最后的赢家应该由市场力量而不是基金会决定。“我们帮助竞争者、供应商和客户一起工作，并在一个中立的论坛上进行工作。”Linux 基金会的 Mike Dolan 说到，“在一个开放的论坛里，大家用脚投票。如果开发人员、资源和购买力等都集中向了某些项目，那么这些项目可以成为事实上的标准。这就是科技行业的竞争的方式。”

Most open source leaders agree that when the ecosystem follows open source principles, the fragmentation and duplication of effort get resolved over time. "We want to see different ideas in a new space, and we want them to try them out in rapid succession," said Mike Milinkovich of Eclipse. "Open source is the best way to do that.

You do not want to corral that innovation; we want to encourage it. Competition will determine the winners and losers. Over time, projects will consolidate, and the ecosystem can move forward."

大多数开源领袖都同意，当生态系统遵循开源原则时，分裂和重复工作会随着时间的推移得到解决。“我们希望在一个新的空间里看到不同的想法，并希望他们迅速地尝试这些想法。”Eclipse 的 Mike Milinkovich 说到，“开源是最好的方式。你不应该紧固创新，而是应该鼓励创新。赢家和输家通过竞争决出。随着时间的推移，项目将得到发展，而生态系统也可以向前发展。”

Open source leaders also insist that intelligent project design can go a long way toward reducing unnecessary fragmenta- tion. Establishing neutral, inclusive, and transparent structures for collaboration will broaden the tent and reduce incentives to create parallel efforts. "When we launch a project, we do it in a way that says this is going to be neutral," said Mike Dolan of the Linux Foundation. He points to Kubernetes, where Google went to great lengths to distribute control over the project and reassure other contributors that Google was ready and willing to collabo- rate. "Google could have open sourced Kubernetes and kept all the maintainer control," said Dolan. "Instead, they handed off key parts of the codebase to other companies and leaders who proved very capable of doing it. In doing so, Google got broad buy-in and helped make Kubernetes the de facto standard for the industry."

开放源码的领导者还坚持认为，明智的项目设计可以在很大程度上减少不必要的分裂现象。建立中立、包容和透明的协作关系，会让我们未来的路更宽，也可以减少重复劳动。“当我们启动一个项目时，我们应该让它成为中立的。”Linux 基金会的 Mike Dolan 说到。他指出，在 Kubernetes 中，谷歌花了很大力气来分配对项目的控制权，并向其他贡献者保证，谷歌已经准备好并愿意进行合作。Dolan 说，“谷歌本可以将 Kubernetes 开源，并保持所有维护者的控制权。但我们（没有这么做，而是）把代码库的关键部分交给了其他公司和领导人，事实证明他们非常有能力做到这一点。这样做以后，谷歌得到了广泛的支持，并使 Kubernetes 成为了行业的事实标准。”

Promoting Global Inclusion​

促进全球包容​

Once firmly rooted in the United States, today's open source community is increasingly global and cosmopolitan. China, for example, has become a significant consumer of and contributor to open source technologies. Not only do nearly 90% of Chinese firms use open source technologies⁷, Chinese users are the second most prolific group on GitHub after users from the United States.⁸

曾经在美国根深蒂固的开源社区，今天正变得越来越全球化和国际化。例如，中国已经成为开源技术的重要消费者和贡献者。不仅近90%的中国公司使用开源技术⁷，中国用户是 GitHub 上仅次于美国用户的第二大用户群体。⁸

With China intent on boosting its software prowess, Chinese participation in open source will increase dramatically in the years ahead. China's Ministry of Industry and Information Technology (MIIT) has expressed concerns about its domestic software indus- try's international competitiveness and sees deeper participation in international open source projects as a means to place itself on an equal footing with global players⁹. Among the plans to improve the state of homegrown software, the MIIT is investing in a series of software parks, implementing additional policy supports, and creating two or three open source foundations or communities to bolster China's international influence.

随着中国致力于提升其软件实力，中国在开源领域的参与度将在未来几年大幅增加。中国工业和信息化部（MIIT）对其国内软件产业的国际竞争力表示担忧，并将更深入地参与国际开源项目视为一种手段，使其与全球玩家处于平等地位⁹。 工信部正在投资一系列软件园区，实施额外的政策支持，并创建两三个开源基金会或社区，以增强中国的国际影响力。

"A global open collaboration orchestrated by an effective foundation is arguably the best way to reduce fragmentation and promote international cooperation."

“一个由高效基金会策划的全球开源协作可以说是减少分裂和促进国际合作的最佳方式”

Chinese technology leaders have already initiated and championed several prominent open source projects. Alibaba, for example, has one of China's most robust open source talent pools. An active participant in RISC-V, the global open source semiconduc- tor community, the e-commerce giant recently took the bold step of open sourcing its semiconductor design development via the OpenXuantie project. ¹⁰ In another example, Baidu launched Apollo in 2017, which has since evolved into one of the world's leading open source solutions for autonomous vehicles.¹¹ Baidu is lever- aging driverless technology in its Apollo Go robotaxi service. The autonomous taxi service currently operates in five Chinese cities, but the company plans to expand Apollo Go to 65 cities by 2025 and then 100 cities by 2030.¹²

中国技术领袖已经发起并支持了几个著名的开源项目。例如，阿里巴巴拥有中国最强大的开源人才库之一。作为 RISC-V（全球开源半导体制造商社区）的积极参与者，这家电子商务巨头最近采取了大胆的步骤，通过 OpenXuantie 项目对其半导体设计开发进行开源。¹⁰ 在另一个例子中，百度于2017年推出了 Apollo，此后，Apollo 已发展成为全球领先的自动驾驶汽车开源解决方案之一。¹¹ 百度正在其 Apollo Go 机器人出租车服务中利用无人驾驶技术。自动驾驶出租车服务目前在中国五个城市运营，但该公司计划到2025年将 Apollo Go 扩展到65个城市，然后到2030年扩展到100个城市。¹²

China is a prominent example of the globalization of OSS. However, many emerging economies contain large communities of open source developers, including India, Russia, Korea, and Ukraine. Harvard Business School researchers Nataliya Langburd Wright, Frank Nagle, and Shane Greenstein observe in a recent study that "Just like their counterparts in developed economies, programmers around the globe employ open source tools, speak the vocabulary of open source, and interact with open source libraries."¹³ Engagement with OSS communities, in turn, is giving rise to new entrepreneurial ventures and accelerating the pace of economic development. Wright, Nagle, and Greenstein conclude that "[OSS] represents an opportunity for low- and middle-in- come countries to reach the technological frontier more quickly than if they needed to develop such software from scratch or obtain it from costly sources..."¹⁴

中国是开放源码软件全球化的一个突出例子。然而，许多新兴经济体包含大量开源开发者，包括印度、俄罗斯、韩国和乌克兰。哈佛商学院（Harvard Business School）的研究人员 Nataliya Langburd Wright、Frank Nagle和Shane Greenstein在最近的一项研究中观察到，“与发达经济体的同行一样，全球各地的程序员使用开源工具，使用开源词汇，并与开源库互动。”，¹³ 正在催生新的创业企业，加快经济发展步伐。Wright、Nagle和Greenstein总结道，“OSS为中低收入国家提供了一个机会使其可以更快抵达技术前沿，相比从头开始开发此类软件或从昂贵的来源获得此类软件……” ¹⁴

Calista Redmond, CEO of RISC-V, argues that a global open collabo- ration orchestrated by an effective foundation is arguably the best way to reduce fragmentation and promote international coopera- tion. "Collaboration on open standards and software has proven throughout history that alignment to a shared collective model reduces the temptation and economic feasibility for ecosystem participants to take a proprietary approach to common building blocks," said Redmond. "We are creating a strong foundation with a global community where roughly one-third of our members are in NA, one-third in AMEA, and one-third in APAC."

RISC-V 首席执行官Calista Redmond认为，由一个有效的基金会组织的全球开放合作可以说是减少分裂和促进国际合作的最佳方式。Redmond 表示：“在开放标准和软件上的合作在整个历史上都证明，与共享的集体模型相一致，可以减少生态系统参与者对共同构建块采取专有方法的诱惑和经济可行性。”。“我们正在建立一个强大的全球社区基础，其中约三分之一的成员在北美，三分之一在欧洲、中东和非洲，三分一在亚太地区。”

"It's easier to collaborate globally now," said Redmond. "We have the technology to support globally distributed teams." Redmond points to growing global participation in RISC-V's technical working groups. Today, RISC-V has 65+ working groups. Redmond said there could be 80 by the end of 2022. "Now we are starting to ship actual products in a variety of vertical markets, including automo- tive, industrials, transportation, and aerospace. It's a remarkable time. We are building a robust ecosystem across workloads, from embedded to enterprise, and accomplishing in five or six years what it took earlier microprocessor architectures 20 years to do."

Redmond 说：“现在全球合作更容易了。”。“我们拥有支持全球分布式团队的技术。” Redmond 还指出，RISC-V 技术工作组的全球参与度越来越高。如今，RISC-V 拥有65个以上的工作组。雷德蒙表示，到2022年底可能会有80人。“现在，我们开始在各种垂直市场销售实际产品，包括汽车、工业、运输和航空航天。这是一个了不起的时刻。我们正在构建一个从嵌入式到企业级的跨工作负载的强大生态系统，并在五到六年内完成了早期微处理器架构20年才能完成的任务。”

The barriers to global participation​

全球参与的障碍​

"The hegemony of North American participants can overshadow open source projects that originated in other parts of the world."

“北美参与者的霸权可能会使起源于世界其他地区的开源项目黯然失色。”

Open source leaders consulted for the study agree that global participation in open source is on the rise. However, there is also broad recognition that a failure to eliminate several formidable barriers to full participation could result in regional fragmenta- tion in the open source ecosystem. For example, leaders point to language, culture, and geopolitics as ongoing challenges. There also remains a prevalent sense that companies and foundations headquartered in the United States have outsized influence in shaping most open source projects.

为这项研究咨询的开源领袖一致认为，全球对开源的参与正在增加。然而，人们也普遍认识到，如果不能消除充分参与的几个巨大障碍，可能会导致开源生态系统的区域分裂。例如，领导人将语言、文化和地缘政治视为持续的挑战。人们还普遍认为，总部设在美国的公司和基金会在塑造大多数开源项目方面具有巨大的影响力。

Among the first challenges raised by interviewees is the tech industry's long history of systemic discrimination, including its deeply entrenched sexism and its dismal record on diversity and inclusion. Interviewees suggest that open source communities are not immune to these challenges, despite the community's efforts to address them. "Some parts of the open source world still feel like old school 'bro' culture," said Mark Surman of the Mozilla Foundation. "That's a big issue in a world where diversity of thought and experience are key assets."

受访者提出的首要挑战之一是科技行业长期存在的系统性歧视，包括根深蒂固的性别歧视，以及在多样性和包容性方面的糟糕记录。受访者表示，尽管社区努力应对这些挑战，但开源社区并不能幸免。Mozilla 基金会的 Mark Surman 表示：“开源世界的一些地方仍然感觉像是老派的‘兄弟’文化。”。“在一个思想和经验多样性是关键资产的世界，这是一个大问题。”

Open source leaders fear that a failure to address the open source community's "bro" culture will curtail its access to talent and ingenuity. "The people who don't feel welcomed will build technology in other ways," said Surman. "Unfortunately, that could mean that the best talent will build proprietary technology because they don't have the time and resources to contribute for free."

开源领袖担心，如果不能解决开源社区的“兄弟”文化，将限制其获取人才和创造力的机会。Surman 说：“那些感觉不受欢迎的人会以其他方式构建技术。”。“不幸的是，这可能意味着最优秀的人才将建立专有技术，因为他们没有时间和资源免费贡献。”

Ramon Roche, general manager of the DroneCode Foundation, argues that another cultural barrier to global participation is the lack of acceptance of open source methods and principles in some regions. "In Latin America, we still lack validation that open source is a key component of success and a valid way to produce software," said Roche. "Managers and decision-makers don't understand how the open source community works, and develop- ers often fight uphill battles to contribute to open source efforts."

DroneCode 基金会总经理 Ramon Roche 认为，阻碍全球参与的另一个文化障碍是在某些地区缺乏对开源方法和原则的接受。Roche 表示：“在拉丁美洲，我们仍然缺乏对开源是成功的关键组成部分和生产软件的有效途径的验证。”。“管理者和决策者不了解开源社区是如何运作的，开发人员经常为了为开源工作做出贡献而进行艰苦的斗争。”

When Roche started creating open source code for drones 10 years ago in Mexico, he struggled to find a vibrant open source community locally and lacked the know-how to build one from scratch. "There was nowhere to go for support or help," said Roche. "Most of the open source organizations are based in North America. The estab- lished tech players like Google, Meta, and Microsoft, and the people that work there, control what is going on. They lead steering commit- tees as well. You need to finance your seat or be a maintainer or top contributor to be visible and influential in the community."

10年前，当 Roche 在墨西哥开始为无人机创建开源代码时，他很难在当地找到一个充满活力的开源社区，并且缺乏从头开始构建开源社区的诀窍。“没有地方可以寻求支持或帮助，” Roche 说。“大多数开源组织都设在北美。像谷歌、Meta 和微软这样的老牌科技公司，以及在那里工作的人，控制着正在发生的事情。他们还领导着指导委员会。你需要为自己的席位提供资金，或者成为维护者或最高贡献者，才能在社区中有影响力。”

Reflecting on the Japanese experience, Noriaki Fukuyasu, VP of Japan Operations at the Linux Foundation, says the pace of innova- tion is slower than in North America, and enterprise IT managers are less comfortable with open source. "We have fewer engineers on the user side driving innovation," said Fukuyasu. "They prefer what they perceive to be the more stable, proprietary solutions, and their reticence to experiment is slowing down transformation."

北美参与者的霸权反过来也会掩盖源自世界其他地区的开源项目。Roche 表示：“拉丁美洲的开发者和软件初创公司希望看到更多人承认我们的存在。”。“拉丁美洲的项目常常被忽视。如果你积极寻找它们，整个大陆都有社区和公司，但它们却位于开源社区的核心之外。”

The hegemony of North American participants, in turn, can over- shadow open source projects that originated in other parts of the world. "Latin American developers and software startups would like to see more acknowledgment that we exist," said Roche. "Projects in Latin America are often overlooked. If you actively look for them, there are communities and companies across the conti- nent, but they sit outside the core of the open source community."

Linux 基金会日本运营副总裁 Noriaki Fukuyasu 在反思日本的经验时表示，创新的步伐比北美慢，企业IT经理对开源不太满意。Fukuyasu 表示：“我们在用户端推动创新的工程师更少。”。“他们更喜欢他们认为更稳定、更专有的解决方案，他们对实验的沉默正在减缓转型。”

Even when Japanese enterprises adopt OSS, they are less likely to contribute their modifications back into the upstream code. "They use open source, but they tend to modify locally," said Fukuyasu. "They rarely apply the new patches, even though the patches and fixes exist." Fukuyasu attributes the dearth of engagement to the fact that Japanese enterprises outsource much of their IT manage- ment to external vendors. "They don't see open source as a core competence and, as a result, the community of open source devel- opers is quite small relative to the United States."

即使当日本企业采用 OSS 时，他们也不太可能将其修改贡献回上游代码。Fukuyasu 说：“他们使用开源，但倾向于在本地进行修改。”。“他们很少应用新的修补程序，即使修补程序和修复程序存在。” Fukuyasu 将缺乏参与归因于日本企业将大部分IT管理外包给外部供应商的事实。“他们不认为开源是一项核心能力，因此，与美国相比，开源开发者的社区相当小。”

For the community of open source developers in Japan, it can take time to adjust to open source norms. "Culturally, people are not comfortable showing off their thoughts in public forums, online chats, and mailing lists," said Fukuyasu. "Language is also a big issue. For example, delaying the translation of project mate- rials when launching a new project can significantly slow down adoption by the Japanese community."

对于日本的开源社区开发者来说，适应开放源码规范可能需要时间。Fukuyasu 说：“从文化上讲，人们不愿意在公共论坛、在线聊天和邮件列表中炫耀自己的想法。”。“语言也是一个大问题。例如，在启动一个新项目时，推迟项目材料的翻译可能会大大减缓日本社区的采用。”

The building blocks for global inclusion​

全球包容的基石​

"The scale of the challenge is much larger now because of growing participation." - JIM ZEMLIN

“由于越来越多的参与，现在挑战的规模要大得多。”-JIM ZEMLIN

Creating a more equitable balance of power and promoting global inclusion are critical to the future of open source, especially its talent pool. So, what can the open source community do to avoid fragmentation along regional and cultural fault lines? Key sugges- tions include championing diversity and inclusion, investing in better translation, fostering professionalism, educating participants about open source norms, and using in-person events to build trust.

创造更公平的力量平衡和促进全球包容对于开源的未来至关重要，尤其是对其人才库而言。那么，开源社区可以做些什么来避免地区和文化断层的分裂？关键建议包括倡导多样性和包容性，投资于更好的翻译，培养专业精神，教育参与者了解开源规范，以及利用面对面活动建立信任。

Open source leaders say that policies and practices that foster diversity and inclusion are vital starting points. "It's not only about gender," said Alan Clark of SUSE. "Diversity is also about being aware of the different cultures within our global developer community and ensuring that community methods are inclusive." Clark says collaboration is part of the DNA at SUSE and claims that executives have made efforts to understand and adapt the company's pro- cesses to the unique cultural dynamics in different regions of the world. "Diversity is increasingly key to building a strong talent pool. You can bring in new perspectives and insights. That integration of global perspectives has made open source more successful."

开源领袖表示，促进多样性和包容性的政策和做法是至关重要的起点。SUSE的 Alan Clark 表示：“这不仅仅关乎性别。”。“多样性也意味着了解我们全球开发者社区中的不同文化，并确保社区方法具有包容性。” Clark 表示，合作是SUSE DNA的一部分，并声称高管们已经努力了解并调整公司的流程，以适应世界不同地区的独特文化动态。“多元化越来越成为建立强大人才库的关键。你可以引入新的观点和见解。这种全球视角的融合使开源更加成功。”

Jim Zemlin of the Linux Foundation argues that open source projects should also have DEI requirements but that policies alone are insufficient. "Having a set of collective cultural norms is key," said Zemlin. "But the scale of the challenge is much larger now because of growing participation from around the world." Zemlin points out that social coding platforms can help identify challenges in integrating diverse participation by measuring the form and nature of collaboration. "In 2022, project leaders and open source companies can measure every digital engagement touchpoint. Are there small voices and loud voices? Are you successfully onboard- ing new developers? How long does it take for individuals to con- tribute to discussions actively?"

Linux基金会的Jim Zemlin 认为，开源项目也应该有DEI要求，但仅靠政策是不够的。Zemlin 说：“有一套集体文化规范是关键。”。Zemlin 指出，社交编码平台可以通过衡量协作的形式和性质，帮助识别整合不同参与的挑战。“2022年，项目负责人和开源公司可以衡量每一个数字参与接触点。是否有小的声音和大的声音？您是否成功地加入了新的开发人员？个人需要多长时间才能积极参与讨论？”

Digital engagement data can inform decision-making. Then it's up to leaders to foster a project ethic and culture that attracts diverse participants. "What people miss is the aspect of highly skilled individual leadership," said Zemlin. "You need a technical subject matter expert with the human qualities to lead. And not just people but also the companies who are participating. Pulling these diverse international networks together takes a lot of capability."

数字参与的数据可以为决策提供信息。然后由领导者来培养吸引不同参与者的项目伦理准则和文化。Zemlin 说：“人们怀念的是高度熟练的个人领导力。”。“你需要一个具有人类素质的技术主题专家来领导。不仅是人，还包括参与其中的公司。将这些多样化的国际网络拉到一起需要很多能力。”

An essential task for project leaders is taming the macho "bro" culture that pervades today's tech world. "We insist on a profes- sional culture," said Mike Milinkovich of Eclipse. "To increase inclu- sion, you must focus on professionalism in your dialogue and behavior. Keeping things professional helps smooth cultural differ- ences around conflict resolution and project communication."

项目领导者的一项基本任务是驯服当今科技界弥漫的男子汉“兄弟”文化。“我们坚持职业文化，”Eclipse的 Mike Milinkovich 说。“为了提高包容性，你必须在对话和行为中注重专业性。保持专业性有助于消除冲突解决和项目沟通方面的文化差异。”

"Rapid translation is the key to fostering greater engagement." - NORIYAKI FUKUYASU

“快速翻译是促进更多参与的关键。”-NORIYAKI FUKUYASU

At the operational level, open source leaders are also address- ing language translation challenges. English may be the lingua franca of the software world, but project leaders outside of North America insist that translating project communications into native languages drives broader participation. For example, Ramon Roche of the DroneCode Foundation claims that translation and language are genuine barriers in Latin America and has experi- enced the same challenges in engaging developers from Asia. "Asian communities have been eager adopters of our open source solutions for drones," said Roche. "We found that although they were using our software, they were not contributing very much back. So we hired a bilingual community manager, and she helped us reach those communities. We translated our materials into Korean and Chinese and have seen a large influx of new users." In addition to translating project materials, DroneCode started using popular messaging tools such as WeChat and then went to work translating its user interfaces. "Our Chinese membership picked up significantly once we organized a community to help with the user interface translation efforts," said Roche. "Companies that used to clone our work are now active participants."

在运营层面，开源领导者也在应对语言翻译挑战。英语可能是软件世界的通用语言，但北美以外的项目负责人坚持认为，将项目沟通翻译成母语可以促进更广泛的参与。例如，DroneCode基金会的 Ramon Roche 声称，翻译和语言在拉丁美洲是真正的障碍，在吸引来自亚洲的开发人员方面也遇到了同样的挑战。 Roche 表示：“亚洲社区一直积极采用我们的无人机开源解决方案。”。“我们发现，虽然他们在使用我们的软件，但他们并没有做出太多贡献。所以我们聘请了一位双语社区经理，她帮助我们接触这些社区。我们将我们的材料翻译成韩语和中文，并看到了大量新用户的涌入。”除了翻译项目材料，DroneCode开始使用微信等流行的消息传递工具，然后开始翻译其用户界面。 Roche 表示：“一旦我们组织了一个社区来帮助用户界面翻译工作，我们的中国会员数量就大大增加了。”。“过去克隆我们工作的公司现在是积极的参与者。”

Manual translation is time-consuming and expensive, so open source leaders see machine translation as the future. Linux Foundation Japan, for example, is working with Japanese institutes to implement machine translation systems that will speed up the translations of project materials and user interfaces. "Rapid trans- lation is the key to fostering greater engagement," said Noriaki Fukuyasu. "We are working on it 24/7. The scale of the translation challenge has exceeded what can be done by human resources."

人工翻译耗时且昂贵，因此开源领导者将机器翻译视为未来。例如，日本 Linux 基金会正在与日本研究所合作，实施机器翻译系统，以加快项目材料和用户界面的翻译速度。Noriaki Fukuyasu 表示：“快速翻译是培养更大参与度的关键。”。“我们正在全天候工作。翻译挑战的规模已经超过了人力资源所能完成的任务。"

Fukuyasu and others also argue that the return of in-person events in the post-COVID-19 era will expand the person-to-person connec- tions required to solidify trust in the community. "Japanese people are generally reluctant to contribute until they have had an oppor- tunity to meet the people they are working with," said Fukuyasu. He explains that events build trust by allowing developers to establish a rapport with project maintainers. "COVID-19 put a hold on our Linux Foundation gatherings, but we are eager to get that going again to foster those international connections."

Fukuyasu 和其他人也认为，新冠肺炎后个人活动的回归将扩大巩固社区信任所需的人与人之间的联系。Fukuyasu 说：“日本人通常不愿意做出贡献，除非他们有机会与他们合作的人见面。”。他解释说，事件通过允许开发人员与项目维护人员建立密切关系来建立信任。“新冠肺炎病毒（COVID-19）暂时阻止了我们的 Linux 基金会集会，但我们渴望再次推动这一进程，以促进这些国际联系。”

Transcending Techno-Nationalism​

超越技术民族主义​

While global participation in open source is increasing dramat- ically, the rise of techno-nationalism is pulling in the opposite direction. The competition for national technological superiority is such that ecosystem leaders worry that geopolitical tensions could undermine the international collaboration on which the open source software community depends.

尽管全球对开源的参与在急剧增加，但技术民族主义的兴起却朝着相反的方向发展。国家技术优势的竞争使得生态系统领导人担心地缘政治紧张可能会破坏开源软件社区所依赖的国际合作。

For decades, technology has driven increased interconnectivity and global commerce. Yet, today, investments in technology and innovation are becoming inextricably bound up in geopolitical rivalries. In short, geopolitical rivals are engaged in an increasingly high-stakes contest to reign supreme in the technological sectors thought likely to dominate the 21st century, from robotics and arti- ficial intelligence (AI) to the industrial Internet and advanced telecommunications networks.

几十年来，技术推动了互联性和全球商业的增长。然而，今天，技术和创新投资正与地缘政治竞争密不可分。简而言之，地缘政治竞争对手正在进行一场日益激烈的竞争，以在被认为可能主导21世纪的技术领域中占据主导地位，从机器人和人工智能（AI）到工业互联网和先进的远程通信网络。

Alex Capri of the National University of Singapore defines tech-no-nationalism as "a mercantilist behavior that links a nation's tech capabilities and enterprise with issues of national security, economic prosperity, and social stability."¹⁵ This new brand of techno-nationalism has seen countries worldwide move to restrict the transfer of critical innovations beyond national borders, believing that doing so will spur national economic growth and foster domestic competitive advantages. As a case in point, Capri cites "the steady progression of export controls on tangible, hard technology, followed by restrictions on data access and usage, and, most recently, new controls ... that will impede the free movement and development of human capital."

新加坡国立大学（National University of Singapore）的 Alex Capri 将技术民族主义定义为“将一个国家的技术能力和事业与国家安全、经济繁荣和社会稳定问题联系起来的重商主义行为”。¹⁵ 这一新的技术民族主义标志着世界各国开始限制关键创新在国界之外的转移，相信这样做将刺激国家经济增长，并培育国内竞争优势。作为一个例子， Capri 引用了“有形硬技术出口管制的稳步推进，随之而来的是对数据访问和使用的限制，以及最近的新管制……这将阻碍人力资本的自由流动和发展。”

Some public and private sector leaders believe that borderless technologies will transcend these nationalist tendencies and drive increased interconnectivity in the years ahead, just as they have in the two decades prior. For example, at a recent meeting of the World Economic Forum, Jayraj Nair, chief technology officer of IT services company Wipro, argued that technology will only acceler- ate globalization. "As far as technology is concerned, the scaling of AI, or 5G, or blockchain, any of these technologies will increase the velocity [of globalization]," said Nair. "In fact, the velocity will only exponentially escalate."¹⁶

一些公共和私营部门领导人认为，无边界技术将超越这些民族主义倾向，并在未来几年推动互联互通，就像二十年前一样。例如，在世界经济论坛最近的一次会议上，IT服务公司 Wipro 的首席技术官 Jayraj Nair 认为，技术只会加速全球化。Nair 表示：“就技术而言，人工智能、5G或区块链的规模化，这些技术中的任何一项都将提高全球化的速度。”。“事实上，速度只会呈指数级增长。”¹⁶

Other observers are less sanguine and forecast a new era of deglobalization due to the increased geopolitical tensions and the rise of protectionist measures deployed by various nations. In 2019, for example, Beijing took aim at American technology companies by ordering its government agencies and public institutions to stop using foreign-made computers and software. More recently, Washington broadened the scope of the advanced technologies covered by its export control regulations to include semiconduc- tors. In addition to stemming the flow of critical technologies, Washington is also pursuing a worldwide campaign to block the adoption of 5G wireless technology developed by Chinese telecom giant Huawei. ¹⁷ The net effect of these measures is a decoupling of strategic rivals from global supply chains, digital platforms, and knowledge networks.

其他观察人士则不那么乐观，他们预测，由于地缘政治紧张局势加剧，以及各国采取的保护主义措施增多，将进入一个新的去极端化时代。例如，2019年，北京命令其政府机构和公共机构停止使用外国制造的计算机和软件，以此打击美国科技公司。最近，华盛顿扩大了其出口管制条例所涵盖的先进技术的范围，将半导体制造商包括在内。除了阻止关键技术的流动，华盛顿还在全球范围内开展运动，阻止采用中国电信巨头华为开发的5G无线技术。¹⁷ 这些措施的净效果是战略竞争对手与全球供应链、数字平台和知识网络脱钩。

Will techno-nationalism balkanize open source?​

技术民族主义会阻碍开源事业吗？​

How will techno-nationalism impact collaborative, knowledge-in- tensive activities such as the creation of OSS? Consultations for this study revealed a spectrum of opinions. On one end of the spectrum are those who think that techno-nationalism is fundamentally changing how global innovation networks operate by inserting political considerations into otherwise technical decisions about who participates, on what terms, and to what ends. Several indi- viduals consulted for the study pointed to concrete examples in which geopolitical tensions resulted in national or regional silos.

技术民族主义将如何影响诸如开源软件的创建等知识紧张的合作性活动？这项研究的咨询揭示了一系列意见。另一方面，有人认为技术民族主义正在从根本上改变全球创新网络的运作方式，将政治因素纳入到其他技术决策中，比如谁参与、参与的条件和目的。为研究咨询的几个个人指出了地缘政治紧张导致国家或地区孤立的具体例子。

Others see techno-nationalism as more of a looming threat than a real obstacle to open source collaboration at present. All agreed, however, that techno-nationalism poses a danger to global cooper- ation and that open source communities should commit to politi- cal neutrality.

其他人则认为，技术民族主义更多地是一种迫在眉睫的威胁，而不是目前开源合作的真正障碍。然而，所有人都同意，技术民族主义对全球合作构成危险，开源社区应致力于政治中立。

"Code review in OSS is about improving the code quality and building trust between developers," said Han Xiao, the Berlin-based founder of Jina AI, a commercial OSS company. "Adding politics to the code review will hurt both and eventually roll back the open source movement in China." ¹⁸ Xiao identified the creation of Gitee, a state-backed Chinese competitor to the international code repository platform GitHub, as a clear sign of nationalist prerogatives trumping the open source community's predilection for unencumbered global collaboration. Gitee has become a backup plan of sorts for Chinese organizations concerned the U.S. might someday change its laws in an attempt to exclude Chinese participants from open source codebases. That is a highly unlikely scenario, given that open source is publicly available and that it is impossible to block any one country's access, but it has factored into backup plans.

“OSS 中的代码审查是为了提高代码质量，建立开发者之间的信任，”商业 OSS 公司 Jina AI 的创始人 Han Xiao 表示。“在代码审查中加入政治因素将损害这两者，并最终使中国的开源运动倒退。”¹⁸ Xiao 认为，国家支持的中国国际代码库平台GitHub的竞争对手Gitee的创建，是民族主义特权战胜开源社区偏好无阻碍全球合作的明显标志。Gitee已经成为一些中国组织的备份计划，他们担心美国有朝一日可能会改变法律，试图将中国参与者排除在开源代码库之外。鉴于开源是公开的，不可能阻止任何一个国家的访问，但这已经成为备份计划的一部分，这是极不可能的情况。

"Geopolitical conflicts and tensions are fragmenting the open source community around national interests."

“地缘政治冲突和紧张局势正在围绕国家利益分裂开源社区。”

Rebecca Arcesati, an analyst at the Mercator Institute for China Studies, also sees Gitee and similar homegrown Chinese alter- natives to foreign-owned platforms as part of a broader attempt by the Chinese government to lessen the country's reliance on American tech giants and insulate the domestic open source com- munity from risks arising from geopolitical tensions. Arcesati argues most Chinese developers don't want to be cut off from global open source networks and are circumspect about China's direction. "The more Beijing tries to nationalize open source and create an indigenous ecosystem, the less eager developers will be to participate in what they perceive to be government-led open source projects," said Arcesati.¹⁹

墨卡托中国研究所（Mercator Institute for China Studies）的分析师 Rebecca Arcesati 也认为，Gitee和类似的中国土生土长的外资平台是中国政府更广泛努力的一部分，目的是减少该国对美国科技巨头的依赖，并使国内开源社区免受地缘政治紧张局势带来的风险。Arcesati 认为，大多数中国开发者不想与全球开源网络隔绝，对中国的发展方向持谨慎态度。Arcesati 表示：“北京方面越是试图将开源国有化，创建本土生态系统，开发商就越不愿意参与他们认为是政府主导的开源项目。”。¹⁹

Peixin Hou, chief software architect and community director for Open Source of Huawei, is another of those who see evidence that geopolitical conflicts and tensions are fragmenting the open source community around national interests. He says Chinese users and developers of OSS are concerned that the U.S. government might expand its trade restrictions into the open source world, which would be harmful to both sides and eventually undermine collabo- rative innovation between nations.

华为开源首席软件架构师兼社区总监Peixin Hou是另一位看到地缘政治冲突和紧张局势正在围绕国家利益分裂开源社区的人。他表示，OSS 的中国用户和开发者担心美国政府可能会将其贸易限制扩大到开源世界，这将对双方都有害，并最终破坏国家间的合作创新。

Hou and others voiced concerns that forks could emerge in key software platforms to enable national economies to control aspects of the technology domestically. And then there is the risk that techno-nationalism could diminish the global open source talent pool. "Developers in China have concerns," said Hou. "Will contributors from certain countries be discriminated against when they participate in open source projects? Could concerns about national security lead developers to reduce their participation if geopolitical tensions escalate further?" Hou worries that tech- no-nationalism runs the risk of excluding a significant source of talent and ingenuity. "The trust between developers and open source communities has traditionally depended upon the contri- butions of individual developers instead of his or her country of origin or organizational affiliation, but is this going to change?" asks Hou.

Hou 和其他人表示担心，关键软件可能会出现分叉, 从而使国家经济能够在国内控制技术的各个方面。此外，还有技术民族主义可能会削弱全球开源人才库的风险。“中国的开发商有担忧，” Hou 说。“当某些国家的贡献者参与开源项目时，他们会受到歧视吗？对国家安全的担忧会导致开发者减少他们的参与吗？如果地缘政治紧张局势进一步升级？”侯担心，技术民族主义可能会排除一个重要的人才和创造力来源。“开发人员和开源社区之间的信任传统上取决于单个开发人员的贡献，而不是其原籍国或组织从属关系，但这会改变吗？” Hou 问。

The ongoing conflict between Russia and Ukraine has also raised alarm bells for some open source projects. Ramon Roche of the DroneCode Foundation says the war in Ukraine has changed everything. "Drones are being widely deployed in the conflict," said Roche, "and that brings the security and safety of the supply chains into critical focus." Roche says the U.S. and European coun- tries only want drones developed by trusted manufacturers. "They also want to ensure that foreign entities are not embedding mali- cious code in the open source systems for the drones."

俄罗斯和乌克兰之间持续的冲突也给一些开源项目敲响了警钟。DroneCode基金会的 Ramon Roche 表示，乌克兰战争改变了一切。“无人机在冲突中被广泛部署，” Roche 表示，“这将供应链的安全和保障纳入了至关重要的重点。” Roche 表示美国和欧洲国家只希望无人机由值得信赖的制造商开发。“他们还希望确保外国实体不会在无人机的开源系统中嵌入恶意代码。”

"Europeans see open source as an opportunity to enhance digital autonomy and sovereignty and lessen their dependence on US tech giants." - ASTOR NUMMELIN-CARLBERG

“欧洲人将开源视为增强数字自主性和主权、减少对美国科技巨头依赖的机会。”-ASTOR NUMMELIN-CARLBERG

For years, the DroneCode Foundation worked closely with Chinese developers. As of now, Roche says end users from certain regions can't use software or hardware developed by Chinese compa- nies. "We want open collaboration," said Roche. "We don't want to exclude any developers. They can make valuable contributions, and they can be totally innocuous. Unfortunately, we also have a big Russian community that has completely stopped contributing. We don't even talk now. We had active contributors. We had com- panies doing research and development in the drone space. They are now completely out of the loop."

多年来，DroneCode基金会与中国开发者密切合作。到目前为止， Roche 表示，某些地区的终端用户不能使用中国公司开发的软件或硬件。 Roche 表示：“我们希望开放合作。”。“我们不想排斥任何开发者。他们可以做出有价值的贡献，而且可以是完全无害的。不幸的是，我们还有一个俄罗斯大社区，已经完全停止了贡献。我们现在甚至都不谈。我们有积极的贡献者。我们有一些公司在无人机领域进行研究和开发。他们现在完全脱离了圈子。”

Astor Nummelin Carlberg of OpenForum Europe claims techno-nationalism is also rearing its head in Europe. "The issue of exclud- ing companies and other participants from standards bodies and open source projects based on nationality has become quite contentious," said Carlberg. He notes that there have been cases where European companies have been unwilling to participate in international open source projects in which Chinese compa- nies are also present because of the perceived legal uncertainties and the risk of a policy backlash at home. At the same time, he sees European policymakers attempting to insert national objec- tives into open source projects. "Europeans see open source as an opportunity to enhance digital autonomy and sovereignty and lessen their dependence on U.S. tech giants," said Carlberg. As a result, "European countries often push for greater European par- ticipation in standards bodies, and there are discussions around the creation of uniquely open source projects and foundations."

OpenForum Europe的Astor Nummelin Carlberg声称，技术民族主义也在欧洲抬头。Carlberg 说：“将公司和其他参与者排除在标准机构和基于国籍的开源项目之外的问题已经变得非常有争议。”。他指出，由于法律上的不确定性和国内政策反弹的风险，欧洲公司一直不愿参与中国公司参与的国际开源项目。与此同时，他看到欧洲决策者试图将国家目标纳入开源项目。Carlberg 表示：“欧洲人将开源视为增强数字自主性和主权、减少对美国科技巨头依赖的机会。”。因此，“欧洲国家经常推动欧洲在标准机构中的参与，并围绕创建独特的开源项目和基金会展开讨论。”

Tackling techno-nationalism with transparency and trust​

以透明度和信任应对技术民族主义​

Despite widespread concerns, there is considerable confidence among open source leaders that transparent open source protocols can help the community transcend techno-nationalist tendencies.

尽管存在广泛的担忧，但开源领袖们仍有相当大的信心，认为透明的开源协议可以帮助社区超越技术民族主义倾向。

Alan Clark of SUSE says he sees the risks of techno-nationalism. "It's hard to counter it," he said. "However, the solution is to be open. You can alleviate many concerns about the subversion of code to national interests or other agendas by being open and transparent with your communications and recording all your decisions and how you arrived at those decisions. We need OSS development to transcend national interests. Otherwise, we risk real fragmentation."

SUSE的Alan Clark 克表示，他看到了技术民族主义的风险。“很难对抗，”他说。“然而，解决方案是开放的。你可以通过公开透明的沟通和记录你的所有决定以及你如何做出这些决定，来缓解人们对代码颠覆国家利益或其他议程的担忧。我们需要开源软件的开发，以超越国家利益。否则，我们面临真正的分裂风险。”

Chris Aniszczyk, chief technology officer of the Linux Foundation, notes that mature OSPOs are increasingly helping their organizations navigate project politics and overcome any proclivities toward techno-nationalism. Aniszczyk argues that OSPOs can help organizations "understand and navigate project politics, such as maintaining a neutral stance when multiple influential actors are attempting to steer a project or illuminating the latent political considerations of community members." He suggests that "OSPOs can help companies maintain a neutral posture on techno-nationalism and bridge political differences by cultivating personal and working relationships that transcend national boundaries and political realms. Increasingly, this value extends to the work of foundations and nonprofits, as those realms become important neutral spaces in open source."²⁰

Linux基金会的首席技术官 Chris Aniszczyk 指出，成熟的OSPO（开源办公室）越来越能帮助他们的组织应对项目政治并克服任何倾向于技术民族主义的倾向。Aniszczyk认为，OSPO可以帮助组织“理解和应对项目政治，例如在多个有影响力的参与者试图引导一个项目时保持中立立场，或揭示社区成员的潜在政治考虑。”他建议，“ OSPO 可以通过培养跨越国界和政治领域的个人和工作关系，帮助公司保持技术民族主义上的中立立场并弥合政治分歧。越来越多地，这个价值观延伸到基金会和非营利组织的工作，因为这些领域成为开源中重要的中立空间。”²⁰

"The open source community is a great stage for track two diplomacy." - ROD BECKSTROM

“开源社区是第二轨道外交的绝佳舞台。”-ROD BECKSTROM

Ramon Roche of the DroneCode Foundation agrees that transpar- ent protocols are the key to ensuring that open source projects operate without geopolitical tensions influencing how and when they engage with talented developers**.** "If your infrastructure is secure, and you have robust processes for testing and deploying new software, then you can trust the source code no matter where it comes from," said Roche.

DroneCode基金会的 Ramon Roche 同意，透明协议是确保开源项目在不受地缘政治紧张局势影响的情况下运行的关键。“如果您的基础设施是安全的，并且您拥有测试和部署新软件的强大流程，那么无论源代码来自何处，您都可以信任源代码。” Roche 说。

Rod Beckstrom goes even further, suggesting that open source communities could provide informal bridges to help reconcile geo- political tensions. "Look at science and its rapid progression on so many fronts," said Beckstrom. "The progress continues despite the politics and the tensions between the U.S. and China." He expects open source will follow a similar trajectory to other scientific dis- ciplines. "In fact, the open source community is a great stage for track two diplomacy," said Beckstrom. "We need to build mutual trust and respect. Open source collaboration provides an opportu- nity for informal networking and relationship building."

Rod Beckstrom 更进一步，他建议开源社区可以提供非正式的桥梁，帮助调和地缘政治紧张局势。 Beckstrom 说：“看看科学及其在许多方面的快速发展。”。“尽管美国和中国之间存在政治和紧张关系，但进展仍在继续。”他预计开源将遵循与其他科学学科类似的轨迹。 Beckstrom 说：“事实上，开源社区是第二轨道外交的绝佳舞台。”。“我们需要建立互信和尊重。开源协作为非正式网络和建立关系提供了机会。”

In the end, open source leaders agree that countries that close off collaboration at national borders will be less successful than those that embrace global cooperation and its benefits. "Fragmentation due to techno-nationalist imperatives is inherently misguided," said Jim Zemlin. "Policymakers are the ones creating these tensions. Many don't even realize that they are giving up the good stuff because of a lack of trust, including faster times to market and the ability to leverage a much larger developer community."

最终，开源领导人一致认为，在国家边界上关闭合作的国家将比那些接受全球合作及其利益的国家更不成功。Jim Zemlin 表示：“由于技术民族主义的要求而导致的分裂本质上是错误的。”。“政策制定者是制造这些紧张局势的人。许多人甚至没有意识到，由于缺乏信任，他们正在放弃好东西，包括更快的上市时间和利用更大的开发商社区的能力。”

Breaking Down the Governance Silos​

突破治理壁垒​

Most of the early open source projects, including Linux and Apache, grew out of the voluntary efforts of a small but dispersed group of individuals. As the projects gained commercial traction, concerned stakeholders came together to create nonprofit orga- nizations that could provide the legal and economic infrastructure for ongoing community collaboration and make projects such as Linux less dependent on the individuals who initiated them. The resulting OSS foundations, including the Linux Foundation, the Apache Software Foundation, and others, are now integral to the open source ecosystem.

大多数早期开源项目，包括Linux和Apache，都是通过少数分散的个人自发努力而发展起来的。随着项目获得商业吸引力，相应的利益相关者聚集在一起创建了非营利组织，能够为正在进行的社区合作提供法律支持和经济基础，并减少诸如Linux这些项目对发起人个体的依赖。由此产生的OSS基金会，例如Linux基金会、Apache软件基金会等，如今都成为了开源生态系统的组成部分。

The creation of new open source projects has seen a commensurate increase in the number of new foundations. Javier Cánovas of the Universitat Oberta de Catalunya recently led an empirical study of open source foundations and found over 100 active entities across a wide range of open source projects.²¹ As Cánovas observes:

伴随着新开源项目的创建，新基金会的数量也有了相应的增加。加泰罗尼亚开放大学（the Universitat Oberta de Catalunya）的Javier Cánovas最近领导了一项关于开源基金会的实证研究，并在众多开源项目中发现了超过100个活跃的实体。²¹ Cánovas经过观察得出：

"The survival of an OSS project largely depends on its ability to retain developers, onboard new ones (i.e., newcomers), and create a community of users who promote its adoption and use. As these projects grow, developers tend to organize and build communities. Still, many lack formal governance models to structure and manage the (potentially large) community around them (and the challenges this implies). Support to deal with all kinds of organizational decisions (including legal and economic aspects) is a huge concern for all projects at this stage."

“一个OSS项目的存续在很大程度上取决于它是否有能力留下开发者、吸收新的开发人员（即新人），以及创建一个帮助其被采纳和使用的用户社区。随着这些项目的发展，开发者倾向于社区的组织和构建。尽管如此，许多公司仍然缺乏正式的治理模型来构建和管理其（可能很大的）外延社区（以及其中的挑战）。对执行各种组织决策（包括法律和经济方面）的支持是这个阶段所有项目的一大焦点。”

While mandates vary from organization to organization, foun- dations typically set the stage for collaboration on open source projects. The roles include building tools and processes to enable collaborative development, hosting a structured gover- nance process for steering the evolution of open source projects, handling legal issues (particularly around intellectual property licensing, trademarks, and patents), and engaging with policymak- ers and regulators. Many foundations also play a role in educa- tion, training, and marketing. Across these domains, foundations provide a legal entity to hire staff and raise funds to pay for activi- ties that benefit the community.

虽然各个组织的授权有所不同，但基金会通常会为开源项目的合作奠定基础。其作用包括构建可以支持开发的工具和流程，主持结构化的治理流程以指导开源项目的发展，处理法律事务（特别是关于知识产权许可、商标和专利的问题），以及与决策者和监管者进行沟通。许多基金会还在教育、培训和营销方面发挥作用。在这些领域中，基金会提供了一个法人实体来雇佣员工和筹集经费去资助有益于社区的活动。

The sheer number of foundations identified in Cánovas' empirical study raises a question as to whether the governance of OSS is now too diffuse to enable sufficient progress on the challenges facing the community. For example, has the proliferation of founda- tions created a crowded field that could ultimately impede efforts to develop global standards, address security vulnerabilities, and promote the adoption of open source solutions? And does a crowded field make it more difficult for interested stakeholders to determine how and where to allocate their time and resources?

实证研究过程中，Cánovas在确定基金会的实际数量时提出了一个问题，即当前的 OSS 治理是否过于分散，以至于无法在社区面临的挑战上取得足够的进展。例如，基金会的激增是否创造了一片红海，最终可能阻碍全球标准的制定、安全漏洞的解决和促进采用开源解决方案的努力？一个拥挤的领域是否会让感兴趣的利益相关者更难决定如何以及在哪里分配他们的时间和资源。

Several open source leaders consulted for the study agreed that the proliferation of open source foundations and projects has become problematic. They worry, for example, that the flurry of new open source projects and associations for narrow verticals will pull key stakeholders in too many directions. As one inter- viewee put it, "Quite frankly, none of the participants has a clue how to do open source. It is disconcerting. The probability of success is very low. Their scope is too narrowly focused. They don't understand that open source is a unique discipline they don't have the skills to master."

为该研究提供咨询的几位开源领导者一致认为，开源基金会和项目的激增已经成为问题。举例来说，他们担心新的开源项目和针对狭窄垂直领域的协会将把重要的利益相关者拉向过多的方向。正如一位受访者所言，“坦率地讲，没有一个参与者知道如何做开源。这让人感到不安。成功的希望渺茫。这些人的局限太狭窄了。他们不明白开源是一门独特的学科，并没有掌握相关技能。”

The proliferation of new foundations has already led some enter- prises to be more selective about how and where they engage. For example, Deborah Bryant, formerly of Red Hat, notes that her OSPO was spending more time re-evaluating the firm's participation in software foundations on a regular cadence to "ensure that [Red Hat was] getting a return on its investment."²²

新基金会的激增已经导致一些企业在参与方式和领域上更加挑剔。例如，曾受雇于红帽公司的Deborah Bryant表示，她的 OSPO 正在耗费更多时间来定期重新评估公司对软件基金会的参与，以“确保（红帽）从投资中获得回报”。²²

"As vendors, we must determine which foundations and projects our customers care about. It's time consuming." - ALAN CLARKE

“作为供应商，我们必须确定我们的客户关心哪些基金会和项目。这是一件很耗时的事情。” ——ALAN CLARKE

Meanwhile, Alan Clarke of SUSE acknowledges that foundations are businesses and that they ultimately compete for members and revenues. But the imperative to increase memberships and revenues by launching new projects creates what he and others describe as "vendor fatigue" and "engagement overload." "Foundations create projects to address the sexy spaces in hopes that doing so will boost memberships and revenues," said Clark. "The result may be multiple different approaches to the same problem, and you get fragmented solutions. Then, as vendors, we must determine which founda- tions and projects our customers care about. Which projects will address the real market needs, and which will be successful? It's time-consuming."

与此同时，来自SUSE的Alan Clarke承认，基金会也是企业，他们最终所争夺的是会员和收益。但是，通过推出新项目来增加会员数量和收益的必然性，导致了大家所说的“卖方疲劳”和“用户参与过载”。Clark 表示：“基金会通过创建项目来提高吸引力，并希望借此增加会员数量和收益。”“结果可能是同一问题出现多种不同的解决方法，你会得到分裂的解决方案。因此，作为供应商，我们必须确定客户所关心的是哪些基金会和项目。哪些项目将满足真正的市场需求，哪些项目将获得成功？这是一件很耗时的事情。”

Nevertheless, some argued that creating new OSS foundations is justified if they can mobilize more efficiently and effectively to address narrower mandates defined by specific industries, regions, and application spaces. "Policymakers realize that open source is a vital part of the innovation economy," said Mike Milinkovich of the Eclipse Foundation. "To protect the future prosperity of their citizens, they need to understand and participate in open source. Inevitably there will be verticals and jurisdictions where stakehold- ers take solace from working with organizations that speak their language and have similar norms and legal frameworks."

尽管如此，一些人仍然坚信，如果能够更有效地动员新的 OSS 基金会来解决由特定行业、地区和应用空间定义的更垂直赛道，那么创建新的OSS基金会是合理的。“决策者意识到开源是经济创新的重要组成部分，”Eclipse基金会的Mike Milinkovich表示。“为了保护公民未来的繁荣，他们需要理解和参与开源。不可避免地，在某些领域和司法范围内，利益相关者会通过与说自己语言、拥有类似规范和法律框架的组织合作中获得安慰。”

Until recently, most of the OSS foundations were California-based organizations. However, as open source becomes increasingly global, many ecosystem leaders concede that the present and future gov- ernance of open source communities can't be located solely in California. "Sometimes you need specialized expertise or capabilities to address the needs of a particular vertical or region," said Jim Zemlin of the Linux Foundation. "For example, the E.U. is working on technology sovereignty and seeking to harness open source to lessen the influence of U.S. tech giants. If you want to access E.U. grant funding to contribute to relevant projects, you need European experts, and your organization must also be incorporated in the E.U." To that end, the Linux Foundation launched a European branch (Linux Foundation Europe) in September 2022 to strengthen its part- nerships with European constituencies and provide an on-ramp for European projects and companies seeking to harness open source solutions in the public and private sectors. ²³

到如今，大多数OSS基金会都设在了加利福尼亚。然而，随着开源变得越来越全球化，许多生态系统领导者都承认，开源社区目前和未来的治理将不会仅仅局限于加州。Linux基金会的Jim Zemlin表示:“有时你需要特定的专业知识或能力来满足特定垂直领域或地区的需求。”“例如，欧盟正在致力于技术主权，并试图利用开源来削弱美国科技巨头的影响力。如果你在相关项目上希望获得欧盟的资助，那么就需要聘用欧洲专家，你的组织也必须在欧盟国家注册。”鉴于此，Linux基金会于2022年9月成立了欧洲分支机构（Linux基金会欧洲），以加强与欧洲资助者的合作关系，并为寻求在公共和私营部门利用开源解决方案的欧洲项目和公司提供一个窗口。²³

In this sense, Milinkovich and Zemlin agree that one could inter- pret the creation of regional associations as a sign of success rather than a failure of global collaboration. They point to China, which is on the record as wanting to be an influential player in open source with its own associations and projects. "The European Commission may do the same," said Milinkovich. "These regional associations may be unsuccessful, but hopefully give rise to a com- petition of ideas."

从这个意义上讲，Milinkovich 与 Zemlin 都认为，人们可以把区域性协会的创立看作是全球合作成功的标志，而不是失败的标志。他们以中国为例，中方公开表示希望通过自己的协会和项目成为开源领域具有影响力的参与者。Milinkovich 说:“欧盟委员会可能也会效仿。“这些区域性协会不一定会取得成功，但非常有希望引导一场思维的竞赛。”

"All stakeholders consulted for the study agree that improved collaboration between open source foundations is required to address the ecosystem's challenges."

“参与这项研究的所有利益相关者一致认为，为了应对生态系统的挑战，需要改进开源基金会之间的合作。”

Whatever their feelings on the proliferation of new foundations and initiatives, all stakeholders consulted for the study agree that improved collaboration between open source foundations is required to address the ecosystem's challenges. Indeed, with modern tools, open source leaders see few excuses for not working together to address issues of shared concern. "The foundations should be insisting on open and broad collaboration to limit the duplication of effort," said Alan Clark of SUSE. "We need to find a way to align the projects. In fact, the projects themselves need to follow open source methods. The design and development pro- cesses should be transparent. The meetings and records should be open. The discussions and decision-making should be well docu- mented. In other words, the initiatives that foundations lead should be truly open source projects," said Clark.

无论对新基金会和新项目的激增抱有什么样的看法，所有参与研究的利益相关者都已经意识到，为了应对生态系统的挑战，需要改进开源基金会之间的合作。事实上，通过使用现代化工具，开源领袖们几乎没有了不想通过合作方式来解决共同关心问题的借口。SUSE的 Alan Clark 认为：“各个基金会应当坚持开放和广泛的合作，以规避重复工作。”“我们需要找到一种方法来协调这些项目。事实上，项目本身需要遵循开源方法。设计和开发过程应该是透明的。会议和记录要予以公开。讨论和决策应该有很好的文件记录。换句话说，基金会领导的项目应该是真正的开源项目。”

Mike Dolan of the Linux Foundation also sees an opportunity for larger open source foundations to provide an umbrella for smaller projects, reducing overlap and economizing on overhead and other resources. "We might launch five projects in a quarter. GitHub is launching 5,000 new projects a day," said Dolan. The challenge is that each has a unique set of stakeholders who want a neutral, growing project that enables new cost savings or market opportunities---and they want to work on them together. Foundations enable them to work together in a structured way. Dolan argues that it is difficult in many instances to curtail the creation of new projects. However, he sees a role for foundations in helping to align efforts and streamline operations. "This innova- tion is happening with or without us," said Dolan, "so what we're trying to do is to concentrate on a few projects that matter and provide an umbrella structure for projects with shared objectives to come together."

Linux基金会的 Mike Dolan 也分析了大型开源基金会为小型项目提供护佑的机遇：减少重叠，节约开销和其他资源。“我们可能会在一个季度推出五个项目。GitHub 每天推出5000个新项目，”Dolan 这样说。其中的挑战在于，每个公司都有一组独特的利益相关者，他们想要一个中立的、持续发展的项目，以实现新的成本节约或市场机会——他们想共同奋斗。基金会使他们能够以一种结构化的方式并肩协作。Dolan 认为，在许多情况下，限制新项目的创建是很困难的。不过，他看到了基金会在帮助协调各方努力和简化运营方面的作用。Dolan 表示：“不管有没有我们，这种创新都会发生，所以我们正在努力做的是专注于几个重要的项目，并为有共同目标的项目提供一个保护框架。”

Maintaining critical open source infrastructure​

关键开源基础设施维护​

One area urgently calling for increased collaboration is securing and safeguarding the vast patchwork of critical open source com- ponents. Decentralized innovation has produced a remarkable tapestry of open source components, and their deployment have widely supported the digital economy. However, maintaining the disparate components is a complex challenge that requires a transparent and coordinated approach and more significant funding and resources from organizations that draw value from open source infrastructure.

如果说哪个领域迫切需要加强合作，那无疑是海量关键开源组件的安全和保护。大量的开源组件在去中心化创新的过程中产生，它们的部署已经对数字经济提供了广泛支持。然而，对不同组件的维护也是一项复杂的挑战，需要采取透明和同步的方式，并向那些在开源基础设施中获益组织申请更多的资金和资源。

Cybercriminals and other malevolent networks are ramping up their attacks, making cybersecurity essential to safeguarding the global economy and defending critical infrastructure. As a result, industries and governments have invested considerable sums in correcting the frequent security issues plaguing proprietary software. However, the recent Log4Shell software vulnerabili- ties highlight the need for a commensurate effort to protect open source tools, which are just as critical and often more ubiquitous than their proprietary counterparts.

网络犯罪分子和其他恶意网络行为正在不断加大攻击力度，网络安全对于保护全球经济和保护关键基础设施变得至关重要。因此，行业和政府都投入了大量资金来治理那些频发的困扰专有软件的安全问题。然而，最近的Log4Shell软件漏洞突出表明，开源工具的保护也需要付出相应的努力，这些工具与专有工具一样重要，而且往往更普及。

Open source components are embedded in numerous pieces of critical infrastructure that provide the underpinnings for global commerce, from power grids, shipping, and transportation to electronic commerce and finance. Understanding which compo- nents are most widely used and most vulnerable to exploitation is crucial for the continued health of the open source ecosystem and the broader digital economy. As Jim Zemlin, executive director of the Linux Foundation, explains, "Hundreds of thousands of OSS packages are in production applications throughout the supply chain. Understanding what we need to be assessing for vulnera- bilities is the first step for ensuring long-term security and sus- tainability of OSS."²⁴ However, as the Laboratory for Innovation Science at Harvard points out, "it is difficult to fully understand the health and security of OSS because 1) OSS, by design, is distrib- uted in nature, so there is no central authority to ensure quality and maintenance, and 2) because OSS can be freely copied and modified, it is unclear how much OSS, and precisely what types of OSS, are most widely used."²⁵

许多关键基础设施中都嵌入了分裂开源组件，这些基础设施为全球商业提供的基础服务从电网、物流和交通直到电子商务和金融。了解哪些组件使用最广泛、最容易被利用，对于开源生态系统和更广泛数字经济的持续健康至关重要。正如Linux基金会执行董事Jim Zemlin所阐述的，“在整个供应链中，有数十万个 OSS 软件包处于应用程序的研发中。明确了解哪些漏洞需要评估，是确保OSS长期安全和可持续发展的首要任务。”²⁴ 然而，正如哈佛大学创新科学实验室所持的态度，“很难完全了解开源软件的健康和安全程度，因为：（1）从设计上讲，开源软件本质上是分布式的，没有一个权威中枢对其质量和维护进行保证；（2）因为开源软件可以自由复制和修改，目前尚不清楚有多少开源软件，或者更确切地说，哪种类型的开源软件被广泛使用。”²⁵

Tracking the proliferation of OSS and monitoring potential vulnera- bilities are complex tasks. Just as vexing, however, is the challenge of maintaining the vast number of critical OSS components in use today. As Kent Walker, Alphabet's president of global affairs, points out, "[In most cases] there's no official resource allocation and few formal requirements or standards for maintaining the security of critical open source code."²⁶ While high-profile projects, such as Linux, have active communities and receive regular attention, other projects are infrequently updated and have few watchers.

跟踪OSS的增长和监测潜在的漏洞是一项复杂的任务。然而同样令人烦恼的，是当下大量关键OSS组件投入使用的挑战。正如Alphabet的全球事务总裁Kent Walker所指出的一样，“在大多数情况下，没有官方的资源分配，很少有正式的规范或标准来保证关键开源代码的安全性。”²⁶“尽管Linux等高调的项目有活跃的社区并时刻被关注，但其他项目却不能经常更新，也很少有人注意。”

"Open source infrastructure is the classic small pieces, loosely joined with lots of independent components developed by small maintainers who are not necessarily compensated for their work," said Mark Surman. As the ecosystem addresses its sustainabil- ity challenges, Surman advises, "It is vital to remember that open source is a tremendous accelerator of innovation and the digital economy. It's not realistic to consolidate it all. So how can we ensure longevity? Are there ways to compensate those maintain- ers? Could we have a Patreon for open source components?"

Mark Surman认为：“开源基础设施是典型分裂，众多由小规模维护人员开发的独立组件被连接在一起，而这些维护人员的工作不一定会享受报酬。”在生态系统应对可持续性发展挑战的问题上，他建议到：“一定要牢记，开源是创新和数字经济的巨大加速器。全部加固是不现实的。那么，我们如何才能青春永驻呢?有补偿这些维护者的办法吗？我们也可以拥有一个Patreon来支持开源组件吗?”

In the absence of a distributed compensation and resourcing model, organizations such as the newly created Open Source Security Foundation (OpenSSF) will play a vital role in identifying critical com- ponents, assessing vulnerabilities, and establishing new commu- nity-based processes and standards for regular maintenance and testing. "The OpenSSF is an industry effort with a roving SWAT team," said Jim Zemlin. "They will identify the abandoned projects and then shore them up. The scorecard and SLSA frameworks we are working on are key to this. We can use these frameworks to identify the vulnerable components, including all the dependencies in the ecosystem, and then target resources to those unsupported or under-resourced areas."

在分散补偿和资源分配模型不足的情况下，一些像开源安全基金会（OpenSSF）之类新兴组织将在识别关键组件、评估漏洞和新建基于社区的定期维护和测试过程和标准等方面发挥至关重要的作用。 Jim Zemlin认为：“OpenSSF是一整个行业努力的成果，它拥有一个流动的SWAT小组。”“他们识别出一些即将中止的项目，然后予以支持。我们正在开发的记分卡和SLSA框架是其中的关键。我们可以使用这些框架来识别脆弱的组件，包括生态系统中所有的依赖项，然后让资源向到那些不受支持或资源不足的领域倾斜。”

"Many leaders consulted for the study would also like to see large enterprises and other significant beneficiaries pitching in to help sustain a thriving open source ecosystem."

“为这项研究提供咨询的许多领导者也希望大型企业和其他显著受益者参与其中，助力维持一个蓬勃发展的开源生态系统。”

In 2022, DARPA, the U.S. military's research arm, weighed in on the matter with a multi-million-dollar effort, over 18 months, to help identify malicious actors and prevent them from corrupting critical open source infrastructure. DARPA notes that much of the U.S. Department of Defense's computing infrastructure rests on a foun- dation of OSS. DARPA's so-called "Social Cyber" program will harness AI "to detect and counteract any malicious campaigns to submit flawed code, launch influence operations, sabotage development, or even take control of open-source projects." Part of the effort involves scouring through millions of lines of code to detect vulnerabilities. DARPA will also analyze social interactions on mailing lists and other forums to gain insight into the community of software developers who write, fix, implement, and influence that code. DARPA hopes that sentiment analysis deployed at scale will allow researchers to identify trustworthy contributors and the individuals and groups that justify extra vigilance.²⁷ However, the countereffect is that devel- opers and open source advocates see any government monitoring as potentially harmful and intrusive. Programs like this could lead to backlash from the same project communities that governments intend to support.

2022年，美国军方研究机构DARPA耗时18个月、耗资数百万美元，对恶意行为的识别工作进行支持，并阻止其破坏关键开源基础设施。DARPA 指出，美国国防部的大部分计算基础设施都基于OSS。DARPA 所谓的“社交网络”项目将利用人工智能“检测和抵消各种恶意行为，诸如提交有缺陷的代码，发起影响行动，破坏开发，甚至控制开源项目。”这些工作中有一部分就包括在数百万行代码中检测漏洞。DARPA 还将分析邮件列表和其他论坛上的社交互动，以深入了解编写、修复、实现和影响代码的软件开发社区。DARPA希望大规模部署的情绪分析可以帮助研究人员识别可信的贡献者，以及需要加以警惕的个人和团体。²⁷ 然而事与愿违，开发人员和开源倡导者都认为任何政府监控都带有潜在的危害性和入侵性。这种项目可能会在政府计划支持的项目社区中引起反弹。

Stormy Peters says GitHub is also trying to make it easier for devel- opers to make their software more secure by providing a free and open database of vulnerability information and enabling private vul- nerability reporting. However, many leaders consulted for the study would also like to see large enterprises and other significant benefi- ciaries pitching in to help sustain a thriving open source ecosystem.

Stormy Peters 表示，GitHub 还试图通过提供免费开放的漏洞信息数据库和授权定制漏洞报告，让开发人员更容易提高软件安全性能。然而，为该研究提供咨询的许多领导者也希望看到大型企业和其他重要受益者参与进来，共同为开源生态系统的蓬勃发展提供帮助。

"Technology consumers, especially the enterprises, have had a free ride for far too long," said Mike Milinkovich of Eclipse. "Some vendors include open source components in the products they use, yet enterprises rarely give anything back to the communities they rely upon for their application development. The sustainabil- ity problems are related to the lack of money and resources to do all the things that must be done." Peters agrees that the absence of funding for small project maintainers is a problem and notes that GitHub is also working on tools to help companies contribute finan- cial resources to maintaining critical infrastructure components.

Eclipse的Mike Milinkovich认为：“消费型科技，尤其是在企业中，搭了太长时间的便车。”“一些供应商在产品中包含开源组件，但很少向他们所依赖的应用程序开发社区提供任何回馈。可持续发展问题与缺乏资金、资源去处理那些必要的事情息息相关。”Peters也认可小型项目维护者缺乏资金已经成为问题，并指出GitHub也在致力于开发一些工具，帮助企业贡献经费资源来维护关键基础设施组件。

Milinkovich, Zemlin, Peters, and others claim that software vendors and enterprise users have received the memo that they need to engage in the communities from which they are drawing benefits. "It is time to recalibrate their engagement in light of where they get the code and what they need to do to ensure the code is properly main- tained and sustainable," said Milinkovich. "In the end, there is no free lunch." Zemlin points to Google (one of Alphabet's subsidiaries) as one of several good enterprise stewards that have stepped up to help make code libraries bulletproof.

Milinkovich、Zemlin、Peters等人声称，软件供应商和企业用户已经收到了一份备忘录，他们需要参与社区活动，以便从中获益。Milinkovich说:“这是一个恰当的时机，可以根据他们获得代码的渠道、采取何种措施来确保代码得到适当维护和可持续发展，来重新调整他们的参与程度。”“总之，天下没有免费的午餐。”Zemlin指出，谷歌（Alphabet的子公司之一）是几个优秀的企业管理者之一，他们已经开始帮助强化代码库。

In 2020, for example, more than 10% of Alphabet's full-time employ- ees (approximately 15,000) actively contributed to open source projects.²⁸ In addition to managing its own open source code repos- itories, Alphabet employees contribute to a vast pool of external projects and actively participate in boosting the security and sus- tainability of open source and its supply chain. In a significant sign of progress, hundreds of prominent enterprise and consumer tech- nology firms, ranging from Amazon to VMware, have established OSPOs and dedicate comparable proportions of their workforce to developing and maintaining open source projects.²⁸

例如，在2020年，超过10%的Alphabet全职员工（约15，000人）积极地为开源项目做出贡献。²⁸ 除了管理自己的开源代码库外，Alphabet的员工在大量的外部项目中做出了贡献，并积极参与提高开源及其供应链的安全性和可持续性。从亚马逊到VMware，数百家著名的企业和消费科技公司已经建立了 OSPO，并将相当比例的人力用于开发和维护开源项目，这是一个显著的进步现象。²⁹

Ultimately, Zemlin and others would prefer that the ecosystem address the sustainability challenge publicly, transparently, and collaboratively. "The complexity of the modern supply chain is such that we need a transparent and coordinated approach," said Zemlin. "We need coordinated disclosure of potential vulnerabili- ties. We need free training for maintainers of critical projects. We need regular auditing of specific projects. And in some cases, we need to augment the talent pool available to do the heavy lifting on maintaining critical components."

从源头上，Zemlin等人都更希望生态系统能够公开、透明、合作地应对可持续性挑战。Zemlin说:“现代供应链非常复杂，我们需要一种透明和协作的方法。”“我们需要协调一致地披露潜在的漏洞。我们需要为关键项目的维护人员提供免费培训。我们需要对具体项目进行定期审计。有的时候，我们还需要扩充可用的人才库，以完成维护关键组件的繁重工作。”

With so much at stake, Rod Beckstrom crystallizes the sense of urgency to act. "Global reliability is key," said Beckstrom, who spent much of his time as CEO of ICANN and director of the National Cybersecurity Center wrestling with the thorny issues of Internet governance and cybersecurity. "The market has to step in. Operation Global Blackout from Anonymous was a credible threat. The system is vulnerable, and we need to look closely at the central points of failure. That said, I don't worry too much about the open source systems. The ecosystem is rife with shep- herds and custodians. Open source has added tremendous value to human life. Some people will try to break it. Those efforts will likely fail. Bottom-up will win."

时不我待，Rod Beckstrom深知形势已经迫在眉睫。Beckstro在担任ICANN首席执行官和国家网络安全中心主任期间，耗费大量时间解决互联网治理和网络安全的棘手问题。他呼吁道：“关键是全球化可靠性。” “市场必须介入。来自匿名者的全球封锁行动是对可信化的威胁。这个系统是脆弱的，我们需要密切关注故障的中心点。实际上，我不太担心开源系统。生态系统中到处都是牧羊人和监护人。开源为人们生活带来巨大的价值。有人试图打破它，而这些努力很可能会失败。自下而上才能笑到最后。”

Increasing collaboration on technology policy and regulation​

强化在科技政策和监管方面的合作​

"The foundations would be much stronger if they worked together." - ALAN CLARKE

“如果他们齐心协力，基础会更加牢固。” ——ALAN CLARKE

Beyond cybersecurity, open source leaders consulted for the study point to a host of other Internet policy issues on which they argue there could be improved collaboration. For example, in critical matters such as intellectual property, privacy, and anti- trust, there is a widely shared view that the open source commu- nity has not been as influential or assertive in technology policy dialogues as it should.

除了网络安全之外，为这项研究提供咨询的开源领导者还指出了许多其他互联网政策问题，他们认为在这些问题上可以改善合作方式。例如，在知识产权、隐私和反垄断等关键问题上，人们普遍认为，开源社区在技术政策对话中没有发挥应有的影响力或判断力。

"Educating politicians can be an uphill battle," said Rod Beckstrom. "They don't always understand the complexities and nuances of Internet infrastructure and the related policy issues. But there is no shortage of critical policy issues where the open source view is needed, including patent issues, privacy, cybersecurity, antitrust, and beneficial AI."

Rod Beckstrom 称：“对政治家进行教育可能会是一场艰苦的战斗。”“他们并不总是理解互联网基础设施和相关政策问题的复杂性和细微差别。但在关键的政策问题上，也不缺乏开源观点，包括专利问题、隐私、网络安全、反垄断和有益的人工智能。”

The absence of a coordinated open source response to such issues has left the playing field open to domination by larger, better-resourced entities. "The big tech players with deep pockets and teams of lobbyists have tended to dominate the policy and regulatory conversations," said Alan Clark of SUSE. Clark says the open source community has been reactive rather than active on most policy issues. He and others would like to see open source foundations come together to propose new policies around security, transparency, privacy, and other pertinent matters. "The foundations would be much stronger if they worked together," said Clark. "The open source point of view is especially relevant today. We need an open source approach to solving global problems."

对上述问题缺乏配套的开源响应，导致竞争环境被规模更大、资源更好的实体所统治。SUSE的Alan Clark 表示：“拥有雄厚财力和游说团队的大型科技公司往往主导着政策和监管对话。”Clark 说，开源社区在大多数政策问题上一直处于被动位置而非主动。他和其他人希望看到开源基金会联合起来，围绕安全、透明、隐私和其他相关问题提出新的政策。Clark 认为：“如果大家合作起来，基础会更加牢固。”“开源的观点在今天尤为重要。我们需要一种开源的方法来解决全球性问题。”

Mike Milinkovich of Eclipse calls the relative absence of open source foundations in crucial policy debates a "sin of omission." "We are not a set of stakeholders that policymakers and politicians are accustomed to dealing with." However, Milinkovich also concedes that the current state of collaboration among open source foun- dations is "abysmal and almost non-existent." "Just looking after our own communities is hard enough," said Milinkovich. "Engaging with our peers is difficult. We don't have a good venue to do it. We also compete for members and projects. The bottom line is that we need to grow up and collaborate."

Eclipse 的 Mike Milinkovich 称，在关键政策辩论过程中，开源基金会的相对缺席是一种“疏忽之罪”。“我们是不政策制定者和政治家习惯于打交道的那种利益相关者。”然而，Milinkovich也承认，目前开源基金会之间的合作状态“糟糕透顶，几乎没有”。Milinkovich 说：“光是照料我们自己的社区就已经很难了。”“与同行交流很困难。我们没有一个合适的地点。我们还竞争会员和项目。唯独底线是需要成长和合作。”

"We need a repeatale and trustable process that achieves public policy goals through open source innovation." - GABRIELE COLUMBRO

“我们需要一个可复现、可信赖的流程，从而通过开源创新实现公共政策目标。” ——GABRIELE COLUMBRO

Jim Zemlin agrees that the foundations don't have a stellar track record of collaboration. However, he points out that open source is on the radar in the wake of the Log4Shell vulnerabilities. "Going forward, we have an opportunity to be much more influential in guiding the evolution of the Internet," said Zemlin. Mike Dolan adds that much of the behind-the-scenes work the Linux Foundation does may not be visible because it is not set up or resourced to be a full-time government education organization. "We do not have government education staff sitting full time in Washington, or Brussels, or Beijing, or Tokyo," said Dolan, "but we are here to protect the ability of open source communities to collaborate and thrive. We channel our members, brands, and capabilities into those efforts. I think it's been quite effective. Open source com- munities have been active since 1990, and, in that time, there has been no policy that killed open source. The reality is that we have big defenders. Microsoft, IBM, Red Hat, Google, Oracle, Intel, and others are equipped to stand up to the U.S. government if they try to do something that threatens the open source collaboration underpinning multi-billion dollar businesses they can't just walk away from."

Jim Zemlin 也认为，这些基金会在合作方面没有出彩的历史。然而，他同时指出，随着Log4Shell漏洞的出现，开源正在受到关注。Zemlin 说：“展望未来，我们有机会在引导互联网发展方面发挥更大的影响力。” Mike Dolan 补充到，Linux 基金会所做的许多幕后工作可能不为人所知，因为它不是一个全职的政府教育组织。“我们没有在华盛顿、布鲁塞尔、北京或东京从事全职工作的政府教育人员，” Dolan 说，“但我们在这里是为了保护开源社区合作和繁荣发展的能力。我们将会员、品牌和能力输送到这些努力之中。我认为这很有效。开源社区自1990年以来一直很活跃，并且从那时起，没有任何政策会扼杀开源。实际上我们有强大的守护者。微软、IBM、红帽、谷歌、甲骨文、英特尔和其他公司都有能力对抗美国政府，如果政府试图做一些事情，威胁到支持数十亿美元业务的开源合作，这些企业就不能坐视不管。”

Beckstrom argues that the open source community could increase its policy influence through lightweight coordination. "Convene a regular meeting circle of top foundation leaders," said Beckstrom. "Create a dialogue among the leaders, and identify the shared issues on which the ecosystem could collectively assert its voice. Then create a circle of the chief legal counsels. There could be a benefit from further collaboration between the policy leads."

Beckstrom认为，开源社区可以通过轻量级协调来增强其政策影响力。Beckstrom说：“召集顶级基金会领导者的定期会议。在领导者之间创建对话，并确定生态系统可以共同发声的共同问题。然后创建首席法律顾问的圈子。政策领域的进一步协作可能会带来益处。”

Astor Nummelin Carlberg of OpenForum Europe notes that there are challenges on the governmental side as well. "In Europe, we work with the European Commission around issues ranging from product safety to cybersecurity to privacy," said Carlberg. "However, many policies and regulations in those domains are still driven by national bodies. It requires a lot of resources and staffing to participate in policy deliberations across so many individual nation-states." Carlberg argues that creating OSPOs at the national level could provide an interface for discussions around policy and regulation and notes that France has built one and Germany is in the process of doing so. "We won't have a coherent voice if we work company-by-company and foundation-by-foundation."

OpenForum Europe的Astor Nummelin Carlberg指出，政府方面也存在挑战。Carlberg说：“在欧洲，我们与欧洲委员会合作解决从产品安全到网络安全和隐私等一系列问题。然而，许多政策和法规在这些领域仍然由国家机构推动。参与许多单独的国家政策讨论需要大量的资源和人员配备。” Carlberg认为，在国家层面创建OSPO可以为政策和法规讨论提供接口，并指出法国已经建立了一个OSPO，德国正在进行这样的工作。Carlberg表示：“如果我们逐个公司和基金会开展工作，我们将没有一个连贯的声音。”

More broadly, there is a global opportunity for the OSS community to position itself as a rich source of solutions for public policy issues. "The biggest frontier for open source is in the public sphere," said Gabriele Columbro of FINOS and Linux Foundation Europe. "The Linux Foundation has perfected its governance models for enabling collaboration with corporations and individuals. We need a similar model and pattern of engagement with the public sector." Columbro points to digital public services, healthcare, education, and climate change as significant opportunity spaces for open source solutions. "We need a repeatable and trustable process that achieves public policy goals through open source innovation."

进一步讲，OSS社区有一个全球化的机会，可以将自己定位成为公共政策问题解决方案的丰富来源。FINOS 和 Linux 欧洲基金会的Gabriele Columbro 说:“开源最大的前沿是在公共领域。”“Linux 基金会已经完善了与公司及个人合作的治理模型。我们需要与公共机构建立类似的合作模式。”Columbro 指出，数字公共服务、医疗保健、教育和气候变化是开源解决方案的重要机会领域。”“我们需要一个可重复和可信赖的过程，通过开源创新来实现公共政策目标。”

Conclusion​

结论​

In its purest form, OSS development is a way of producing software that relies entirely on self-organizing communities of individuals who come together voluntarily to work on a software project. However, most successful OSS communities mix elements of hierarchy and self-organization and rely on meritocratic principles of organiza- tion. In other words, the most skilled and experienced community members provide leadership and help integrate contributions from the community.

在其最纯粹的形式中，开源软件开发是一种完全依靠自我组织的个人社区自愿聚集在一起工作的方式。然而，大多数成功的开源社区都混合了等级制度和自我组织的元素，并依赖于组织的精英主义原则。换句话说，最有技能和经验的社区成员提供领导，并帮助整合社区的贡献。

This combination of decentralized innovation and effective leadership is integral to the long-term viability and success of open source projects. As Professor Christopher Yoo put it, "Success of an open source project depends on inspiring a community of people willing to work on it. In a real sense, an open source leader's authority depends on the existence of followers. In a world where all contributions are voluntary, and the community is always free to exit the community by forking the project, leaders' ability to retain their positions depends largely on their responsiveness to the needs of those led. These needs include providing fast feedback, serving as an effective moderator of technical disputes and personality conflicts, and realistic interim and long-term goals."³⁰

这种分散式创新和有效的领导力的结合对于开源项目的长期生存能力和成功至关重要。正如 Christopher Yoo 教授所说：“开源项目的成功取决于激发一群愿意为之工作的人的社区。从某种意义上说，开源领导者的权威性取决于追随者的存在。在所有贡献都是自愿的、社区始终可以通过分叉项目自由退出的世界中，领导者保留其职位的能力在很大程度上取决于他们对被领导者需求的反应性。这些需求包括提供快速反馈、作为技术争议和个性冲突的有效调解者、以及制定现实的中期和长期目标。” ³⁰

The Linux ecosystem provides an excellent example of how leader- ship and strong governance can reduce fragmentation. In the early days of Linux, Linus Torvalds' role as the project leader was instru- mental in averting the risk of fragmentation and project forking.

Linux生态系统提供了一个极好的例子，说明领导力和强有力的治理可以减少分裂。在Linux的早期，Linus Torvalds作为项目领导者的角色对避免分裂和项目分叉的风险起了重要作用。

Torvalds' status as Linux's creator made him the natural person to exercise authority over the community. When required, Torvalds did not hesitate to take action to prevent significant forks from emerging. However, he bolstered his authority by taking great care to document and justify his decisions. His dedication and sound judgment in managing the community fostered considerable goodwill, as did his deft touch in handling community politics and interpersonal dynamics. Ultimately, that transparency also enabled Linus to delegate decisionmaking for the codebase to core maintainers, who have over decades grown to be the core engine of contribution to and maintenance of the modern Linux kernel.

Torvalds 作为 Linux 的创始人，天然地成为行使社区权威的人。在需要时，Torvalds毫不犹豫地采取行动，防止出现重大分叉。然而，他通过认真记录和证明自己的决策来增强自己的权威性。他在管理社区方面的奉献精神和明智的判断力，培养了相当多的善意，他在处理社区政治和人际动态方面的娴熟手法也赢得了赞誉。最终，这种透明度也使Linus能够将代码库的决策委托给核心维护人员，他们在几十年的时间里成为现代Linux内核贡献和维护的核心引擎。

As Professor Yoo concludes, "To say that open source projects require a type of leadership that is somewhat different from the leadership that characterizes commercial companies that produce proprietary software is not to say that they need no leadership at all. On the contrary, ensuring that an open source platform does not fragment depends on the presence of an actor with sufficient authority to resolve disputes and to steer the platform in a beneficial direction."³¹

正如 Yoo 教授所总结的：“说开源项目需要的领导方式与生产专有软件的商业公司的领导方式有所不同，并不意味着它们不需要领导。相反，确保开源平台不会分裂取决于一个具有足够权威来解决争端并将平台引导到有益方向的行动者的存在。”³¹

In discussions for the study, open source leaders offered several additional concrete recommendations to address some of the pain points described in this report. We divide the recommendations into two broad categories: a) managing fragmentation in the development and governance of open source solutions and b) confronting techno-nationalism and fostering global inclusion.

在研究讨论中，开源领袖提供了几个额外的具体建议，以解决本报告中描述的一些痛点。我们将这些建议分为两大类：a) 管理开源解决方案的开发和治理中的分裂，b) 应对技术民族主义并促进全球包容。

Managing fragmentation​

管理分裂​

The recommendations for managing fragmentation in the development and governance of open source solutions include forging greater alignment between open source projects, strengthening inter-foundation collaboration, and harnessing open source maturity models to help identify robust code libraries and components.

管理开源解决方案开发和治理中的分裂的建议包括加强开源项目之间的协调，加强基金会间的合作，利用开源成熟度模型来帮助识别稳健的代码库和组件。

HARNESS MATURITY MODELS​

利用成熟度模型​

While open source leaders acknowledge some fragmentation-related challenges, they warn that "solving" the fragmentation problem risks killing the goose that laid the golden egg. "When people perceive fragmentation, they often look at it from a consumer point of view," said Mike Milinkovich of the Eclipse Foundation. "They see a broad landscape of possible solutions and wonder what is safe, what is supported, and what is sustainable." Rather than "solving fragmentation," Milinkovich and others suggest that an open source maturity model would make it easier to identify robust code libraries and components and thus focus the community's efforts. As Mike Dolan put it, "The proliferation of open source projects is not necessarily bad. It just means that there are many options out there. It also means that we need better filters to make it easy for developers and end users to discover the little modules that do things that are useful for them."

虽然开源领袖们承认了一些与分裂相关的挑战，但他们警告说，“解决”分裂问题可能会毁掉下金蛋的鹅。 “当人们看到分裂时，他们通常会从消费者的角度来看待它，” Eclipse基金会的Mike Milinkovich说道，“他们看到了许多可能的解决方案，想知道什么是安全的，什么是得到支持的，什么是可持续的。” Milinkovich和其他人建议，与其“解决分裂”，不如采用开源成熟度模型来更容易地识别出稳健的代码库和组件，从而集中社区的努力。正如Mike Dolan所说，“开源项目的扩散不一定是坏事，这只是意味着有很多选择。这也意味着我们需要更好的过滤器，以便开发人员和最终用户可以发现对他们有用的小模块。”

ENLIST SKILLED COMMUNITY MANAGERS​

征召熟练的社区经理​

If effective leadership is integral to successful open source projects, then skilled community managers are the foot soldiers for building high-performing collaboration networks.

如果有效的领导是成功的开源项目的不可或缺的一部分，那么有技能的社区经理是构建高效协作网络的步兵。

Unfortunately, in a world dominated by proprietary technologies, few people understand how to create and grow an open source ecosystem. However, Calista Redmond of RISC-V points out that technologists are adapting to a new way of working as open stan- dards increasingly overtake proprietary approaches. "Ethernet is a great example," said Redmond, "where proprietary approaches are now nearly nonexistent." Redmond and her colleagues have built the RISC-V community from scratch to become the world's most popular open and widely used microprocessor instruction set architecture standard. Along the way, RISC-V encountered numerous concerns about forking, especially when companies in the ecosystem identified missing pieces and had the temptation to develop proprietary solutions.

不幸的是，在一个被专有技术主导的世界里，很少有人了解如何创建和发展开源生态系统。然而，RISC-V 的 Calista Redmond 指出，随着开放标准逐渐取代专有方法，技术人员正在适应新的工作方式。“以太网就是一个很好的例子，”Redmond说，“在那里，专有方法现在几乎不存在了。”Redmond 和她的同事们从零开始建立了RISC-V社区，成为了全球最受欢迎的开放式和广泛使用的微处理器指令集架构标准。在此过程中，RISC-V 遇到了许多关于分叉的问题，特别是当生态系统中的公司发现缺失的部分并有诱惑开发专有解决方案时。

To avoid fragmentation in the community, Redmond and her team work hard to gather participants and align efforts on the missing pieces. "We have to run really fast to catch up with our community," said Redmond. "It's a different skill set. Most people have built proprietary strongholds. We need people who know how to orchestrate true collaboration. Our CTO comes from Sun Microsystems, where he was responsible for Solaris. He is very community-oriented. You need to find those people with the skills for ecosystem leadership."

为了避免社区的分裂，Redmond 和她的团队努力汇集参与者，并协调努力解决缺失的部分。Redmond 说，“我们必须跟上我们的社区。”这需要不同的技能。大多数人都建立了专有领地，我们需要那些知道如何协调真正协作的人。我们的首席技术官来自 Sun Microsystems，在那里他负责Solaris。他非常注重社区。你需要找到那些具备生态系统领导技能的人。

ALIGN OPEN SOURCE PROJECTS AROUND SHARED GOALS​

将开源项目围绕共同目标进行整合​

Open source foundations are reluctant to play a lead role in identi- fying and championing winning open source projects, arguing that picking winners is a marketplace function. However, leaders do see a need for better project curation and want foundations and other ecosystem participants to make greater efforts to align projects with similar objectives. "We nurture multiple projects, and some- times they overlap," said Gabriele Columbro, general manager of Linux Foundation Europe. "But the most mature foundations have a project life cycle where they can help coalesce efforts and even consolidate projects." Columbro says that survival of the fittest, or "open source Darwinism," will usually dictate which projects are ultimately sustainable. However, he and other open source leaders agree that bringing similar projects under a shared umbrella can eliminate duplication, economize overhead, and reduce so-called "vendor fatigue." In some instances, foundations could also do a better job killing or archiving projects. "We are very good at bringing projects in," said Columbro. "But it's equally important we do a great job cycling projects through the life cycle and shelving projects when necessary."

开源基金会不愿扮演识别和推广优胜开源项目的主导角色，他们认为挑选优胜者是市场的职能。然而，领导人们认为需要更好的项目筛选，并希望基金会和其他生态系统参与者在更好地将项目与相似目标对齐方面做出更大努力。Linux基金会欧洲的总经理 Gabriele Columbro 表示：“我们培养多个项目，有时它们会重叠。但最成熟的基金会都有一个项目生命周期，在那里他们可以帮助凝聚努力，甚至整合项目。” Columbro 说，适者生存或“开源达尔文主义”通常决定哪些项目最终是可持续的。然而，他和其他开源领导人都同意，将类似的项目纳入一个共享的伞下可以消除重复、节约开销并减少所谓的“供应商疲劳”。在某些情况下，基金会还可以更好地关闭或归档项目。Columbro 说：“我们很擅长引入项目。但同样重要的是，我们要在适当的时候将项目引导通过生命周期，并对其进行归档。”

STRENGTHEN INTER-FOUNDATION COLLABORATION ON ECOSYSTEM CHALLENGES​

加强基金会间在生态系统挑战方面的合作​

The need for enhanced collaboration between open source projects and foundations extends to other priorities for the ecosys- tem, including joint efforts to advance open source advocacy on a range of Internet governance issues. Mark Surman of the Mozilla Foundation said foundation leaders could leverage the communi- ty's shared values as a starting point for collaboration. "The open source community is united by core values such as independence, decentralization, public assets, and public benefits," said Surman. "In essence, we agree on the vital role of the commons." The next step is to convene the foundation leaders and work together to identify shared policy goals. "What are possible threads of unity, and to what ends should we pull them?" asks Surman.

加强开源项目和基金会之间的协作需要在生态系统的其他优先事项方面，包括联合努力推进一系列互联网治理问题的开源倡导工作。Mozilla 基金会的 Mark Surman 表示，基金会领导人可以利用社区的共同价值观作为合作的起点。“开源社区的核心价值观，如独立性、去中心化、公共资产和公共利益，使我们团结在一起，” Surman 说。“实际上，我们都认同公共资源的重要作用。”下一步是召集基金会领导人并共同努力，以确定共享政策目标。“我们可以找到哪些团结的纽带，并达到什么目的呢？”Surman问道。

One goal that all ecosystem leaders agree on is the need to build trust and confidence in OSS and support the ongoing maintenance of critical open source infrastructure. "The cybersecurity order from the White House has put the ecosystem on notice," said Jerry Cuomo of IBM. "Now, the stewards of open source need to step up. It would be huge if the community had a shared ledger and audit system where we could demonstrate that the software is robust and secure. We need a transparent, ecosystem-wide view of our vulnerabilities, and we need to be able to predict potential problems. That's an OSS service that the community can trust."

所有生态系统领导者都同意一个目标，即需要建立对开源软件的信任和信心，并支持关键开源基础设施的持续维护。 "来自白宫的网络安全令让生态系统警觉起来，" IBM 的 Jerry Cuomo 表示。 "现在，开源软件的管理者需要站出来。如果社区拥有一个共享的分类账和审计系统，能够证明软件是强大和安全的，那将是巨大的。我们需要一个透明、全生态系统范围内的漏洞视图，并且我们需要能够预测潜在问题。这是社区可以信任的开源软件服务。"

Open source security and sustainability are top of mind, but eco- system leaders point to various policy issues on which open source foundations could find common ground. "The foundations should do more to educate policymakers and work on shared issues such as data security, intellectual property, antitrust, and privacy, among other things," said Peixin Hou of Huawei. "We urgently need global action on these issues."

开源安全和可持续性是当前的主要问题，但是生态系统领导者指出，开源基金会可以在数据安全、知识产权、反垄断和隐私等共同关注的政策问题上找到共同点。 "基金会应该更多地教育决策者，共同解决诸如数据安全、知识产权、反垄断和隐私等问题，" 华为的 Peixin Hou 表示。 "我们迫切需要全球性的行动来解决这些问题。"

Confronting techno-nationalism and fostering global inclusion​

应对技术民族主义和促进全球包容​

The recommendations for confronting techno-nationalism and fostering global inclusion include positioning foundations as neutral actors, building reputation frameworks and audit systems for open source code, and creating tools and protocols for inte- grating diverse contributors into open source communities.

应对技术民族主义和促进全球包容的建议包括将基金会定位为中立的参与者、建立针对开源代码的声誉框架和审计系统，以及创建整合多元贡献者到开源社区的工具和协议。

BUILD REPUTATION FRAMEWORKS​

建立声誉框架​

Adherence to transparent and secure development protocols is, ultimately, the best antidote to fears that national interests could taint or even corrupt open source projects. "To counter the tech- no-nationalism, we need to instill trust in the software develop- ment process," said Jim Zemlin. For example, Zemlin proposes the creation of reputation frameworks with better peer review and third-party audits. "We need trust networks that are transparent and scalable enough to work across open source communities," said Zemlin. "You can think of it as a liquidity of trust. Where you are from and whom you work for are not as relevant as knowing that your work is trustworthy and high-quality. It's the code that is vital. So we need a reputation framework for the codebase."

遵循透明和安全的开发协议，最终是消除国家利益可能玷污或甚至破坏开源项目的最佳解决方案。"为了抵制技术民族主义，我们需要在软件开发过程中建立信任,"Jim Zemlin 说。例如，Zemlin 建议创建具有更好的同行评审和第三方审计的声誉框架。"我们需要透明和可扩展到所有开源社区的信任网络，" Zemlin说。"你来自哪里，以及你为谁工作并不重要，知道你的工作是值得信任和高质量的才是重要的。所以我们需要针对代码库的声誉框架。"

POSITION FOUNDATIONS AND PROJECTS AS NEUTRAL ACTORS​

将基金会和项目定位为中立参与者​

In addition to reputation frameworks, positioning open source foundations and projects as impartial actors is critical to creating a neutral home for global collaboration. Establishing neutral, inclusive, and transparent structures for collaboration will not only broaden participation but can also reduce incentives for ecosystem participants to create parallel efforts. Reflecting on his work at ICANN, Rod Beckstrom said his number-one job was building a neutral zone in the domain name system that holds the Internet together. "We did everything we could to bring China and Russia into the tent," said Beckstrom. "We were doing it for the global community. Otherwise, we are starting from a position of mistrust." Likewise, building confidence in ICANN's protocols and decision-making process was critical to creating a produc- tive relationship with countries that were suspicious of American dominance of Internet governance. "As long as the system works openly and fairly, everyone can participate," said Beckstrom. "The Internet is a global infrastructure---it must remain neutral. It's to the benefit of the world."

除了声誉框架之外，将开源基金会和项目定位为公正的参与者对于创建全球合作的中立家园至关重要。建立中立、包容和透明的合作结构不仅可以扩大参与度，还可以减少生态系统参与者创建平行努力的动机。在回顾他在 ICANN 的工作时，Rod Beckstrom 说他的首要工作是在维持互联网的域名系统中建立一个中立区域。"我们尽了一切努力将中国和俄罗斯纳入帐篷，" Beckstrom说。"我们为全球社区而这么做。否则，我们将从不信任的立场开始。"同样，建立对 ICANN 协议和决策过程的信心对于与对美国互联网治理主导怀有怀疑态度的国家建立富有成效的关系至关重要。"只要系统公开、公正，每个人都可以参与，" Beckstrom 说。"互联网是全球基础设施——必须保持中立。这对世界有利。"

EDUCATE POLICYMAKERS ABOUT THE DOWNSIDES OF TECHNO-NATIONALISM​

教育决策者有关技术民族主义的弊端​

To combat techno-nationalism, ecosystem leaders must convince policymakers that restricting the transfer of critical innovations across national borders is paradoxical and self-defeating in a world where cross-border collaborations are the backbone of countless innovation communities. Calista Redmond and others argue that open source and global standards provide a superior path for both local and global economic growth because global collaboration leads to global markets with long-term strategic importance. “Every country has a home-team bias, but the growing techno-nationalism is a major concern,” said Redmond. “We need to educate the community and the policymakers about the downsides of techno-nationalism. Countries can fund companies and initiatives locally, but they must participate globally. Countries won’t be successful if they close off collaboration at national borders.” Columbro even adopted that perspective as a motto to define the mission of Linux Foundation Europe: “Collaborate locally, innovate globally.”

为了应对技术民族主义，生态系统领袖必须说服政策制定者，限制跨国界传递关键创新是矛盾和自我毁灭的，因为跨国界合作是无数创新社区的支柱。Calista Redmond 和其他人认为，开源和全球标准为本地和全球经济增长提供了更优越的道路，因为全球合作导致具有长期战略重要性的全球市场。Redmond 表示：“每个国家都有一种本土偏见，但不断增长的技术民族主义是一个重大问题。我们需要教育社区和政策制定者关于技术民族主义的不利因素。国家可以在本地资助公司和计划，但必须全球参与。如果关闭国家边界上的合作，国家就不会成功。” Columbro 甚至将这一观点作为 Linux 基金会欧洲定义使命的座右铭：“本地合作，全球创新。”

CREATE THE CONDITIONS TO INTEGRATE DIVERSE CONTRIBUTORS​

创造条件以整合不同贡献者​

The challenges of integrating different languages and cultures into open source communities are not new problems, and there is considerable confidence in the ecosystem's capacity to foster global inclusion. As Stormy Peters at GitHub explains, "The open source community has been integrating diversity for a long time. We have people contributing from across Europe, Asia, Africa, and South America. We have always understood the importance of international networks and communications, even more than the corporate community. We have leveraged asynchronous commu- nications to address the fact that users in some regions had less Internet bandwidth."

将不同语言和文化融入开源社区的挑战并不是新问题，生态系统在促进全球包容方面有相当的信心。正如 GitHub 的Stormy Peters所解释的那样，“开源社区一直在整合多样性。我们有来自欧洲、亚洲、非洲和南美的贡献者。我们一直理解国际网络和通信的重要性，甚至比企业社区更重要。我们利用异步通信来解决一些地区用户的互联网带宽较低的问题。”

The sheer number of people that GitHub and other organizations are onboarding into the global open source community provides proof of the ecosystem's progress in integrating diverse contributors. "We have proven that open source projects can operate globally," said Peters. "We are working effectively across regions and in multiple languages. We are creating OSPOs to structure the engagement of companies and organizations with the open source community."

GitHub 和其他组织吸纳到全球开源社区的人数之多，证明了这个生态系统在整合不同贡献者方面取得了进展。“我们已经证明开源项目可以在全球范围内运作，” Peters 表示。“我们在跨区域和多语言方面的合作非常有效。我们正在创建 OSPO 来规范公司和组织与开源社区的互动。”

Open source leaders agree, however, that the community can do more to promote global inclusion. For example, open source leaders underlined the need to invest in rapid machine translation capabilities for project communications. Open source leaders also discussed the importance of promoting open source norms, taming the industry's macho "bro" culture, and fostering professionalism in community dialogues and decision-making. Finally, collaboration platforms such as GitHub can enable open source communities to integrate diverse contributions at scale. Key advances in the GitHub platform include new tools to improve collaboration, translate mate- rials, and monitor the productivity and engagement of community members. "We believe we have the tools to bring open source col- laboration to a new level," said Peters.

然而，开源领导人们认为社区可以做更多来促进全球包容。例如，开源领导人强调了投资于快速机器翻译能力以进行项目通信的必要性。开源领导人还讨论了在社区对话和决策中促进开源规范、驯服行业的“兄弟文化”和培养专业精神的重要性。最后，GitHub 等协作平台可以使开源社区在规模上整合多样化的贡献。GitHub 平台的关键进展包括新工具来改进协作、翻译材料以及监测社区成员的生产力和参与度。“我们相信我们有工具可以将开源协作提升到一个新的水平，” Peters 说道。

Final thoughts​

总结​

By any yardstick, OSS is wildly successful. Hundreds of millions of users of set-top boxes, smart fridges, and other home appli- ances use OSS, and billions of people use it indirectly whenever they access Google, Facebook, or the myriad of other apps and websites. Whether you drive a Tesla, Toyota, or Mercedes, chances are very high it's running Linux and open source in the back- ground.³² So too are the supercomputers that power everything from advanced climate models to AI-enabled drug discovery and other scientific pursuits, such as astronomy, meteorology, and nuclear physics.³³

无论用什么标准来衡量，开源软件系统都非常成功。数亿用户使用机顶盒、智能冰箱和其他家用电器使用 OSS，而数十亿人在访问Google、Facebook 或无数其他应用程序和网站时也在间接使用 OSS。无论你开特斯拉、丰田还是奔驰，它背后很有可能都在运行Linux和开源软件。³² 超级计算机也是如此，它们为从先进气候模型到支持AI药物发现和其他科学研究（如天文学、气象学和核物理学）的一切提供动力。³³

The global open source community powering these innovations is encountering some inevitable fragmentation. Some of the frag- mentation in software development is essential to how the open source community functions. A globally decentralized ecosystem may produce some overlap, but its constant churn of incremen- tal innovation and improvement has yielded a vast reservoir of software building blocks for the digital economy.

支持这些创新的全球开源社区遇到了一些不可避免的分化。软件开发中的一些分化对于开源社区的运作至关重要。全球分裂的生态系统可能会产生一些重叠，但其不断的渐进式创新和改进已经产生了一个庞大的软件构建块库，为数字经济提供支持。

In other instances, fragmentation in the community is creating needless redundancy, driving up costs and complexity for producers and consumers alike. Worst of all, intensifying techno- nationalism could introduce new geopolitical fault lines, disrupting the free flow of ideas and restricting the community's access to talented developers.

在其他情况下，社区的分化正在创造不必要的冗余，增加生产者和消费者的成本和复杂性。最糟糕的是，日益加剧的技术民族主义可能会引入新的地缘政治断层，扰乱思想的自由流动，并限制社区获取才华横溢的开发人员的能力。

Now it is up to the community of developers, public and private sector organizations, companies, foundations, and beyond to continue to push for global collaboration. The open source commu- nity is larger, more diverse, and more capable than ever, but its progress is not forever inevitable. It is incumbent upon the commu- nity's leaders to take the necessary steps to continue these trendlines into the future.

现在，推动全球合作的责任在于开发者社区、公共和私营部门组织、公司、基金会等等。开源社区比以往任何时候都更加庞大、多样化和能力强大，但其进步并非永远不可避免。社区的领导者有责任采取必要的步骤，将这些趋势延续到未来。

About the Author​

关于作者​

Anthony is the founder and president of the DEEP Centre and an internationally recognized authority on the digital revolution, innovation, and creativity in business and society. He is co-au- thor (with Don Tapscott) of the groundbreaking bestseller Wikinomics and its follow-up Macrowikinomics: New Solutions for a Connected Planet.

Anthony 是 DEEP Centre 的创始人和总裁，是商业和社会中数字革命、创新和创造力的国际公认权威人士。他与Don Tapscott 合著了划时代的畅销书《维基经济学》及其续集《大维基经济学：连接星球的新解决方案》。

Among other appointments, Anthony serves as a research director with the Blockchain Research Institute, an expert advisor to the Markle Foundation's Initiative for America's Economic Future, and a senior fellow with the Lisbon Council in Brussels. Anthony was recently a committee member of the National Research Council's Committee on Science for the EPA's Future, a visiting fellow with the Munk School of Global Affairs at the University of Toronto, and chief advisor to Brazil's Free Education Project. His work on technol- ogy and innovation has been featured in publications such as the Harvard Business Review, the Huffington Post and The Globe and Mail.

除了其他职务外， Anthony 还担任区块链研究所的研究主任，马克尔基金会美国经济未来计划的专家顾问，以及位于布鲁塞尔的里斯本理事会的高级研究员。 Anthony 最近是美国国家研究委员会“未来环保科学委员会”的委员、多伦多大学蒙克全球事务学院的访问学者以及巴西自由教育项目的首席顾问。他的技术和创新工作曾在《哈佛商业评论》、《赫芬顿邮报》和《环球邮报》等出版物中受到关注。

Endnotes​

脚注​

Futurewei maintains ongoing, in-depth collaboration with forward-thinking companies worldwide.

Futurewei 与全球前瞻性公司保持着持续深入的合作关系。

We pursue openness in research and development (R&D) by embracing an open innovation model and striving to share ideas and knowledge with technology communities to create new business opportunities.

我们通过采用开放式创新模式和努力与技术社区分享想法和知识以创建新的业务机会来追求研究和开发中的开放性。

• Our vision is Shaping the Future Toward a Fully Connected, Intelligent World.

• Our mission is Developing Innovations to Benefit an Intelligent and Digital Society via Open Source, Standardization, and Collaboration within Ecosystems.

• 我们的愿景是“引领未来走向完全连接的智能世界。”

• 我们的使命是“通过开放源代码、标准化和生态系统内的协作开发创新，造福智能数字社会。”

Our experts have actively engaged in standards programs for the past two decades. Through this work, we participate in developing next- generation wireless technologies and networks and building open ecosystems through open application platforms for ICT systems.

我们的专家已经积极参与标准化计划已有二十年。通过这项工作，我们参与开发下一代无线技术和网络，并通过开放应用平台为ICT系统建立开放的生态系统。

www.futurewei.com

Founded in 2021, Linux Foundation Research explores the growing scale of open source collaboration, providing insight into emerging technology trends, best practices, and the global impact of open source projects. Through leveraging project databases and networks, and a commitment to best practices in quantitative and qualitative methodologies, Linux Foundation Research is creating the go-to library for open source insights for the benefit of organizations the world over.

Linux 基金会研究成立于2021年，探索了开源协作的不断扩大规模，提供有关新兴技术趋势、最佳实践和开源项目的全球影响的见解。通过利用项目数据库和网络，以及承诺采用数量和质量方法的最佳实践，Linux 基金会研究正在为全球组织创建开源洞察的权威库。

twitter.com/linuxfoundation

facebook.com/TheLinuxFoundation

linkedin.com/company/the-linux-foundation

youtube.com/user/TheLinuxFoundation

github.com/LF-Engineering

Copyright © 2023 The Linux Foundation

版权所有 © 2023 Linux基金会

This report is licensed under the Creative Commons Attribution-NoDerivatives 4.0 International Public License.

本报告采用知识共享署名-禁止演绎 4.0 国际公共许可证授权。

To reference the work, please cite as follows: Anthony Williams, "Enabling Global Collaboration: How Open Source Leaders Are Confronting the Challenges of Fragmentation," The Linux Foundation, January, 2023.

引用本文，请使用以下格式：Anthony Williams，“Enabling Global Collaboration: How Open Source Leaders Are Confronting the Challenges of Fragmentation，”The Linux Foundation，2023年1月。

Copyleft和GNU通用公共许可证：全面教程和指南

Copyright © 2018 Chestek Legal.

Copyright © 2003--2005, 2008, 2014--2015, 2018 Bradley M. Kuhn.

Copyright © 2014--2015 Anthony K. Sebro, Jr.

Copyright © 2014 Denver Gingerich.

Copyright © 2003--2007, 2014 Free Software Foundation, Inc.

Copyright © 2008, 2014 Software Freedom Law Center.

版权所有 © 2018 Chestek Legal。

版权所有 © 2003--2005，2008，2014--2015，2018 Bradley M. Kuhn。

版权所有 © 2014--2015 Anthony K. Sebro, Jr。

版权所有 © 2014 Denver Gingerich。

版权所有 © 2003--2007，2014自由软件基金会。

版权所有 © 2008，2014软件自由法律中心。

The copyright holders grant the freedom to copy, modify, convey, adapt, and/or redistribute this work (except Appendices [B][--E]) under the terms of the Creative Commons Attribution Share Alike 4.0 International License. A copy of that license is available at (https://creativecommons.org/licenses/by-sa/4.0/legalcode.

版权持有者授予自由复制，修改，传播，适应和/或重新分发本作品（除附录B--E外），根据知识共享署名相同4.0国际许可协议的条款。该许可证的副本可在 https://creativecommons.org/licenses/by-sa/4.0/legalcode 找到。

Appendices [B--E] include copies of the texts of various licenses published by the FSF, and they are all licensed under the license, "Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.". However, those who seek to make modified versions of those licenses should note the explanation given in the GPL FAQ.

附录B--E包括由FSF发表的各种许可证的文本副本，它们都在许可证下许可，“每个人都被允许复制和分发本许可证文件的逐字副本，但不允许更改。”但是，那些试图制作修改版本的许可证的人应注意GPL FAQ中给出的解释。

As a public, collaborative project, this Guide is primarily composed of the many contributions received via its public contribution process. Please review its Git logs for full documentation of all contributions, and Appendix [A] contains a list of third-party works from which some material herein was adapted.

作为公共协作项目，本指南主要由通过其公共贡献过程接收到的许多贡献组成。请查看其Git日志以获取所有贡献的完整文档，附录A包含了一些本文所述材料的第三方作品列表。

The most recent version is available online at https://copyleft.org/guide/. Patches are indeed welcome to this material. Sources can be found in the Git repository at https://k.copyleft.org/guide/.

最新版本可在线获取https://copyleft.org/guide/。欢迎为此材料提供补丁。源代码可以在Git存储库 https://k.copyleft.org/guide/ 中找到。

PREFACE

前言

This tutorial is the culmination of nearly a decade of studying and writing about software freedom licensing and the GPL. Each part of this tutorial is a course unto itself, educating the reader on a myriad of topics from the deep details of the GPLv2 and GPLv3, common business models in the copyleft licensing area (both the friendly and unfriendly kind), best practices for compliance with the GPL, for engineers, managers, and lawyers, as well as real-world case studies of GPL enforcement matters.

这篇教程是近十年来关于自由软件许可和GPL的研究和写作的总结。本教程的每一部分都是一个独立的课程，向读者介绍了许多主题，包括GPLv2和GPLv3的深入细节、copyleft许可证领域常见的商业模式（友好和不友好的类型）、工程师、经理和律师遵守GPL的最佳实践，以及GPL执法事项的实际案例研究。

It is unlikely that all the information herein is necessary to learn all at once, and therefore this tutorial likely serves best as a reference book. The material herein has been used as the basis for numerous live tutorials and discussion groups since 2002, and the materials have been periodically updated. They likely stand on their own as excellent reference material.

一次性学习所有的信息是不太可能的，因此本教程最好作为参考书使用。自2002年以来，这些材料已经被用作许多现场教程和讨论小组的基础，并且这些材料定期更新。它们可能作为优秀的参考材料独立存在。

However, if you are reading these course materials without attending a live tutorial session, please note that this material is merely a summary of the highlights of the various CLE and other tutorial courses based on this material. Please be aware that during the actual courses, class discussion and presentation supplements this printed curriculum. Simply reading this material is not equivalent to attending a course.

但是，如果你在没有参加现场教程的情况下阅读这些课程材料，请注意，这些材料仅是基于这些材料的各种CLE和其他教程课程的亮点摘要。请注意，在实际课程中，课堂讨论和演示会补充这个印刷课程。仅仅阅读这些材料是不能等同于参加课程的。

Part I： Detailed Analysis of the GNU GPL and Related Licenses

第一部分：GNU GPL 及相关许可证的详细分析

This part of the tutorial gives a comprehensive explanation of the most popular Free Software copyright license, the GNU General Public License ("GNU GPL", or sometimes just "GPL") -- both version 2 ("GPLv2") and version 3 ("GPLv3") -- and teaches lawyers, software developers, managers and business people how to use the GPL (and GPL'd software) successfully both as a community-building "Constitution" for a software project, and to incorporate copylefted software into a new Free Software business and in existing, successful enterprises.

本教程的这一部分对最流行的自由软件版权许可证，即GNU通用公共许可证（“GNU GPL”，有时简称为“GPL”）——第2版（“GPLv2”）和第3版（“GPLv3”）——进行了全面的解释，引导律师、软件开发人员、管理人员和业务人员如何成功地使用GPL（以及GPL软件），将其作为软件项目的社区建设“章程”，并将著佐权(copylefted)的软件合并到新的自由软件业务和现有的成功企业中。

To benefit from this part of the tutorial, readers should have a general familiarity with software development processes. A basic understanding of how copyright law applies to software is also helpful. The tutorial is of most interest to lawyers, software developers and managers who run or advise software businesses that modify and/or redistribute software under the terms of the GNU GPL (or who wish to do so in the future), and those who wish to make use of existing GPL'd software in their enterprise.

为了从教程的这一部分中受益，读者应该对软件开发过程有一个大致的了解。对版权法如何适用于软件的基本理解也很有帮助。本教程最感兴趣的是律师、软件开发人员和管理人员，他们经营软件业务，建议根据GNU GPL条款修改和/或重新分发软件（或希望在将来这样做），还有那些希望在他们的企业中使用已有的GPL软件的人。

Upon completion of this part of the tutorial, readers can expect to have learned the following:

看完本教程的这一部分后，读者可以期望学到以下内容：

• The freedom-defending purpose of various terms in the GNU GPLv2 and GPLv3.

• The differences between GPLv2 and GPLv3.

• The redistribution options under the GPLv2 and GPLv3.

• The obligations when modifying GPLv2'd or GPLv3'd software.

• How to build a plan for proper and successful compliance with the GPL.

• The business advantages that the GPL provides.

• The most common business models used in conjunction with the GPL.

• How existing GPL'd software can be used in existing enterprises.

• The basics of LGPLv2.1 and LGPLv3, and how they differ from the GPLv2 and GPLv3, respectively.

• The basics to begin understanding the complexities regarding derivative and combined works of software.

• GNU GPLv2和GPLv3中各种术语，目的是捍卫自由；

• GPLv2和GPLv3的区别；

• 基于GPLv2和GPLv3的再分发选项；

• 修改GPLv2或GPLv3软件时应遵循的义务；

• 如何制定计划以正确且成功地遵守GPL协议；

• GPL提供的业务优势；

• 与GPL结合使用的最常见的商业模式；

• 企业如何使用已有的GPL软件；

• LGPLv2.1和LGPLv3的基础知识，以及它们分别与GPLv2和GPLv3的区别；

• 开始了解有关软件的衍生和组合作品的复杂性的基础知识。

CHAPTER 1 WHAT IS SOFTWARE FREEDOM?​

第一章 什么是软件自由？​

Study of the GNU General Public License (herein, abbreviated as GNU GPL or just GPL) must begin by first considering the broader world of software freedom. The GPL was not created in a vacuum. Rather, it was created to embody and defend a set of principles that were set forth at the founding of the GNU Project and the Free Software Foundation (FSF) -- the preeminent organization that upholds, defends and promotes the philosophy of software freedom. A prerequisite for understanding both of the popular versions of the GPL (GPLv2 and GPLv3) and their terms and conditions is a basic understanding of the principles behind them. The GPL family of licenses are unlike nearly all other software licenses in that they are designed to defend and uphold these principles.

研究GNU通用公共许可证（此处缩写为GNU GPL或简称GPL）必须首先考虑更广泛的软件自由世界。 GPL不是凭空产生的，它是为了体现和捍卫在GNU项目和自由软件基金会 (FSF) 成立时提出的一系列原则而创建的，FSF是一个维护、捍卫和促进软件自由哲学的卓越组织。 理解GPL的两个流行版本（GPLv2 和 GPLv3）及其条款和条件的先决条件是对它们背后的原则有基本的理解。GPL系列许可证与几乎所有其他的软件许可证不同，因为它们旨在捍卫和维护这些原则。

1.1 The Free Software Definition​

1.1 自由软件的定义​

The Free Software Definition is set forth in full on FSF's website at http://fsf.org/philosophy/free-sw.html. This section presents an abbreviated version that will focus on the parts that are most pertinent to the GPL.

自由软件定义在FSF的网站 http://fsf.org/philosophy/free-sw.html 上有完整的阐述。 本节提供一个缩略版，将重点放在与GPL最密切的部分。

A particular user has software freedom with respect to a particular program if that user has the following freedoms:

如果某个特定用户具有以下自由，则这个用户就具有与特定程序相关的软件自由：

• The freedom to run the program, for any purpose.

• The freedom to study how the program works, and modify it

• The freedom to redistribute copies.

• The freedom to distribute copies of modified versions to others.

• 出于任何目的执行程序的自由；

• 了解程序的运行机制，可以随意修改的自由；

• 随意分发软件副本的自由；

• 将修改后的软件副本分发给他人的自由。

The focus on "a particular user" is particularly pertinent here. It is not uncommon for a subset of a specific program's user base to have these freedoms, while other users of the same version the program have none or only some of these freedoms. Section [12.2] talks in detail about how this can unfortunately happen even if a program is released under the GPL.

对“特定用户”的关注在这里尤为重要。某个特定程序的用户群的一部分人拥有这些自由的情况并不少见，而同一版本程序的其他用户则没有或只有其中的一部分自由。第 12.2 章节详细讨论了这种情况，即使程序是基于GPL发布的。

Many people refer to software with these freedoms as "Open Source." Besides having a different political focus from those who call such software by the name "Free Software"¹, those who call the software "Open Source" are often focused on a side issue. Specifically, user access to the source code of a program is a prerequisite to make use of the freedom to modify. However, the important issue is what freedoms are granted in the license that applies to that source code.

许多人将具有这些自由的软件称为“开源”。除了与那些将此类软件称为“自由软件” ¹ 的人有着不同的政治关注点之外，将软件称为“开源”的人通常关注的是一个次要问题。具体来说，用户访问程序的源代码是实现修改自由的先决条件。然而，重要的问题是在适用于该源代码的许可证中授予了哪些自由。

Software freedom is only complete when no restrictions are imposed on how these freedoms are exercised. Specifically, users and programmers can exercise these freedoms noncommercially or commercially. Licenses that grant these freedoms for noncommercial activities but prohibit them for commercial activities are considered non-free. The Open Source Initiative (OSI ) (the arbiter of what is considered "Open Source") also regards such licenses as inconsistent with its "Open Source Definition".

只有当如何行使这些自由没有任何限制时，软件自由才是完整的。具体而言，用户和程序员可以非商业或商业的方式行使这些自由。那些仅限于非商业活动的一些自由，但禁止商业活动自由的许可，被认为是非自由的。开源促进会(OSI)（被认为是“开源”的仲裁者）也认为此类许可证与其“开源定义”不一致。

In general, software for which any of these freedoms are restricted in any way is called "nonfree" software. Some use the term "proprietary software" more or less interchangeably with "nonfree software". The FSF published a useful explanation of various types of software and how they relate to one another.

一般来说，以任何方式限制自由的软件被称为“非自由”软件。有些人或多或少地将“专有软件”一词与“非自由软件”互换使用。 FSF发布了一份有用的对各种类型的软件以及它们之间的相互关系的解释

Keep in mind that none of the terms "software freedom", "open source" and "free software" are known to be trademarked or otherwise legally restricted by any organization in any jurisdiction. As such, it's quite common that these terms are abused and misused by parties who wish to bank on the popularity of software freedom. When one considers using, modifying or redistributing a software package that purports to be Open Source or Free Software, one must verify that the license grants software freedom.

请记住，“软件自由”、“开源”和“免费软件”等术语均未被任何司法管辖区的任何组织注册商标，或以其他方式限制使用。这些术语被某些机构滥用和误用是很常见的现象，因为他们希望扩大软件自由的普及度。当考虑使用、修改或重新分发声称是开源或自由软件的软件包时，必须验证许可证是否授予软件自由。

Furthermore, throughout this text, we generally prefer the term "software freedom", as this is the least ambiguous term available to describe software that meets the Free Software Definition. For example, it is well known and often discussed that the adjective "free" has two unrelated meanings in English: "free as in freedom" and "free as in price". Meanwhile, the term "open source" is even more confusing, because it appears to refer only to the "freedom to study", which is merely a subset of one of the four freedoms.

此外，在本文中，我们通常更喜欢“软件自由”一词，因为在那些描述符合自由软件定义的软件的一堆术语中，它的歧义最小。例如，大家经常讨论的英文中的形容词“自由”，它有两个不相关的含义：“使用的自由”和“价格的免费”。同时，“开源”一词更令人困惑，因为它似乎仅指“学习的自由”，这仅仅是四个自由中的一个。

The remainder of this section considers each of each component of software freedom in detail.

本节的其余部分将详细考虑软件自由的每个组成部分。

1.1.1 The Freedom to Run​

1.1.1 执行程序的自由​

The first tenet of software freedom is the user's fully unfettered right to run the program. The software's license must permit any conceivable use of the software. Perhaps, for example, the user has discovered an innovative use for a particular program, one that the programmer never could have predicted. Such a use must not be restricted.

软件自由的首要原则是用户拥有完全不受限制地执行该程序的权利。该软件的许可证必须允许用户以任意方式使用软件。例如，也许用户发现了针对一个特定场景的创新用途，这个场景可能是程序员从未预料到的。不得限制此类用途。

It was once rare that this freedom was restricted by even proprietary software; but such is quite common today. Most End User License Agreements (EULAs) that cover most proprietary software typically restrict some types of uses. Such restrictions of any kind are an unacceptable restriction on software freedom.

曾经很少有使用软件的自由受到限制的情况，在专有软件中也很少见；但现在却很普遍。大多数基于最终用户许可协议（EULAs）的专有软件，通常限制某些类型的用途。任何这些形式的限制对软件自由来说，都是不可接受的。

1.1.2 The Freedom to Change and Modify​

1.1.2 更改和修改程序的自由​

Perhaps the most useful right of software freedom is the users' right to change, modify and adapt the software to suit their needs. Access to the source code and related build and installation scripts are an essential part of this freedom. Without the source code, and the ability to build and install the binary applications from that source, users cannot effectively exercise this freedom.

软件自由的最有用的权利也许是用户拥有根据自己的需求更改、修改和调整软件的权利。对源代码以及相关的构建和安装脚本的访问权限，是该自由的重要组成部分。如果没有源代码，以及基于该源码构建和安装二进制应用程序的脚本，用户就无法有效地行使这种自由。

Programmers directly benefit from this freedom. However, this freedom remains important to users who are not programmers. While it may seem counterintuitive at first, non-programmer users often exercise this freedom indirectly in both commercial and noncommercial settings. For example, users often seek noncommercial help with the software on email lists and in user groups. To make use of such help they must either have the freedom to recruit programmers who might altruistically assist them to modify their software, or to at least follow rote instructions to make basic modifications themselves.

程序员是这种自由的直接受益者。但是，这种自由对于非程序员的用户来说也很重要。虽然看起来似乎有点违反直觉，但非程序员用户通常在商业和非商业环境中，间接行使这种自由。例如，用户经常在电子邮件列表和用户群组中需求软件上的非商业性帮助。为了能够使用这种便利，必须允许他们自由地招募可能会免费帮助他们修改软件的程序员，或者允许他们按照使用说明可以自己进行基本的修改。

More commonly, users also exercise this freedom commercially. Each user, or group of users, may hire anyone they wish in a competitive free market to modify and change the software. This means that companies have a right to hire anyone they wish to modify their Free Software. Additionally, such companies may contract with other companies to commission software modifications.

更常见的是，用户还可以在商业上行使这种自由。每个用户或一组用户都可以在竞争激烈的自由市场中，雇用他们希望的任何人来修改和更改软件。这意味着公司有权雇用任何愿意修改其免费软件的人。此外，公司可以与其他公司签订合同，委托进行软件修改。

1.1.3 The Freedom to Copy and Share​

1.1.3 复制和分享软件的自由​

Users share Free Software in a variety of ways. Software freedom advocates work to eliminate a fundamental ethical dilemma of the software age: choosing between obeying a software license and friendship (by giving away a copy of a program to your friend who likes the software you are using). Licenses that respect software freedom, therefore, permit altruistic sharing of software among friends.

用户以多种方式分享自由软件。软件自由倡导者致力于消除软件时代的一个基本道德困境：在遵守软件许可和友谊之间做出选择（当你的朋友喜欢你正在使用的软件时，赠送一份程序副本给他）。 因此，尊重软件自由的许可证允许在朋友之间无私地分享软件。

The commercial environment also benefits from this freedom. Commercial sharing includes selling copies of Free Software: that is, Free Software can be distributed for any monetary price to anyone. Those who redistribute Free Software commercially also have the freedom to selectively distribute (i.e., you can pick your customers) and to set prices at any level that redistributor sees fit.

商业环境也得益于这种自由。商业共享包括出售自由软件的副本：也就是说，可以用任何货币价格将自由软件分发给其他人。那些以商业方式重新分发自由软件的人，也可以有选择地自由分发（如可以选择你自己的客户），并可以自行设置合适的价格水平。

Of course, most people get copies of Free Software very cheaply (and sometimes without charge). The competitive free market of Free Software tends to keep prices low and reasonable. However, if someone is willing to pay billions of dollars for one copy of the GNU Compiler Collection, such a sale is completely permitted.

当然，大多数人都可以非常便宜地获得自由软件的副本（有时甚至是免费的）。竞争激烈的自由软件市场倾向于保持低价和合理的价格。但是如果真有人愿意花费数十亿美元购买一份GNU编译集，这也是完全允许的。

Another common instance of commercial sharing is service-oriented distribution. For example, some distribution vendors provide immediate security and upgrade distribution via a special network service. Such distribution is not necessarily contradictory with software freedom.

商业共享的另一个常见方式是面向服务的分发。例如，一些分发供应商通过特殊的网络服务提供即时安全和升级服务。这种分发方式不一定与软件自由相矛盾。

(Section [12.2] of this tutorial talks in detail about some common Free Software business models that take advantage of the freedom to share commercially.)

（本教程的第12.2章部分详细讨论了一些常见的利用商业实现自由软件的自由共享的业务模式。）

1.1.4 The Freedom to Share Improvements​

1.1.4 分享改进的自由​

The freedom to modify and improve is somewhat empty without the freedom to share those improvements. The software freedom community is built on the pillar of altruistic sharing of improved Free Software. Historically it was typical for a Free Software project to sprout a mailing list where improvements would be shared freely among members of the development community. ² Such noncommercial sharing is the primary reason that Free Software thrives.

如果没有分享改进的自由，修改和改进的自由多少有点空洞。软件自由社区建立在无私共享改进的自由软件的基础上。从历史上看，自由软件项目的典型做法是建立一个邮件列表，开发社区的成员可以在其中免费分享改进的内容。² 这种非商业性质的共享方式是自由软件蓬勃发展的主要原因。

Commercial sharing of modified Free Software is equally important. For commercial support to exist in a competitive free market, all developers -- from single-person contractors to large software companies -- must have the freedom to market their services as augmenters of Free Software. All forms of such service marketing must be equally available to all.

修改后的自由软件的商业共享同样重要。为了在竞争激烈的自由市场中提供商业支持，所有的开发人员——从个人承包商到大型软件公司——都应该可以自由地将他们的服务作为自由软件的补充进行销售。这种形式的服务营销必须对所有人一视同仁。

For example, selling support services for Free Software is fully permitted. Companies and individuals can offer themselves as "the place to call" when software fails or does not function properly. For such a service to be meaningful, the entity offering that service needs the right to modify and improve the software for the customer to correct any problems that are beyond mere user error.

例如，销售免费软件的支持服务是完全允许的。当软件出现故障或无法正常运行时，公司和个人可以将自己作为“呼叫客服”。为了使此类服务有意义，提供该服务的实体需要有权为客户修改和改进软件，以纠正任何超出用户错误的问题。

Software freedom licenses also permit any entity to distribute modified versions of Free Software. Most Free Software programs have a "standard version" that is made available from the primary developers of the software. However, all who have the software have the "freedom to fork" -- that is, make available nontrivial modified versions of the software on a permanent or semi-permanent basis. Such freedom is central to vibrant developer and user interaction.

软件自由许可证还允许任何实体分发自由软件的修改版本。大多数自由软件程序都有一个“标准版本”，可以从软件的主要开发人员那里获得。然而，所有拥有该软件的人都有“分叉自由”——也就是说，可以永久或半永久地提供软件的重要修订版本。这种自由是充满活力的开发人员和用户交互的核心。

Companies and individuals have the right to make true value-added versions of Free Software. They may use freedom to share improvements to distribute distinct versions of Free Software with different functionality and features. Furthermore, this freedom can be exercised to serve a disenfranchised subset of the user community. If the developers of the standard version refuse to serve the needs of some of the software's users, other entities have the right to create a long- or short-lived fork to serve that sub-community.

公司和个人有权制作的自由软件的增值版本。他们可以自由地改进，并分享具有不同功能和特性的自由软件版本。此外，这种自由可以用来服务于被剥夺权力的用户群体。如果标准版本的开发人员拒绝满足某些软件用户的需求，则其他实体有权创建一个长期或短期的分支，提供服务满足于这些软件用户。

1.2 How Does Software Become Free?​

1.2 软件是如何变得自由的？​

The previous section set forth key freedoms and rights that are referred to as "software freedom". This section discusses the licensing mechanisms used to enable software freedom. These licensing mechanisms were ultimately created as a community-oriented "answer" to the existing proprietary software licensing mechanisms. Thus, first, consider carefully why proprietary software exists in the first place.

上一节阐述了被称为“软件自由”的一些关键自由和权利。本节讨论用于实现软件自由的许可机制。这些许可机制被看作是将现有专有软件许可机制转变为面向社区机制的“答案”所在。 因此，首先要仔细考虑为什么会有专有软件存在。

The primary legal regime that applies to software is copyright law. Proprietary software exists at all only because copyright law governs software.³ Copyright law, with respect to software, typically governs copying, modifying, and redistributing that software (For details of this in the USA, see §106 and §117 of Title17 of the United States Code).⁴ By law (in the USA and in most other jurisdictions), the copyright holder (most typically,the author) of the work controls how others may copy, modify and/or distribute the work. For proprietary software, these controls are used to prohibit these activities. In addition, proprietary software distributors further impede modification in a practical sense by distributing only binary code and keeping the source code of the software secret.

适用于软件的主要法律制度是版权法。专有软件的存在完全是因为版权法对软件的管理规定。³关于软件的版权法，主要是对软件的复制、修改和再发行的管理规定（有关美国的详细信息，请参阅《美国法典》第17篇的§106和§117）。⁴ 根据法律（在美国和大多数其他司法管辖区），作品的版权持有者（通常是作者本人） 可以控制其他人如何复制、修改和/或分发作品。专有软件的这些控制行为禁止了软件的相关操作。此外，专有软件分销商只发行二进制可执行代码，严格保密源代码，这也进一步阻碍了实际意义上的代码修改。

Copyright is not a natural state, it is a legal construction. In the USA, the Constitution permits, but does not require, the creation of copyright law as federal legislation. Software, since it is an "original work of authorship fixed in any tangible medium of expression ... from which they can be perceived, reproduced, or otherwise communicated, either directly or with the aid of a machine or device" (as stated in 17 USC § 102), is thus covered by the statute, and is copyrighted by default.

版权不是一种自然状态，它是一种法律结构。在美国，宪法允许但不要求将版权法作为联邦立法。软件，因为它是“固定在任何有形表达媒介中的原创作品……可以直接或借助机器/设备从中感知、复制或以其他方式传播”（如 《美国法典》第17篇 第§102章节所述)，因此受法规保护，默认情况下受版权保护。

However, software, in its natural state without copyright, is Free Software. In an imaginary world with no copyright, the rules would be different. In this world, when you received a copy of a program's source code, there would be no default legal system to restrict you from sharing it with others, making modifications, or redistributing those modified versions.⁵

但是，在没有版权的自然状态下，软件是自由软件。在没有版权的虚拟世界中，规则会有所不同。在虚拟世界上，当你收到一个程序的源代码副本时，不会有默认的法律制度来限制你与他人共享、进行修改或重新分发这些修改后的版本。⁵

Software in the real world is copyrighted by default and is automatically covered by that legal system. However, it is possible to move software out of the domain of the copyright system. A copyright holder can often disclaim their copyright. (For example, under USA copyright law it is possible for a copyright holder to engage in conduct resulting in abandonment of copyright.) If copyright is disclaimed, the software is effectively no longer restricted by copyright law. Software not restricted by copyright is in the "public domain."

现实世界中的软件默认受版权保护，并自动受该法律体系保护。但是，可以将软件移出版权系统的范围。版权所有者通常可以放弃他们的版权。（例如，根据美国版权法，版权所有者可以实施某些操作，放弃版权。）如果放弃版权，则该软件实际上不再受版权法的限制。不受版权限制的软件属于“公共领域软件”。

1.2.1 Public Domain Software​

1.2.1 公共领域软件​

In the USA and other countries that are parties to the Berne Convention on Copyright, software is copyrighted automatically by the author when she fixes the software in a tangible medium. In the software world, this usually means typing the source code of the software into a file.

在美国和其他加入《伯尔尼版权公约》的国家，当作者将软件固定在有形介质中时，软件自动受到版权保护。在软件世界中，这通常意味着将软件的源代码输入到文件中。

Imagine if authors could truly disclaim those default controls of copyright law. If so, the software is in the public domain --- no longer covered by copyright. Since copyright law is the construction allowing for most restrictions on software (i.e., prohibition of copying, modification, and redistribution), removing the software from the copyright system usually yields software freedom for its users.

想象一下，如果作者真的放弃了版权法的默认控制。如果是这样，该软件就属于公共领域 --- 不再受版权保护。由于版权法是允许对软件进行操作限制（如禁止复制、修改和重新分发）的结构定义，因此从版权系统中删除软件通常会为其用户带来软件自由。

Carefully note that software truly in the public domain is not licensed in any way. It is confusing to say software is "licensed for the public domain," or any phrase that implies the copyright holder gave express permission to take actions governed by copyright law.

请注意，真正属于公共领域的软件未以任何方式获得许可。关于软件“已获得公共领域许可”，或任何关于版权所有者明确允许采取受版权法管辖的行为的暗示说法，都是令人困惑的。

Copyright holders who state that they are releasing their code into the public domain are effectively renouncing copyright controls on the work. The law gave the copyright holders exclusive controls over the work, and they chose to waive those controls. Software that is, in this sense, in the public domain is conceptualized by the developer as having no copyright and thus no license. The software freedoms discussed in Section [1.1] are all granted because there is no legal system in play to take them away.

如果版权所有者声明将其代码发布到公共领域，实际上他就放弃了对作品的版权控制。法律赋予版权所有者对作品的独占控制权，他们可以选择放弃这些控制权。从这个意义上说，处于公共领域的软件被开发人员认定为没有版权，因此也就没有许可证。第[1.1] 节（#the-free-software-definition）中讨论的软件自由都是被授予的，因为没有法律制度可以剥夺这些自由。

Admittedly, a discussion of public domain software is an oversimplified example. Because copyright controls are usually automatically granted and because, in some jurisdictions, some copyright controls cannot be waived (see Section [1.2.4] for further discussion), many copyright holders sometimes incorrectly believe a work has been placed in the public domain. Second, due to aggressive lobbying by the entertainment industry, the "exclusive Right" of copyright, that was supposed to only exist for "Limited Times" according to the USA Constitution, appears to be infinite: simply purchased on the installment plan rather than in whole. Thus, we must assume no works of software will fall into the public domain merely due to the passage of time.

诚然，对公共领域软件的讨论是一个过于简单化的例子。因为版权控制通常是自动授予的，并且在某些司法管辖区，某些版权控制不能被放弃（请参考第 [1.2.4] 节（#non-usa-copyright-regimes）以了解进一步的讨论），许多版权所有者有时会错误地认为作品已经发布到了公共领域。其次，由于娱乐业的积极游说，根据美国宪法规定，版权的“专有权”本应仅存在于“有限时间”，但看起来似乎是无限的：只是分期付款购买，而不是全部购买。因此，我们必须假设没有任何软件作品会因为时间的流逝而落入公共领域。

Nevertheless, under USA law it is likely that the typical disclaimers of copyright or public domain dedications we see in the Free Software world would be interpreted by courts as copyright abandonment, leading to a situation in which the user effectively receives a maximum grant of copyright freedoms, similar to a maximally-permissive Free Software license.

然而，根据美国法律，我们在自由软件世界中看到的典型的版权免责声明，或公共领域专有申明，可能会被法院解释为放弃版权，从而授予了用户实际上最大程度的版权自由，类似于最大程度的自由软件许可证。

The best example of software known to truly be in the public domain is software that is published by the USA government. Under 17 USC 101 105, all works published by the USA Government are not copyrightable in the USA.

目前所知的真正属于公共领域的软件最好的例子，是由美国政府发布的软件。根据《美国法典》第17章101-105，在美国，美国政府出版的所有作品均不受版权保护。

1.2.2 Why Copyright Free Software?​

1.2.2 为什么需要版权自由的软件？​

If simply disclaiming copyright on software yields Free Software, then it stands to reason that putting software into the public domain is the easiest and most straightforward way to produce Free Software. Indeed, some major Free Software projects have chosen this method for making their software Free. However, most of the Free Software in existence is copyrighted. In most cases (particularly in those of FSF and the GNU Project), this was done due to very careful planning.

假如只是放弃了对软件的版权就产生了自由软件，那么将软件发布到公共领域是产生自由软件最简单和最直接的方式，这看起来是理所当然的。事实上，一些主要的自由软件项目已经选择了这种方法来使他们的软件成为自由软件。然而，现存的大多数自由软件是受版权保护的。在大多数情况下（特别是在FSF和GNU项目中），这些项目的规划都非常仔细。

Software released into the public domain does grant freedom to those users who receive the standard versions on which the original author disclaimed copyright. However, since the work is not copyrighted, any nontrivial modification made to the work is fully copyrightable.

当原作者将作品发布到公共领域以否认版权时，就将软件自由授予了那些已经收到标准版本的用户。虽然原作品不受版权保护，但对原作品所做的任何重要修改都是受版权保护的。

Free Software released into the public domain initially is Free, and perhaps some who modify the software choose to place their work into the public domain as well. However, over time, some entities will choose to proprietarize their modified versions. The public domain body of software feeds the proprietary software. The public commons disappears, because fewer and fewer entities have an incentive to contribute back to the commons. They know that any of their competitors can proprietarize their enhancements. Over time, almost no interesting work is left in the public domain, because nearly all new work is done by proprietarization.

起初，发布到公共领域的自由软件是自由的，一些修改软件的人也会选择将他们的作品发布到公共领域。然而，随着时间的推移，一些实体选择将其修改后的版本专有化。公共领域的软件主体为专有软件提供了支持。随着越来越少的实体有动力回馈公共领域，公共资源就消失了。他们知道，任何竞争对手都可以将自己的增强功能专有化。随着时间的推移，公共领域几乎不会留下任何有趣的项目，因为几乎所有的新项目都是由专有化的实体完成的。

A legal mechanism is needed to redress this problem. FSF was in fact originally created primarily as a legal entity to defend software freedom, and that work of defending software freedom is a substantial part of its work today. Specifically because of this "embrace, proprietarize and extend" cycle, FSF made a conscious choice to copyright its Free Software, and then license it under "copyleft" terms. Many, including the developers of the kernel named Linux, have chosen to follow this paradigm.

因此，需要一个法律机制来解决这个问题。事实上，FSF最初主要是作为一个捍卫软件自由的法律实体而创建的，而捍卫软件自由是其现在工作的重要组成部分。特别是由于这种“拥抱、专有化和扩展”的循环，FSF有意识地选择对其自由软件进行版权保护，然后根据“copyleft”条款对其进行许可。许多人，包括Linux内核的开发人员，都选择遵循这种模式。

Copyleft is a strategy of utilizing copyright law to pursue the policy goal of fostering and encouraging the equal and inalienable right to copy, share, modify and improve creative works of authorship. Copyleft (as a general term) describes any method that utilizes the copyright system to achieve the aforementioned goal. Copyleft as a concept is usually implemented in the details of a specific copyright license, such as the [GNU General Public License (GPL)] and the Creative Commons Attribution Share Alike License (the latter of which is the license of this work itself). Copyright holders of creative work can unilaterally implement these licenses for their own works to build communities that collaboratively share and improve those copylefted creative works.

Copyleft是一种利用版权法来实现政策目标的策略，意在促进和鼓励平等和不可剥夺的复制、共享、修改和改进原创作品的权利。Copyleft（作为一个通用术语）描述了利用版权系统实现上述目标的一些方法。Copyleft作为一个概念，通常在特定版权许可证的细节中体现，例如[GNU 通用公共许可 (GPL)] 和（Creative Commons Attribution Share Alike License）知识共享署名共享类似许可（后者是这个项目本身的许可证）。创意作品的版权持有者可以单方面为自己的作品实施这些许可，建立社区，共同分享和改进这些copyleft的创意作品。

Copyleft uses functional parts of the copyright system to achieve an unusual result (legal protection for free sharing). Copyleft modifies, or "hacks" copyright law, which is usually employed to strengthen the rights of authors or publishers, to strengthen instead the rights of users. Thus, Copyleft is a legal strategy and mechanism to defend, uphold and propagate software freedom. The basic technique of copyleft is as follows: copyright the software, license it under terms that give all the software freedoms, but use the copyright law controls to ensure that all who receive a copy of the software have equal rights and freedom. In essence, copyleft grants freedom, but forbids others to forbid that freedom to anyone else along the distribution and modification chains.

Copyleft使用版权系统的功能部分来实现一个不同寻常的结果（免费共享的法律保护）。Copyleft修改或“破解”版权法以加强用户的权利，而版权法通常用于加强作者或出版商的权利。因此，Copyleft是一种捍卫、支持和传播软件自由的法律策略和机制。Copyleft的基本原则为：对软件进行版权保护，在赋予所有软件自由的条款下颁发软件许可证，但使用版权法控制，以确保所有获得软件副本的人都享有平等的权利和自由。本质上，copyleft赋予用户自由，也禁止某些用户的垄断行为，即通过控制软件的分发和修改的后续链条限制其他人的软件自由。

Copyleft's "reciprocity" or "share and share alike" rule protects both developers, who avoid facing a "prioritized" competitor of their project, and users, who can be sure that they will have all four software freedoms --- not only in the present version of the program they use, but in all its future improved versions. Copyleft is a general concept. Much like ideas for what a computer might do must be implemented by a program that actually does the job, so too must copyleft be implemented in some concrete legal structure. "Share and share alike" is a phrase that is used often enough to explain the concept behind copyleft, but to actually make it work in the real world, a true implementation in legal text must exist, written as a "copyright license". The GPL implements the concept of copyleft for software-oriented and other functional works of a technical nature. The "CC BY SA" license implements copyleft for works of textual, musical and visual authorship, such as this tutorial.

Copyleft的“互惠”或“共享和类似共享”的原则同时保护了开发者和用户，开发者可以避免面对他们项目的“优先”竞争对手，用户可以确保他们将拥有所有的四种软件自由——不仅限于当前他们使用的程序版本，也包括未来的所有改进版本中。Copyleft是一个笼统的概念。就像计算机可以做什么的想法必须由一个实际执行该任务的程序实现一样，copyleft也必须在某些具体的法律结构中实现。“共享和类似共享”这个短语经常被用来解释copyleft背后的概念，但要真正让它在现实世界中发挥作用，必须有一个真正的法律文本实现，即“版权许可”。GPL为面向软件和其他技术性质的功能性作品实现了copyleft的概念。 “CC BY SA”许可证为文本、音乐和视觉作者的作品提供了copyleft版权保护，例如本教程。

Copyleft advocates often distinguish between the concept of a "strong copyleft" or a "weak copyleft". However, "strong vs. weak" copyleft is not a dichotomy, it's a spectrum. The strongest copylefts strive to the exclusive rights that copyright grants to authors as extensively as possible to maximize software freedom.

Copyleft倡导者经常区分“强copyleft”或“弱copyleft”的概念。然而，“强与弱”copyleft并不是二分法原则，而是一个范围。最强的copyleft版权力图授予作者尽可能广泛的专有权，以最大限度地提高软件自由度。

As a copyleft gets "weaker", the copyleft license typically makes "trade offs" that might impede software freedom, but reach other tactic goals for the community of users and developers of the work.

随着copyleft变得“微弱”，copyleft许可证可能会做一些"权衡"，可能会阻碍软件自由，但会实现用户和项目开发者社区的其他策略目标。

In other words, strong copyleft licenses place the more requirements on how "the work" is licensed. The unit of copyright law is "the work". In that sense, the "work" referenced by the licenses is anything that can be copyrighted or will be subject to the terms of copyright law. Strong copyleft licenses exercise their scope fully. Anything which is "a work" or a "work based on a work" licensed under a strong copyleft is subject to its requirements, including the requirement of complete, corresponding source code ⁶. Thus, copyleft licenses, particularly strong ones, seek to ensure the same license covers every version of "work based on the work", as recognized by local copyright law, and thereby achieve the specific strategic policy aim of ensuring software freedom for all users, developers, authors, and readers who encounter the copylefted work.

换句话说，较强的copyleft许可对“作品”的许可方式提出了更高的要求。是以“作品”为单位进行版权法认定的。从这个意义上说，许可证所指的“作品”是任何可以受版权保护或受版权法条款约束的东西。较强的copyleft许可证充分发挥了其作用。任何基于较强的copyleft许可的“作品”或“基于作品的作品”都必须遵守其要求，包括所有相应的源代码 ⁶。因此，copyleft许可证，特别是较强的许可证，旨在确保相同的许可证涵盖当地版权法认可的“基于作品的作品”的所有版本，从而确保实现与当前copyleft版权作品相关的所有用户、开发者、作者和读者的软件自由的特定战略目标。

1.2.3 Software and Non-Copyright Legal Regimes​

1.2.3 软件和非版权法律制度​

The use, modification and distribution of software, like many endeavors, simultaneously interacts with multiple different legal regimes. As was noted early via footnotes, copyright is merely the most common way to restrict users' rights to copy, share, modify and/or redistribute software. However, proprietary software licenses typically use every mechanism available to subjugate users. For example:

与许多努力一样，软件的使用、修改和分发同时与多种不同的法律制度相互制约。正如早期通过脚注指出的那样，版权只是限制用户复制、共享、修改和/或重新分发软件的最常见的方式。但是专有软件许可证通常会使用所有各种机制来控制用户。例如：

• Unfortunately, despite much effort by many in the software freedom community to end patents that read on software (i.e., patents on computational ideas), they still exist. As such, a software program might otherwise seem to be unrestricted, but a patent might read on the software and ruin everything for its users.⁷

• 软件自由社区中的人做了很多努力，希望能终止通过读取软件内容生成专利的行为（即跟软件思想相关的专利），但还是未能成功。因此，一个软件程序可能看起来不受限制，但有些人可能会读取该软件并生成专利，进而毁掉其他用户的一切。⁷

Digital Restrictions Management (usually called DRM ) is often used to impose technological restrictions on users' ability to exercise software freedom that they might otherwise be granted.⁸ The simplest (and perhaps oldest) form of DRM, of course, is separating software source code (read by humans), from their compiled binaries (read only by computers). Furthermore, 17 USC 1201 often prohibits users legally from circumventing some of these DRM systems.

虽然授予了软件自由，但数字限制管理（也被称为DRM）通常对用户行使软件自由的能力施加技术限制。⁸最简单的（也是最古老的）DRM的形式，是将软件源代码（人类可阅读的）与编译的二进制文件（仅由计算机读取）分开。此外，《美国法典》第17篇 第§102章节 通常从法律层面禁止用户规避DRM系统中的一些。

Most EULAs also include a contractual agreement that bind users further by forcing them to agree to a contractual, prohibitive software license before ever even using the software.

大多数EULA协议还包括一份用户合同，强制用户在使用软件之前同意合同性的、禁止性的软件许可来进一步约束用户。

Thus, most proprietary software restricts users via multiple interlocking legal and technological means. Any license that truly respect the software freedom of all users must not only grant appropriate copyright permissions, but also prevent restrictions from other legal and technological means like those listed above.

所以，大多数专有软件会通过多种相互关联的法律和技术手段来限制用户。任何真正尊重用户软件自由的许可证，不仅必须授予适当的版权许可，还必须防止上述其他法律和技术手段的限制。

1.2.4 Non-USA Copyright Regimes​

1.2.4 美国之外的版权制度​

Generally speaking, copyright law operates similarly enough in countries that have signed the Berne Convention on Copyright, and software freedom licenses have generally taken advantage of this international standardization of copyright law. However, copyright law does differ from country to country, and commonly, software freedom licenses like the GPL must be considered under the copyright law in the jurisdiction where any licensing dispute occurs.

一般来说，在签署了《伯尔尼版权公约》的国家中，版权法的运作非常相似，软件自由许可通常采用了国际标准化的版权法。然而，不同国家的版权法确实有所不同，通常像GPL这样的软件自由许可，必须在发生许可纠纷的司法管辖区，根据版权法予以考虑。

Those who are most familiar with the USA's system of copyright often are surprised to learn that there are certain copyright controls that cannot be waived nor disclaimed. Specifically, many copyright regimes outside the USA recognize a concept of moral rights of authors. Typically, moral rights are fully compatible with respecting software freedom, as they are usually centered around controls that software freedom licenses generally respect, such as the right of an authors to require proper attribution for their work.

那些最熟悉美国版权制度的人通常会惊讶地发现，有些版权控制既不能放弃也不能否认。具体来说，美国以外的许多版权制度都承认作者的道德权利概念。通常，道德权利与尊重软件自由完全兼容，因为道德权利通常是以软件自由许可所允许的控制为中心，例如作者要求对其作品进行适当归属的权利。

1.3 A Community of Equality​

1.3 平等的社区​

The previous section described the principles of software freedom, a brief introduction to mechanisms that typically block these freedoms, and the simplest ways that copyright holders might grant those freedoms to their users for their copyrighted works of software. The previous section also introduced the idea of copyleft : a licensing mechanism to use copyright to not only grant software freedom to users, but also to uphold those rights against those who might seek to curtail them.

上一节描述了软件自由的原则，简要介绍了阻止这些自由的一些机制，以及版权所有者授予用户软件自由的最简单的方式，允许用户使用受版权保护的软件作品。同时还介绍了copyleft 的概念：一种使用版权的许可机制，不仅可以授予用户软件自由，还可以维护这些权利，防止试图限制这些权利的人。

Copyleft, as defined in [1.2.2,] is a general term for this mechanism. The remainder of this text will discuss details of various real-world implementations of copyleft --most notably, the GPL.

如[第1.2.2节]的Copyleft定义，它是该机制的一个通用术语。本书的其他章节将会讨论现实世界中copyleft的一些实现方式 -- 最值得注意的就是GPL。

This discussion begins first with some general explanation of what the GPL is able to do in software development communities. After that brief discussion in this section, deeper discussion of how GPL accomplishes this in practice follows in the next chapter.

讨论首先会解释GPL在软件开发社区中的作用。本节只进行简短讨论，下一章将深入讨论GPL如何在实践中实现这一点。

Simply put, though, the GPL ultimately creates a community of equality for both business and noncommercial users.

不过，简单来说，最终GPL为商业用户及非商业用户创建了一个平等的社区。

1.3.1 The Noncommercial Community​

1.3.1 非商业社区​

A GPL'd code base becomes a center of a vibrant development and user community. Traditionally, volunteers, operating noncommercially out of keen interest or "scratch an itch" motivations, produce initial versions of a GPL'd system. Because of the efficient distribution channels of the Internet, any useful GPL'd system is adopted quickly by noncommercial users.

GPL的代码库已经成为充满活力的开发者和用户社区的中心。一般来说，出于浓厚的兴趣爱好或“试一把”的动机，志愿者会以非商业的方式制作一个GPL系统的初始版本。由于互联网的高效分发渠道，任何有用的GPL系统都会很快被非商业用户所采用。

Fundamentally, the early release and quick distribution of the software gives birth to a thriving noncommercial community. Users and developers begin sharing bug reports and bug fixes across a shared intellectual commons. Users can trust the developers, because they know that if the developers fail to address their needs or abandon the project, the GPL ensures that someone else has the right to pick up development. Developers know that the users cannot redistribute their software without passing along the rights granted by the GPL, so they are assured that every one of their users is treated equally.

从根本上来说，软件的早期发布和快速分发催生了一个繁荣的非商业社区。用户和开发人员都在知识共享的社区中分享错误报告和修复补丁。用户非常信任开发人员，因为他们知道如果开发人员不能满足他们的需求或放弃项目，GPL协议能确保其他人有权接手并持续开发。开发人员知道，如果将GPL的权利授予用户，用户就没法二次分发他们的软件，因此他们需要确信每一位用户受到平等对待。

Because of the symmetry and fairness inherent in GPL'd distribution, nearly every GPL'd package in existence has a vibrant noncommercial user and developer base.

就是因为GPL分发协议的对称性和公平性，几乎每个GPL项目都拥有一个活跃的非商业用户和开发者群体。

1.3.2 The Commercial Community​

1.3.2 商业群体​

By the same token, nearly all established GPL'd software systems have a vibrant commercial community. Nearly every GPL'd system that has gained wide adoption from noncommercial users and developers eventually begins to fuel a commercial system around that software.

同样，几乎所有已建立的GPL软件系统都有一个充满活力的商业社区。每个获得非商业用户和开发人员拥护的GPL系统，最终几乎都开始围绕该软件为商业系统提供动力。

For example, consider the Samba file server system that allows Unix-like systems (including GNU/Linux) to serve files to Microsoft Windows systems. Two graduate students originally developed Samba in their spare time and it was deployed noncommercially in academic environments.⁹ However, very soon for-profit companies discovered that the software could work for them as well, and their system administrators began to use it in place of Microsoft Windows NT file-servers. This served to lower the cost of running such servers by orders of magnitude. There was suddenly room in Windows file-server budgets to hire contractors to improve Samba. Some of the first people hired to do such work were those same two graduate students who originally developed the software.

例如，以Samba文件服务器系统为例，它允许类Unix系统（如GNU/Linux）向微软的Windows系统提供文件服务。Samb最初是由两名研究生在业余时间开发的，并在学术环境中部署，并未商业化。⁹ 之后很快商业公司就发现了该软件也适用于他们，公司的系统管理员开始使用它取代了微软的Windows NT文件服务器。这有助于将此类服务器的运行成本降低几个数量级。Windows文件服务器就有了多的预算空间，可以雇用承包商来改进Samba。最早受雇从事这项工作的正是最初开发该软件的两名研究生。

The noncommercial users, however, were not concerned when these two fellows began collecting paychecks off of their GPL'd work. They knew that because of the nature of the GPL that improvements that were distributed in the commercial environment could easily be folded back into the standard version. Companies are not permitted to proprietarize Samba, so the noncommercial users, and even other commercial users are safe in the knowledge that the software freedom ensured by the GPL will remain protected.

当那两位学生开始从他们的GPL工作中获取报酬时，非商业用户也并不担心。他们知道，由于GPL的性质，在商业环境中实现的改进会很快地融入到标准版本。不允许任何公司将Samba私有化，非商业用户、其他商业用户都知道，GPL协议会确保软件自由将继续受到保护。

Commercial developers also work in concert with noncommercial developers. Those two now-long-since graduated students continue to contribute to Samba altruistically, but also get paid work doing it. Priorities change when a client is in the mix, but all the code is contributed back to the standard version. Meanwhile, many other individuals have gotten involved noncommercially as developers, because they want to "cut their teeth on Free Software," or because the problems interest them. When they get good at it, perhaps they will move on to another project, or perhaps they will become commercial developers of the software themselves.

商业开发商也会与非商业开发商合作。那两位已经毕业了的学生继续无私地为Samba做出贡献，但同时也获得了报酬。当有客户参与其中时，优先级会发生变化，但所有的代码都会回馈给标准版本。与此同时，许多其他人也作为开发者参与了非商业活动，因为他们想“在自由软件上小试牛刀”，或者是他们对这些问题感兴趣。当他们擅长编程时，也许会转向另一个项目，或者他们自己可能会成为软件的商业开发人员。

No party is a threat to another in the GPL software scenario because everyone is on equal ground. The GPL protects rights of the commercial and noncommercial contributors and users equally. The GPL creates trust, because it is a level playing field for all.

在GPL软件场景中，任何一方都不会对另外一方构成威胁，因为每个人都是平等的。GPL协议平等地保护了商业和非商业贡献者和用户的权利。GPL协议创造信任，因为它位所有人提供了公平的竞争环境。

1.3.3 Law Analogy​

1.3.3 法律类比​

In his introduction to Stallman's Free Software, Free Society, Lawrence Lessig draws an interesting analogy between the law and Free Software. He argues that the laws of a free society must be protected much like the GPL protects software. So that I might do true justice to Lessig's argument, I quote it verbatim:

在介绍Stellman的《自由软件、自由社会》时，Lawrence Lessig在法律和自由软件之间做了一个有趣的类比。他认为自由社会的法律也需要受到保护，就像GPL协议保护软件一样。为了能真正公正地对待Lessig的论点，我逐字引用了它：

A "free society" is regulated by law. But there are limits that any free society places on this regulation through law: No society that kept its laws secret could ever be called free. No government that hid its regulations from the regulated could ever stand in our tradition. Law controls. But it does so justly only when visibly. And law is visible only when its terms are knowable and controllable by those it regulates, or by the agents of those it regulates (lawyers, legislatures).

“自由社会”是受法律规范的。但是任何自由社会都通过法律对这种规定施加了限制：任何对法律保密的社会都不能被称为自由。任何向受监管者隐藏其法规的政府都无法立足于我们的传统。法律控制。但只有在显而易见的情况下，它才会这样做。法律只有在其条款可被监管者或监管者的代理人（律师、立法机关）知晓和控制时才是可见的。

This condition on law extends beyond the work of a legislature. Think about the practice of law in American courts. Lawyers are hired by their clients to advance their clients' interests. Sometimes that interest is advanced through litigation. In the course of this litigation, lawyers write briefs. These briefs in turn affect opinions written by judges. These opinions decide who wins a particular case, or whether a certain law can stand consistently with a constitution.

这种法律条件超出了立法机关的工作范围。想想美国法院的法律实践。律师受雇于他们的客户，目的是促进他们客户的利益。有时，这种利益是通过法律诉讼来推进的。在此诉讼过程中，律师撰写简报。这些简报反过来会影响法官撰写的意见。这些意见决定了在某一案件中谁会获胜，或者某项法律是否能够与宪法保持一致。

All the material in this process is free in the sense that Stallman means. Legal briefs are open and free for others to use. The arguments are transparent (which is different from saying they are good), and the reasoning can be taken without the permission of the original lawyers. The opinions they produce can be quoted in later briefs. They can be copied and integrated into another brief or opinion. The "source code" for American law is by design, and by principle, open and free for anyone to take. And take lawyers do---for it is a measure of a great brief that it achieves its creativity through the reuse of what happened before. The source is free; creativity and an economy is built upon it.

正如Stallman所说，这个过程中的所有材料都是免费的。法律简报是公开的，可供他人免费使用。论据透明（这不同于说它们是好的），无需原律师许可即可取证。他们提出的意见可以在以后的简报中引用。可以将它们复制并整合到另一份简报或意见中。美国法律的“源代码”在设计上和原则上都是开放的，任何人都可以免费使用。以律师的做法为例——因为这是一个伟大的简报的衡量标准， 它通过重用以前的案例来实现其创造力。来源是免费的；创造力和经济是建立在它之上的。

This economy of free code (and here I mean free legal code) doesn't starve lawyers. Law firms have enough incentive to produce great briefs even though the stuff they build can be taken and copied by anyone else. The lawyer is a craftsman; his or her product is public. Yet the crafting is not charity. Lawyers get paid; the public doesn't demand such work without price. Instead this economy flourishes, with later work added to the earlier.

这种免费代码经济（这里我指的是免费法律代码）不会让律师挨饿。律师事务所有足够的动力来制作出色的简报，即使他们制作的东西可以被其他任何人拿走和复制。律师是工匠；他或她的简报是公开的。然而，手工艺品不是慈善。律师得到报酬；公众不会要求律师无偿工作。取而代之的是，这种经济会蓬勃发展，后期的工作会逐渐添加到早期的工作中。

We could imagine a legal practice that was different --- briefs and arguments that were kept secret; rulings that announced a result but not the reasoning. Laws that were kept by the police but published to no one else. Regulation that operated without explaining its rule.

我们可以想象一种不同的法律实践——保持简报和论据的保密性；宣布结果但不宣布推理的裁决。警察遵守的法律，但不向其他人公开。没有解释规则的相关规定。

We could imagine this society, but we could not imagine calling it "free." Whether or not the incentives in such a society would be better or more efficiently allocated, such a society could not be known as free. The ideals of freedom, of life within a free society, demand more than efficient application. Instead, openness and transparency are the constraints within which a legal system gets built, not options to be added if convenient to the leaders. Life governed by software code should be no less.

我们可以想象这样的社会，但我们无法假装称它为“自由”。无论这个社会中的激励是否会得到更好或更有效的分配，这样的社会都不能被称为自由。自由的理想，自由社会中的生活，需要的不仅仅是有效的应用。相反，公开和透明是建立法律体系的约束条件，而不是领导者需要时可以随意添加的选项。由软件代码支配的生活应该不会少。

Code writing is not litigation. It is better, richer, more productive. But the law is an obvious instance of how creativity and incentives do not depend upon perfect control over the products created. Like jazz, or novels, or architecture, the law gets built upon the work that went before. This adding and changing is what creativity always is. And a free society is one that assures that its most important resources remain free in just this sense.[^10^]

代码编写不是法律诉讼。它更好、更丰富、更有生产力。但创造力和激励是不依赖于对所创造产品的完美与否的，法律就是一个明显的例子。就像爵士乐、小说或建筑一样，法律是建立在之前的作品之上的。这种添加和改变就是创造力的本质所在。一个自由的社会就是确保其最重要的资源在某种意义上保持免费。¹⁰

In essence, lawyers are paid to service the shared commons of legal infrastructure. Few citizens defend themselves in court or write their own briefs (even though they are legally permitted to do so) because everyone would prefer to have an expert do that job.

从本质上讲，律师是为法律基础设施的公共服务而工作的。很少有公民在法庭上为自己辩护或撰写自己的案情简报（即使法律允许他们这样做），每个人都更愿意让专家来做这项工作。

The Free Software economy is a market ripe for experts. It functions similarly to other well established professional fields like the law. The GPL, in turn, serves as the legal scaffolding that permits the creation of this vibrant commercial and noncommercial Free Software economy.

对于专家来说，自由软件经济是一个成熟的市场。它的功能类似于法律等其他成熟的专业领域。反过来，GPL协议又是一个法律脚手架，允许创建这个充满活力的商业和非商业的自由软件经济。

CHAPTER 2 A TALE OF TWO COPYLEFT LICENSES​

第2章 两个著佐权许可证的故事​

While determining the proper methodology and criteria to yield an accurate count remains difficult, the GPL is generally considered one of the most widely used Free Software licenses. For most of its history --- for 16 years from June 1991 to June 2007 --- there was really only one version of the GPL, version 2.

尽管还没办法选择适当的方法和标准给出准确统计，但GPL是公认最广泛使用的自由软件许可证之一。在它大部分历史（从1991年6月到2007年6月的16年）中，GPL实际上只有一个版本，即第二版。

However, the GPL had both earlier versions before version 2, and, more well known, a revision to version

然而，GPL既有第二版之前的早期版本，也有更知名的第三版修订版。

Historical Motivations for the General Public License​

2.1 通用公共许可证的历史动因​

The earliest license to grant software freedom was likely the Berkeley Software Distribution ("BSD") license. This license is typical of what are often called lax, highly permissive licenses. Not unlike software in the public domain, these non-copyleft licenses (usually) grant software freedom to users, but they do not go to any effort to uphold that software freedom for users. The so-called "downstream" (those who receive the software and then build new things based on that software) can restrict the software and distribute further.

最早的授予软件自由的许可证可能是伯克利软件分发（Berkeley Software Distribution，“BSD”）许可证。这个许可证是典型的、高度宽松的许可证，通常被称为“宽松许可证”。与公共领域的软件不一样，这些非著佐权许可证（通常）将软件自由授予用户，但它们并不为用户维护这种软件自由。所谓的 "下游"（那些收到软件后在该软件基础上添砖加瓦的人）可以限制该软件进一步分发。

The GNU's Not Unix ("GNU") project, which Richard M. Stallman ("RMS") founded in 1984 to make a complete Unix-compatible operating system implementation that assured software freedom for all. However, RMS saw that using a license that gave but did not assure software freedom would be counter to the goals of the GNU Project. RMS invented "copyleft" as an answer to that problem, and began using various copyleft licenses for the early GNU Project programs.¹

为了实现对完全兼容Unix的操作系统的应用、保证所有人的软件自由，Richard M. Stallman（RMS）于1984年创建“GUN Not Unix（GNU）”项目。然而，RMS发现使用许可证可以赋予却不能保证软件自由，这可能与GUN项目的目标背道而驰。于是RMS发明了“著佐权”来解决这个问题，并且开始在早期GNU项目程序中使用各种形式的著佐权许可证。¹

Proto-GPLs And Their Impact​

2.2 原始GPL及其影响​

The earliest copyleft licenses were specific to various GNU programs. For example, The Emacs General Public License was likely the first copyleft license ever published. Interesting to note that even this earliest copyleft license contains a version of the well-known GPL copyleft clause:

最早的著佐权许可证是专门针对各种GNU程序的。例如，Emacs通用公共许可证可能是有史以来发布的第一个著佐权许可证。有趣的是，即使是这个最早的著佐权许可证也包含了著名的GPL著佐权条款的一个版本：

You may modify your copy or copies of GNU Emacs . . . provided that you also . . . cause the whole of any work that you distribute or publish, that in whole or in part contains or is a derivative of GNU Emacs or any part thereof, to be licensed at no charge to all third parties on terms identical to those contained in this License Agreement.

你可以修改你的GNU Emacs副本……如果你也……使你的任何全部或部分包含GNU Emacs或作为其衍生作品分发或发布的作品的整体，以与本许可协议中包含的条款相同的条款免费授权给所有第三方。

This simply stated clause is the fundamental innovation of copyleft. Specifically, copyleft uses the copy- right holders' controls on permission to modify the work to add a conditional requirement. Namely, downstream users may only have permission to modify the work if they pass along the same permissions on the modified version that came originally to them.

这个阐述简明的条款是著佐权的根本创新。具体来说，著佐权通过著作权所有者对修改作品的权限的控制，增加了一个条件，即：

下游用户只有在将他们最初被赋予的修改版本的权限传递给他人时，才可能拥有修改作品的权限。

These original program-specific proto-GPLs give an interesting window into the central ideas and devel- opment of copyleft. In particular, reviewing them shows how the text of the GPL we know has evolved to address more of the issues discussed earlier in § [1.2.3.]

这些起初特定于程序的原始GPL提供了一个了解著佐权的中心思想和发展的有趣窗口。此外，仔细研究它们可以看到我们熟悉的GPL文本是如何逐步演变以解决前面 [1.2.3.] 节中讨论过的更多问题的。

The GNU General Public License, Version 1​

2.3 GNU通用公共许可证，第一版​

In January 1989, the FSF announced that the GPL had been converted into a "subroutine" that could be reused not just for all FSF-copyrighted programs, but also by anyone else. As the FSF claimed in its announcement of the GPLv1:²

1989年1月，FSF宣布GPL已经被转换成为一个“子例程”，不仅可以被所有受FSF著作权保护的程序重复使用，还可以被任何其他人重复使用。正如FSF在GPLv1的公告中所宣称的那样：²

To make it easier to copyleft programs, we have been improving on the legalbol architecture of the General Public License to produce a new version that serves as a general-purpose subroutine: it can apply to any program without modification, no matter who is publishing it.

为了使著佐权程序更方便使用，我们一直在改进通用公共许可证的法律体系结构，以便产生一个可以作为通用子例程的新版本：无论由谁发布，它都适用于任何程序而无需修改。

This, like many inventive ideas, seems somewhat obvious in retrospect. But, the FSF had some bright people and access to good lawyers when it started. It took almost five years from the first copyleft licenses to get to a generalized, reusable GPLv1. In the context and mindset of the 1980s, this is not surprising. The idea of reusable licensing infrastructure was not only uncommon, it was virtually nonexistent! Even the early BSD licenses were simply copied and rewritten slightly for each new use.³ The GPLv1's innovation of reusable licensing infrastructure, an obvious fact today, was indeed a novel invention for its day.⁴

这一点，就像许多具有创造性的想法一样，回想起来似乎是显而易见的。但是，FSF在成立之初拥有一些人才，也能接触到优秀的律师。从第一个著佐权许可证到形成通用的、可重复使用的GPLv1，花了将近五年的时间。在20世纪80年代的背景和思维模式下，这并不奇怪。可重复使用基础许可的想法不仅不常见，而且几乎不存在！即使是早期的BSD许可证也只是通过简单地复制和改写来适应每个新用途。³GPLv1对可重复使用基础许可的创新，在今天是显而易见的事实，在当时确实是一项新颖的发明。⁴

The GNU General Public License, Version 2​

2.4 GNU通用公共许可证，第二版​

The GPLv2 was released two and a half years after GPLv1, and over the following sixteen years, it became the standard for copyleft licensing until the release of GPLv3 in 2007 (discussed in more detail in the next section).

GPLv2比GPLv1晚两年半发布，在接下来的16年里，它成为了著佐权许可的标准，直到2007年GPLv3发布(下一节将详细讨论)。

While this tutorial does not discuss the terms of GPLv1 in detail, it is worth noting below the three key changes that GPLv2 brought:

虽然本指南不详细讨论GPLv1的条款，但GPLv2带来的三个关键变化值得一提：

• Software patents and their danger are explicitly mentioned, inspiring (in part) the addition of GPLv2 §§5--7. (These sections are discussed in detail in §7.2, §7.3 and §7.5 of this tutorial.) 软件专利及其风险被明确提及，(在一定程度上)激发了GPLv2 §§5-7的加入。(这些部分将在本指南的§7.2、§7.3和§7.5中详细讨论。)

• GPLv2 §2's copyleft terms are expanded to more explicitly discuss the issue of combined works. (GPLv2 *§*2 is discussed in detail in § 5.1 in this tutorial).

• GPLv2 §2的著佐权术语得到了扩展，可以更明确地讨论组合作品的问题。(GPLv2 §2将在本指南的§5.1中详细讨论)。

• GPLv2 §3 includes more detailed requirements, including the phrase "the scripts used to control compi- lation and installation of the executable", which is a central component of current GPLv2 enforcement. (GPLv2 §3 is discussed in detail in §5.2 in this tutorial).

• GPLv2 §3包含了更详细的需求，包括短语“用于控制可执行文件的编译和安装的脚本”，这是当前GPLv2实施的核心组件。(GPLv2 §3将在本指南的§5.2中详细讨论)。

The next chapter discusses GPLv2 in full detail, and readers who wish to dive into the section-by-section discussion of the GPL should jump ahead now to that chapter. However, the most interesting fact to note here is how GPLv2 was published with little fanfare and limited commentary. This contrasts greatly with the creation of GPLv3.

下一章将详细讨论GPLv2，希望深入了解GPL逐节讨论的读者现在可以跳到那一章。然而，这里要指出的最有趣的事实是，GPLv2是如何在没有大肆宣传和有限报道的情况下发布的。这与GPLv3的诞生形成了鲜明对比。

The GNU General Public License, Version 3​

2.5 GNU通用公共许可证，第三版​

RMS began drafting GPLv2.2 in mid-2002, and FSF ran a few discussion groups during that era about new text of that license. However, rampant violations of the GPL required more immediate attention of FSF's licensing staff, and as such, much of the early 2000's was spent doing GPL enforcement work.⁵ In 2006, FSF began in earnest drafting work for GPLv3.

RMS在2002年年中开始起草GPLv2.2, FSF在那个时期组织了一些讨论小组，讨论该许可证的新文本。然而，猖獗的GPL侵权行为需要FSF的授权人员更加及时的关注，因此，2000年早期的大部分时间都花在了GPL的实施工作上。5 2006年，FSF正式开始GPLv3的起草工作。

The GPLv3 process began in earnest in January 2006. It became clear that many provisions of the GPL could benefit from modification to fit new circumstances and to reflect what the entire community learned from experience with version 2. Given the scale of revision it seems proper to approach the work through public discussion in a transparent and accessible manner.

GPLv3的进程于2006年1月正式开始。很明显，GPL的许多条款可以从修改中完善，以适应新的情况并反映出整个社区从第二版的经验中得到的教训。考虑到修订的规模，似乎以透明和可访问的方式通过公开讨论来处理工作是合适的。

The GPLv3 process continued through June 2007, culminating in publication of GPLv3 and LGPLv3 on 29 June 2007, AGPLv3 on 19 November 2007, and the GCC Runtime Library Exception on 27 January 2009.

GPLv3进程一直持续到2007年6月，最终于2007年6月29日发布了GPLv3和LGPLv3，并于2007年11月19日发布了AGPLv3，以及于2009年1月27日发布了GCC运行时库异常。

All told, four discussion drafts of GPLv3, two discussion drafts of LGPLv3 and two discussion drafts of AGPLv3 were published and discussed. Ultimately, FSF remained the final arbiter and publisher of the licenses, and RMS himself their primary author, but input was sought from many parties, and these licenses do admittedly look and read more like legislation as a result. Nevertheless, all of the "v3" group are substantially better and improved licenses.

总共发布并讨论了四份GPLv3讨论草案、两份LGPLv3讨论草案和两份AGPLv3讨论草案。最终，FSF仍然是许可证的最终仲裁者和出版方，RMS自己是许可证的主要作者，但是征求了许多人士的意见，因此这些许可证确实看起来和读起来更像立法。尽管如此，整个“v3”组都有了很大的改进，成为了更好的许可证。

GPLv3 and its terms are discussed in detail in Chapter [9.]

GPLv3及其术语将在第[9]章中详细讨论。

The Innovation of Optional "Or Any Later" Version​

2.6 可选“或任何后来”版本的创新​

An interesting fact of all GPL licenses is that there are ultimately multiple choices for use of the license. The FSF is the primary steward of GPL (as discussed later in §8.1 and §9.17). However, those who wish to license works under GPL are not required to automatically accept changes made by the FSF for their own copyrighted works.

所有GPL许可证的一个有趣的事实是：最终有多种使用许可证的选择。FSF是GPL的主要管理者（稍后将在*§8.1 和§*9.17).中讨论）。然而，那些希望在GPL下授权作品的人不需要自动接受FSF对他们自己受著作权保护的作品所做的更改。

Each licensor may chose three different methods of licensing, as follows:

每个许可人可以选择以下三种不同的许可方式：

• explicitly name a single version of GPL for their work (usually indicated in shorthand by saying the license is "GPLvX-only"), or

• 为他们的作品明确指定一个GPL版本（一般用“仅限GPLvX”这样的简写来表示），或者

• name no version of the GPL, thus they allow their downstream recipients to select any version of the GPL they choose (usually indicated in shorthand by saying the license is simply "GPL"), or

• 不指定GPL的任何版本，这样他们允许下游接收者任意选择GPL的任何版本（一般只简称许可证是“GPL”），或者

• name a specific version of GPL and give downstream recipients the option to choose that version "or any later version as published by the FSF" (usually indicated by saying the license is "GPLvX-or-later")⁶

• 指定一个特定的GPL版本，并让下游接收者选择该版本“或由FSF发布的任何更高版本”（一般会说许可证是“GPLvX或更高版本”）。[^6^]

Oddly, this flexibility has received (in the opinion of the authors, undue) criticism, primarily because of the complex and oft-debated notion of "license compatibility" (which is explained in detail in 9.10). Copyleft licenses are generally incompatible with each other, because the details of how they implement copyleft differs. Specifically, copyleft works only because of its requirement that downstream licensors use the same license for combined and modified works. As such, software licensed under the terms of "GPLv2- only" cannot be combined with works licensed "GPLv3-or-later". This is admittedly a frustrating outcome.

奇怪的是，这种灵活性受到了（在作者看来是不适当的）批评，主要是因为“许可证兼容性”（x 9.10中有详细解释）的复杂性以及对其概念的争论不断。著佐权许可证通常彼此不兼容，因为履行著佐权的细节不同。具体来说，著佐权生效的唯一条件是它要求下游许可方对合并和修改的作品使用相同许可。因此，在“仅限GPLv2”条款下授权的软件不能与使用“GPLv3或更高版本”许可的作品结合。诚然，这是一个令人沮丧的结果。

Other copyleft licenses that appeared after GPL, such as the Creative Commons "Attribution-Share Alike" licenses, the Eclipse Public License and the Mozilla Public License require all copyright holders choosing to use any version of those licenses to automatically allow use of their copyrighted works under new versions.[^7^] Of course, Creative Commons, the Eclipse Foundation, and the Mozilla Foundation (like the FSF) have generally served as excellent stewards of their licenses. Copyright holders using those licenses seems to find it acceptable to fully delegate all future licensing decisions for their copyrights to these organizations without a second thought.

在GPL之后出现的其他著佐权许可证，如知识共享“署名-相同方式共享”许可证、Eclipse公共许可证和Mozilla公共许可证要求所有选择使用这些许可证的任何版本的著作权所有者自动允许在新版本下使用其受著作权保护的作品。7 当然，知识共享组织、Eclipse基金会和Mozilla基金会（像FSF一样）通常都是他们自己的许可证的优秀管理员。使用这些许可证的著作权所有者似乎发现可以毫不犹豫地将其著作权的所有未来许可决策完全委托给这些组织。

However, note that FSF gives herein the control of copyright holders to decide whether or not to implicitly trust the FSF in its work of drafting future GPL versions. The FSF, for its part, does encourage copyright holders to chose by default "GPLvX-or-later" (where X is the most recent version of the GPL published by the FSF). However, the FSF does not mandate that a choice to use any GPL requires a copyright holder ceding its authority for future licensing decisions to the FSF. In fact, the FSF considered this possibility for GPLv3 and chose not to do so, instead opting for the third-party steward designation clause discussed in Section 9.17.

但是请注意，FSF在此赋予了著作权所有者决策权，他们可以决定是否在起草未来GPL版本的工作中绝对信任FSF。就FSF而言，它确实鼓励著作权所有者默认选择“GPLvX或更高版本”（其中X是FSF发布的GPL的最新版本）。然而，FSF并没有强制要求选择使用任何GPL需要著作权所有者将其未来许可决策的权力交给FSF。事实上，FSF考虑了GPLv3的这种可能性却选择不这样做，而是选择了9.17.节中讨论的第三方管理指定条款。

Complexities of Two Simultaneously Popular Copylefts​

2.7 两个著佐权同时普遍使用的复杂性​

Obviously most GPL advocates would prefer widespread migration to GPLv3, and many newly formed projects who seek a copyleft license tend to choose a GPLv3-based license. However, many existing copylefted projects continue with GPLv2-only or GPLv2-or-later as their default license.

显然，大多数GPL倡导者更倾向于广泛迁移至GPLv3，而且许多新成立的项目在挑选著佐权许可证时倾向于选择基于GPLv3的许可证。然而，许多现有受著佐权保护的项目仍继续使用“仅限GPLv2”或“GPLv2或更高版本”作为默认许可证。

While GPLv3 introduces many improvements --- many of which were designed to increase adoption by for-profit companies --- GPLv2 remains a widely used and extremely popular license. The GPLv2 is, no doubt, a good and useful license.

虽然GPLv3引入了许多改进——其中许多改进旨在促进营利性公司的采用——GPLv2仍是一个被广泛使用和非常受欢迎的许可证。毫无疑问，GPLv2是一个优秀且实用的许可证。

However, unlike GPLv1 before it, GPLv2 remains an integral part of the copyleft licensing infrastructure. As such, those who seek to have expertise in current topics of copyleft licensing need to study both the GPLv2 and GPLv3 family of licenses.

然而，与之前的GPLv1不同的是，GPLv2仍然是著佐权基础许可中不可分割的一部分。因此，那些希望在当前著佐权许可相关的话题方面拥有专业知识的人需要同时研究GPLv2和GPLv3系列许可证。

Furthermore, GPLv3 is more easily understood by first studying GPLv2. This is not only because of their chronological order, but also because much of the discussion material available for GPLv3 tends to talk about GPLv3 in contrast to GPLv2. As such, a strong understanding of GPLv2 helps in understanding most of the third-party material found regarding GPLv3. Thus, the following chapter begins a deep discussion of GPLv2.

此外，先研究GPLv2会更容易理解GPLv3。这不仅是因为它们的时间顺序，还因为许多关于GPLv3的可用讨论材料倾向于将GPLv3与GPLv2进行对比。因此，对GPLv2的深刻理解有助于理解大多数关于GPLv3的第三方材料。因此，下一章开始深入讨论GPLv2。

CHAPTER 3 RUNNING SOFTWARE AND VERBATIM COPYING​

第3章 运行软件与逐字复制​

This chapter begins the deep discussion of the details of the terms of GPLv2. In this chapter, we consider the first two sections: GPLv2 §§0--2. These are the straightforward sections of the GPL that define the simplest rights that the user receives.

本章开始深入讨论GPLv2条款的细节。在本章中，我们将考虑前两个部分：GPLv2 第0-2条。这些是GPL中简单明了的部分，定义了用户获得的最单纯的权利。

3.1 GPLv2 §0: Freedom to Run​

3.1 GPLv2 §0：自由运行​

GPLv2 §0, the opening section of GPLv2, sets forth that copyright law governs the work. It specifically points out that it is the "copyright holder" who decides if a work is licensed under its terms and explains how the copyright holder might indicate this fact.

GPLv2 §0——GPLv2的开篇部分阐述了作品受著作权法管辖。该部分特别指出由“著作权所有者”决定作品是否根据其条款进行许可，并解释了著作权所有者如何表明这一事实。

A bit more subtly, GPLv2 §0 makes an inference that copyright law is the only system that can restrict the software. Specifically, it states:

更微妙的一点是，GPLv2 §0推断著作权法是唯一可以限制软件的系统。具体来说，它指出:

Activities other than copying, distribution and modification are not covered by this License; they are outside its scope.

本许可证对除复制、分发和修改外的其他活动无效；它们超出了其适用范围。

In essence, the license governs only those activities, and all other activities are unrestricted, provided that no other agreements trump GPLv2 (which they cannot; see Sections 7.3 and 7.5). This is very important, because the Free Software community heavily supports users' rights to "fair use" and "unregulated use" of copyrighted material. GPLv2 asserts through this clause that it supports users' rights to fair and unregulated uses.

本质上，许可证只管理这些活动，所有其他活动都是不受限制的，如果没有其他协议限制GPLv2（这是不可能的；参见第7.3和7.5).节）。这是非常重要的，因为自由软件社区大力支持用户享有对受著作权保护的材料的“合理使用”和“不受管制的使用”的权利。GPLv2通过这一条款声明它支持用户公平和不受管制的使用权利。

Fair use (called "fair dealing" in some jurisdictions) of copyrighted material is an established legal doctrine that permits certain activities regardless of whether copyright law would otherwise restrict those activities. Discussion of the various types of fair use activity are beyond the scope of this tutorial. However, one important example of fair use is the right to quote portions of the text in a larger work so as to criticize or suggest changes. This fair use right is commonly used on mailing lists when discussing potential improvements or changes to Free Software.

对受著作权保护的材料的合理使用（在某些司法管辖区称为“公平交易”）是一种既定的法律原则，允许进行某些活动而不管著作权法是否会限制这些活动。关于各种类型的合理使用活动的讨论超出了本指南的范围。然而，合理使用的一个重要典型是有权在较大的作品中引用文本的部分内容，以便进行批评或提出修改建议。当讨论自由软件的潜在改进或变化时，这种合理使用权在邮件列表中会被经常使用。

Fair use is a doctrine established by the courts or by statute. By contrast, unregulated uses are those that are not covered by the statue nor determined by a court to be covered, but are common and enjoyed by many users. An example of unregulated use is reading a printout of the program's source code like an instruction book for the purpose of learning how to be a better programmer. The right to read something that you have access to is and should remain unregulated and unrestricted.

合理使用是由法院或法令确立的原则。相比之下，不受管制的使用是指那些不受法令保护也不在法院管辖范围内、但很常见且深受广大用户喜爱的使用方式。它的一个例子是：为了学习如何成为一个更好的程序员，像阅读说明书一样阅读程序源代码的打印资料。阅读你能读到的东西的权利是且应该保持不受监管和限制的。

Thus, the GPLv2 protects users' fair and unregulated use rights precisely by not attempting to cover them. Furthermore, the GPLv2 ensures the freedom to run specifically by stating the following:

因此，GPLv2正是通过不试图包含它们来保护用户的公平和不受监管的使用权。此外，GPLv2通过声明以下内容确保了运行的自由：

"The act of running the Program is not restricted."

“运行程序的行为不受限制。”

Thus, users are explicitly given the freedom to run by GPLv2 §0.

因此，用户明确地获得了使用GPLv2 §0运行的自由。

The bulk of GPLv2 §0 not yet discussed gives definitions for other terms used throughout. The only one worth discussing in detail is "work based on the Program". The reason this definition is particularly interesting is not for the definition itself, which is rather straightforward, but because it clears up a common misconception about the GPL.

尚未讨论的大部分GPLv2 §0给出了贯穿始终的其他术语的定义。唯一值得详细讨论的是“基于程序的作品”。这个定义之所以特别有趣不是因为这个相当简明的定义本身，而是因为它澄清了关于GPL的一个常见误解。

The GPL is often mistakenly criticized because it fails to give a definition of "derivative work" or "com- bined work". In fact, it would be incorrect and problematic if the GPL attempted to define these terms. A copyright license, in fact, has no control over the rules of copyright themselves. Such rules are the domain of copyright law and the courts --- not the licenses that utilize those systems.

GPL经常被错误地批评，因为它没有给出“衍生作品”或“组合作品”的定义。事实上，如果GPL试图定义这些术语，才是不正确且有问题的。著作权许可证实际上并不能控制著作权规则本身。这样的规则属于著作权法和法院（而不是使用这些系统的许可证）的管辖范围。

Copyright law as a whole does not propose clear and straightforward guidelines for identifying the deriva- tive and/or combined works of software. However, no copyright license --- not even the GNU GPL --- can be blamed for this. Legislators and court opinions must give us guidance in borderline cases. Meanwhile, lawyers will likely based their conclusions on the application of rules made in the context of literary or artistic copyright to the different context of computer programming and by analyzing the (somewhat limited) case law and guidance available from various sources. (Chapter [14.1] discusses this issue in depth.)

著作权法整体并没有就识别软件的衍生作品和/或组合作品提出明确而直接的指导方针。然而，没有著作权许可证——甚至GNU GPL——才应该对此负责。立法者和法院必须在边界模糊的案件中为我们提供指导。与此同时，律师们可能会根据文学或艺术著作权背景下制定的规则在计算机编程的不同背景下的应用情况，以及通过分析（有限的）案例法和各种渠道获得的指导来得出结论。（第[14.1]节深入讨论了这个问题。）

3.2 GPLv2 §1: Verbatim Copying​

3.2 GPLv2 §1：逐字复制​

GPLv2 §1 covers the matter of redistributing the source code of a program exactly as it was received. This section is quite straightforward. However, there are a few details worth noting here.

GPLv2 第1条涵盖了重新完整分发程序源代码的问题。这部分相当简单明了。但有一些细节值得一提。

The phrase "in any medium" is important. This, for example, gives the freedom to publish a book that is the printed copy of the program's source code. It also allows for changes in the medium of distribution. Some vendors may ship Free Software on a CD, but others may place it right on the hard drive of a pre-installed computer. Any such redistribution media is allowed.

“在任何媒介中”这句话很重要。举个例子，它交出了将程序源代码的打印副本作为一本书出版的自由。它还允许更改分发媒介。一些厂商可能以CD的形式推出自由软件，但其他厂商可能将其直接置入预装计算机的硬盘驱动器中。任何这样的重新分发媒体都是允许的。

Preservation of copyright notice and license notifications are mentioned specifically in GPLv2 *§*1. These are in some ways the most important part of the redistribution, which is why they are mentioned by name. GPL always strives to make it abundantly clear to anyone who receives the software what its license is. The goal is to make sure users know their rights and freedoms under GPL, and to leave no reason that users might be surprised the software is GPL'd. Thus throughout the GPL, there are specific references to the importance of notifying others down the distribution chain that they have rights under GPL.

GPLv2 §1中特别提到著作权通知和许可证通知的保存。在某种程度上，这些是重新分发作品中最重要的部分，这就是提及它们的原因。GPL一直在努力让收到软件的人都清楚地知道它的许可证是什么。我们的目标是确保用户知道他们在GPL限制下的权利和自由，没有理由让用户对软件使用GPL感到惊讶。因此，整个GPL中都有专门提到通知分发链下游的其他人他们拥有GPL限制下的权利的重要性。

GPL disclaims all warranties that legally can be disclaimed (which is discussed later in sections 8.3 and 8.4). Users generally rarely expect their software comes with any warranties, since typically all EULAs and other Free Software licenses disclaim warranties too. However, since many local laws require "consipi- cous" warranty disclaimers, GPLv2 1 explicitly mentions the importance of keeping warranty disclaimers in tact upon redistribution.

GPL放弃所有法律上可以放弃的担保（这将在后面的8.3节和8.4).节中讨论）。用户通常很少期望他们的软件附带任何担保，因为通常所有的EULA和其他自由软件许可证也都放弃担保。然而，由于许多地方法律要求“明显的”免责声明，GPLv2 *§*1明确提到在重新分发时完整保留免责声明的重要性。

Note finally that GPLv2 §1 creates groundwork for the important defense of commercial freedom. GPLv2 §1 clearly states that in the case of verbatim copies, one may make money. Re-distributors are fully permitted to charge for the re-distribution of copies of Free Software. In addition, they may provide the warranty protection that the GPL disclaims as an additional service for a fee. (See Section [12.2] for more discussion on making a profit from Free Software redistribution.)

最后请注意，GPLv2 §1为捍卫商业自由奠定了基础。GPLv2 §1明确指出在逐字复制的情况下可以赚钱。重新分发者对自由软件副本的重新分发版进行收费是完全允许的。此外，他们还可以提供GPL拒绝的担保，将其作为附加服务进行收费。（有关从自由软件重新分发中获利的更多讨论，请参见第[12.2]节。）

CHAPTER 4 DERIVATIVE WORKS: STATUTE AND CASE LAW​

第四章 衍生作品：法规和案例法​

As described in the [earlier general discussion of copylef]t, strong copyleft licenses such as the GPL seek to uphold software freedom via the copyright system. This principle often causes theoretical or speculative dispute among lawyers, because "the work" --- the primary unit of consideration under most copyright rules -- is not a unit of computer programming. In order to determine whether a "routine" an "object", a "function", a "library" or any other unit of software is part of one "work" when combined with other GPL'd code, we must ask a question that copyright law will not directly answer in the same technical terms.

如前面关于copyleft的一般讨论所述，像GPL这样的强制copyleft许可证通过版权系统来维护软件自由。这一原则经常引起律师之间的理论或推测性争议，因为在大多数版权规则下，“作品”——最主要的考虑单位——并不是计算机编程的一个单位。为了确定一个“程序”，一个“对象”，一个“函数”，一个“库”或任何其他软件单位，当与其他GPL代码组合时是否是一个“作品”，我们必须提出一个版权法直接无法用同样的技术术语回答的问题。

Therefore, this chapter digresses from discussion of GPL's exact text to consider the matter of combined and/or derivative works --- a concept that we must understand fully before considering GPLv2 2--3. At least under USA copyright law, The GPL, and Free Software licensing in general, relies critically on the concept of "derivative work" since software that is "independent," (i.e., not "derivative") of Free Software need not abide by the terms of the applicable Free Software license. As much is required by 106 of the Copyright Act, 17 U.S.C. 106 (2002), and admitted by Free Software licenses, such as the GPL, which (as we have seen) states in GPLv2 0 that "a 'work based on the Program' means either the Program or any derivative work under copyright law." It is being a derivative work of Free Software that triggers the necessity to comply with the terms of the Free Software license under which the original work is distributed. Therefore, one is left to ask, just what is a "derivative work"? The answer to that question differs depending on which court is being asked.

因此，在考虑GPL的确切文本之前，本章偏离讨论合并和/或衍生作品的问题——这是一个我们必须完全理解的概念，才能考虑GPLv2 2-3。至少在美国版权法下，GPL和自由软件许可证的普遍使用，关键在于“衍生作品”的概念，因为独立于自由软件的软件（即不是“衍生”软件）不必遵守适用的自由软件许可证条款。这在版权法第106条、17 U.S.C. 106（2002）中被要求，并被自由软件许可证，如GPL所承认，GPLv2 0规定：“基于该程序的作品”指的是该程序或根据版权法的任何衍生作品。”只有成为自由软件的衍生作品才会触发需要遵守原始作品所分发的自由软件许可证条款的必要性。因此，人们不得不问，什么是“衍生作品”？这个问题的答案取决于被问的是哪个法院。

The analysis in this chapter sets forth the differing definitions of derivative work by the circuit courts. The broadest and most established definition of derivative work for software is the abstraction, filtration, and comparison test ("the AFC test") as created and developed by the Second Circuit. Some circuits, including the Ninth Circuit and the First Circuit, have either adopted narrower versions of the AFC test or have expressly rejected the AFC test in favor of a narrower standard. Further, several other circuits have yet to adopt any definition of derivative work for software.

本章分析了各个巡回法院对派生作品的不同定义。对于软件而言，最广泛和最成熟的派生作品定义是由第二巡回法院创造和发展的抽象、过滤和比较测试（“AFC测试”）。包括第九巡回法院和第一巡回法院在内的一些巡回法院已经采用了AFC测试的较窄版本，或明确拒绝了AFC测试，而采用了较窄的标准。此外，其他几个巡回法院还没有采用任何关于软件派生作品的定义。

As an introductory matter, it is important to note that literal copying of a significant portion of source code is not always sufficient to establish that a second work is a derivative work of an original program. Conversely, a second work can be a derivative work of an original program even though absolutely no copying of the literal source code of the original program has been made. This is the case because copyright protection does not always extend to all portions of a program's code, while, at the same time, it can extend beyond the literal code of a program to its non-literal aspects, such as its architecture, structure, sequence, organization, operational modules, and computer-user interface.

作为一个引言，需要注意的是，直接复制源代码的大部分并不总是足以证明第二个作品是原始程序的派生作品。相反，即使完全没有复制原始程序的字面源代码，第二个作品也可以是原始程序的派生作品。这是因为版权保护并不总是延伸到程序代码的所有部分，同时，它也可以超越程序的字面代码，涵盖程序的非字面方面，例如其结构、序列、组织、操作模块和计算机用户界面。

The Copyright Act​

4.1 版权法​

The copyright act is of little, if any, help in determining the definition of a derivative work of software. However, the applicable provisions do provide some, albeit quite cursory, guidance. Section 101 of the Copyright Act sets forth the following definitions:

版权法在确定软件衍生作品的定义方面没有多少帮助，然而，适用的规定确实提供了一些相当肤浅的指导。版权法第101条规定了以下定义：

A "computer program" is a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result.

“计算机程序”是一组语句或指令，直接或间接用于计算机，以实现某种结果。

A "derivative work" is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a "derivative work."

“衍生作品”是基于一个或多个现有作品的作品，例如翻译、音乐编排、戏剧化、虚构化、电影版本、录音、艺术复制、缩写、概括或任何其他形式，在其中一个作品可以被重构、转化或改编。由编辑修订、注释、阐述或其他修改组成的作品，如果整体上代表了一部独创性作品，则为“衍生作品”。

These are the only provisions in the Copyright Act relevant to the determination of what constitutes a derivative work of a computer program. Another provision of the Copyright Act that is also relevant to the definition of derivative work is § 102(b), which reads as follows:

“衍生作品”是基于一个或多个现有作品的作品，例如翻译、音乐编排、戏剧化、虚构化、电影版本、录音、艺术复制、缩写、概括或任何其他形式，在其中一个作品可以被重构、转化或改编。由编辑修订、注释、阐述或其他修改组成的作品，如果整体上代表了一部独创性作品，则为“衍生作品”。

In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.

在任何情况下，对于作者原创的作品，版权保护都不会扩展到其中包含的任何思想、程序、流程、系统、操作方法、概念、原理或发现，无论其以何种形式被描述、解释、说明或体现在该作品中。

Therefore, before a court can ask whether one program is a derivative work of another program, it must be careful not to extend copyright protection to any ideas, procedures, processes, systems, methods of operation, concepts, principles, or discoveries contained in the original program. It is the implementation of this requirement to "strip out" unprotectable elements that serves as the most frequent issue over which courts disagree.

因此，在法院可以询问一个程序是否是另一个程序的衍生作品之前，必须小心不要将原始程序中包含的任何思想、程序、流程、系统、操作方法、概念、原理或发现扩展到版权保护范围之内。解决“剥离”不受保护元素的问题，是法院之间最常见的争议问题。

4.2 Abstraction, Filtration, Comparison Test​

4.2 抽象、筛选、比较测试​

As mentioned above, the AFC test for determining whether a computer program is a derivative work of an earlier program was created by the Second Circuit and has since been adopted in the Fifth, Tenth, and Eleventh Circuits. Computer Associates Intl., Inc. v. Altai, Inc., 982 F.2d 693 (2nd Cir. 1992); Engineering Dynamics, Inc. v. Structural Software, Inc., 26 F.3d 1335 (5th Cir. 1994); Kepner-Tregoe, Inc. v. Leadership Software, Inc., 12 F.3d 527 (5th Cir. 1994); Gates Rubber Co. v. Bando Chem. Indust., Ltd., 9 F.3d 823 (10th Cir. 1993); Mitel, Inc. v. Iqtel, Inc., 124 F.3d 1366 (10th Cir. 1997); Bateman v. Mnemonics, Inc., 79 F.3d 1532 (11th Cir. 1996); and, Mitek Holdings, Inc. v. Arce Engineering Co., Inc., 89 F.3d 1548 (11th Cir. 1996).

如上所述，用于确定计算机程序是否是早期程序的派生作品的AFC测试是由第二巡回法院创建的，自那时以来已被第五、第十和第十一巡回法院采纳。具体案例包括：Computer Associates Intl.，Inc. v. Altai，Inc.，982 F.2d 693（第二巡回法院1992年）；Engineering Dynamics，Inc. v. Structural Software，Inc.，26 F.3d 1335（第五巡回法院1994年）；Kepner-Tregoe，Inc. v. Leadership Software，Inc.，12 F.3d 527（第五巡回法院1994年）；Gates Rubber Co. v. Bando Chem. Indust.，Ltd.，9 F.3d 823（第十巡回法院1993年）；Mitel，Inc. v. Iqtel，Inc.，124 F.3d 1366（第十巡回法院1997年）；Bateman v. Mnemonics，Inc.，79 F.3d 1532（第十一巡回法院1996年）；以及Mitek Holdings，Inc. v. Arce Engineering Co.，Inc.，89 F.3d 1548（第十一巡回法院1996年）。

Under the AFC test, a court first abstracts from the original program its constituent structural parts. Then, the court filters from those structural parts all unprotectable portions, including incorporated ideas, expression that is necessarily incidental to those ideas, and elements that are taken from the public domain. Finally, the court compares any and all remaining kernels of creative expression to the structure of the second program to determine whether the software programs at issue are substantially similar so as to warrant a finding that one is the derivative work of the other.

在AFC测试中，法院首先从原始程序中抽象出其组成结构部分。然后，法院从这些结构部分中筛选出所有不可保护的部分，包括融入的想法、与这些想法必然有关的表达和从公共领域中获取的元素。最后，法院比较任何和所有剩余的创造性表达核心与第二个程序的结构，以确定所涉及的软件程序是否存在实质相似，从而认定其中一个是另一个的派生作品。

Often, the courts that apply the AFC test will perform a quick initial comparison between the entirety of the two programs at issue in order to help determine whether one is a derivative work of the other. Such a holistic comparison, although not a substitute for the full application of the AFC test, sometimes reveals a pattern of copying that is not otherwise obvious from the application of the AFC test when, as discussed below, only certain components of the original program are compared to the second program. If such a pattern is revealed by the quick initial comparison, the court is more likely to conclude that the second work is indeed a derivative of the original.

通常，应用AFC测试的法院将对所涉及的两个程序的整体进行快速的初步比较，以帮助确定其中一个是否是另一个的派生作品。虽然这种整体比较并不能代替对AFC测试的全面应用，但有时它可以显示出从原始程序的某些组件与第二个程序进行比较时并不明显的复制模式。如果快速的初步比较揭示了这样的模式，法院更有可能得出结论，即第二个作品确实是原作的派生作品。

4.2.1 Abstraction​

4.2.１ 抽象化​

The first step courts perform under the AFC test is separation of the work's ideas from its expression. In a process akin to reverse engineering, the courts dissect the original program to isolate each level of abstraction contained within it. Courts have stated that the abstractions step is particularly well suited for computer programs because it breaks down software in a way that mirrors the way it is typically created. However, the courts have also indicated that this step of the AFC test requires substantial guidance from experts, because it is extremely fact and situation specific.

根据 AFC 测试，法院执行的第一步是将作品的想法与表达方式分开。类似于反向工程的过程，法院解剖原始程序以隔离其中包含的每个抽象级别。法院表示，由于它以与软件通常创建方式相似的方式将软件分解，因此抽象化步骤特别适用于计算机程序。然而，法院还指出，AFC 测试的这一步骤需要专家的大量指导，因为它具有极其事实和情况的特定性。

By way of example, one set of abstraction levels is, in descending order of generality, as follows: the main purpose, system architecture, abstract data types, algorithms and data structures, source code, and object code. As this set of abstraction levels shows, during the abstraction step of the AFC test, the literal elements of the computer program, namely the source and object code, are defined as particular levels of abstraction. Further, the source and object code elements of a program are not the only elements capable of forming the basis for a finding that a second work is a derivative of the program. In some cases, in order to avoid a lengthy factual inquiry by the court, the owner of the copyright in the original work will submit its own list of what it believes to be the protected elements of the original program. In those situations, the court will forgo performing its own abstraction, and proceed to the second step of the AFC test.

例如，一个抽象级别集合按照从一般到具体的顺序如下：主要目的、系统架构、抽象数据类型、算法和数据结构、源代码和目标代码。正如这组抽象级别所示，在 AFC 测试的抽象化步骤中，计算机程序的字面元素，即源代码和目标代码，被定义为特定的抽象级别。此外，程序的源代码和目标代码元素并不是形成发现第二个作品是原始程序的衍生作品的唯一元素。在某些情况下，为了避免法院进行冗长的事实调查，原始作品的版权所有人将提交其自己的保护元素列表。在这种情况下，法院将放弃执行自己的抽象化，直接进行 AFC 测试的第二步骤。

4.2.2 Filtration​

4.2.2 过滤​

The most difficult and controversial part of the AFC test is the second step, which entails the filtration of protectable expression contained in the original program from any unprotectable elements nestled therein. In determining which elements of a program are unprotectable, courts employ a myriad of rules and procedures to sift from a program all the portions that are not eligible for copyright protection.

AFC测试中最具争议和难度的部分是第二步，涉及从原始程序中筛选出包含保护性表达的部分，并从中滤除任何非保护性的元素。在确定程序中哪些元素是不受保护的时，法院采用各种规则和程序来筛选出所有不符合版权保护资格的部分。

First, as set forth in 102(b) of the Copyright Act, any and all ideas embodied in the program are to be denied copyright protection. However, implementing this rule is not as easy as it first appears. The courts readily recognize the intrinsic difficulty in distinguishing between ideas and expression and that, given the varying nature of computer programs, doing so will be done on an ad hoc basis. The first step of the AFC test, the abstraction, exists precisely to assist in this endeavor by helping the court separate out all the individual elements of the program so that they can be independently analyzed for their expressive nature. A second rule applied by the courts in performing the filtration step of the AFC test is the doctrine of merger, which denies copyright protection to expression necessarily incidental to the idea being expressed. The reasoning behind this doctrine is that when there is only one way to express an idea, the idea and the expression merge, meaning that the expression cannot receive copyright protection due to the bar on copyright protection extending to ideas. In applying this doctrine, a court will ask whether the program's use of particular code or structure is necessary for the efficient implementation of a certain function or process. If so, then that particular code or structure is not protected by copyright and, as a result, it is filtered away from the remaining protectable expression.

首先，根据版权法第102（b）条款，程序中包含的所有想法都将被否认版权保护。然而，执行此规则并不像它最初看起来那么容易。法院充分认识到区分思想和表达之间的内在困难，鉴于计算机程序的多样性，这样做将是一个临时性的基础。 AFC测试的第一步——抽象，恰恰是为了帮助法院将程序的所有单独元素分离出来，以便可以独立地分析它们的表现性质。法院在执行AFC测试的过程中应用的第二个规则是合并原则，该原则否认与表达所表达的思想必然相关的表达的版权保护。这个原则的理由是，当只有一种表达思想的方式时，思想和表达合并，意味着由于版权保护不扩展到思想，表达不能获得版权保护。在应用这个原则时，法院将询问程序是否使用特定的代码或结构对某个功能或流程的高效实现是必需的。如果是，那么该特定代码或结构不受版权保护，因此从其余可保护表达式中过滤掉。

A third rule applied by the courts in performing the filtration step of the AFC test is the doctrine of scenes a faire, which denies copyright protection to elements of a computer program that are dictated by external factors. Such external factors can include:

法院在执行AFC测试的筛选步骤中应用的第三个规则是通用场景原则，该原则否认由外部因素决定的计算机程序的元素的版权保护。这些外部因素可以包括：

• The mechanical specifications of the computer on which a particular program is intended to operate

• Compatibility requirements of other programs with which a program is designed to operate in conjunc- tion

• Computer manufacturers' design standards

• Demands of the industry being serviced, and widely accepted programming practices within the computer industry

• 特定程序的计算机的机械规格

• 与设计为一起运行的其他程序的兼容性要求

• 计算机制造商的设计标准

• 所服务的行业的需求以及计算机行业内广泛接受的编程实践

Any code or structure of a program that was shaped predominantly in response to these factors is filtered out and not protected by copyright. Lastly, elements of a computer program are also to be filtered out if they were taken from the public domain or fail to have sufficient originality to merit copyright protection.

如果程序的任何代码或结构主要是针对这些因素而形成的，则会被过滤掉，并且不受版权保护。最后，如果计算机程序的元素来自公共领域或缺乏足够的原创性，也应该被过滤掉。

Portions of the source or object code of a computer program are rarely filtered out as unprotectable elements. However, some distinct parts of source and object code have been found unprotectable. For example, constants, the invariable integers comprising part of formulas used to perform calculations in a program, are unprotectable. Further, although common errors found in two programs can provide strong evidence of copying, they are not afforded any copyright protection over and above the protection given to the expression containing them.

计算机程序的源代码或目标代码的部分很少被过滤为不可保护元素。然而，有些源代码和目标代码的独特部分被发现是不可保护的。例如，常量，即组成程序中用于执行计算的公式的不变整数，是不可保护的。此外，虽然在两个程序中发现的常见错误可以提供复制的强有力证据，但它们不享有任何超出包含它们的表达所享有的版权保护。

4.2.3 Comparison​

4.2.3 比较​

The third and final step of the AFC test entails a comparison of the original program's remaining protectable expression to a second program. The issue will be whether any of the protected expression is copied in the second program and, if so, what relative importance the copied portion has with respect to the original program overall. The ultimate inquiry is whether there is "substantial" similarity between the protected elements of the original program and the potentially derivative work. The courts admit that this process is primarily qualitative rather than quantitative and is performed on a case-by-case basis. In essence, the comparison is an ad hoc determination of whether the protectable elements of the original program that are contained in the second work are significant or important parts of the original program. If so, then the second work is a derivative work of the first. If, however, the amount of protectable elements copied in the second work are so small as to be de minimis, then the second work is not a derivative work of the original.

AFC测试的第三个也是最后一个步骤是将原始程序剩余的可保护表达式与第二个程序进行比较。问题在于第二个程序中是否复制了任何受保护的表达式，如果有，复制部分在整个原始程序中的相对重要性是什么。最终的问题是原始程序的受保护元素与潜在的衍生作品之间是否存在“实质性”相似性。法院承认这个过程主要是定性而非定量的，是根据具体情况进行的。实质上，比较是一种临时决定，用于确定第二个作品中包含的原始程序可保护元素是否是原始程序的重要组成部分。如果是，那么第二个作品就是第一个作品的衍生作品。然而，如果第二个作品中复制的可保护元素数量非常少，以至于可以视为微不足道，则第二个作品不是原始作品的衍生作品。

4.3 Analytic Dissection Test​

4.3 分析解剖测试​

The Ninth Circuit has adopted the analytic dissection test to determine whether one program is a derivative work of another. Apple Computer, Inc. v. Microsoft Corp., 35 F.3d 1435 (9th Cir. 1994). The analytic dissection test first considers whether there are substantial similarities in both the ideas and expressions of the two works at issue. Once the similar features are identified, analytic dissection is used to determine whether any of those similar features are protected by copyright. This step is the same as the filtration step in the AFC test. After identifying the copyrightable similar features of the works, the court then decides whether those features are entitled to "broad" or "thin" protection. "Thin" protection is given to non-copyrightable facts or ideas that are combined in a way that affords copyright protection only from their alignment and presentation, while "broad" protection is given to copyrightable expression itself. Depending on the degree of protection afforded, the court then sets the appropriate standard for a subjective comparison of the works to determine whether, as a whole, they are sufficiently similar to support a finding that one is a derivative work of the other. "Thin" protection requires the second work be virtually identical in order to be held a derivative work of an original, while "broad" protection requires only a "substantial similarity."

第九巡回上诉法院采用了分析解剖测试来确定一个程序是否是另一个程序的衍生作品。《苹果电脑公司诉微软公司》（Apple Computer, Inc. v. Microsoft Corp.）, 35 F.3d 1435 (9th Cir. 1994)。分析解剖测试首先考虑两个作品的观点和表达是否存在实质性的相似之处。一旦发现相似之处，就使用分析解剖来确定是否有任何受版权保护的相似之处。这一步与AFC测试中的过滤步骤相同。在确定了两个作品中受版权保护的相似之处后，法院将决定这些特征是否有“广泛”的或“薄弱”的保护。对于非版权保护的事实或观点，如果它们只是通过组合而获得版权保护，则只有其结构和表达方式才受到“薄弱”保护，而版权保护的表达方式本身则获得“广泛”保护。根据所享有的保护程度，法院随后确定了适当的标准来进行主观比较，以确定两个作品是否整体上足够相似，从而支持其中一个作品是另一个作品的衍生作品的结论。如果采用“薄弱”保护，第二个作品必须几乎完全相同才能被认为是原始作品的衍生作品；而如果采用“广泛”保护，则只需要存在“实质性相似性”。

4.4 No Protection for "Methods of Operation"​

4.4 “操作方法”不受保护​

The First Circuit has taken the position that the AFC test is inapplicable when the works in question relate to unprotectable elements set forth in 102(b). Their approach results in a much narrower definition of derivative work for software in comparison to other circuits. Specifically, the First Circuit holds that "method of operation," as used in 102(b) of the Copyright Act, refers to the means by which users operate computers. Lotus Development Corp. v. Borland Int'l., Inc., 49 F.3d 807 (1st Cir. 1995). In Lotus, the court held that a menu command hierarchy for a computer program was uncopyrightable because it did not merely explain and present the program's functional capabilities to the user, but also served as a method by which the program was operated and controlled. As a result, under the First Circuit's test, literal copying of a menu command hierarchy, or any other "method of operation," cannot form the basis for a determination that one work is a derivative of another. As a result, courts in the First Circuit that apply the AFC test do so only after applying a broad interpretation of 102(b) to filter out unprotected elements. E.g., Real View, LLC v. 20-20 Technologies, Inc., 683 F. Supp.2d 147, 154 (D. Mass. 2010).

第一巡回法院认为，当涉及到《版权法案》第102(b)条列出的不受保护元素时，AFC测试不适用于所讨论的作品。他们的方法相对于其他巡回法院的软件派生作品定义更为狭窄。具体来说，第一巡回法院认为，《版权法案》第102(b)条所使用的“操作方法”是指用户操作计算机的方式。在Lotus Development Corp. v. Borland Int'l., Inc.案中，法院认为，计算机程序的菜单命令层次结构是无法受版权保护的，因为它不仅仅是向用户解释和展示程序的功能能力，还作为控制程序操作的方法。因此，在第一巡回法院的测试中，菜单命令层次结构或其他“操作方法”的文字复制不能成为确定一部作品是否为另一部作品的派生作品的依据。因此，适用AFC测试的第一巡回法院在筛选出未受保护元素的广泛解释之后，才会适用该测试。例如，Real View, LLC v. 20-20 Technologies, Inc., 683 F. Supp.2d 147, 154 (D. Mass. 2010)案。

4.5 No Test Yet Adopted​

4.5 尚未采用测试​

Several circuits, most notably the Fourth and Seventh, have yet to declare their definition of derivative work and whether or not the AFC, Analytic Dissection, or some other test best fits their interpretation of copyright law. Therefore, uncertainty exists with respect to determining the extent to which a software program is a derivative work of another in those circuits. However, one may presume that they would give deference to the AFC test since it is by far the majority rule among those circuits that have a standard for defining a software derivative work.

几个巡回法院，尤其是第四和第七巡回法院，尚未宣布他们对派生作品的定义以及AFC测试、分析性解剖或其他测试是否最适合他们对版权法的解释。因此，在这些巡回法院中，仍然存在不确定性，无法确定软件程序在多大程度上是另一部作品的派生作品。然而，可以假定他们会尊重AFC测试，因为在那些已经有定义软件派生作品标准的巡回法院中，AFC测试明显占多数。

4.6 Cases Applying Software Derivative Work Analysis​

4.6 应用于软件衍生作品分析的案例​

In the preeminent case regarding the definition of a derivative work for software, Computer Associates v. Altai, the plaintiff alleged that its program, Adapter, which was used to handle the differences in operating system calls and services, was infringed by the defendant's competitive program, Oscar. About 30% of Oscar was literally the same code as that in Adapter. After the suit began, the defendant rewrote those portions of Oscar that contained Adapter code in order to produce a new version of Oscar that was functionally competitive with Adapter, without having any literal copies of its code. Feeling slighted still, the plaintiff alleged that even the second version of Oscar, despite having no literally copied code, also infringed its copyrights. In addressing that question, the Second Circuit promulgated the AFC test.

在关于软件衍生作品定义的权威案例Computer Associates v. Altai中，原告声称其用于处理操作系统调用和服务差异的程序Adapter被被告的竞争性程序Oscar侵犯了。 Oscar约30％的代码与Adapter的代码完全相同。诉讼开始后，被告重写了那些包含Adapter代码的Oscar部分，以产生一个新版本的Oscar，它在没有任何字面上的代码副本的情况下在功能上与Adapter竞争。尽管如此，原告声称，即使是Oscar的第二个版本，尽管没有任何文字上复制的代码，也侵犯了它的版权。在回答这个问题时，第二巡回法院颁布了AFC测试。

In abstracting the various levels of the program, the court noted a similarity between the two programs' parameter lists and macros. However, following the filtration step of the AFC test, only a handful of the lists and macros were protectable under copyright law because they were either in the public domain or required by functional demands on the program. With respect to the handful of parameter lists and macros that did qualify for copyright protection, after performing the comparison step of the AFC test, it was reasonable for the district court to conclude that they did not warrant a finding of infringement given their relatively minor contribution to the program as a whole. Likewise, the similarity between the organizational charts of the two programs was not substantial enough to support a finding of infringement because they were too simple and obvious to contain any original expression.

在抽象化程序的各个层面时，法院注意到两个程序的参数列表和宏之间的相似之处。然而，在AFC测试的过滤步骤之后，只有少数列表和宏受版权法保护，因为它们要么是公有领域的，要么是对程序的功能需求所必需的。对于少数符合版权保护的参数列表和宏，在执行AFC测试的比较步骤之后，地区法院认为它们并不值得被认定为侵犯，因为它们对整个程序的贡献相对较小。同样，两个程序组织图之间的相似之处也不足以支持侵权的发现，因为它们太简单和显而易见，不包含任何原创表达。

In the case of Oracle America v. Google, 872 F. Supp.2d 974 (N.D. Cal. 2012), the Northern District of California District Court examined the question of whether the application program interfaces (APIs) asso- ciated with the Java programming language are entitled to copyright protection. While the court expressly declined to rule whether all APIs are free to use without license (872 F. Supp.2d 974 at 1002), the court held that the command structure and taxonomy of the APIs were not protectable under copyright law. Specifi- cally, the court characterized the command structure and taxonomy as both a "method of operation" (using an approach not dissimilar to the First Circuit's analysis in Lotus) and a "functional requirement for com- patibility" (using Sega v. Accolade, 977 F.2d 1510 (9th Cir. 1992) and Sony Computer Ent. v. Connectix, 203 F.3d 596 (9th Cir. 2000) as analogies), and thus unprotectable subject matter under 102(b).

在Oracle America v. Google案中，北加利福尼亚地区法院审查了与Java编程语言相关的应用程序接口（API）是否享有版权保护的问题。虽然法院明确拒绝裁定所有API是否可在未获许可的情况下免费使用，但法院认为API的命令结构和分类法不受版权法保护。具体而言，法院将命令结构和分类法表述为“操作方法”（采用类似于Lotus中第一巡回法院分析的方法）和“兼容性的功能要求”（使用Sega v. Accolade，977 F.2d 1510（9th Cir. 1992）和Sony Computer Ent. v. Connectix，203 F.3d 596（9th Cir. 2000）作为类比），因此是根据102(b)不受保护的主题。

Perhaps not surprisingly, there have been few other cases involving a highly detailed software derivative work analysis. Most often, cases involve clearer basis for decision, including frequent bad faith on the part of the defendant or over-aggressiveness on the part of the plaintiff.

也许不令人意外的是，很少有其他案例涉及高度详细的软件衍生作品分析。大多数情况下，案例涉及更明显的决策基础，包括被告的频繁恶意行为或原告的过度侵权行为。

4.7 How Much Do Derivative Works Matter?​

4.7 派生作品有多重要？​

It is certainly true that GPL intends for any work that is determined a "derivative work" under copyright law must be licensed as a whole under GPL, as will be discussed in the following chapter. However, as we finish up our discussion derivative works, we must note that preparation of a derivative work is by far not the only way to create a new work covered by GPL.

毫无疑问，GPL旨在确保任何在版权法下被认定为“衍生作品”的作品必须作为整体在GPL下进行许可，这将在下一章中讨论。然而，当我们结束对衍生作品的讨论时，必须指出制作衍生作品远不是创建GPL覆盖的新作品的唯一方式。

In fact, while derivative work preparation is perhaps the most exciting area of legal issues to consider, the more mundane ways to create a new work covered by GPL are much more common. For example, copyright statutes generally require permission from the copyright holder to grant explicit permission to modify a work in any manner. As discussed in the next chapter, the GPL does grant such permission, but requires the modified work must also be licensed under the terms of the GPL (and only GPL: see*§* 7.3 in this tutorial). Determining whether software was modified is a substantially easier analysis than the derivative work discussions and considerations in this chapter.

事实上，尽管制作衍生作品可能是考虑法律问题最令人兴奋的领域，但通过更为平凡的方式创建GPL覆盖的新作品则更为常见。例如，版权法通常要求获得版权持有人的许可，以明确许可对作品进行任何方式的修改。如下一章所讨论的，GPL确实授予了这种许可，但要求修改后的作品也必须根据GPL的条款进行许可（而且只能是GPL：参见本教程中的§7.3）。确定软件是否被修改是一项相对容易的分析，与本章关于衍生作品的讨论和考虑相比要简单得多。

The question of derivative works, when and how they are made, is undoubtedly an essential discussion in the interpretation and consideration of copyleft. That is why this chapter was included in this tutorial. However, as we return from this digression and resume discussion of the detailed text of the GPLv2, we must gain a sense of perspective: most GPL questions center around questions of modification and distribution, not preparation of derivative works. Derivative work preparation is ultimately a small subset of the types of modified versions of the software a developer might create, thus, while an excessive focus on derivative works indulges us in the more exciting areas of copyleft, we must keep a sense of perspective regarding their relative importance.

衍生作品的问题、它们何时以及如何制作，无疑是在解释和考虑版权公用原则方面的必要讨论。这就是为什么本教程包含了这一章的原因。然而，当我们从这一跑题中回到对GPLv2详细文本的讨论并继续讨论时，我们必须有一个全局的认识：大多数GPL问题都集中在修改和分发问题上，而不是制作衍生作品。制作衍生作品最终只是开发人员可能创建的软件修改版本类型的一小部分，因此，虽然过分关注衍生作品能使我们沉浸在版权公用原则更激动人心的领域中，但我们必须保持相对重要性的观念。

CHAPTER 5 MODIFIED SOURCE AND BINARY DISTRIBUTION​

第5章 修改源代码和二进制分发​

In this chapter, we discuss the two core sections that define the rights and obligations for those who modify, improve, and/or redistribute GPL'd software. These sections, GPLv2 2--3, define the central core rights and requirements of GPLv2.

本章中，我们讨论了修改、改进和/或重新分发GPL软件的权利和义务的两个核心部分。这些部分，即GPLv2 2-3，定义了GPLv2的核心权利和要求。

5.1 GPLv2 §2: Share and Share Alike​

5.1 GPLv2 第2条：分享和分享相同​

For many, this is where the "magic" happens that defends software freedom upon redistribution. GPLv2 2 is the only place in GPLv2 that governs the modification controls of copyright law. If users distribute modified versions a GPLv2'd program, they must follow the terms of GPLv2 2 in making those changes. Thus, this sections ensures that the body of GPL'd software, as it continues and develops, remains Free as in freedom. To achieve that goal, GPLv2 2 first sets forth that the rights of redistribution of modified versions are the same as those for verbatim copying, as presented in GPLv2 1. Therefore, the details of charging money, keeping copyright notices intact, and other GPLv2 1 provisions are intact here as well. However, there are three additional requirements.

对于许多人来说，这就是“魔法”发生的地方，它在重新分发时保护了软件自由。GPLv2 2是在GPLv2中仅控制版权法修改控制的地方。如果用户分发了GPLv2'd程序的修改版本，他们必须遵循GPLv2 2的条款进行更改。因此，这些部分确保了GPL'd软件库随着其不断发展和发展，仍然保持自由。为了实现这个目标，GPLv2 2首先规定修改版本的重新分发权与逐字复制的重新分发权相同，就像GPLv2 1中所述的那样。因此，收费细节、版权声明完整性和其他GPLv2 1规定也在这里得到保留。但是，还有三个额外的要求。

5.1.1 The Simpler Parts of GPLv2 §2​

5.1.1 GPLv2第2条简单部分​

The first (GPLv2 2(a)) requires that modified files carry "prominent notices" explaining what changes were made and the date of such changes. This section does not prescribe some specific way of marking changes nor does it control the process of how changes are made. Primarily, GPLv2 2(a) seeks to ensure that those receiving modified versions know the history of changes to the software. For some users, it is important to know that they are using the standard version of program, because while there are many advantages to using a fork, there are a few disadvantages. Users should be informed about the historical context of the software version they use, so that they can make proper support choices. Finally, GPLv2 2(a) serves an academic purpose --- ensuring that future developers can use a diachronic approach to understand the software.

第一个（GPLv2 2（a））要求修改的文件要带有“重要通知”，解释了进行了哪些更改以及更改的日期。本节并未规定标记更改的某种特定方式，也不控制更改的过程。主要是为了确保接收修改版本的人知道软件的变更历史。对于某些用户，知道他们正在使用程序的标准版本很重要，因为虽然使用分支有很多优点，但也有一些缺点。用户应该了解他们使用的软件版本的历史背景，以便他们可以做出适当的支持选择。最后，GPLv2 2（a）具有学术目的 - 确保未来的开发人员可以使用历时的方法来理解软件。

GPLv2 2(c), a relatively simple section, requires that any program which (before modification) "normally reads commands interactively when run" and displays or prints legal information also display all copyright notices, warranty disclaimer, modification indications and a pointer to the license, even in modified versions. The requirement is relatively simple, and relates to an important policy goal of copyleft: downstream users should be informed of their rights. Its implications and details are straightforward and simple.

GPLv2 2（c）是一个相对简单的部分，要求在运行之前“通常会交互地读取命令”的任何程序，以及显示或打印法律信息的程序也必须在修改版本中显示所有版权声明、保证免责声明、修改指示和指向许可证的指针。这个要求相对简单，与copyleft的一个重要政策目标有关：下游用户应该知道他们的权利。它的影响和细节是简单明了的。

5.1.2 GPLv2 §2(b)​

5.1.2 GPLv2 2(b)​

Meanwhile, GPLv2 2(b) requires careful and extensive study. Its four short lines embody the some of the essential legal details of "share and share alike". These 46 words are considered by some to be the most worthy of careful scrutiny because they can be a source of great confusion when not properly understood. In considering GPLv2 2(b), first note the qualifier: it only applies to derivative, combined and/or modified works that "you distribute or publish". Despite years of education efforts on this matter, many still believe that modifiers of GPL'd software must publish or otherwise share their changes. On the contrary, GPLv2 2(b) does not apply if the changes are never distributed. Indeed, the freedom to make private, personal, unshared changes to software for personal use only should be protected and defended.¹¹

与此同时，GPLv2第2条(b)要求仔细而广泛的研究。它的四行简短文字包含了“共享及共享同类”的一些基本法律细节。这46个单词被一些人认为是最值得仔细审查的，因为当它们没有被正确理解时，它们可以成为极大的混淆源。在考虑GPLv2第2条(b)时，首先要注意限定语：它仅适用于您分发或发布的派生、组合和/或修改作品。尽管在这个问题上已经进行了多年的教育工作，但许多人仍然认为GPL'd软件的修改者必须发布或以其他方式分享他们的修改。相反，GPLv2第2条(b)不适用于从未分发的更改。事实上，应该保护和维护仅用于个人使用的私人、个人、未共享软件的更改的自由。¹¹

Next, we again encounter the same matter that appears in GPLv2 *§*0, in the following text:

接下来，我们再次遇到出现在GPLv2§0中的相同问题，如下所示：

"...that in whole or part contains or is derived from the Program or any part thereof."

"...包含或源自程序或其任何部分的全部或部分内容。"

Again, the GPL relies here on copyright law. If, under copyright law, the modified version "contains or is derived from" the GPL'd software, then the requirements of GPLv2 2(b) apply. The GPL invokes its control as a copyright license over the modification of the work in combination with its control over distribution of the work.

同样，GPL在这里依赖于版权法。如果根据版权法，修改版本“包含或源自”GPL的软件，则适用GPLv2第2条(b)的要求。GPL通过其对作品修改和分发的版权许可证的控制来调用其控制。

The final clause of GPLv2 2(b) describes what the licensee must do if she distributes or publishes a modified version of the work --- namely, the following:

The final clause of GPLv2 2(b) describes what the licensee must do if she distributes or publishes a modified version of the work --- namely, the following:

GPLv2第2条(b)的最后一条款描述了许可证持有人在分发或发布作品的修改版本时必须执行的操作，即以下内容：

[The work must] be licensed as a whole at no charge to all third parties under the terms of this License.

作品必须作为一个整体在本许可证的条款下免费授权给所有第三方使用。

That is probably the most tightly-packed phrase in all of the GPL. Consider each subpart carefully.

这可能是GPL中最密集的短语。仔细考虑每个子部分。

The work "as a whole" is what is to be licensed. This is an important point that GPLv2 2 spends an entire paragraph explaining; thus this phrase is worthy of a lengthy discussion here. As a programmer modifies a software program, she generates new copyrighted material --- fixing expressions of ideas into the tangible medium of electronic file storage. That programmer is indeed the copyright holder of those new changes. However, those changes are part and parcel to the original work distributed to the programmer under GPL. Thus, the license of the original work affects the license of the new whole combined and/or derivative work.

"作为一个整体"的作品是需要被授权的。这是GPLv2 2节用整个段落解释的一个重要观点，因此这个短语在这里值得进行详细的讨论。当程序员修改一个软件程序时，她产生了新的版权材料——将思想的表达形式固定到电子文件存储的有形媒介中。那个程序员确实是这些新变化的版权持有人。然而，这些变化是与GPL下分发给程序员的原始作品紧密相关的。因此，原始作品的许可证影响新整个组合和/或派生作品的许可证。

It is certainly possible to take an existing independent work (called) and combine it with a GPL'd program (called ). The license of , when it is distributed as a separate and independent work, remains the prerogative of the copyright holder of . However, when is combined with , it produces a new work that is the combination of the two (called + ). The copyright of this combined work, + , is held by the original copyright holder of each of the two works.

当一个独立的作品（称为 ）与GPL的程序（称为 ）结合时，很可能出现的情况是：当 作为一个单独和独立的作品分发时，其许可证仍然是版权持有人的专属权利。然而，当与 一起组合时，它们产生了一个新的作品（称为 ），它是两个作品的组合。新作品 + 的版权由两个作品的原始版权持有人持有。

In this case, GPLv2 2 lays out the terms by which + may be distributed and copied. By default, under copyright law, the copyright holder of would not have been permitted to distribute + ; copyright law forbids it without the expressed permission of the copyright holder of . (Imagine, for a moment, if were a proprietary product --- would its copyright holders give you permission to create and distribute + without paying them a hefty sum?) The license of , the GPL, states the options for the copyright holder of who may want to create and distribute + . The GPL's pre-granted permission to create and distribute combined and/or derivative works, provided the terms of the GPL are upheld, goes far above and beyond the permissions that one would get with a typical work not covered by a copyleft license. Thus, to say that this condition is any way unreasonable is simply ludicrous.

在这种情况下，GPLv2 §2详细说明了可以分发和复制+的条款。根据版权法，默认情况下，不允许拥有者在未经许可的情况下分发+；版权法禁止这样做。 （想象一下，如果是一个专有产品，其版权持有者会允许您创建和分发+而不支付他们巨额费用吗？）GPL，即版权协议，规定了可能希望创建和分发+的版权所有者的选项。在遵守GPL条款的情况下，预先授予创建和分发组合和/或派生作品的权限远远超出了未受到版权通用许可证保护的作品所能获得的许可权限。因此，认为这个条件在任何方面都是不合理的纯属荒谬。

The GPL recognizes what is outside its scope. When a programmer's work is "separate and independent" from any GPL'd program code with which it could be combined, then the obligations of copyleft do not extend to the work separately distributed. Thus, Far from attempting to extend copyleft beyond the scope of copyright, the licenses explicitly recognize.

GPL认识到超出其范围的事情。当程序员的工作与任何可以与之结合的GPL程序代码“独立且独立”时，版权义务不适用于单独分发的工作。因此，远非试图将通用许可证超出版权范围，这些许可证明确承认了超出其范围的事情。

Thus, GPL recognizes what is outside its scope. When a programmer's work is "separate and inde- pendent" from any GPL'd program code with which it could be combined, then copyleft obligations do not extend to the independent work separately distributed. Thus, far from attempting to extend copyleft beyond the scope of copyright, GPL explicitly limits the scope of copyleft to the scope of copyright.

因此，GPL认识到超出其范围的事情。当程序员的工作与任何可以与之结合的GPL程序代码“独立且独立”时，版权义务不适用于单独分发的工作。因此，远非试图将通用许可证超出版权范围，这些许可证明确限制了通用许可证的范围，以符合版权的范围。

GPL does not, however (as is sometimes suggested) distinguish "dynamic" from "static" linking of pro- gram code. It is occasionally suggested that a subroutine "dynamically" linked to GPL'd code is, by virtue of the linking alone, inherently outside the scope of copyleft on the main work. This is a misunderstanding. When two software components are joined together to make one work (whether a main and some library subroutines, two objects with their respective methods, or a program and a "plugin") the combination infringes the copyright on the components if the combination required copyright permission from the com- ponent copyright holders, as such permission was either not available or was available on terms that were not observed.

GPL并不区分程序代码的“动态”链接和“静态”链接，尽管有时会有这种说法。有时会建议将一个“动态”链接到GPL代码的子例程视为单独存在于版权保护范畴之外，仅仅由于链接本身。这是一种误解。当两个软件组件被连接在一起形成一个整体（无论是主要程序和一些库子例程、两个具有各自方法的对象还是程序和“插件”）时，如果组合需要从组件版权持有人获得版权许可，而此类许可证要么不可用，要么是在未遵守条款的情况下可用，那么该组合就会侵犯这些组件的版权。

In other words, when combining other software with GPL'd components, the only available permission is GPL. The combiner must observe and respect the GPL observed on the combination as a whole. It matters not if that combination is made with a linker before distribution of the executable, is made by the operating system in order to share libraries for execution efficiency at runtime, or results from runtime references in the language at runtime (as in Java programs).

换句话说，当将其他软件与GPL组件结合使用时，唯一可用的许可是GPL。组合者必须尊重并遵守GPL作为整体所遵守的规定。无论这种组合是在链接器在可执行文件分发之前进行的，还是由操作系统在运行时为了共享库而进行的，或者是由语言在运行时的运行时引用所导致的（如Java程序）。

The next phrase of note in GPLv2 2(b) is "licensed . . . at no charge." This phrase confuses many. The sloppy reader points out this as "a contradiction in GPL" because (in their confused view) that clause of GPLv2 2 says that re-distributors cannot charge for modified versions of GPL'd software, but GPLv2 1 says that they can. Avoid this confusion: the "at no charge" does not prohibit re-distributors from charging when performing the acts governed by copyright law,¹² but rather that they cannot charge a fee for the license itself. In other words, redistributors of (modified and unmodified) GPL'd works may charge any amount they choose for performing the modifications on contract or the act of transferring the copy to the customer, but they may not charge a separate licensing fee for the software.

GPLv2 2(b)中需要注意的下一句话是“免费授权”。这句话让很多人感到困惑。粗心的读者会指出这是“GPL中的矛盾”，因为（在他们混淆的观点中）GPLv2 2中的这一条款说，重新发布者不能为GPL软件的修改版本收费，而GPLv2 1却说他们可以。避免这种混淆： “免费”不是禁止重新发布者在执行受版权法约束的行为时收费，¹² 而是他们不能为软件本身收取单独的许可费用。换句话说，（修改和未修改的）GPL作品的重新发布者可以为执行合同上的修改或向客户传递副本的行为收取任意金额，但他们不能为软件收取单独的许可费。

GPLv2 2(b) further states that the software must "be licensed . . . to all third parties." This too yields some confusion, and feeds the misconception mentioned earlier --- that all modified versions must be made available to the public at large. However, the text here does not say that. Instead, it says that the licensing under terms of the GPL must extend to anyone who might, through the distribution chain, receive a copy of the software. Distribution to all third parties is not mandated here, but GPLv2 2(b) does require re- distributors to license the whole work in a way that extends to all third parties who may ultimately receive a copy of the software.

GPLv2 2(b)进一步规定软件必须“授权……给所有第三方使用。”这也导致了一些困惑，并滋生了前面提到的误解，即所有修改版本都必须向公众公开。然而，这里的文字并没有说到这一点。相反，它说授权必须延伸到通过分发渠道可能获得软件副本的任何人。这里并没有强制要求向所有第三方分发，但GPLv2 2(b)要求再分发者以一种方式授权整个作品，使其适用于最终可能接收到软件副本的所有第三方。

In summary, GPLv2 2(b) says what terms under which the third parties must receive this no-charge license. Namely, they receive it "under the terms of this License", the GPLv2. When an entity chooses to redistribute a work based on GPL'd software, the license of that whole work must be GPL and only GPL. In this manner, GPLv2 *§*2(b) dovetails nicely with GPLv2 *§*6 (as discussed in Section 7.3 of this tutorial).

总之，GPLv2 2(b)规定了第三方必须获得此无费许可证的条款。换句话说，他们获得的是“本许可证”的条款，即GPLv2。当一个实体选择基于GPL软件再分发作品时，整个作品的许可证必须是GPL，只能是GPL。通过这种方式，GPLv2 2(b)与GPLv2 第6条（如本教程的7.3部分所讨论的）紧密结合。

The final paragraph of GPLv2 2 is worth special mention. It is possible and quite common to aggregate various software programs together on one distribution medium. Computer manufacturers do this when they ship a pre-installed hard drive, and GNU/Linux distribution vendors do this to give a one-stop CD or URL for a complete operating system with necessary applications. The GPL very clearly permits such "mere aggregation" with programs under any license. Despite what you hear from its critics, the GPL is nothing like a virus, not only because the GPL is good for you and a virus is bad for you, but also because simple contact with a GPL'd code-base does not impact the license of other programs. A programmer must expend actual effort to cause a work to fall under the terms of the GPL. Redistributors are always welcome to simply ship GPL'd software alongside proprietary software or other unrelated Free Software, as long as the terms of GPL are adhered to for those packages that are truly GPL'd.

GPLv2第2节的最后一段值得特别提及。在一个分发介质上聚合各种软件程序是可能且很常见的。计算机制造商在出货时这样做，GNU/Linux发行商则提供一站式CD或URL以获取具有必要应用程序的完整操作系统。GPL非常明确地允许这种“纯聚合”与任何许可证下的程序一起使用。尽管你从批评者那里听到的不是这样，GPL与病毒完全不同，不仅因为GPL对你有益而病毒对你有害，而且因为与GPL的代码库的简单接触不会影响其他程序的许可证。程序员必须实际努力才能使一个作品适用于GPL的条款。再分发者总是欢迎将GPL软件与专有软件或其他无关的自由软件一起分发，只要真正使用GPL的软件包的条款遵守GPL即可。

5.1.3 Right to Private Modification​

5.1.3 私有修改权​

The issue of private modifications of GPLv2'd works deserves special attention. While these rights are clearly explicit in GPLv3 2 2 (see 9.4 of this tutorial for details), the permission to create private modifications is mostly implicit in GPLv2. Most notably, the requirements of GPLv2 2 (and GPLv2 3, which will be discussed next) are centered around two different copyright controls: both modification and distribution. As such, GPLv2 2's requirements need only be met when a modified version is distributed; one need not follow them for modified versions that are not distributed.¹³

对于 GPLv2 的作品进行私有修改的问题需要特别注意。虽然 GPLv3 2 2 中明确列出了这些权利（有关详情请参见本教程的 9.4 部分），但是在 GPLv2 中，创造私有修改的许可大多是暗含的。特别是，GPLv2 2（和将在下一节讨论的 GPLv2 3）的要求围绕两个不同的版权控制展开：修改和分发。因此，只有在分发修改版本时才需要遵守 GPLv2 2 的要求；对于未分发的修改版本，不需要遵守这些要求。¹³

However, the careful reader of GPLv2 will notice that, unlike GPLv3, no other clauses of the license actually give explicit permission to make private modifications. Since modification of software is a control governed by copyright, a modifier needs permission from the copyright holder to engage in that activity.

然而，仔细阅读 GPLv2 的读者会注意到，与 GPLv3 不同，许可证的其他条款实际上没有明确允许进行私有修改的许可。由于软件修改是受版权控制的控制，因此修改者需要获得版权持有人的许可才能从事这项活动。

In practice, however, traditional GPLv2 interpretation has always assumed that blanket permission to create non-distributed modified versions was available, and the FSF has long opined that distribution of modified versions is never mandatory. This issue is one of many where GPLv3 clarifies in explicit text the implicit policy and intent that was solidified via long-standing interpretation of GPLv2.

然而，在实践中，传统的 GPLv2 解释一直假定拥有创造非分发修改版本的全面许可，而FSF 长期以来一直认为分发修改版本从来不是强制性的。这个问题是 GPLv3 明确文本阐明了长期解释 GPLv2 所确定的隐含政策和意图的众多问题之一。

5.2 GPLv2 §3: Producing Binaries​

5.2 GPLv2 第3条：生成二进制文件​

Software is a strange beast when compared to other copyrightable works. It is currently impossible to make a film or a book that can be truly obscured. Ultimately, the full text of a novel, even one written by William Faulkner, must be presented to the reader as words in some human-readable language so that they can enjoy the work. A film, even one directed by David Lynch, must be perceptible by human eyes and ears to have any value.

与其他可版权作品相比，软件是一种奇特的生物。目前还没有一种能真正被隐藏的电影或书籍。即使是威廉·福克纳写的小说全文也必须以某种人类可读的语言形式呈现给读者，以便他们能够享受这部作品。一部由大卫·林奇执导的电影也必须可被人类的眼睛和耳朵感知才有任何价值。

Software is not so. While the source code --- the human-readable representation of software --- is of keen interest to programmers, users and programmers alike cannot make the proper use of software in that human-readable form. Binary code --- the ones and zeros that the computer can understand --- must be predicable and attainable for the software to be fully useful. Without the binaries, be they in object or executable form, the software serves only the didactic purposes of computer science.

软件不同。尽管源代码是软件的人类可读表现形式，对程序员来说是非常重要的，但用户和程序员不能以这种人类可读的形式正确地使用软件。二进制代码，即计算机能够理解的一和零，必须是可预测且可获得的，才能充分发挥软件的作用。如果没有二进制文件，无论是目标文件还是可执行文件，该软件只能用于计算机科学的教学目的。

Under copyright law, binary representations of the software are simply modified versions (and/or deriva- tive works) of the source code. Applying a systematic process (i.e., "compilation"¹⁴) to a work of source code yields binary code. The binary code is now a new work of expression fixed in the tangible medium of electronic file storage.

根据版权法，软件的二进制表示只是源代码的修改版本（和/或派生作品）。将源代码作品应用一种系统的过程（即“编译”¹⁴）会产生二进制代码。现在，二进制代码是以电子文件存储为载体的新的表达形式。

Therefore, for GPL'd software to be useful, the GPL, since it governs the rules for creation of modified works, must grant permission for the generation of binaries. Furthermore, notwithstanding the relative popularity of source-based GNU/Linux distributions like Gentoo, users find it extremely convenient to receive distribution of binary software. Such distribution is the redistribution of modified works of the software's source code. GPLv2 3 addresses the matter of creation and distribution of binary versions.

因此，为了让GPL的软件有用，GPL必须授予生成二进制文件的许可，因为它管理修改作品的规则。此外，尽管基于源代码的GNU/Linux发行版（如Gentoo）相对受欢迎，用户发现接收二进制软件的分发非常方便。这种分发是软件源代码的修改作品的再分发。GPLv2 3解决了创建和分发二进制版本的问题。

Under GPLv2 3, binary versions may be created and distributed under the terms of GPLv2 1--2, so all the material previously discussed applies here. However, GPLv2 3 must go a bit further. Access to the software's source code is an incontestable prerequisite for the exercise of the fundamental freedoms to modify and improve the software. Making even the most trivial changes to a software program at the binary level is effectively impossible. GPLv2 3 must ensure that the binaries are never distributed without the source code, so that these freedoms are passed through the distribution chain.

根据GPLv2 3，可以在GPLv2 1-2的条款下创建和分发二进制版本，因此之前讨论的所有材料在这里都适用。但是，GPLv2 3必须更进一步。访问软件源代码是行使修改和改进软件的基本自由的必要条件。在二进制层面上进行最微小的更改实际上是不可能的。GPLv2 3必须确保二进制文件没有在未提供源代码的情况下进行分发，以便这些自由通过分发链传递。

GPLv2 3 permits distribution of binaries, and then offers three options for distribution of source code along with binaries. The most common and the least complicated is the option given under GPLv2 3(a).

GPLv2 3允许分发二进制文件，然后提供了三种选项，以便将源代码与二进制文件一起分发。最常见且最简单的选项是GPLv2 3(a)提供的选项。

GPLv2 3(a) offers the option to directly accompany the source code alongside the distribution of the binaries. This is by far the most convenient option for most distributors, because it means that the source- code provision obligations are fully completed at the time of binary distribution (more on that later).

GPLv2第3条(a)提供了在二进制文件分发的同时直接附带源代码的选择。这对于大多数分发者来说是最方便的选择，因为它意味着在二进制分发时完全完成了源代码提供义务（稍后将更详细地说明）。

5.2.1 Complete, Corresponding Source (CCS)​

5.2.1 完整、对应的源代码（CCS）​

Under GPLv2 3(a), the source code provided must be the "corresponding source code." Here "correspond- ing" primarily means that the source code provided must be that code used to produce the binaries being distributed. That source code must also be "complete". GPLv2 3's penultimate paragraph explains in de- tail what is meant by "complete". In essence, it is all the material that a programmer of average skill would need to actually use the source code to produce the binaries she has received. Complete source is required so that, if the licensee chooses, she should be able to exercise her freedoms to modify and redistribute changes. Without the complete source, it would not be possible to make changes that were actually directly derived from the version received.

在GPLv2 3(a)下，提供的源代码必须是“对应的源代码”。在这里，“对应的”主要意味着提供的源代码必须是用于生成所分发的二进制文件的代码。该源代码还必须是“完整的”。GPLv2 3的倒数第二段详细解释了“完整”的含义。实质上，它是程序员需要实际使用源代码来生成收到的二进制文件所需的所有材料。需要完整的源代码，以便许可证持有人选择时，可以行使修改和重新分发更改的自由。如果没有完整的源代码，就不可能制作实际上是直接源自所收到版本的更改。

Based on the appearance of those two words, GPL theorists will often refer to the source code required under the previsions of this section as "Complete, Corresponding Source", sometimes abbreviated as CCS. CCS is not a formal, defined term in GPLv2, but rather, GPL theorists coined the acronym CCS to embody not just the concepts of "complete" and "corresponding" as found in GPLv2, but the entirety of GPLv2's requirements for source code provisioning. In other words, GPL theorists might say: "the company provided some source, but it wasn't CCS", which would mean the source code failed in some ways to meet some term of GPLv2.